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

From: [email-masked]
Date: Tue, 23 May 2017 22:40:55 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

        Title           : Security Considerations for RFC5011 Publishers
        Authors         : Wes Hardaker
                          Warren Kumari
	Filename        : draft-ietf-dnsop-rfc5011-security-considerations-01.txt
	Pages           : 12
	Date            : 2017-05-23

Abstract:
   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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-rfc5011-security-considerations-01
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-considerations-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5011-security-considerations-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Michael StJohns <[email-masked]>
Date: Wed, 24 May 2017 15:56:56 -0400

I did a quick review - it's improving, but still is getting the basics 
wrong.

This document is written with language that works only with the start 
with one key/one key in/one key out/end with one key model for trust 
anchor keys.  5011 specifically recommends that there be at least two 
trust anchor keys and this document doesn't quite get the problem 
statement right given that both 5011 and DNSSEC support a steady state 
of more than one trust anchor key.

The actual issues related to the problem stated (of publisher guidance) 
are "How long must a publisher wait after publishing a new key before 
revoking ALL previous trust anchors?" And  "How long to wait before 
signing ONLY with the newest key?"  (These are actually the same 
question looked at from slightly different angles). The issue is not the 
more limited generic question of how long to wait before you start 
signing with the new key.  (Please avoid the phrasing "use the key" 
throughout).

For example, consider a trust point with trust anchor keys A, B and 
where A is generally signing the DNSKEY RR Set at the trust point.  The 
publisher desires to replace A with a new key C.   The publisher 
generates C, signs the RRSet with B and publishes the RRSet containing B 
and C.   At time T+holddown, C has probably joined the first of many 
validator trust point sets.  At some time T+holddown+N, most of the live 
validators will have added C.   At this point the publisher revokes A, 
publishes a trust set with A, B, C and signed with A and B and continues 
this for at least the hold down time.  At which point the published 
RRSet is now B, C signed by B (C is a standby key) and most validators 
trust points have B,C installed in them.  (Or B signed by B for that 
matter - "Missing" is an abnormal state, not an illegal one and was 
there mainly because  RRSet size issues  mostly weren't brought up while 
5011 was being discussed).

Note that A could have been revoked starting with the first publication 
of C  at the cost of reducing the validator trust anchor set to a single 
key.  That would be the model for an emergency revocation of A.

So:  Minimum time to start signing with the new key is the hold down 
time (you can sign earlier, but no validator will trace trust through it 
so why bother?).
Minimum time to wait before revoking all previous trust anchors OR 
signing the RRSet ONLY with the new key is hold down time counted from 
expiration date of the signature over previous DNSKey RRSET plus some 
slop - in the example the slop is 7 days and that's a reasonable value 
for the parameters.   That's also the minimum time a new key should be 
published and signed even if you're planning on using it as a backup key 
and not including it in further RRSets for now.

Note that the example in the draft at section 6 is missing a 
consideration.  It's not the expiration time, but the expiration date 
that needs to be considered - if you issue a new RRSet while the 
signature on the old one has only 4 days to go, you have the 4 day 
exposure, not 10.

Mike

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 24 May 2017 14:38:45 -0700

> of more than one trust anchor key.

Mike,

I agree with everything you wrote.  But I believe that (nearly)
everything you wrote is about how you believe everyone *should* be using
5011.  IE, guidance as to the recommended way to use DNSKEYs within a
zone, how many to have, good practices about using them and publishing
them, how many keys should be used to sign the records, etc.
And all of that sounds like incredibly useful information.

But that's not at all what this document is trying to address.  We're
trying to address the fact that almost no one is currently using your
recommended practice and nearly everyone is using the "add a new key,
switch to it after period X, and then remove the old key".  This is the
current real world reality, including with the root zone.  So though
you're absolutely right that you could have 3 keys (and likely should)
and could double-sign as well with multiple keys, few actually do this.
And the current root-key roll plan certainly doesn't either.

Our goal is only to document the *minimum* requirements for rolling a
key and making use of it as quickly as possible.  Out of scope is "the
preferred best practice".  With that in mind, do you have a specific
objection to some technical piece that does fall in that scope?  we'd
certainly like to hear it (especially with text provided).

I'd also love to see DNSOP take on an additional document that handles
the wider problem of "best practice" that would include your entire
plan.  I'd certainly support for it's adoption.

