On 8/1/2016 6:00 PM, Wes Hardaker wrote:
The following draft, authored by Warren and I, might be of interest to
the dnsop crowd:
https://tools.ietf.org/html/draft-hardaker-rfc5011-security-considerations-00
[it currently does not have a home]
I went off and thought about this for a while and came up with:
1) The absolute earliest time that the FIRST resolver would install a
new trust anchor: publicationTime + holdDownTime
2) The absolute earliest time that the PUBLISHER can assume that the
FIRST resolver has installed the new trust anchor: (latestExpirationTime
of all DNSKey RRSets that do not contain KNew or publicationTime
(whichever is later) ) + holdDownTime
3) The time when a publisher can assume reasonable numbers of resolvers
have installed the new trust anchor (and incidentally the period in
which they should avoid revoking the keys being used to add the new
trust anchor): Some time after (2) depending on how much penetration
you want and making wild guesses about things like off-line resolvers
rejoining the internet after being away. So I think this is related
specifically to the original TTL. So maybe this is
latestExpiration + holdDownTime + N*MAX(any originalTTL published in the
DNSKEY RRSig record over the new key) where N is >= 2. But this is no
better than a SWAG at the numbers.
For the current root key rollover stuff, I think 3 months is a pretty
good SWAG.
The above doesn't actually change the basic model of DNS as an
incoherent data protocol. The time from publication to acceptance by
an individual client of any published data varies drastically from the
acceptance of that same data by a different client at a different place
in the network with different query patterns. If a new NS record were
added to the root tomorrow, we wouldn't expect the entire world to pick
that up immediately and we would expect that there would be some time
until a large percentage of resolvers would know about the new NS and
start using it. That incoherence time would be related to the time it
takes to propagate the NS records to the other root servers and for TTLs
to expire on the existing data and the actual liveness of the resolvers.
Why this calculation should be very different for the root DNSKEY RRSet
escapes me.
Mike
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
