[ksk-rollover] root zone KSK rollover operations workshop planning

[David Conrad]

Hi,

On Sep 19, 2014, at 8:26 AM, Paul Hoffman <paul.hoffman at vpnc.org> wrote:
> - It is literally insane to attack a 2048-bit key that is protecting a 1024-bit key that is used for signing the same material (in this case, the root zone). Thus, there is no cryptographic reason to roll the 2048-bit KSK as long as the root is signed with 1024-bit ZSKs.

If the argument here is whether or not we should roll the key based on the feasibility of someone to brute forcing a 2048 bit key, I’d agree it is insane.

But I don’t think anyone here (or elsewhere) is arguing that. I believe the core idea is that because we don’t know what the future holds (e.g., someone comes up with a novel attack against RSA), we need to be in a position to change the key. In order to change the key, we need:

- the key changing policies and processes.
- experience with operationally changing the key according to those policies and processes.
- some level of assurance that the Internet won’t break if we change the key.

That’s the reason for this mailing list (and workshop during the ICANN LA meeting).

> - Changing the signing algorithm (which I strongly support) is not a KSK rollover and thus out of scope for this discussion except insofar as if there is a planned algorithm change, that could affect the perceived need for the KSK rollover. If changing the signing algorithm *is* in scope for this discussion, the title of the discussion should change.

I’m not sure arguing the semantics of the terminology used in the name of this mailing list is a good use of time.

> - Changing the signing policy to be one where the KSK and ZSK are both 2048 would have a huge effect on the decisions about KSK rollover because we then need to discuss the attack resistance of 2048-bit RSA keys and the value of breaking the root key signatures. If possibly changing that signing policy is in scope, that needs to be stated early.

At this stage of the game, I personally think everything that could impact changing the key and/or the implications of changing the key should be in scope.  

Regards,
-drc
(ICANN CTO, but speaking for myself only)
-------------- 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/20140919/6580b407/signature.asc>