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