Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt

[Michael StJohns <[e-mail]>]

I appreciate your comments, but they are pretty much inapplicable to the 
document.  I'd suggest if this approach is important to you that you 
draft an ID and gather comments on that document.

If you want to recommend changes to 5011 - same comment.

What we're discussing now is guidance for the publisher that's trying to 
understand the implications of following 5011 timing considerations and 
how those relate to the publishing schedule.

Mike


On 5/25/2017 9:52 PM, Mark Andrews wrote:
> These questions are why I don't like RFC5011.  There is lots of
> missing metadata about DNSKEYs that exists in CERTs.  We could
> supply this metadata in TBD records at the apex of the zone which
> are like extended DS records (I will call these records VU records).
>
> Things like "valid until" where validators go insecure if they no
> longer have any stored trust anchors with a "valid until" in the
> future.  Where zone operators commit to signing with the DNSKEY
> until after the "valid until" time has passed.
>
> e.g.
> 	. VU <date> <key-alg> <hash-alg> <hash>
>
> where these records get updated periodically if you want to extend
> the life of the matching DNSKEY record.
>
> A KSK key rollover would involve publishing a new VU record along
> with the new DNSKEY record.
>
> 	. VU <date1> <key-alg> <hash-alg> <hash1>
> 	. VU <date2> <key-alg> <hash-alg> <hash2>
>
> If a validator is off line during the KSK rollover then it would
> continue to have just
>
> 	. VU <date1> <key-alg> <hash-alg> <hash1>
>
> and if it is restarted after <date1> it would start in insecure
> mode.
>
> Similarly if it just misses a updates of the VU records to extend
> the DNSKEY's lifetime it would start up insecurely.
>
> 	. VU <date1> <key-alg> <hash-alg> <hash1>
>
> 		to
> 	
> 	. VU <date2> <key-alg> <hash-alg> <hash1>
>
> Mark
>
> In message <[e-mail]>, Michael StJohns writes:
>> Hi Paul -
>>
>> I appreciate that both you and Wes have new skills related to mind
>> reading about my intents, but you're probably reading the wrong mind.
>>
>> I have stated the question a publisher needed to answer fairly
>> succinctly in the past:
>>
>> "How long must a publisher wait until it is reasonably certain that a
>> new key has been installed as a trust anchor in all but a slim minority
>> of live DNS 5011 resolvers?"
>>
>> That question is the correct one to answer because it covers all the rest:
>>
>> "How long should a publisher wait after publishing a new key before it
>> signs the trust point DNSKEY RRSet with ONLY that key?"   Same answer as
>> to the question above because you have to wait to stop signing with all
>> the other trust anchors until the trust anchor uptake rate for the new
>> key at the resolvers is sufficient (for some value of sufficient).
>> "How long should a publisher wait after publishing a new key before it
>> revokes ALL of the old trust anchor keys?"   Same answer to the above,
>> and incidentally forces you to only sign with the new key.
>>
>> Note that the answers to the question the document asks are different
>> than as stated (because of the one in/one out assumption):
>> "How long must a publisher wait after publishing a new key before it
>> signs the trust point DNSKEY RRSet with that key?"  Answer is that it
>> may begin signing the RRSet immediately upon publication, resolvers will
>> not start tracing trust through that key until at least the hold down
>> time.  The publisher may indeed delay signing as long as it wants as
>> long as there are other trust anchor keys available.
>>
>> "How long must a publisher wait after a publishing a new key before it
>> revokes an older trust anchor key?"  Answer is that it depends on how
>> many trust anchor keys are assumed to be in most resolver's set.  If
>> only one, then you wait until you are "reasonably certain that a new key
>> has been installed as a trust anchor..."  If its more than one, then it
>> depends on the trust point's policy of how many keys to keep more than
>> anything.
>>
>> The important part in this document is getting a handle on the
>> publication uptake time for most resolvers given a new key.   The rest
>> of the guidance flows from that.
>>
>> My specific point is that this document should talk to the protocol, not
>> limit the discussion to current practices - especially since current
>> practices are really a proper subset of the allowed behavior.   I do
>> understand what the root is doing right now, and you're both correct
>> that I wish they were using at least a two key trust anchor set as
>> steady state.  But that still doesn't obviate my point about writing the
>> document to the protocol and not the practice.
>>
>> In the current document, I'd rewrite the math and discussion to deal
>> with how I framed the question (e.g. its about how long it takes to
>> populate enough resolvers).   If there is then a desire to talk about
>> the current root update process, then do that as an appendix or an
>> example and I think doing the analysis against the current root key
>> update process is a good idea.
>>
>> Later, Mike
>>
>>
>>
>>
>> On 5/25/2017 1:15 PM, Paul Hoffman wrote:
>>> Most people reading an RFC about the DNS probably expect it to be
>>> about the public DNS we know. That public DNS currently has one KSK,
>>> and there are no plans to change that (although there might be in the
>>> future). Given that, and given Mike's comments on the doc, I propose
>>> the following.
>>>
>>> Change the Abstract from:
>>>     This document describes the math behind the minimum time-length that
>>>     a DNS zone publisher must wait before using a new DNSKEY to sign
>>>     records when supporting the RFC5011 rollover strategies.
>>> To:
>>>     This document describes the math behind the minimum time-length that
>>>     a DNS zone publisher must wait before using a new DNSKEY to sign
>>>     records when supporting the RFC5011 rollover strategies in zones
>>>     that have a single key signing key.
>>>
>>> Just before Section 1.1, add a paragraph:
>>>
>>> This document describes only the case where a zone has only a single
>>> key signing key (KSK). It does not apply to zones that have multiple
>>> KSKs. The current public DNS has a single KSK covering the root zone,
>>> and this document focuses mostly on that KSK in its discussion.
>>>
>>> --Paul Hoffman
>>>
>>> _______________________________________________
>>> DNSOP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop