Wes/Warren - you still owe a response on the following.
On 7/19/2017 4:42 AM, Michael StJohns wrote:
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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
