On Mon, Oct 15, 2007 at 12:44:37PM -0400, Kemp, David P. wrote:
Perhaps there has been no discussion because there is nothing to
complain about. Controversy, or "clash" in media terms, is what sells.
The document appears to be a well-thought-out approach to providing
header integrity protection (but not confidentiality, for which
encapsulation is required). Unlike the current encapsulation approach,
it is compatible with header-protection-unaware applications, and it
avoids the issue of how to represent inner and outer headers to users by
not using an outer header in the first place.
Silence can also indicate apathy. So let's start diving into whether it's so
cool that there's nothing to say, or we don't care so much that there's
nothing to say.
I read this draft over, and indeed, it documents a new approach to header
protection, and it appears to be heavily influenced by the DKIM approach to
header processing. To hit the high points:
* A new signed attribute is introduced, which contains
* An algorithm identifier to indicate a canonicalization algorithm to be
used when presenting the headers to the digesting algorithm
* A digesting algorithm identifier
* An ordered list of headers, multiple instances of a header are indicated
by listing the header name more than once
* A digest of the canonical values of those headers
* Uh, that's pretty much it
Now, there's some things in here that need fixing. I'm sure there's some ASN.1
fun, especially debating NULL vs. absent parameters for
CanonAlgorithmIdentifier. I'm sure there might be some opinions about whether
the digest algorithm should be specified in the outer SignedData
digestAlgorithms list. And the security goals need some work -- "The main
security goal of mail message header protection is not to protect the whole
RFC 2822 header against manipulation, but to make it possible for the
receiving client to detect which headers have been changed." isn't exactly true,
you can't figure out which headers have been changed, only that "something in
the list of headers that were protected with the digest has changed".
One appealing aspect is that it is compatible with current practice -- it is
incremental functionality that oblivious clients will simply skip. And the
cost of this approach is fairly little -- slightly increased message size.
OK, so I'll start. Is there some goal that we can achieve with this mechanism
that is better than the "just wrap a whole message/rfc822 and lord knows how
you merge the resulting headers" approach that is the current practice?
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com