Subject: Re: The subject line leakage problem

From: "Housley, Russ" <[email-masked]>
Date: Tue, 18 Dec 2001 09:42:21 -0500

Phil:

Thanks for raising this issue.

After the intended-recipients discussion, it was clear to me that several 
RFC 821 header lines needed various forms of protection.  The level of 
automated checking is different for each of them.  Some need 
confidentiality, and others do not (and cannot without disrupting the mail 
delivery).

I would like to steer this discussion toward a signed attribute (a CHOICE 
of IA5String and UTF8String (for international characters that are coming 
soon)).  The attribute would contain a subset of the header lines.

My initial cut at the header lines that ought to be included are FROM, TO, 
CC, SUBJECT, and DATE.  So, for Phil's message that started this thread, 
the attribute would contain:

     From: "Hallam-Baker, Phillip" <[email-masked]>
     To:
     Cc: [email-masked]
     Subject: The subject line leakage problem
     Date: Mon, 17 Dec 2001 10:34:39 -0800

I think that the content-hints attribute defined in RFC 2634 should be used 
to carry the real subject line when the RFC 821 header carries a masked 
subject line.

Russ

At 10:34 AM 12/17/2001 -0800, Hallam-Baker, Phillip wrote:
>All,
>
>         One of the ongoing problems with people using PGP is that people
put
>confidential information in the mail subject lines, eg:
>
>Subject: Proposed purchase of Excite@Home
>Subject: Your STD test results
>Subject: Planned head count reduction
>
>         etc.
>
>So over the years there have been plenty of fixes involving CMS encrypted
>attributes etc. which gets into the rat hole of what other headers to add
>in.
>
>So instead of that how about the following fix:
>
>1) A Best Current Practice Draft that says
>2) Clients SHOULD offer users the option of replacing the subject line on
>confidential messages and carrying the subject as the first line in the
body
>of the message.
>
>
>So the above message would become
>
>Subject: Confidential
>Subject: Confidential
>Subject: Confidential
>
>And when opened we get something like:
>
>Subject: Confidential
>
>Subject: Proposed purchase of Excite@Home
>
>Alice,
>         Yadda Yadda Yadda ....
>
>
>         So, no need for any modification of existing specs, complete
>backwards interop and the bug in the spec gets fixed.
>
>                 Phill
>
>Phillip Hallam-Baker FBCS C.Eng.
>Principal Scientist
>VeriSign Inc.
>[email-masked]
>781 245 6996 x227
>
>
>

============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 18 Dec 2001 13:18:13 -0500

Ned:

Thanks for correcting the details.

RFC 822 defines a header, which is clearly outside the SMTP envelope.  The 
RFC 822 header is separated from the content by a blank line.  The subject 
line is before this blank line, so it cannot be protected by a content 
encapsulation protocol.

Sorry for any confusion that may have resulted from the loose terminology 
in my first message.

Russ

At 09:28 AM 12/18/2001 -0800, [email-masked] wrote:
> > The subject line issue is not a problem in the X.400 world.  SMTP
carries
> > the subject line is in the envelope.
>
>On the contrary, in SMTP the subject field is part of the content, not part
>of the envelope. Specifically, it is part of the message header.
>
> > The corresponding X.400 protocols
> > (P1, P3, and P7) do not.  In X.400, the subject line is part of the 
> content.
>
>This part is correct, but it fails to get at the reason why X.400 and SMTP
>differ in their ability to protect the entire content of a message end to
>end.

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 18 Dec 2001 15:24:20 -0500

Jim:

I was thinking about the upcoming need to support international character 
sets.  The DNS is going to support more than ASCII in the near future.

Russ

At 06:11 PM 12/18/2001 +0000, Jim Craigie wrote:
> > soon)).
>Since ASCII characters are encoded identically in a UTF8String and an 
>IA5String there is no need to introduce a CHOICE - keep it simple and just 
>define the syntax as UTF8String.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 27 Dec 2001 05:07:44 -0800

All,

	I for one would be all in favor of putting in place a
fully spec'd kosher solution here. 

	However the issue of introduction and backwards compatibility
