On 9/21/2014 2:37 PM, David Conrad wrote:
On Sep 21, 2014, at 10:49 AM, Michael StJohns <msj@nthpermutation.com> wrote:
Worst case is compromise of all trust anchor keys. 5011 allows you to recover from an N-1 compromise (where you have at least one private key associated with the root trust anchor set that hasn't been compromised). This has always been my problem with 5011-based rollovers.
Given the protections specified in the DPS, all the scenarios in which we have to do an emergency key roll seem ridiculously unlikely. However, I assume we have to be prepared for the worst case scenario. Since 5011 can’t help us with that scenario and emergency key rollovers is a superset of planned rollovers, I’ve been unclear as to the advantage 5011 provides.
And then there is the issue of (likely permanent) lack of universal implementation of 5011...
Am I missing something?
I think someone once said that "Democracy is the worst form of government, except for all others". 5011 is pretty much the same with respect to DNSSEC. If you go back to the original requirements document (which was hard fought), you'll see the assumptions we made about what might be possible. 5011 has the advantage of being in-band, is designed to work without dependence on non-DNS (e.g. x.509 PKI) infrastructure, and understands the difference between the DNS transport protocol and the DNS data protocol limitations. It was also designed to work with existing DNSSEC implementations through the addition of a simple program that could do 5011 DNS queries and update the local DNSKEY trust anchor stores. You say "5011 can't help with that scenario" ... but the truth is, NOTHING can help you with that scenario due to the one-way nature of DNS data. The goal of 5011 was to provide a set of mechanisms that could be used to minimize the chance of a complete root trust anchor compromise and recover from anything but that complete compromise. I think it met that goal. The problem I have now is that whoever set up the current root of trust either didn't actually read the "protection only applies if you have more than a single root of trust" or avoided placing a second root of trust for some reason that seemed to make sense at the time. What should have happened when this got started was for 2-3 roots of trust key sets to be created and distributed as part of the initial bring up. Neither 5011 nor DNSSEC require that more than one of those roots of trust be present in the published RRSet if the argument was about space in the replies, but the current model means that - absent 5011 or a year to two (five?) year publicity campaign to add new trust anchors - we've got a problem with superseding the existing KSK key, emergency *or* planned. I designed a pretty good protocol. I was somewhat dismayed when the deployment at the root didn't match 5011 requirements, even though the DPS cited 5011 as the operational model. But that's past. What do you want to do next? WRT to 5011, one way to do a rollover exercise without screwing over the non-5011 resolvers is to do the following: Current KSK is A - it stays. Add B key. (plus 30 day hold down) Add C key. (plus 30 day hold down) Revoke B key. The TA set goes from {A} to {A, B} to {A,B,C} to {A,C}. The servers that only know A continue to work. Other servers update their TA store and we do some post twiddling analysis to see whether or not the updates made it through. Later, Mike
Regards, -drc