Memory Hole protected e-mail headers

[Daniel Kahn Gillmor]

On Tue 2015-08-04 03:57:14 -0400, Daiki Ueno wrote:
> As I will eventually implement it in Emacs (Gnus),

yay!  glad to hear this.

> I would like to clarify a point: is it just meant to be a guideline,
> or aiming at an amendment to RFC 3156?

in the long term, we hope to make a formal specification.  there was
enough interest among a group of developers to experiment with different
mechanisms first, though.  We are hoping to gather development
experience and a rough consensus about how this works for existing MUAs
before submitting a formal RFC.

> If it is the former, it makes sense to reuse the valid MIME structure.
> However, the implementation could be complicated, as it basically
> means to add an exception based on the message structure.

It's not an exception based on message structure -- it's that the header
information is bound to the message body.

> On the other hand, if it is possible to revise RFC 3156, perhaps we
> could have a simpler message structure, something like:
>
>     |--- multipart/signed
>       |--- text/plain
>       |--- application/pgp-signature
>       |--- application/octet-stream (signed rfc822-headers)
>
> or:
>
>     |--- multipart/encrypted
>       |--- application/pgp-encrypted
>       |--- application/octet-stream
>       |--- application/octet-stream (encrypted rfc822-headers)

We've had similar proposals (see the "alternatives considered" section
at https://github.com/ModernPGP/memoryhole/blob/master/README.md).

> where the rfc822-headers part is appended to the message as an optional
> 3rd part.  This is an incompatible change, but I suppose this doesn't
> break most of existing MUAs, as long as they only look at the first two
> parts.

The particular structure you propose would be a violation of RFC 3156.
(https://tools.ietf.org/html/rfc3156#section-4 "The multipart/encrypted
MIME body MUST consist of exactly two body parts," and
https://tools.ietf.org/html/rfc3156#section-5 "The multipart/signed body
MUST consist of exactly two parts.").  We don't want to break existing
clients that read these rules strictly.

But other structures are possible, including this kind of approach:

└┬╴multipart/signed 1706 bytes
 ├┬╴multipart/mixed 850 bytes
 │├─╴text/rfc822-headers 228 bytes
 │└┬╴multipart/alternative 450 bytes
 │ ├─╴text/plain 86 bytes
 │ └─╴text/html 202 bytes
 └─╴application/pgp-signature 455 bytes

Because we want some (but not all) protected headers to be visible for
users of legacy (non-memoryhole-aware) MUAs, we might then need multiple
text/rfc822-headers parts (one part for visible headers inside an
encrypted message, the other for invisible).  In discussion last week,
several of us came to agreement that using the embedded MIME headers
seemed the cleanest for invisible headers, and that we'd reserve a
text/rfc822-header for explicitly visible ("force-display") headers.

> Also, like Werner's idea[1], it allows IMAP MUAs to retrieve the
> metadata part (the 3rd part) independently of the main part.  That
> would be useful for generating a summary.

Sure, but such a summary would necessarily be independent of the message
as a whole, right?  because the MUA couldn't fetch the whole message to
verify it.

So you'd get a verifiable and/or encrypted summary that might or might
not be legitimately bound to the message itself.  This seems like a
different goal than the goal of protecting e-mail headers.  If folks
want to talk separately about a separately-fetchable e-mail manifest, i
think that would be a distinct conversation.

> There are, of course, some drawbacks:
>
> - the 3rd part cannot be verified/decrypted with existing MUAs

in the scheme we're looking at, we don't expect the embedded headers
(the pieces in the MIME header blocks themselves) to be visible to
existing MUAs.  But we do expect the "force-display" part to be visible
to any MUA that can decrypt and can render DSNs, so we are aiming for
some level of backward compatibility here.

> - the 3rd part must be securely associated with the 2nd part, to prevent
>   the entire message structure from being crafted by attackers

This strikes me as a very tricky risk and a source of serious confusion
and UI/UX trouble.  I'd really rather not get into those particular
problems with this proposal unless we have a well-understood and simple
way out of them.  Do you see a way to resolve it cleanly?

    --dkg