I should like to ask how querying for TXT records constitutes "using DNS in
an incorrect manner". I would also like to understand how DNS software,
answering queries for TXT records regularly thereby specifically functioning
as documented, can possibly be construed as "designed for a different
reason".
Can you further explain on what ground I should feel justified in second
guessing the work product of the DNS effort and instead believe you when you
say that, despite the fact that DNS is advertised to work one way by those
who created and endorsed it, and despite empirical evidence to the contrary
as evidenced by millions of SPF and DK records currently extant,
nevertheless, DNS can't do the job and we should move on to something else.
It's one thing to put a warning that dns-based key publishing may effect the
performance and stability of some DNS implementations - this is certainly
possible. It's another to try and claim that DNS itself is insufficient to
the task.
As always, just my opinion. Your mileage may vary.
--
Arvel
----- Original Message -----
From: "william(at)elan.net" <william(_at_)elan(_dot_)net>
To: "Arvel Hathcock" <arvel(_at_)altn(_dot_)com>
Cc: "ietf-mailsig" <ietf-mailsig(_at_)imc(_dot_)org>
Sent: Wednesday, July 27, 2005 7:25 PM
Subject: Re: revised Proposed Charter
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