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

From: Hal Finney <[email-masked]>
Date: Thu, 17 Sep 1998 12:14:46 -0700

Ian Bell writes:

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

The Subject header would be one which would benefit most from encryption.
Subjects leak information about message contents.  Used carelessly, they
may expose the meaning of the message, or at least indicate which messages
contain sensitive information that might be targetted by an attacker.

However, replacing the Subject header only when the message is stored
for later reference misses another possible benefit.  Many archived
messages are never even referred to again.

What would be even better would be if the user's mail software decrypted
all messages in the incoming mailbox and "promoted" message/rfc822
headers up to the message header level.  Then the encrypted message
subjects could be displayed before the messages are read.  Busy email
users often use Subject headers to prioritize their mail handling.
But to make use of this capability, decrypted Subject headers must be
presented by the mail software beforehand.

I'd like to see a convention established for interpreting the
message/rfc822 type in this way, possibly when accompanied by some
other syntax.

Hal

---

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

> message/rfc822 type in this way, possibly when accompanied by some

I agree that this would be useful functionality -- I've suggested adding
it several times in the past, but was never able to get much support
for it.

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.

I personally favor a message/rfc822 parameter, but I can also see a case for
putting it elsewhere. What do other people think? If there seems to be
consensus that this needs to be on message/rfc822, I'd be happy to write
a short draft defining such a parameter.

				Ned

---

From: "Bart Schaefer" <[email-masked]>
Date: Thu, 17 Sep 1998 16:16:44 -0700

On Sep 17,  3:47pm, Ned Freed wrote:
> Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages

I think such a parameter would be useful in other situations besides
signed message content, so I support defining it in message/rfc822 rather
than in the signature.

If you do write a draft, please make mention of the interpretation of
this parameter when the message/rfc822 is included by reference via
message/external-body.

-- 
Bart Schaefer                                                   Zanshin
http://www.well.com/user/barts                   http://www.zanshin.com

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 17 Sep 1998 16:41:48 -0700

>a short draft defining such a parameter.

Given that OpenPGP is about to go to IESG last call in days, and S/MIME is
in it's last throes, and that the two groups are sure to do things
differently :-), I think a message/rfc822 parameter would be best.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "John W. Noerenberg" <[email-masked]>
Date: Thu, 17 Sep 1998 17:20:09 -0700

>MIME message/rfc822 content.

Putting the indicator the header exposes information about the message -- 
the decrypted contents of the message is supposed to replace the headers of 
the message.  Keeping it inside doesn't reveal this.

>a short draft defining such a parameter.

Maybe only the truly paranoid care about this, but it does violate a 
security principle.  Putting it inside the ciphertext probably complicates 
the MUA's job, but I don't think it's a particularly daunting complication.

john noerenberg
[email-masked]
  ----------------------------------------------------------------------
  --if we are to be saved, it will not be by Romans but by saints.
  -- Thomas Cahill, "how the Irish Saved Civilization", 1995
  ----------------------------------------------------------------------

---

From: "Bart Schaefer" <[email-masked]>
Date: Thu, 17 Sep 1998 18:51:45 -0700

On Sep 17,  5:20pm, John  W. Noerenberg wrote:
} Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
}
} At 3:47 PM -0700 9/17/98, Ned Freed 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 indicator the header exposes information about the message -- 
} the decrypted contents of the message is supposed to replace the headers of 
} the message.  Keeping it inside doesn't reveal this.

I think you misunderstand, John.  I believe the suggested format is for
the outer message to specify an encrypted Content-Type, and then for the
encrypted content to be a message/rfc822 with a parameter specifying that
its headers should replace the enclosing message's headers only after the
inner message is successfully decrypted.

This hides the parameter (indeed, it hides the entire nested message/rfc822
structure) inside the ciphertext, but allows a sufficiently clever UA to
present the contained message in place of the top-level message.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

---

From: Ned Freed <[email-masked]>
Date: Thu, 17 Sep 1998 22:55:50 -0700 (PDT)

> the message.  Keeping it inside doesn't reveal this.

The header indicator would be on the _inner_ header, not the outer one.
This is no more revealing than anything else that's "inside".

> the MUA's job, but I don't think it's a particularly daunting complication.

I'm talking about putting it inside the ciphertext (assuming encyption
is used, of course).

Amusingly enough, we've had objections in the past from security experts saying
that putting the MIME labelling of the encrypted content inside the encryption
is a Bad Thing. (Of course this didn't result in any changes.) So much for
agreement in principle ;-)

				Ned

---

From: Steve Hole <[email-masked]>
Date: Fri, 18 Sep 1998 09:55:19 -0600

> a short draft defining such a parameter.

So do I.   There are some reasonably complex interplays between cached and 
displayed structures in the presence of security - especially in an IMAP4 mail 
client.   Clients that cache MIME structures will often do things like cache
overlays for security multiparts so that their UI code doesn't have to know
anything about security -- that is all handled at the MIME abstraction level.
Also there has been discussion many times in the past of having "proxy 
security handling" for IMAP servers where the IMAP server handles decoding
encrypted messages on behalf of the client and sending the decoded content
over an encrypted data connection to the client.   Note that this is not a 
real situation now, but there are lots of reasons for people to want this 
behaviour in the future and it continues to be discussed.

The message/rfc822 solution would work transparently in the cases described 
above.   If the parameter is attached to the security multiparts then it is
possible that it will be occluded or lost by an MUA in the act of removing 
the security.   Putting it at the message/rfc822 level means that it will
always be exposed to UI code and the UI can decide how to "cook" the display
to show the right thing. 

Cheers. 

---  
Steve Hole                           
The Esys Corporation
Mailto:[email-masked]  
Phone:403-424-4922

---

From: "William H. Geiger III" <[email-masked]>
Date: Fri, 25 Sep 1998 15:21:52 -0500

-----BEGIN PGP SIGNED MESSAGE-----

In <[email-masked]>, on 09/18/98 
   at 10:55 AM, Steve Hole <[email-masked]> said:

>security handling" for IMAP servers where the IMAP server handles
>decoding encrypted messages on behalf of the client and sending the
>decoded content over an encrypted data connection to the client.   Note
>that this is not a  real situation now, but there are lots of reasons for
>people to want this  behaviour in the future and it continues to be
>discussed.

IMHO this is *not* a good idea.

The purpose of using end-to-end encryption is to avoid the use of unknown
3 party systems to relay encrypted data. Decrypting on the server then
re-encrypting via different means devalues the original encryption and
brings unnecessary exposure of the raw data. It would also require that
the decryption keys of the recipient be stored on the server adding an
added level of insecurity.

While I have played with "proxy security handling" in the past it has been
for out-bound encryption, in-bound signature verification, and policy
enforcement. In-bound decryption & out-bound signing should never be done
by anyone but the owner of the private keys.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: The best way to accelerate Windows is at escape velocity.