Subject: [openpgp] Fwd: Encrypting / Signing the mail subject?

From: David Leon Gil <[email-masked]>
Date: Mon, 16 Mar 2015 15:17:10 -0700

(And, actually, as I assume DKG won't mind me noting his proposal on
gnupg-devel here.)

---------- Forwarded message ----------
From: *Daniel Kahn Gillmor* <[email-masked]>
Date: Friday, January 16, 2015
Subject: Encrypting / Signing the mail subject?
To: Hanno Böck <[email-masked]>, [email-masked]

despite the fact that the IETF's OpenPGP WG is closed, i think that
[email-masked] <javascript:;> mailing list is still active.  It may be
worth
discussing issues like this in that forum as well, to get a wider range
of buy-in.

. . .

Embedded Header Proposal
========================

Here's a counter-proposal to consider, which relies on PGP/MIME.
PGP/MIME messages are the only reliably structured mail OpenPGP e-mail
messages anyway [0].

A normal PGP/MIME signed text/plain message structure looks like this
(Content-Type of each part is shown) [1]:

A └┬╴multipart/signed
B  ├─╴text/plain
C  └─╴application/pgp-signature [signature.asc]

I propose sending a message with an additional text/rfc822-headers [2] part
injected as a sub-part in the message, like this:

D └┬╴multipart/signed
E  ├┬╴multipart/mixed
F  │├─╴text/rfc822-headers inline [header]
G  │└─╴text/plain
H  └─╴application/pgp-signature [signature.asc]

the text/rfc822-headers mime type is defined here:

In this case, only select headers would be embedded (those headers that
are to be signed/encrypted.  The embedded header part (F, above) should
be Content-Disposition: inline, and should be subject to all the usual
rules of parsing mail message headers.

This allows senders to sign arbitrary headers (not just Subject:), and
it works for both signing and encryption.

For sending and receiving MUAs unaware of this convention, no changes
need to be made; at worst, a receiving MUA can simply ignore the
text/rfc822-headers MIME part.  But since it's of type text/* and
Content-Disposition: inline, they may choose to just render it directly
at the top of the message, which would look very similar to your
proposal.

This e-mail message contains a signed set of embedded headers in the way
i've proposed.  How does it render in your unaware MUA?  feel free to
send me a private report if you like.

for aware MUAs, we'd need to spec out the detailed rules:

Message handling guidelines for embedded-header-aware MUAs
==========================================================

composing (sending) MUAs (signed messages)
------------------------------------------

the composing MUA, when crafting a signed message, needs to know which
header fields should be included.  By default, this might just be
Subject:, though maybe it's worth including Date: as well.

This could be represented in MUA configuration as a simple list of
headers:

signed_headers:
 * Subject
 * Date
 * From
 * To
 * Cc

composing (sending) MUAs (encrypted messages)
---------------------------------------------

the composing MUA, when crafting an encrypted message, needs to know
which header fields should be encrypted, and what the default
replacement for that field should be.

This could be represented in MUA configuration as a list of
(header,value) pairs:

Some headers may have a value marked as <omit>, to indicate that the
header should not be exposed publicly at all, but should only be present
in the embedded header.

encrypted_headers:
 * (Subject,"ENCRYPTED SUBJECT")
 * (In-Reply-To,<omit>)
 * (References,<omit>)

Ideally, these lists would be shared across clients and would have sane
defaults, since shared configuration increases ambiguity to an attacker.

(note that the choices described above would hide threading information
>From an attacker)

composing (sending) MUAs (encrypted+signed messages)
----------------------------------------------------

some messages are both signed and encrypted.  an MUA which composes such
a message should craft the embedded headers using the union of all
headers in both signed_headers and encrypted_headers, sign and encrypt
the message, and only then replace or omit the external header fields as
directed by the encrypted_headers configuration.

receiving MUAs (encrypted messages)
-----------------------------------

An MUA that receives an encrypted message with a text/rfc822-headers
part should loop through the embedded headers.  for each embedded
header, it should compare it with the external header of the same label.

If they differ, the MUA should treat the message as though the embedded
header is the correct value.

receiving MUAs (signed messages)
--------------------------------

An MUA that receives a signed message with a text/rfc822-headers part
should loop through the embedded headers.  for each embedded header, it
should compare it with the external header of the same label.

If they differ, the MUA should treat the message as though the embedded
header is the correct value.  The MUA may want to expose the unsigned
value of that header to the user with a warning that it is unsigned.

Whether they differ or not, the MUA should indicate to the user that the
signed parts are signed, and should make a visible distinction between
signed and unsigned headers.

-------

open questions
==============

redundant header parts?
-----------------------

We'd also need to define what happens if more than one
text/rfc822-headers part shows up in a multipart message -- most simply,
we could say that we only process text/rfc822-headers if it happens to
be the first non-multipart part within the multipart/signed or
multipart/encrypted part.  This prevents the receiving MUA from
applying text/rfc822-headers from a forwarded (attached)
signed/encrypted message.

disallowed headers?
-------------------

Are there any headers that *should not* be permitted to be rewritten in
this way?  For example, what would it mean if someone were to embed a
Received: header?  a Message-ID header?

If some are unacceptable, should we have a blocklist (allow arbitrary
headers by default, only reject certain ones) or an allowlist (block
arbitrary headers by default, only accept certain ones like Subject and
date)?

redundant headers
-----------------

within a single header block, there could still be more than one
instance of a given header.  The message itself could also have multiple
copies of a given header (e.g. the Comments and Keywords fields [3]).
If multiple copies of a given header appear in either the exposed header
or the embedded header, and their values differ, how should we resolve
the difference?

-------

[0] https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/

[1] MIME message structure representations shown here are generated from
    actual messages via devel/printmimestructure from the notmuch git
    repository at git://notmuchmail.org/git/notmuch

[2] text/rfc822-headers:   https://tools.ietf.org/html/rfc6522#section-4

[3] Comments and Keywords: https://tools.ietf.org/html/rfc5322#section-3.6.5

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Sat, 28 Mar 2015 18:41:38 +0100

On Sat, 2015-03-28 at 15:19 +0100, Albrecht Dreß wrote:
> And, yes, I missed RFC 6648 which deprecates X-something headers -
> maybe a "Comments:" header might be used instead of it?
Just don't use a generic term like comments for anything which would be
really machine-readed.
That always causes troubles sooner or later.

Cheers,
Chris.