Possibly questionable security decisions in DNS root management

Ben Laurie benl at google.com
Tue Oct 20 13:24:11 EDT 2009


On Sat, Oct 17, 2009 at 10:23 AM, John Gilmore <gnu at toad.com> wrote:
>> Even plain DSA would be much more space efficient on the signature
>> side - a DSA key with p=2048 bits, q=256 bits is much stronger than a
>> 1024 bit RSA key, and the signatures would be half the size. And NIST
>> allows (2048,224) DSA parameters as well, if saving an extra 8 bytes
>> is really that important.
>
> DSA was (designed to be) full of covert channels.
>
>> Given that they are attempted to optimize for minimal packet size, the
>> choice of RSA for signatures actually seems quite bizarre.
>
> It's more bizarre than you think.  But packet size just isn't that big
> a deal.  The root only has to sign a small number of records -- just
> two or three for each top level domain -- and the average client is
> going to use .com, .org, their own country, and a few others).  Each
> of these records is cached on the client side, with a very long
> timeout (e.g. at least a day).  So the total extra data transfer for
> RSA (versus other) keys won't be either huge or frequent.  DNS traffic
> is still a tiny fraction of overall Internet traffic.  We now have
> many dozens of root servers, scattered all over the world, and if the
> traffic rises, we can easily make more by linear replication.  DNS
> *scales*, which is why we're still using it, relatively unchanged,
> after more than 30 years.
>
> The bizarre part is that the DNS Security standards had gotten pretty
> well defined a decade ago, when one or more high-up people in the IETF
> decided that "no standard that requires the use of Jim Bidzos's
> monopoly crypto algorithm is ever going to be approved on my watch".
> Jim had just pissed off one too many people, in his role as CEO of RSA
> Data Security and the second most hated guy in crypto.  (NSA export
> controls was the first reason you couldn't put decent crypto into your
> product; Bidzos's patent, and the way he licensed it, was the second.)
> This IESG prejudice against RSA went so deep that it didn't matter
> that we had a free license from RSA to use the algorithm for DNS, that
> the whole patent would expire in just three years, that we'd gotten
> export permission for it, and had working code that implemented it.
> So the standard got sent back to the beginning and redone to deal with
> the complications of deployed servers and records with varying algorithm
> availability (and to make DSA the "officially mandatory" algorithm).
> Which took another 5 or 10 years.

ts a fun story, but... RFC 4034 says RSA/SHA1 is mandatory and DSA is
optional. I wasn't involved in DNSSEC back then, and I don't know why
it got redone, but not, it seems, to make DSA mandatory. Also, the new
version is different from the old in many more ways that just the
introduction of DSA.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list