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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
