On 1/25/10 12:56 PM, "Edward Lewis" <ed.le...@neustar.biz> wrote: > 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. > You can - sure. Why not? For a while the NIST recommendation was to have 2048 bit ZSK and KSK's. Now that better tools are out there, no need to go by file sizes anymore :)
> 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. I've been assured there is some sort of calculation involved, but I can't do it. All of the NIST recommendations are really grounded in the (Fed) PKI world. DNSSEC isn't big enough (or well known) to justify a separate set of policy recommendations. NIST(via the NSA) has decided that 1024 bit RSA could be vulnerable soon, so a stake in the ground is planted to move PKI certs (and everything else) to 2048 bit RSA. After much debate, we (networking) got them (Comp Security) to back down and agree that 1024 bit was still ok, as long as the key is changed ~3 months (at max). Otherwise it would policy to have both keys be 2048 bits. Scott > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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 > =================================== Scott Rose NIST sco...@nist.gov ph: +1 301-975-8439 Google Voice: +1-571-249-3671 http://www.dnsops.gov/ =================================== _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
