Re: [DNSOP] Review of draft-ietf-dnsop-rfc5011-security-considerations-13, was Re: [Ext] IETF meeting prep and what

[Michael StJohns <[e-mail]>]

On 6/18/2021 7:11 PM, Paul Wouters wrote:
> Section 6.1.7 confuses me a bit as it defines a numResolvers variable,
> and uses that to calculate an acceptable new timing period. To me it
> feels that number of resolvers should not matter, as we should stick
> to the formal time where all resolvers are either updated or no longer
> updatable. This arguments also bleeds into Section 6.2 where it is used
> indirectly.

Hi Paul -

There's a bit of discussion on the WG list but basically:


1) Given various parameters, calculate the earliest date at which a 
publisher can assume at least 1 resolver with perfect connectivity (e.g. 
all questions answered when asked) was able to install the new trust 
anchor.   Note that you figure this assuming only a single resolver and 
non-synchronicity between publisher and resolver which means the 
earliest date for the publisher is the latest date the perfect resolver 
would do the install of the new trust anchor.

2) Given set of N resolvers with imperfect connectivity (e.g, online but 
with occasional lost message/retransmits using 5011 timing) where the 
imperfection is characterized as L% chance of any given message being 
lost, how much longer after (1) should you wait to get to the 
statistical point where K% of the N resolvers have been able to install 
a new trust anchor?

(2) represents a safety factor and is calculated based on N, L and K.   
It ignores the set of offline resolvers in the calculation, because 
there is no way to characterize them.

The question "all resolvers updated" is not an answerable question nor 
one answered by the document.   "Statistically, 99.9999% of resolvers 
have updated" is an answerable question with some margin of error 
assuming N and L can be characterized.  The size of N has a small but 
important impact on the final result. 
https://mailarchive.ietf.org/arch/msg/dnsop/JEPKl_3A5azV_l_UYKTtXGb8QtU/

Later, Mike