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

[Wes Hardaker <[e-mail]>]

Michael StJohns <[e-mail]> writes:

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

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.

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

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.

> 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

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.

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

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