At 21:14 -0800 1/22/10, Eric Rescorla wrote:
I haven't formed a useful opinion one way or the other about the operational value of frequent key rollovers. However, it seems to me that the value of those practices is more or less independent of key size, so we've travelled fairly far afield from the original claim that we need rollovers to compensate for being forced to use overly-short RSA keys.
What I've taken from this thread is that choices made for key management are not driven by cryptographic considerations. What I wonder now is whether my choice for key size is too big - the cost of that is the DNS response datagram size.
I envision monthly changes of the ZSK and annual changes of the KSK. I can't see any savings in extending the periodicity of this, but I can see savings in lowering the number of bits needed to send the public key and signature along.
Last time I looked (a few months ago) most signed TLDs to use 2048 bit KSKs and 1024 bit ZSKs. Perhaps there is no reason to have two different sized keys, I would guess that since "a chain is only as strong as its weakest link" all keys could be dropped to 1024, or even less.
But what nags at me are the NIST recommendations that talk of a keys having so many bits of randomness - like a 1K or 2K key having 112 bits.
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
