At 12:30 PM +0200 2006-04-05, Werner Koch wrote:
DKIM just doesn't work - at least not as described in the I-D I am
aware of. The canonicalization rules needed for MIME are broken and
may be used to inject a faked message within a DKIM signed one. The
recipient (or MTA) will see that the mail verified okay but the actual
content shown is the faked one. See Thomas Roessler's "noswp
considred harmful"[1].
I haven't looked that closely into DKIM, but I'll take you at
your word with regard to the weaknesses you describe. However, this
doesn't mean that these weaknesses can't be fixed.
The problems I'm concerned about with DKIM do not appear to be
fixable, at least not if you're doing it at an individual level as
opposed to the domain.
Very highly non-scalable.
I doubt that. A PKA record like
"v=pka1;fpr=A4D94E92B0986AB5EE9DCD755DE249965B0358A2"
can be squeezed into less that 32 bytes with a dedicated RR type.
Yeah, but that's probably 31.999999999999999999999999999 more
bytes than you're storing in the DNS today (per user), and with tens
of millions of users in a single flat zone, all that adds up really
fast.
If
you don't want to use general keyservers, add the space for an URL.
The latter may even be optimized by extending the system to define URL
shortcuts like looking up the default key distribution method of the
domain (e.g. by using HTTP).
If you can take all the keys out of the DNS and put them into
something like a customized web server (with maybe one key in the DNS
for the entire domain to tell everyone how to access that web
server), then we've exchanged DNS server scalability (a subject I
have some familiarity with and something I care a great deal about)
for web server scalability (something I know less about, and which I
care a lot less about).
--
Brad Knowles, <brad(_at_)stop(_dot_)mail-abuse(_dot_)org>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
LOPSA member since December 2005. See <http://www.lopsa.org/>.
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com