[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-allman-dkim-base-00.txt
> Earl Hood <earl@xxxxxxxxxxxx> wrote:
> > On July 30, 2005 at 21:56, EKR wrote:
> >
> > > 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 IETF engaging in major new effort without
> > > having some level of comfort that it will actually succeed.
> >
> > Sam Hartman makes a similiar point in his MASS BOF message.
> >
> > A separate document can be created that defines the security threat
> > being addressed, analysis of threat, and the types of solutions that
> > may adequately address that threat.
> Well, I generally like to do the threat analysis before the solution
> design. Otherwise, how do you know that you're choosing the right
> solution?
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 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.
> > > 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.
> > > -----
> > >
> > > The first point does not apply to PEM (RFC 1421).
> >
> > How? Checking the PEM-related RFCs, PEM does nothing with the message
> > header fields. For non-PEM aware MUAs, PEM-specific data is visible
> > to the human. (BTW, what is the percentage of MUAs that support PEM?)
> 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.
Ned