need to be carefully considered. We don't want to have people not
implement the full fix because they are waiting for others to deploy.

	I would like to keep the hack on the table as an interim
patch for the time being. Certainly the sooner we stop leaking
subject lines the better

	I don't consider the security of any other headers to be 
particularly serious. Routing info is disclosed as a matter of course 
and the existence of mailling lists and byzantine forwarding makes
the intended recipient issue impossible to resolve.

		Phill

> -----Original Message-----
> From: Housley, Russ [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2001 9:42 AM
> To: Hallam-Baker, Phillip
> Cc: [email-masked]
> Subject: Re: The subject line leakage problem
> 
> 
> Phil:
> 
> >         One of the ongoing problems with people using PGP 
> is that people put
> >confidential messages and carrying the subject as the first 
> line in the body
> >of the message.
> >
> >

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 27 Dec 2001 10:20:56 -0500

Paul:

I was trying to be a good reporter.  I was not trying to put any spin 
(positive or negative) on the comments.  I will try to answer your
questions.

>>First, he is pleased to see the working group addressing the subject line
>>issue.  While this issue was not part of his initial concerns, he agrees
>>that it deserves a solution.
>
>Non-To: headers are of concern, but they are a completely different beast 
>than To: headers with respect to Don's draft.

Don acknowledges the difference.  He is glad that we are discussing a 
solution that addresses the issues that he raised as well as issues raised 
by others.

>>Second, he would like to see the working group mandate the inclusion of
the
>>TO, CC, and FROM lines whenever encryption and signature are used
>>together.
>
>Why only those headers? Other headers are also important. Date: comes to
mind.

These are the ones that Don and I discussed on the phone.  Further, Don 
acknowledges the issues with BCC and mail lists.

I do not think that DATE is particularly important if the signing-time 
attribute is used.

>>   As he explained in is I-D, he does not believe that many users
>>are able to understand the interaction between signing, encrypting, or
both
>>(in either order).
>
>True.
>
>>Third, he would like to see the TO, CC, and FROM lines automatically
>>processed by the receiving mail agent software.  While he acknowledges the
>>issues associated with BCC, mail lists, and so on, he firmly believes that
>>the people writing the software understand the situation much better than
>>mass market e-mail users.
>
>True.
>
>>Fourth, he would like to see the working group mandate the inclusion of
the
>>TO, CC, and FROM lines whenever the sending agent or the receiving agent
>>represents a human.  In other words, computer-to-computer communications
>>may not need these to be protected.
>
>And we determine that how?

I will offer my interpretation of his comments.  When someone builds a 
piece of software, they have a target market for that software.  When mail 
agent software is intended for computer-to-computer communications, he not 
too concerned because, as stated above, Don has more faith in programmers 
than mass market mail system users.

 From a specification point of view, it would be much easier to require the 
inclusion of these fields all of time.

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 27 Dec 2001 14:34:54 -0500

Thanks Ned.  This approach makes sense, but this is not what I thought you 
meant by your first posting.

Russ

At 09:19 AM 12/27/2001 -0800, [email-masked] wrote:
> > It seems that message/rfc822 is used to encapsulate an entire message.
In
> > this case, we want to repeat a subset of the RFC 822 header lines from
the
> > current message, and we never want to duplicate the body.
>
>I think this is the wrong way to go about it. If you want to protect an
>entire message including its outermost headers, simply place the entire
>message inside your protective envelope using the message/rfc822 construct.
>Then strip the outer, unprotected header to its barest essentials.
>
>The process is then reversed by the receiver.
>
>This approach uses nothing but existing media types and can leverage
existing
>support for message/partial and message/rfc822. It doesn't require that 
>you add
>additional fields to your structures, with all the attendant deployment
>problems that will cause.
>
> > The required support for message/rfc822 is attractive, but I am not sure
> > that is has the correct semantics.  Can you explain your idea further?
>
>See above. At most what's needed here is an indicator in the protected
content
>that it is to be merged with the outer message header on receipt. That
could
>easily be done with either a message-context or a content-disposition field
in
>the protected content.
>                                 Ned