Earl Hood <earl(_at_)earlhood(_dot_)com> 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