> time (you can sign earlier, but no validator will trace trust through
> it so why bother?).

This is a valid point and we need to look at the wording.  Because we
really mean "the minimum time at which you can *only* sign with a new
key".  You're absolutely right there.

> slop

1) it's really the second half, and the first half doesn't matter.  It
   doesn't matter whether you revoke or not.  The important statement is
   if you sign only with a key newer than the hold down time plus "slop"
   (and to use your own argument: there could be multiple introduced
   keys, and the point being you can't sign with *only* any of them
   until that key's hold down plus slop).

2) It's the slop we're trying to define.  IE, what's the minimum time
   you must way before signing with only a fairly new key.  It's not
   "slop", it's a required time period and a hard minimum fact (the
   2*TTL is really the only true "slop").

> in the example the slop is 7 days and that's a reasonable value
> for the parameters.

No, that's one of my points: it's 17 days, not 7.  7 would leave you
vulnerable to the attack in question, assuming you were signing only
with a key published at T+37.  You must wait until T+47 at minimum.

> signature on the old one has only 4 days to go, you have the 4 day

I keep following you in the above and agreeing with it until the end.

Most importantly, "expiration time" is not the right wording.  You're
absolutely right there, and we need to define it more carefully using
the expiration (sigexpire) date.  I'll look into that.

I'm not sure what "new RRSet" you're envisioning for the rest.  We
really only care about the replay time of the RRSIGs on only the K_old
set.

[There are certainly more complex examples we could throw into the mix,
such as publishing multiple keys over lapping in time periods, but I
don't see the benefit of confusing the reader with an even more complex
example].
-- 
Wes Hardaker
USC/ISI

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 25 May 2017 10:15:40 -0700

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

---

From: Bob Harold <[email-masked]>
Date: Thu, 25 May 2017 14:27:06 -0400

On Thu, May 25, 2017 at 1:15 PM, Paul Hoffman <[email-masked]> wrote:

> 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.
>
> 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

Although the root zone is mentioned, I don't think "this document focuses
mostly on that KSK"

I might be wrong, but it would seem to me that the doc covers two
situations:
1. How long to wait after publishing a key before signing exclusively with
that key.
2. How long after you stop signing with a key before you remove it.
And both should apply no matter how many keys a zone happens to have.

-- 
Bob Harold

---

From: Michael StJohns <[email-masked]>
Date: Thu, 25 May 2017 15:22:10 -0400

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.
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 25 May 2017 14:31:42 -0700

Bob Harold <[email-masked]> writes:

> I might be wrong, but it would seem to me that the doc covers two situations:
> 1. How long to wait after publishing a key before signing exclusively with that key.

Thank you.  That is exactly the intent of the document.  

> 2. How long after you stop signing with a key before you remove it.

Actually, it's how long you have to wait before removing a key that you
set the revoke bit on.

> And both should apply no matter how many keys a zone happens to have.

Yes yes yes.  It has nothing to do with the number of keys.  It's purely
the "if you exclusively sign with a (any) new key before it has been
published for this length of time, you're vulnerable to attack".

-- 
Wes Hardaker
USC/ISI

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 May 2017 11:52:22 +1000

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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Michael StJohns <[email-masked]>
Date: Thu, 25 May 2017 23:27:11 -0400

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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 31 May 2017 19:44:46 +0000

Coming late to this thread, I have a question.

How many operational instances of "Automated Updates" [RFC 5011] are there?

Besides the root zone KSK, I don't know of any.  I do some monitoring of DNSSEC practices, years ago I noticed one TLD appearing to follow RFC 5011's semantics.  But in recent looks that TLD seems to have abandoned the practice (I've never made contact to confirm).  In a scan of second-level names a month ago, I found only traces of revoked keys (KSK and ZSK!).

I ask because of the issues raised in the thread regarding the number of keys assumed in the operation.  Automated Updates apparently (to me) was defined with more than one active secure entry point in mind, but in practice, the only operating example I've witnessed of Automated Updates relies on a single active secure entry point.

I've asked around (tool developers) and, so far, no other examples have popped up.  I'm sure there are some out there.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 31 May 2017 20:54:14 +0000

Answering my own question...relooking at my data, I see two TLD operators (running a total of 4 zones) revoking KSK's on a regular basis.

On 5/31/17, 15:44, "Edward Lewis" <[email-masked]> wrote: