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

[Mark Andrews <[e-mail]>]

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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]