Subject: RE: Protecting fields via message/rfc822 and merging issues

From: "Bonatti, Chris" <[email-masked]>
Date: Wed, 1 May 2002 14:14:49 -0400

Hi Blake,

  See embedded comments below.

> > 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.
> 
> [bcr] Right, and I think this also includes header security 
> policies (not necessarily cryptography, but generic 
> rewriting) applied by the organization such as rewritten 
> address lines for host name hiding or adding disclosed 
> recipients.  I think this is where we start running into a 
> problem, and where we're in danger of failing.

  I don't see this as so big a problem with (c).  All you need to do to make sure that you don't override the outer fields is to ensure that recipients aren't originating those fields in the inner wrapper.  I could think of a number of ways to implement that.  In fact, it sounds like an excellent market discriminator.  :-)

> > 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.
> 
> [bcr] I think that the biggest problem I'm having is that 
> we're trying to mix authenticated / unauthenticated / 
> encrypted / unencrypted headers together and try to do the 
> right thing in an automated fashion.  As much as as we might 
> like to define this, I think the only option might be to take 
> the coward's way out and explain that the presentation and 
> merging of the headers are the problem of the client, and 
> that it's not possible to automatically mix them.  The 
> realization that I'm coming to is that there is no utility in 
> merging the headers, and we shouldn't even attempt it, and we 
> should document that the client needs to potentially make 
> decisions about how much to trust the internal headers vs. 
> the external headers, and it is their responsibility to 
> demonstrate the separation.

  I take the point I think you're making that there might be numerous GOOD ways of doing this depending on your assumptions, and that there might therefore not be a BEST way.  If a product is capable of showing you both and indicating what is authenticated or encrypted and what isn't, that might be best.

> [bcr] My thinking right now is along the lines of the 
> following, and I could very well be missing some important 
> issues:
> 
> 1. Use message/rfc822 with a full set of headers for the 
> inner protected content.  This is backward compatible, and 
> it's entirely possible that existing clients might even 
> process this correctly.
> 
> 2. Define placebo values for any outer message required 
> fields.

  I didn't figure we needed to do this, but it's more important in the scenario you suggest.  For "Date:" I would suggest 1/1/1970 (zero in UNIX, I think).  I guess I don't have a value to suggest for "From:".  The difficulty is that you need to have a minimally conformant address.  Anybody out there have a suggestion?

> 3. Explain the client considerations for presentation.

  I still think that we can do better than saying nothing here.  Perhaps we can describe a default rule similar to the option (c) I described, hanging under a SHOULD.  That way, if there was a good reason to do something different it's okay.

Best regards,
Chris

---

From: "Omer Hasret" <[email-masked]>
Date: Thu, 2 May 2002 10:04:23 +0200

Suggestion for "From:" field below,

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bonatti, Chris
Sent: mercredi 1 mai 2002 20:15
To: Blake Ramsdell
Cc: IETF SMIME WG
Subject: RE: Protecting fields via message/rfc822 and merging issues

Hi Blake,

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

  I don't see this as so big a problem with (c).  All you need to do to
make sure that you don't override the outer fields is to ensure that
recipients aren't originating those fields in the inner wrapper.  I
could think of a number of ways to implement that.  In fact, it sounds
like an excellent market discriminator.  :-)

> demonstrate the separation.

  I take the point I think you're making that there might be numerous
GOOD ways of doing this depending on your assumptions, and that there
might therefore not be a BEST way.  If a product is capable of showing
you both and indicating what is authenticated or encrypted and what
isn't, that might be best.

> 2. Define placebo values for any outer message required

  I didn't figure we needed to do this, but it's more important in the
scenario you suggest.  For "Date:" I would suggest 1/1/1970 (zero in
UNIX, I think).  I guess I don't have a value to suggest for "From:".
The difficulty is that you need to have a minimally conformant address.
Anybody out there have a suggestion?

--------------------- From: John Doe?

> 3. Explain the client considerations for presentation.

  I still think that we can do better than saying nothing here.  Perhaps
we can describe a default rule similar to the option (c) I described,
hanging under a SHOULD.  That way, if there was a good reason to do
something different it's okay.

Best regards,
Chris

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 16 May 2002 11:35:51 -0400

Chris & Blake:

My comments below, prefixed by [RH]...

To jog your memory, Chris made the original posting.
Blake replied with his comments prefixed with [bcr].

> >   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.
>
>[bcr] One way to think about message/partial is that this header privacy
>issue represents a new S/MIME idiom, and thus you need to write a bunch of
>code anyway to handle it.  The argument against message/partial would be
>that applications are using a separate MIME library which would choke on
>message/partial if it didn't already support it, and older clients that are
>unaware of this use might fail completely to process the message.  I would
>be more in favor of exploring message/rfc822, since I'm fairly certain that
>most GUI implementations just pop up a new message window.  This has the
>added benefit of automatically providing compartementalization of the
>protected headers, since those will be attributes of the new window.

[RH] I think that message/rfc822 should be the mandatory to implement 
approach.  If we want to explore message/partial, it should not be 
mandatory to implement.

>[bcr] Right, and I think this also includes header security policies (not
>necessarily cryptography, but generic rewriting) applied by the organization
>such as rewritten address lines for host name hiding or adding disclosed
>recipients.  I think this is where we start running into a problem, and
>where we're in danger of failing.
>
> >   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.
>
>[bcr] I agree -- I think this is going to be part of any work that we
>pursue.
>
> >   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.
>
>[bcr] I think that the biggest problem I'm having is that we're trying to
>mix authenticated / unauthenticated / encrypted / unencrypted headers
>together and try to do the right thing in an automated fashion.  As much as
>as we might like to define this, I think the only option might be to take
>the coward's way out and explain that the presentation and merging of the
>headers are the problem of the client, and that it's not possible to
>automatically mix them.  The realization that I'm coming to is that there is
>no utility in merging the headers, and we shouldn't even attempt it, and we
>should document that the client needs to potentially make decisions about
>how much to trust the internal headers vs. the external headers, and it is
>their responsibility to demonstrate the separation.
>
>[bcr] My thinking right now is along the lines of the following, and I could
>very well be missing some important issues:
>
>1. Use message/rfc822 with a full set of headers for the inner protected
>content.  This is backward compatible, and it's entirely possible that
>existing clients might even process this correctly.
>
>2. Define placebo values for any outer message required fields.
>

[RH] I would like to see a very simple approach.  The sender MUST put the 
same values in both the 822 header and the inner protected 
header.  Whenever possible, the recipient SHOULD display the values from 
the inner protected header.  We need to explain the cases where this will 
be difficult and the ones from the outer unprotected header need to be used.

Russ