[Opendnssec-develop] Questions unanswered

[Rick van Rein]

Hello,

> > Question 1 is based on the assumption that the Signer Engine is
> > responsible for re-signing. It is actually not a real question, but a
> > remark: The Signer Engine determines the inception and expiration times
> > on signatures given the refresh interval value it retrieved from KASP,
> > right?
> 
> That's my understanding; KASP is just a database with logic that will 
> allow it to list the keys that should be included in the zone (and which 
> key should be used to sign it) at any given time.

I think it makes sense to isolate cryptograpghic knowledge in KASP and
DNS knowledge in the Signer Engine.  It also happens to match the way
the knowledge is distributed over groups, which means less interfaces
to interact about.

> > Question 2: What's the difference between zone resigning interval and
> > signature
> > refresh interval? Imho, they are the same, but described differently.
> 
> That sounds right, but I'm not sure - can anyone else comment?

I can imagine zones being resigned before signatures require refreshing,
for reasons of zone transfer timing, signature validation timing, and
such.  Perhaps cache storing times also play a part.

Not sure where you found these terms, but this is how I read them.

> > Question 4: What is meant with signature jitter and clockskew? Does this
> > affect
> > the zone content? If so, in what way?
> 
> As I understand it, signature jitter is a means by which the lifetime of 
> signatures in a zone is varied around some mean so that you don't get all 
> signatures expiring at the same time.  Over a period of time, they should 
> end up expiring at a continuous rate.  This even out the load on a system 
> where you are doing continuous signing.

Ah, that's different from what I assumed with these terms.  I only know
jitter as undesirable timing variations, not desired ones.  Aside from the
fact that what you are describing is good, this is what I read in the
terms:

Distributed systems each do their own timekeeping -- and not always very
accurately.  As a matter of fact, Einstein taught us that there is no
concept of distributed same-time occurrences.  NTP is fighting hard to
pin down Einstein's reasonings to the smallest possible differences in
timing accross servers, but not to zero.  Milliseconds are common, at
least that's what I've seen.  When you use a primary clock source such
as a GPS device you still get into trouble if it takes you long to read
the data and/or process it.  That's the sort of thing that I have in
mind when we speak of timing jitter and clock skew.

> Clockskew is the (maximum) amount by which the clocks on the authoritative 
> server and the validator differ.  This needs to be taken into account else 
> you could have a signature that is valid on the server but expired on the 
> validator.

Yes.

> > And an extra question: Why should KASP store the TTL for NSECs.
> > Shouldn't these be derived from the SOA's minimum field for negative
> > caching?
> 
> Not sure about this.

I agree with anyone who wants to keep KASP as much as possible dedicated
to cryptography, and pull away complicating (error and hole causing)
aspects of DNS.  My ideal would be to have KASP equal to PKCS #11...

If anyone has a good idea about the influence of SOA timing parameters
on the DNSSEC framework, I think it should make a good read on this
list, because I at least am a bit weary about what its influences are.

-Rick