Re: [DNSOP] new dnsop related draft: RFC5011 security considerations

[Michael StJohns <[e-mail]>]

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