On Fri, 23 Dec 2005, Mark Delany wrote:
On Thu, Dec 22, 2005 at 06:35:47AM -0800, william(at)elan.net allegedly wrote:
Not necessarily. One of the proposals that went into DKIM had characteristic
of storing public key fingerprints in dns. This seems quite close to DK but
has a number of advantages and unlike DKIM or DK does not put serious extra
pressure on DNS infrastructure
Unproved speculation. As you know, email, compared to HTTP and P2P
(neither of which sought approval from the IETF) constitutes an
increasingly tiny part of the Internet load these days. The serious
pressure comes from applications that never came near the IETF.
That is not a proper comparison. DNS is a key protocol (not to be
confused with protocol "for keys" :) for almost all other L7 protocols
on the net. HTTP was just "another" protocol and its use would not have
had much effect on say telnet or ftp (ok, for ftp it might as it began
to be used as replacement, but that is different matter). We have to be
a lot more careful what we choose to do with dns and I think it should
stay primarily as a protocol for "linking" domain names. to specific
data locations rather then becoming all-purpose database.
Another issue is that dns is not just client->server protocol where
impact of using it would only be limited to server that chose to
deploy dkim records and client that chose to check it.
My view is that there is enough uncertainty and that if load on [core]
protocol like dns can be minimized and moved into specific L7 protocol
like SMTP, that it should be done. And we do have easy enough way to
do it with DK-like system by using fingerprints.
like ip addresses (i.e. fixed size small data) would not work so well for
when data served & answer would either come close to or exceed 512bytes
UDP limit.
Unproved speculation. As you know, 512 is not a UDP limit it's a DNS
implementation limit which was long ago removed by EDNS0 - an IETF
standard.
Nevertheless for immediate future [at least 5 more years, probably 10]
512bytes is basically limit that dns records should fit in.
BTW - that case of adding EDNS extension to widely deployed system and
how slow long it takes to do is an example why adding additional key
authorization methods to DKIM would not be easy and why we should worry
about this issue right now.
The other minor matter is that the Internet is already participating
in a billion+ DK signed and verified emails per day - I've been
watching, but as yet, no news at 11. At what point do you expect the
pressure to be noticed?
The number of emails being signed and checked is actually the main
factor - especially for sites that constantly communicate with each
other.
What would make a difference is large number of "small" domains that only
occasionally send emails but would have a signature on them requiring
checking dns and caching the public key (I predict that specialized
optimized caching servers would be needed - in fact its somewhat in my
area so I may even make good money if we all have this requirement ...)
Also small mail servers that have to check all signed emails would see
these issues in even greater degree. What would also make a difference
is when users at the largest domains begin to demand to be able to use
their own unique keys.
William. I admire your interest in optimizing DNS load, but, as Knuth
might ask, is it premature? If you think not, convince us otherwise.
Nothing is premature when it comes to dns. Once you make mistake its
difficult to fix (without impacting ongoing deployment) even if other
services are known to be impacted. As I said, it comes down to that we
do have other choices to putting large records in dns and they are
basically close to being equivalent to public keys in dns, so we should
choose those. At the very least make them available as core supported
authorization methods so in the future if problems are found, there would
be a backup plan that does not require upgrade of every site software.
--
William Leibzon
Elan Networks
william@xxxxxxxx
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf