Subject: RE: Header Protection for S/MIME

From: Lijun Liao <[email-masked]>
Date: Mon, 22 Oct 2007 16:01:19 +0200

>"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".

That is what we mean. Perhaps we need to reorganize the sentences.

>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.

First, the most clients show only one set of headers. Second, if two sets of
headers are supported, there are some fields which are in both sets. This is 
more confusing to the end user than the proposed approach.

>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.
Right. The goal is to detect whether there is any modification to the protected
headers. To find out what header was changed, surely one can put a list of 
entry (header field name and the hash value). However this is trivial. The
embedded message approach also does not provide any mechanism to find out it.

>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.
Surely you can define a data format to specify the headers to protected. However
it has the following disadvantages:
 2.1. It enlarges the message size;
 2.2. The header fields must be presented twice in a message
 2.3. The comparison of the header fields is complex, especially for the fields
      with multiple instances.
Hence putting the header fields in the CMS attribute needs more complexity and 
message size, but does not provide any more security.

>3.  It is not clear to me that this approach is actually smaller than
>placing the headers to be protected into the attribute directly.
See the comment to 2.

Regards,

Lijun