-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Blake Ramsdell
Sent: Monday, October 15, 2007 7:28 PM
To: Kemp, David P.
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: Header Protection for S/MIME
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
I think that there is a shortage here as with the current embedded message
draft in terms of guidance about what to do for changed headers. A
statement to the user that "one or more of the following headers was
changed" is more confusing to the user than displaying two sets of headers
which might be the default behavior with the current documents.
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
--
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com
I do have some other issues with this document as it currently stands.
1. As you pointed out this document does not really meet the stated
criteria of finding out what header was changed. As in the DKIM world all
you know is that someone changed the headers in such as way that the
canonicalization algorithm did not ignore what the change was.
2. It is not clear to me that just placing the data of the headers into the
attribute and providing some ways of canonicalizing the comparisons between
the actual header and the attribute header is a better approach.
3. It is not clear to me that this approach is actually smaller than
placing the headers to be protected into the attribute directly.
All that being said, my preferred solution to this problem has always been
to place the headers to be protected into an attribute. I have never been a
fan of the embedded message approach.
Jim