Subject: Re: Protection of header elements in an S/MIME message

From: Blake Ramsdell <[email-masked]>
Date: Tue, 01 Feb 2005 04:01:17 -0800

Jim Schaad wrote:
> I would recommend looking at RFC 3261 section 23.4.1 for a description of
> how SIP handled the comparison problem between the outer and inner headers.

This is by far the biggest area we wussed out on from my perspective. I 
think it was an intractable rathole, however, so I will defend my wussiness.

> The MASS group would not be open to saying that the correct answer is to
> have an embedded message that is promoted when found.  I don't know if this
> has been implemented by any S/MIME implemenation I would be surprised if it
> was widely adopted.

I'm not going to speculate on the adoption, but I would be curious what 
options are being considered, especially for the purpose of privacy 
protecting headers (not just digital signatures).

If it's the "list all the headers that are covered by the signature" 
approach which I think is used by both DomainKeys and IIM, we'd need to 
supplement that with a solution to handle privacy protected headers, in 
order for it to be suitable for S/MIME and/or OpenPGP.

I think there is some peril here, Jim -- in one sentence you warn us 
that MASS won't use an embedded header approach, right after you explain 
that SIP (and S/MIME) use that exact approach.

The good news is that means I'm completely offending only one of the 
four people we're supposed to help with the initial direction that I 
would suggest (using the current S/MIME strategy with better defined 
rules about header merging).

So should we take this on? Where do people stand on this? I've had 
enough time to recharge from the last beat-down I took from this issue 
that I'd probably suit up and take some hits.

Blake
-- 
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 1 Feb 2005 09:35:54 -0800

Blake,

MASS I think is going to fail because they are trying to solve the problem
without upsetting anybody by adding some attachements.  The solution that
MASS has proposed and SIP has adopted basically involve copying the headers
into a signed portion of the message and then specifying rules for how you
deal with mis-matched headers.

In both cases not all headers are being copied, only specific headers.  

Actually given the text that you have in the message draft, I consider it to
be useless and I don't know of anybody who is going to be able to deal well
with the message.  Its not very backwards compatable (i.e. no current
implementation will handle it well) and its not well defined for how header
comparision is done.

Since MASS is not using S/MIME in any way shape or form, I doubt you are
offending them.

jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Blake Ramsdell
> Sent: Tuesday, February 01, 2005 4:01 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 'Russ Housley'
> Subject: Re: Protection of header elements in an S/MIME message
> 
> 
> Jim Schaad wrote:
> > I would recommend looking at RFC 3261 section 23.4.1 for a 
> description 
> > of how SIP handled the comparison problem between the outer 
> and inner headers.
> 
> This is by far the biggest area we wussed out on from my 
> perspective. I think it was an intractable rathole, however, 
> so I will defend my wussiness.
> 
> > The MASS group would not be open to saying that the correct 
> answer is 
> > to have an embedded message that is promoted when found.  I 
> don't know 
> > if this has been implemented by any S/MIME implemenation I would be 
> > surprised if it was widely adopted.
> 
> I'm not going to speculate on the adoption, but I would be 
> curious what options are being considered, especially for the 
> purpose of privacy protecting headers (not just digital signatures).
> 
> approach which I think is used by both DomainKeys and IIM, 
> we'd need to supplement that with a solution to handle 
> privacy protected headers, in order for it to be suitable for 
> S/MIME and/or OpenPGP.
> 
> I think there is some peril here, Jim -- in one sentence you 
> warn us that MASS won't use an embedded header approach, 
> right after you explain that SIP (and S/MIME) use that exact approach.
> 
> The good news is that means I'm completely offending only one 
> of the four people we're supposed to help with the initial 
> direction that I would suggest (using the current S/MIME 
> strategy with better defined rules about header merging).
> 
> So should we take this on? Where do people stand on this? 
> I've had enough time to recharge from the last beat-down I 
> took from this issue that I'd probably suit up and take some hits.
> 
> Blake
> --

---

From: Blake Ramsdell <[email-masked]>
Date: Tue, 01 Feb 2005 12:37:00 -0800

> implementation will handle it well) and its not well defined for how header

Ouch. But yes, you're absolutely correct that nobody will be able to 
deal well with the message (with the definition of "well" being defined 
as "merging the headers in an unambiguous way that represents both the 
intent of the sender and the desire of the receiver").

> Since MASS is not using S/MIME in any way shape or form, I doubt you are

I am offending them in that the way I would solve this problem is by 
putting headers in an inner attachment, which you've pointed out (twice) 
is a non-starter for them. If we try to come up with a unified mechanism 
for doing this, my strawman would be:

1. Inner message/rfc822

2. Rules for merging headers

3. What to do about required external headers and how to placate people 
who require them ("placebo" headers)

If anyone's interested, there are at least two relevant threads in the 
archive:

"Protecting fields via message/rfc822 and merging issues"

"The subject line leakage problem"

Blake

---

From: [email-masked]
Date: Tue, 01 Feb 2005 20:09:09 -0800 (PST)

> 2. Rules for merging headers

FWIW, at some of the groundwork for header merging can be found in the
specification for how to handle message/partial in RFC 2046.

				Ned

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 1 Feb 2005 22:11:59 -0800

Blake,

It's actually my opinion that MASS is a non-starter because they are trying
too hard to makes sure nobody sees that it exists.  I think they should take
the hit of saying -- see I have MASS implemented.  I guess I get to try and
be loud at the IETF.

jim 

> From: Blake Ramsdell [mailto:[email-masked]] 
> Sent: Tuesday, February 01, 2005 12:37 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> > Actually given the text that you have in the message draft, 
> I consider 
> > it to be useless and I don't know of anybody who is going 
> to be able 
> > to deal well with the message.  Its not very backwards compatable 
> > (i.e. no current implementation will handle it well) and 
> its not well 
> > defined for how header comparision is done.
> 
> Ouch. But yes, you're absolutely correct that nobody will be 
> able to deal well with the message (with the definition of 
> "well" being defined as "merging the headers in an 
> unambiguous way that represents both the intent of the sender 
> and the desire of the receiver").
> 
> > Since MASS is not using S/MIME in any way shape or form, I 
> doubt you 
> > are offending them.
> 
> I am offending them in that the way I would solve this 
> problem is by putting headers in an inner attachment, which 
> you've pointed out (twice) is a non-starter for them. If we 
> try to come up with a unified mechanism for doing this, my 
> strawman would be:
> 
> 1. Inner message/rfc822
> 
> 3. What to do about required external headers and how to 
> placate people who require them ("placebo" headers)
>