Re: [DNSOP] requesting WGLC for 5011-security-considerations

[Michael StJohns <[e-mail]>]

On date time vs intervals - I finally realized why Wes and I are 
somewhat disconnected on this.

5011 was written as the protocol for the resolver and is totally 
interval driven.   (E.g. query and retry timers are set and fire based 
on when the resolver performs an action).

This document is being written for the zone publishers, and the process 
of publication is task driven and has humans as protocol element 
timers.  The actual publication of a DNSSEC RRSIG is divorced from both 
the date/time of creation and the RRSig's actual inception and 
expiration dates.  While there is a defined interval between inception 
and expiration, expiration occurs at a fixed point in time and that 
point in time is independent from the interval between publication and 
receipt by the client.

In other words - the correct (or at least better and less subject to 
being misunderstood) way of describing the various points in time the 
publisher should do something is by referencing the fixed point in time 
(expiration) where both publisher and client agree that something 
happens and then figuring other fixed points in time from that point.   
Or to restate it again - "A publisher must wait until June 5th 2010" 
will always evaluate to the same date and time regardless of who 
calculates it and when they calculate it; "A publisher must wait 30 
days" will not.


So :
"
publicationAddWaitInterval :: = MAX (30 Days, originalTTL of NEW DNSKEY 
RRSet) + MAX ( all calculated queryIntervals for OLD and new RRSets)  + 
addSlopInterval
queryInterval ::= MAX (1 hour, MIN (
                                                 15 days,
                                                .5 * expirationInterval 
DNSKey RRSet,
                                                .5 * originalTTL DNSKey 
RRSet)
                                           )

expirationInterval :: = expirationDate - inceptionDate
addSlopInterval ::= 2 * MAX(originalTTL of any  DNSKEY RRSet valid 
during the transition process)

The publicationAddWaitDateTime  is the date and time on which the 
publisher can assume that most of the 5011 capable resolvers have 
accomplished the addition of the new trust anchor to their trust anchor 
sets.  That date is the addHoldDownTimeInterval AFTER the latest in time 
signature expiration date of any RRSet without the new key.  This 
includes both published and unpublished RRSets. Publishers should 
refrain from creating or publishing DNSKEY RRSets signed exclusively by 
a new key until after this date. Specifically, the inception date of 
such an RRSig should be later than the publicationAddWaitDateTime"

The addHoldDownTimeInterval above differs from what is in 5.1 section 
2.4.1 in that this is the publishers view of when the new trust anchor 
is accepted by the resolver which may differ from a specific resolvers 
view (due to when things are actually sent and received).  Section 2.4.1 
has to be combined with the text in section 2.2 which states that the 
key isn't added until after the next time it is seen after the 
expiration of the add hold down. Also, the queryInterval term of this 
calculation should be the maximum of any DNSKEY RRSet seen during the 
transition - it's possible that the publisher may reduce the intervals 
or increase the intervals between RRSets and this provides the publisher 
with the worst case value that any given resolver should be using.


Let's not confuse resolver numbers with publisher numbers and spend a 
bit of time to get the language clear correct and implementable.

Mike