Subject: RE: The subject line leakage problem

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

Jim:

The subject line issue is not a problem in the X.400 world.  SMTP carries 
the subject line is in the envelope.  The corresponding X.400 protocols 
(P1, P3, and P7) do not.  In X.400, the subject line is part of the content.

X.400 does have similar issues with TO, CC, and FROM.  Both SMTP and X.400 
would like to integrity protect these.

Russ

At 09:40 PM 12/17/2001 -0800, Jim Schaad wrote:

> >
> > At 1:37 PM -0800 12/17/01, Hallam-Baker, Phillip wrote:
> > >On the 'replace other headers', the problem there is that we
> > end up back in
> > >the rat-hole. People will propose all sorts of random
> > headers ad infinitum.
> >
> > That doesn't matter because RFC 2822 allows you to add as many
> > ill-conceived headers as you want to a message.
> >
> > >And others will counter that there are integrity problems
> > and then we have
> > >the interop issue, etc.
> >
> > There is no interop issue. What I proposed was that headers found in
> > the body part be *displayed* in the message, not substituted into the
> > message for storage. It's a user presentation hack, not a message
> > format hack.
> >
> > >I don't think that the problem is big enough to require a
> > whole new S/MIME
> > >spec to solve, just a minor tweak to implementations.
> >
> > Fully agree.
> >
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
> >
>
>First, this is an issue for signed as well as encrypted messages.  You
>want to protect the subject for signed messages as well as hide the
>subject for encrypted messages.
>
>Second, the solution of putting items here solves the problem for
>MIME/Internet mail.  But I think that we need to ask the X.400
>communities if they want the problem solved for them as well.
>
>Third, I worry about what happens for forms type messages.  Using the
>multipart may take care of this however.  We initially had a "bug" in
>Microsoft Outlook Express where we place the 822 headers in the body of
>the message, and then populated the display headers from this
>information.  I agree that this is a bad solution and should not be
>persued.
>
>Jim

============================================================================
================
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: [email-masked]
Date: Tue, 18 Dec 2001 09:28:54 -0800 (PST)

> 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

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.

The real reason the two differ is that X.400, unlike SMTP, in theory supports
the transmission of completely different forms of messages. Because of this you
can define, say, a new type of message for EDI. Or voice mail. These things are
called content types in X.400 parlance (not to be confused with a MIME content
type, which is a different thing). Any new content type can carry other content
within it, so a new content type can be nothing but a security enclosure with
the actual content nested inside. Several such security enclosures have been
defined, making it possible to secure X.400 as a whole just underneath the
envelope.

Now, in theory X.400 MTAs only deal with the envelope and are able to pass
arbitrary content types around, making it possible to introduce new ones at any
time. Howevr, I've found that sometimes this works in practice and often it
doesn't. Support for this in real world X.400 implementations is far from
uniform. At least part of the reason why this is so is because this capability
is rarely used, and rarely used capabilities are bound to have bugs, especially
given that most X.400 implementations are rarely updated these days.

SMTP doesn't have this ability to carry arbitrary sorts of messages around.
However, it isn't because it is impossible to add to SMTP or adding it hasn't
been considered. It is possible and it has been considered. The problem is that
it would mean upgrading every SMTP server out there to support it, and this was
and is not considered to be a viable thing to do. Because of this we instead
choose to use MIME facilities to define a security enclosure for SMTP. These
can be used to protect the subject and so forth, but it isn't as clean as the
X.400 scheme. It does, however, interoperate with existing SMTP servers, which
was and is a huge win.

> would like to integrity protect these.

If you're talking about header fields, then the issues for X.400 and SMTP
protection of this information are the same as for subject lines. If, on the
other hand, you're talking about envelope information, then yes, this is a
problem. There are various solutions in this space, but short of deploying a
public key infrastructure that every MTA can use to verify signed recipient
information, there is no real way to completely address the problem.

There are, however, things you can do in SMTP. One of them is to secure
a batch SMTP session (RFC 2442). There are a number of email systems
that support this approach. I suppose something similar is possible in 
X.400 (a P1 content type?), but AFAIK nobody has ever defined such a thing.

				Ned

---

From: Jim Craigie <[email-masked]>
Date: Tue, 18 Dec 2001 18:24:05 +0000

> given that most X.400 implementations are rarely updated these days.

I don't know what X.400 systems you are basing the above comment on. I've been involved with interoperability testing STANAG 4406 PCT (just CMS really), and we have not seen a single problem with an X.400 MTA being unable to relay the new content type. 

> X.400 (a P1 content type?), but AFAIK nobody has ever defined such a 

The X.400 standard defines a double-envelope content-type precisely to allow protection of the envelope where required.

Jim

---

From: Jim Craigie <[email-masked]>
Date: Tue, 18 Dec 2001 18:11:43 +0000

> X.400 does have similar issues with TO, CC, and FROM.  Both SMTP and 
> X.400 would like to integrity protect these.
> 
> Russ

X.400 also carries TO, CC, and FROM in the content.

> I would like to steer this discussion toward a signed attribute (a CHOICE 
> of IA5String and UTF8String (for international characters that are coming 
> 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.

> My initial cut at the header lines that ought to be included are FROM, 

When displaying the originator of a signed message. S/MIME clients should display the Name + RFC822Address from SubjectAltName from the Certificate that signed the message in place of the FROM from the RFC822 Header. They should do the same e.g. when constructing a reply. So I can see little point adding the FROM into this proposed signed attribute. And I think that Paul Hoffman's proposal (reproduced below) is more general, and altogether a better solution.

> Instead, how about encouraging the use of multipart/mixed which 
> starts with text/rfc822-headers. Any headers in that first part are 
> to replace the same headers on display only.

Jim

---

From: [email-masked]
Date: Wed, 19 Dec 2001 09:51:06 -0800 (PST)

> I don't know what X.400 systems you are basing the above comment on. I've
> been involved with interoperability testing STANAG 4406 PCT (just CMS really),
> and we have not seen a single problem with an X.400 MTA being unable to relay
> the new content type.

Well, maybe things have improved. It has been some time since I wrote the
support for this in PMDF-X400 and I no longer recall the specifics, but I don't
believe I was ever successful in getting this to work with another MTA. I
would have tried MAILbus 400 at a minimum and probably Exchange; the
exact timing of the work would have determined which of the several dozen
other MTAs were available for testing at the time.

> The X.400 standard defines a double-envelope content-type precisely to allow
> protection of the envelope where required.

Interesting. I don't recall that being possible. There is a way to nest
messages, but I didn't believe the support for included envelope information
was sufficient for it to be used for this.

				Ned