Comments on draft-allman-dkim-base-00.txt

| Comments (6) | TrackBacks (29) |
From my comments on the ietf-mailsig mailing list. Below the fold.
1.0 Background
DomainKeys Identified Mail (DKIM) is basically an anti-forgery
measure. The idea is that MTAs serving a given domain will
digitally sign messages they forward. Thus, recipients will
be able to detect forgery by absence of a valid signature.
Signing keys are made available via DNS.


2.0 General Comments

2.1 Lack of Complete Motivation

The context in which DKIM (and other similar proposals) is introduced
is that of spam/phishing prevention. Much (most?) spam is forged
and therefore it's often believed that stopping forgery is a 
first step to stopping spam/phishing. This is a contentious
argument with points on both sides, but this document doesn't really
address it at all. It just hand-waves in that direction in the 
introduction:
   
   The ultimate goal of this framework is to prove
   and protect message sender identity and the integrity of the messages
   they convey while retaining the functionality of Internet email as it
   is known today.  Proof and protection of email identity, including
   repudiation and non-repudiation, may assist in the global control of
   "spam" and "phishing".

In my opinion, a substantial new piece of work like this needs 
to start with a threat analysis of the problem and an attempt 
to determine whether the proposed solution is likely to actually
help. I don't see any of this here. I appreciate that the authors
don't want to get drawn into an extended debate, but I'm also
quite uncomfortable with starting a major new effort without 
having some level of comfort that it will actually work.


2.2 Duplication of Existing Mechanisms

DKIM really consists of two loosely coupled protocols.

     (1) A message signing protocol with characteristics somewhat
	 reminiscent of PEM.  
     (2) A key retrieval protocol to retrieve the keys used
	 for (1), as well as to deliver policy about what
	 messages are expected to be signed.

There's no reason why these two need to be coupled at all.
Indeed, it would make a lot of sense to couple a generic
message signature protocol to the key retrieval mechanism
described here.


2.2.1 Message Signing Protocol

At the time of this writing, the IETF has RFCs documenting no
less than four protocols for cryptographically signing e-mail
messages: PEM (RFC1421-1424), MOSS (RFC 1848), S/MIME (RFC 3850-3853),
and OpenPGP (RFC 2440, RFC 3156). All of these were designed to
solve the same basic problem: cryptographically protecting
a message so that it could survive transport via as many
MTAs as possible and still be readable (and verifiable) on
the other end.

DKIM introduces yet another such protocol, one which is conspicuously
less elegant than the currently dominant Security/Multiparts
approach (RFC 1847). What motivation for this choice there is
is in S 1.1:

      the message signature is written to the message header fields so
      that neither human recipients nor existing MUA software are
      confused by signature-related content appearing in the message
      body

As it happens, this was the design that PEM used but was discarded for
S/MIME. As I recall, part of the motivation was the concern at the
time was that the headers would be mangled or removed by MTAs.

I'm not enough of a mail expert to have an informed opinion
on which packaging is superior from the perspective of compatibility,
however it seems to me that the compatibility requirements for 
{S/MIME,OpenPGP} and this application are essentially similar.
If the approach described in DKIM is superior, then shouldn't
we be retargeting S/MIME and OpenPGP to use it? And if not, then
shouldn't DKIM be using S/MIME or OpenPGP?

2.3 General Complexity
The interaction of this design with all the mail headers seems
extremely complex and easy to screw up. Maybe that's necessary
and I don't have an easy way to simplify it, but it's worth
noting.

3.0 Detailed Comments

Below, quotes are set off by -----
S 1.1
------
   The approach taken by DKIM differs from previous approaches to
   message signing (e.g.  S/MIME, OpenPGP) in that:

   o  the message signature is written to the message header fields so
      that neither human recipients nor existing MUA software are
      confused by signature-related content appearing in the message
      body

   o  there is no dependency on public and private key pairs being
      issued by well-known, trusted certificate authorities

   o  there is no dependency on the deployment of any new Internet
      protocols or services for public key distribution or revocation.
        

29 TrackBacks

Listed below are links to blogs that reference this entry: Comments on draft-allman-dkim-base-00.txt.

TrackBack URL for this entry: http://www.educatedguesswork.org/cgi-bin/mt/mt-tb.cgi/354

pacific poker tournament from pacific poker tournament on November 25, 2005 9:08 PM
play texas holdem from play texas holdem on November 26, 2005 8:20 AM

Check these: play texas holdem . Read More

Check these: 888 casino . Read More

party poker freeroll from party poker freeroll on November 27, 2005 9:18 AM

Check these: party poker poker . Read More

play pacific poker from play pacific poker on November 27, 2005 1:27 PM

Check these: pacific poker . Read More

free texas holdem poker online from free texas holdem poker online on November 27, 2005 5:11 PM
texas holdem room from texas holdem room on November 28, 2005 7:51 AM

Check these: texas holdem bluff . Read More

pacific poker com site from pacific poker com site on December 1, 2005 1:24 AM

Check these: pacific poker com . Read More

play blackjack online free from play blackjack online free on December 2, 2005 10:29 AM
Japanese vcd sample from Free sex videos movies sample videos on December 16, 2005 9:35 AM

Totally free full length xxx movies Old male pics Free 3d teen sex Young girls 18 year gallery non... Read More

Lesbian forced insertion free images from Free clips for indian xxx movies on December 18, 2005 10:37 PM

Beastly sex clip free sample Free full rape film Hentai monster sex clips Little boys fucking pict Read More

6 Comments

They're doing textbook RSA signing? My goodness gracious.

(Why not DSA? If we're stuck with RSA, they definitely need some sort of padding scheme. Maybe PSS?)

I think they're not really using textbook RSA. They probably just don't think about it. After all, you just call RSA_sign(), right?

It's RSA; perhaps needs to be described better. RSA has the advantage over DSA that it places more of the cost of signing/verifying on the signer. While we don't view this as a "hashcash" scheme or anything, this is a nice property in this application. We want to minimize the time required to process intentionally bogus signatures.

RSA only has that property if the public exponent e is small. If someone is trying to deny service with bogus signatures, why won't he publish a key with a large e?

Indeed. And generating bogus signatures is trivial, generate a 128-byte random value.

re 5.9.4, 'Wait, isn't this exactly the kind of attack pharmers mount?'

a quick google for "pharming" seems to indicate that it's used to refer to an attacker persuading a registrar to transfer a domain name, e.g. http://www.greenarmor.com/pharming.shtml . Is that what you mean, or do you have another "pharming" in mind? That seems to be an entirely social-engineering-based attack, which doesn't jibe with 5.9.4's discussion of costly, extensive, and prolonged attacks on DNS infrastructure.

update: found it. a comment at http://www.csoonline.com/talkback/071905.html notes another, entirely separate, meaning for 'pharming'.

Anyway, I'd recommend clarifying that comment, since the term clearly has multiple conflicting meanings. (damn neologists!)

Leave a comment