On July 31, 2005 at 02:51, EKR wrote:
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?
Agreed. There appears to be an assumption that such analysis has
been done, but it has not been documented. The principal authors
of the DKIM drafts should consider providing such documentation,
especially for those of us that have come along later in the process.
The document at
<http://www.ietf.org/internet-drafts/draft-housley-mass-sec-review-00.txt>
appears to be an attempt at this, but I think it is lacking.
For example, assertions are made without providing the evidence,
logic, and/or analysis.
It mainly focuses on the security aspects of DK and IIM versus
stating if such methods are the best way to deal with the problems
MASS is supposed to address.
* 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.
But then you have MUA issues. As has been noted, handling of
S/MIME by S/MIME-unaware agents have known problems, and now you
are asking for MUAs to deal with copied headers in the body.
I'm not sure what you mean by "efficient". Performance-wise? You
have data that hows tha thtis is importatn.
I have none. I was just trying to speculate on possible reasons.
Based on other responses to your post, it appears others have
done some concrete analysis. The problem is that such analysis
is not formally documented.
Huh? PEM puts the signature in a header, just like DKIM.
Can your provide an example? It appears PEM puts the signature
in its own header, which is encapsulated in the body and not in the
message headers.
--ewh