[Opendnssec-user] OpenDNSSEC, signing in two locations

[Rick van Rein]

Hi Sebastian,

I suppose we'll discuss your PID issue next week; on the one hand there
is a wish to be more synchronous, on the other hand it is a nuisance
if exactly that turns out to be a problem.  It's not black-and-white,
is what I am saying (which is why a local patch, or a distro-specific
approach as under Debian, is probably the best).

> Some time ago I started a thread in a DNSSEC mailing list asking about
> signing a zone in two different locations, and which considerations I
> should take[1].

Interesting.  Have you seen our blog on a similar setup?

https://dnssec.surfnet.nl/

Specifically, the graphical architecture image:

https://dnssec.surfnet.nl/?p=47

> My intention was to create identical signed zone in
> different locations.

You want to sign in 2 locations, obviously using the same key material!
That sounds daring...  we setup a master with a hot spare and make a
manual decision to switch on the alternate signer.

> Currently OpenDNSSEC can't do that because the inception date depends on
> the time the data is being signed, and the expiration date depends on a
> random jitter. So, to ensure the signatures have equal
> inception/expiration, you need to remove the time/randomness dependencies.

They're there for a good reason, namely to scatter the moments that the
various domains are signed.  However, you could have a deterministic
series generator of some sort, and achieve the desired effect.  It does
sound like an awful amount of synchronisation between the signers, thus
complicating matters when your service goes down.

> I've worked in the following solution using version 1.1.0
> 
> - inception doesn't depend on the current time, but in the current hour.
> That criteria can be changed to round the time to certain unit of time.

You probably also take the domain name into account to scatter the
timing among domains, right?  That's what it is all about.  As a matter
of fact, there's nothing wrong with having a fixed timing variation that
only depends on the domain name, not the hour.  It needn't even be done
through a secure hash or anything, but a simple CRC might do the trick.

An interesting angle, and as far as I can tell not damaging in any way.

> - expiration still uses a jitter, but is not a uniformly distributed
> random variable, but a step function that takes as input the RRset label
> and returns a value between [0, 2*JITTER]. By using this, you make the
> jitter to depend on the label. Initially I tested using the relative
> number of the RRset within the zone, but if you provide zones with equal
> content but different order, the signatures won't be the same.

I think you are saying what I said above?  Or are you still taking
any clocktime into account?

> Recently I updated to 1.1.2 and previous patch were not usable directly,
> so I rewrote and tested.

Thanks.

> The distribution of the signature expiration date is still good, but not
> perfect. That depends on the quality of the hash function used to
> calculate the jitter. I'm attaching a graph with expiration distribution
> of my test zone.

I suppose all you want is a more deterministic distribution function.

> CAVEATS:
> - the signing process has to start in the same hour.

Not if you ignore time in your jittergen.

> - the current jitter generation behavior is hard-coded, including the
> unit of time used to round down the inception time. It seems reasonable,
> if the feature is approved, to make changes to the kasp.xml to signal
> which mechanism use to generate jitter.

Indeed.  Even though the idea of OpenDNSSEC is a clear push-button, there
is a strong tendency to give control over that button in the configfiles.

> I hoping to generate some discussion about the correctness of the
> solution. The corresponding patches are attached.

Thanks, good thinking.  It's close to ours, but we lacked the courage (or need)
to have two signers perform exactly yhe same.


Best wishes,

Rick van Rein