ietf-smime
[Top] [All Lists]

Protecting fields via message/rfc822 and merging issues

2002-04-25 09:30:39

  I had an issue to resolve in draft-ietf-smime-x400wrap concerning the 
treatment of exterior SMTP header fields that are protected inside the X.400 
content.  As Jim Craigie and Ned Freed pointed out back in January, this is 
virtually the same problem as the "leakage" problem that has been extensively 
discussed.  I have since bounced a few ideas off of Blake Ramsdell from the 
RFC2633bis perspective.

  From the prior leakage thread, part of the solution seems to be encapsulation 
of the message (complete with header fields) in the message/rfc822 type and 
using that as our MIME type to be protected.  Another part was the agreement of 
some rules for merging the inner and outer headers on reception.  Lastly, is 
was suggested that we need an indicator to signal that header merging is 
required.

  The first part of the solution seems like a done deal.  I would note that we 
should be able to omit the "orig-date" and "from" fields (required by RFC 2822) 
from the inner message if we use the message/partial type vs message/rfc822 in 
the protected MIME object.  However, I think it would be wise if we simply 
allowed either type in this case.  I think that support for message/rfc822 is 
widespread, perhaps almost universal.  However, the level of support for 
message/partial is unknown (to me anyway).  Also, use of message/partial in 
this way isn't *exactly* for the reasons that RFC2046 describes its use.  Since 
Ned suggested it, I would guess he thinks it is, though.

  I've given some thought to the second part of the solution, and have a 
initial take on how I think we should do the merging of headers.  The options 
are, as I see them:

   a)   Concatenating the contents of the inner fields to the 
        like-named outer fields is simple and works, but has the 
        disadvantage that any deliberately misleading information
        added to the outer headers will be merged with the 
        protected headers -- potentially leading the recipients 
        to believe that there were additional recipients, extra 
        routing hops, etc.  Also a different rule will still be 
        needed for single-valued fields such as subject, 
        message-id, orig-date, and Importance (from MIXER).
        If such a merge is used, then duplicate detection must 
        also be performed.  It would not be reasonable to 
        present the user with a list of recipients showing 
        each recipient twice in the case that the inner and 
        outer messages were identical.

   b)   Discarding the outer 822 message and looking only at the 
        inner fields works provided that the inner message is 
        complete.  However, it does not work if only a partial 
        list of fields is included in the inner message.  Also, 
        since we negate the usefulness of the outer message in 
        all cases, we strongly encourage that it be a blank 
        "dummy" message.  This would effectively require the 
        application to do security processing even to display 
        the originator, subject line, etc. -- fields normally 
        shown in a mailbox view.  Blake also correctly pointed 
        out that this would squash useful headers like "trace" 
        (i.e., Received:...) and things added by list exploders.

   c)   Replacing outer 822 field values with inner field values 
        when available provides is a simple and effective as (a), 
        but does not suffer the same disadvantage.  Unlike (b), 
        it allows a partial list of fields to be included in the 
        inner 822 message, consisting of only those fields the 
        originator wants to have protected.  It encourages 
        vendors to include a complete header in the outer 
        message, thus allowing efficient preliminary application 
        processing on receipt except where a field is 
        deliberately omitted for confidentiality purposes.  
        Blake pointed out to me that in this case, the rules 
        for merging might be much more complex.

  Of these, I think I favor (c).  However, regardless of which option we 
choose, we should say something about using dummy values of the "orig-date" and 
"from" fields in the event that the originator wants to protect the 
confidentiality of that information.  Since these elements are required in an 
822 message, some dummy value MUST be provided in the outer message.  I don't 
think we need to necessarily specify what these values should be, but we should 
say something about the need for them.

  Regarding the third part of the problem, I think the options are pretty 
clear-cut but I am not happy with the answer.  The options as I see them are as 
follows:

12345678901234567890123456789012345678901234567890123456789012345

   a)   Add a signal in outer 822 message headers - This is bad
        because the signal itself can be modified affecting the 
        merging.

   b)   Add a signal in inner 822 message headers - This is bad
        because the signal is pointless.  You already know the 
        822 fields are there because you're already processing 
        them just to get the signal.

   c)   Add the same signal in the outer AND inner headers - This 
        doesn't really work any better than (a) because if the 
        outer indication is stripped, you don't know to look for 
        the inner one.

   d)   Include the signal in a CMS attribute - In a signed-only 
        or signed-and-encrypted message, the attribute should 
        probably be in the inner signedAttrs.  For encrypted-only 
        messages, it would have to go in the unprotectedAttrs, 
        but this is not optimal since it shares the disadvantages 
        of (a).  If this is the way forward, we have to have the 
        subsequent discussion of whether to use an existing or 
        new attribute.

  Obviously, my belief is that (d) is the only one that works.  However, I'm 
not happy with how it works in the encrypted-only case.  I'm also somewhat 
sensitive to "attribute bloat".  I therefore earnestly hope somebody else sees 
something that I've missed.

  Based on this line of thought, I would propose the following strawman 
additions to 2633bis (see below).  I think we'd also probably have to show some 
procedures or examples in section 3, but I did't want to go there until we 
collectively agree whether this is the right answer.  I've not yet come up with 
text for a "merging indicator" either.

Best regards,
Chris


=========================
Add to 2.4.1 or as a new 2.8:

In cases where protection of message headers is required, the protected message 
SHOULD be formatted according to [MSGFMT] including any headers that are to be 
protected.  The resulting message SHOULD comprise the innermost MIME data 
protected by CMS wrappers.  This inner message should be identified by one of 
the following MIME types:

 - message/rfc822

 - message/partial

Note that if message/rfc822 is used, [MSGFMT] requires that at least the "from" 
and "orig-date" fields be present in any such message.  If the originator does 
not wish to include these fields in the protected message, then message/partial 
SHOULD be used.

Under no circumstances shall the "trace" field be present in the inner message 
header.

The outer, unprotected header SHOULD generally omit any header fields that are 
otherwise included in the protected, inner message to prevent duplication.  
However, the minimum requirements of [MSGFMT] MUST be satisfied.  Header fields 
that are protected only by a SignedData wrapper SHOULD be duplicated in the 
outer message header if they provide desired functionality (e.g., MDN 
processing, Subject, X-Priority).  Header fields that are protected by an 
EnvelopedData wrapper MUST NOT be included in the outer message header.  If 
confidentiality of required header fields is desired, then fields containing 
dummy values MUST be included in the outer message header.  The selection of 
appropriate dummy field values is a local implementation matter.

When displaying the received S/MIME message to a recipient, the headers of the 
inner and outer messages MUST be merged to provide the appearance of a 
homogeneous messaging service.  Any field present in the inner message header 
SHALL replace any instances of the like-named field in the outer message 
header.  The resulting merged header SHALL be displayed to the user when the 
S/MIME message is "opened".  The merged header does not need to be preserved in 
the stored message.

Note that it is acceptable to use only the outer message header to affect 
display properties of message that are considered to be unopened (i.e., in 
message summary screens, etc.).



Add to section B:

   [MSGFMT]       Resnick, P. "Internet Message Format", RFC 2822, April 2001.

===================



<Prev in Thread] Current Thread [Next in Thread>