[ksk-change] planned vs. emergency (was Re: [ksk-rollover] root zone KSK ...)

[David Conrad]

Mike,

On Sep 22, 2014, at 10:25 AM, Michael StJohns <msj at nthpermutation.com> wrote:
> - Single trust anchor key, and the associated private key is lost. Impact:  No further signing of the root is possible, a complete trust reboot is necessary.  

Yep.

> Chaos ensues.

Nope. Loss of key does not cause the Internet to stop. In this scenario, we have some amount of time in which to re-bootstrap trust. OS and resolver vendors push out a software update via the methodologies they already use to update their software (e.g., “Software Update” on Macs).

> - Multiple trust anchor keys, and the associated private key for the active key is lost.  Impact:  The active key can't be revoked, but another existing trust anchor key may be activated to sign the DNSKEY RRSet.  Using 5011, a replacement for the lost previously active key can be added to the trust anchor key set.  

Sure, assuming 5011 is implemented and local security policy allows for the trust anchor configuration data to be overwritten spontaneously by an external party. Neither of which I believe we can rely upon, thus we have to be able to fall back to other mechanisms such as a “Software Update”-like system.

[rest of scenarios deleted as they are all variations on the same theme]

I believe part of the confusion is that we’re mixing things here:

1) single vs. multiple keys
2) transitioning between keys

I’m am not arguing single keys are desirable. I would love to have multiple key (it’s one of the reasons I’ve been pushing to get the status of ECC support tested). However, there is the keyset size issue. I do not feel comfortable handwaving away fallback to TCP or fragmentation or middle boxes that react poorly to large response sizes for the root of the DNS.  Call it a character flaw. However, this particular concern can probably be addressed with data. If keyset size can be shown not to break things (at least too much) or we can move to something that allows smaller keys with the same (or better) security level without blowing size limits, it’s all good.

It would seem our real disagreement is around transitioning the keys. I believe that regardless of the number of keys, we need to be prepared for re-bootstrapping trust. I gather you feel otherwise. I also feel that we cannot rely on 5011 and as such, we have to assume the lowest common denominator, namely out-of-band key update mechanisms. This of course does not preclude the use of 5011 in environments where it exists and is permitted to operate (e.g., large managed networks), rather I simply do not believe it is something we can assume in the real world.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20140922/40f74967/signature.asc>