* John Gilmore:

> 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.

And it's still not clear that it works.  No additional suite of
algorithms has been approved for DNSSEC yet.  Even the upcoming
SHA-256 change is, from an implementors perspective, a minor addition
to NSEC3 support because it has been tied to that pervasive protocol
change for political reasons.

> forcibly paid by every domain owner

Not really, most ccTLDs only pay out of generosity, if they pay at all
(and if you make enough fuss at your favorite TLD operator's annual
general meeting, they are likely to cease to pay, too).

> So the total extra data transfer for RSA (versus other) keys won't
> be either huge or frequent.

Crap queries are one problem.  DNS is only efficient for regular DNS
resolution.  Caching breaks down if you use non-compliant or
compliant-to-broken-standards software.  There's also the annoying
little twist that about half of the client (resolver) population
unconditionally requests DNSSEC data, even if they are incapable of
processing it in any meaningful way (which means, in essence, no
incremental deployment on the authoritative server side).

There are some aspects of response sizes for which no full impact
analysis is publicly available.  I don't know if the 1024 bit decision
is guided by private analysis.  (It is somewhat at odds with my own

Florian Weimer                <fwei...@bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra├če 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to