Subject: Encrypting RFC822 headers in S/MIME or PGP/MIME messages

From: Ian Bell <[email-masked]>
Date: Thu, 17 Sep 1998 11:02:49 +0100

(Apologies if this has been done to death in the past - I can imagine
Ned sighing about protracted discussions prior to RFC1847 - but I
couldn't find any discussion in the archives)

RFC2311 (SMIME) and RFC1847 (upon which PGP/MIME has been based) only
allow MIME headers to be protected by the encryption process. Was there
any discussion during the preparation of RFC1847 about the possibility /
desirability / feasibility of allowing general RFC822 headers to be
included in the encrypted part of the message?

The most obvious candidates for headers to be encrypted along with the
MIME headers would be Subject: and Disposition-Notification-To: (the
subject the sender may have intended to use may be too sensitive to use
as the subject of the open message: the sender may want any MDN to be
sent only when the message is decrypted), though cases could probably be
made for just about any RFC822 header.

Could (and should) any replacements for RFC2015 and RFC2311 be amended
to allow RFC822 headers to be sent encrypted, and for the decryption
process to swap any encrypted headers found with the corresponding
headers in the actual message?

As availability of encryption software becomes more widespread, many
end-users may find SMIME/PGP most useful as simply a transport security
mechanism rather than a way of securely storing messages. In any case,
MUAs implementing PGP or S/MIME probably already allow the user to save
the decrypted version of a message.

It would be good if there were an interoperable way of making the
stored, decrypted message reflect the message the author would have
liked to send in the first place. It would be particularly nice if the
author could transmit the intended subject of a message when this may be
too sensitive to put in the open message headers.

-- 
Ian Bell                                           T U R N P I K E  Ltd

---

From: Ned Freed <[email-masked]>
Date: Thu, 17 Sep 1998 11:04:15 -0700 (PDT)

> included in the encrypted part of the message?

There were extensive discussions of this. I probably have several hundred
messages archived on this topic, and there were also WG discussions and several
private meetings where the design team covered this area exhaustively.

The basic conclusion was (and is) that this dog doesn't hunt and cannot be made
to hunt. The problem is that message headers are routinely rewritten by
intervening MTAs as messages are transferred via SMTP. They are refolded,
reordered, addresses are converted from one form to another, encoded
words are added or removed, entire fields are added or deleted.

And all these activities are the rule, not the exception. And it is far more
likely to happen to fields it makes sense to sign, such as subject, to/cc/bcc,
comments, etc. than to any others.

In short, if you want to keep the transports from modifying things, you cannot
put them in the primary header. You either have to put them in the body. And
given this, MIME provides the obvious means to do this if that's what you're
after -- nested messages.

> headers in the actual message?

There is no need to do this. All you need to do is use MIME encapsulation
to put the real headers into the body of the message.

One thing that would be nice is if there was a way to say in the signature
information that the inner message is actually supposed to replace the outer
container message. (This could also be done as a parameter to message/rfc822
if need be, although there are arguments for doing it in the signature.

There is one other thing that is missing, however, and that is a means of
encapsulating the entire message including the envelope. There are many
applications where the envelope itself is sensitive and needs end-to-end
protection.

And there is a proposal on the table to deal with this:
draft-freed-bsmtp-02.txt. This defines envelope encapsulation and the semantics
that necessarily follow from doing it.

> the decrypted version of a message.

Sure.

> too sensitive to put in the open message headers.

See above.

				Ned

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Fri, 18 Sep 1998 13:00:21 +0900

Ian,

From: Ian Bell <[email-masked]>
Subject: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
Date: Thu, 17 Sep 1998 11:02:49 +0100

> headers in the actual message?

To my best knowledge, there is a non-official scheme to do this. Here
is an example:

X-PGP-Sig: 2.6.3ia Subject,From,X-Mailer
        iQCVAwUBM84wngE7m572a9utAQETEgQAwcL38QVdZbkHuW4Mblmje17deuI85R1j
        4yGiDlb1enRDSUyGiLCmk8YphNDiLdKKlMV3Z0opzREUW9Q+sb8fr5s1QXMJhvXs
        7hi7s4+V00rjgbqbqXVNiajKiKfVxd7JTRfe0UIZuOljnURP1ZCMlSRD1rDoCEAg
        1vunQv6QYj4=
        =hvn0

This is a header field to be stored in a header, mixed with fields to
be proteced such as Subject, From, and X-Mailer.

If you are interested, I will ack the author to explain his
experiences.

--Kazu

---

From: Ian Bell <[email-masked]>
Date: Fri, 18 Sep 1998 13:24:02 +0100

In article <[email-masked]>, Ned Freed
<[email-masked]> writes
>private meetings where the design team covered this area exhaustively.

Thought as much :-)

>comments, etc. than to any others.

I was just thinking of encryption, but of course a scheme that covers
signing headers as well as encrypting them is so much the better.

>to put the real headers into the body of the message.

My problem with that was that the intent of encapsulation would not be
clear. However, putting a parameter on the message/rfc822 to make it
clear seems to solve the problem completely.

Later, you wrote:

>Its clear that this indicator has to be on the "inside", since you want the
>signature to be able to cover it. This then begs the question of whether
>it should be an attribute of the signature/encryption facility or of the 
>MIME message/rfc822 content.

Putting the parameter at the encryption header level announces that
there are hidden headers that will be substituted, though maybe that's
too minor a security breach to worry about.

A parameter at the message/rfc822 header level would in one extension
cover signed, encrypted, encrypted-then-signed and encrypted-and-signed
messages, and would even allow messages to be resent without using
Resent- headers if anyone has a use for that!

>
>-- I've suggested adding
>it several times in the past, but was never able to get much support
>for it.
>

Hopefully this thread will have demonstrated sufficient support.