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