On Wed, 27 Jul 2005, Arvel Hathcock wrote:
I think it seems a little silly but it's not harmful so I personally don't
care either way. It's sort of basically saying, "Hey, guess what! Some DNS
records are larger than others - yeah, they're not all the same size." LOL.
How is that funny? 99.99..% of dns records in use right now are smaller
then proposed dk pk records. The only exceptions are some large SPF
records (not something that dns folks like, but in case of SPF large
record are very much an exception and not the norm) and domain system's
own pki records (one per zone where dnssec is employed, which is almost
nowhere right now and its clearly understood that for dnssec and its
pki, the major change from dns udp do dns tcp would be necessary).
Again as I said, one of the bigger problem with DK & DKIM is insistence
on overloading architecture designed for different reasons and with
expectations that its records would be primarily of fixed size and fairly
small. And as DNS is at the core, there is possibility of not just
creating problems for those using dk, but for others as well (i.e. dns
cache systems have to be upgraded, ISP dns resolvers, etc).
And that is at the same time when similar enough alternatives are
available such as:
1. Not using dns at all and using something like HTTP
2. Using much smaller (and always fixed size clsoe to ipv6 no matter what
size public key is) fingerprint records in dns.
3, Other type of protocol that supports both tcp and udp or can do
answers fast (LDAP comes to mind, I know of one or two others).
And while these alternatives (specifically first two which were part of
previous MASS work) are available they are not even going to be looked
at and the only thing being considered (and the only thing explicitly
allowed by proposed charter) is public key retrieval from dns which also
happens to be the only authorization variant that is covered by patent
(i.e. all non-patented solutions are dismissed and seems that is done not
even for technical reasons).
DNS has well known constraints; we are operating within those constraints.
Someday there should be a "Friendly Advice" or "Take it from me brother!"
section in every RFC. If there were, this text would belong there rather
than in "Security Considerations" (just my opinion folks).
Well, IAB was concerned enough that they released some (more then one!)
drafts about the issues of overloading dns and using in incorrect manner.
http://ietfreport.isoc.org/all-ids/draft-iab-dns-choices-02.txt
http://ietfreport.isoc.org/all-ids/draft-iab-dns-assumptions-03.txt
http://ietfreport.isoc.org/all-ids/draft-iab-identities-02.txt
---
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net