Re: key length & fragmentation

["Scott Rose" <scottr@nist.gov>]

----- Original Message -----
From: "Bill Manning" <bmanning@isi.edu>

> % Personally, I think key lengths should be chosen for security reasons,
not
> % DNS server implementation reasons.  However, since any DNSSEC aware
> % resolver/server should also be EDNS aware, so truncation/fragmentation
will
> % be a worry when big keysets are in the picture (multiple algorithms,
etc).
>
> Except it might be an issue earlier than some people think.
> (I think that in an ideal world, security reasons (whatever
> that means) may be the only vector for selecting length.  This
> being the "real" world, I think that to be useful, one has to
> trade of between "enough" crypto-strength and the ability to
> deliver the key(s) to the intended target.)
>
> % In the tests - what were the average size of the KEY RRsets?
>
> single keys.  RSA/SHA1 - 512 & 1024, which generated
> "reasonable" packets.  RSA/SHA1 - 4096 bits, which generated
> UDP fragmentation.
>

Somewhat sidenote:  I've heard discussion that RSA keys over 2048 in length
incurred a significant performance impact over smaller keys.  This
performance impact hits the resolver though, "on the wire" usage wasn't
mentioned.

I think all of these issues need to be addressed in some sort of DNSOPS RFC
or something.  Trouble is that most of us have been too busy trying to get
the protocol to stop moving that we haven't given much thought to stuff like
operational key length.

It has been my intention (when I can find some time) to get some security
policy folk to look at DNSSEC and offer suggestions.

Scott