ietf-mailsig
[Top] [All Lists]

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

2005-07-31 22:53:56

Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
Earl Hood <earl(_at_)earlhood(_dot_)com> wrote:
On July 30, 2005 at 21:56, EKR wrote:
Well, it isn't like we're unfamiliar with the threat, attacks, and solution
space. This is more a matter of documenting what we know than an exploration 
of
new territory that is bound to lead to surprising results.

I'm not convinced that's true. Yes, we have a fair sense of what's
currently happening, but I'm not at all sure that any good analysis
has been done of the likely responses of attackers to this change
in our defense strategy



I agree that something should be provided that explains why something
like S/MIME or OpenPGP are not used a basis for MASS.  Such information
can be provided in the threat analysis document when possible solutions
are mentioned.

BTW, here may be some possible reasons S/MIME or OpenPGP are
not useful as a basis for MASS:

  * S/MIME, et.al. do not provide arbitrary header signing
    capabilities, especially key fields like Subject and From.

Well, unless you do message/rfc822. I could certainly imagine
making a copy of the headers in the body if one wanted to go
the S/MIME direction. Sure, it bloats the messages a bit, but
it has the advantage you're not designing a new cryptographic
messaging protocol.

There is, AFAIK, not a single client out there that handles this sort of 
complex structure adequately. And the majority of clients botch it pretty
thoroughly. And this is in spite of demonstrable need and the relevant
specifications having been stable for years.

I for one am tired of waiting for this particular ship to sail.

Now, I happen to like the multipart/signed construct a lot (I should since I'm
one of the coauthors). But IMO it isn't the right tool to use to solve the set
of problems DKIM is trying to solve.

This is clearly a reasonable argument, but it seems to me that it's
a generic argument that we should replace the structure of all
of our cryptographic e-mail protocols, not just do some one-off
thing for DKIM.


Huh? PEM puts the signature in a header, just like DKIM.

I'm sorry, but PEM does no such thing. PEM uses a variant of RFC 822 syntax,
but places the resulting fields in the message body, not the header. Moreover,
PEM depends on prefix/suffix strings embedded in the body itself to identify
the protected content; there is no indication placed in the header at all.

The fact that this is almost totally at odds with MIME was one of the primary
motivations for starting the MOSS work, which led to the specification of
multipart/signed.

You're right. I had a brain fart when I wrote this.

-Ekr

<Prev in Thread] Current Thread [Next in Thread>