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 <401caf02-5631-de42-489c-8ca334645...@nthpermutation.com>, 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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
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
