[lamps] Common Protected Header practice documented (was "Memory Hole")

[Daniel Kahn Gillmor <[e-mail]>]

Hey LAMPS folks--

At (and shortly after) the OpenPGP e-mail summit [0], a group of MUA
developers went ahead and documented the way that several of us have
been handling header protection in a backward-compatible way.

This bundle of techniques used to be known as "Memory Hole" a while back
but for a couple years now we've been calling it just "Protected
Headers", since "Memory Hole" was confusing and weird for some people.

Hopefully this document can serve as input for appendix A.1.1 of
draft-ietf-lamps-header-protection-requirements-01 [1].

The new draft is at:

    https://datatracker.ietf.org/doc/draft-autocrypt-lamps-protected-headers/

(it's "draft-autocrypt-…" because it's not a single-person draft, and
because most of the experience we have in this comes from
implementations actively engaged in the Autocrypt project [2]. But it is
not a formal part of the Autocrypt specifications at this time, and it
is not intended to ever be limited to Autocrypt implementations.)

To whet your appetite, the summary:

-------
   The Protected Headers scheme relies on three backward-compatible
   changes to a cryptographically-protected e-mail message:

   *  Headers known to the composing MUA at message composition time are
      (in addition to their typical placement as Exposed Headers on the
      outside of the message) also present in the MIME header of the
      root of the Cryptographic Payload.  These Protected Headers share
      cryptographic properties with the rest of the Cryptographic
      Payload.

   *  When the Cryptographic Envelope includes encryption, any Exposed
      Header MAY be _obscured_ by a transformation (including deletion).

   *  If the composing MUA intends to obscure any user-facing headers,
      it MAY add a decorative "Legacy Display" MIME part to the
      Cryptographic Payload which additionally duplicates the original
      values of the obscured user-facing headers.

   When a composing MUA encrypts a message, it SHOULD obscure the
   "Subject:" header, by using the literal string "..." (three U+002E
   FULL STOP characters) as the value of the exposed "Subject:" header.

   When a receiving MUA encounters a message with a Cryptographic
   Envelope, it treats the headers of the Cryptographic Payload as
   belonging to the message itself, not just the subpart.  In
   particular, when rendering a header for any such message, the
   renderer SHOULD prefer the header's Protected value over its Exposed
   value.

   A receiving MUA that understands Protected Headers and discovers a
   Legacy Display part SHOULD hide the Legacy Display part when
   rendering the message.
-------

Please don't be put off by the draft length -- nearly half of the
document consists of test vectors that implementers can use to verify
their ability to consume well-formed, protected-header messages.

I'd be happy to present this work in Singapore if there's space on the
agenda.

Feedback, critiques, comments, etc, are all welcome.

Regards,

        --dkg

[0] https://wiki.gnupg.org/OpenPGPEmailSummit201910
[1] https://tools.ietf.org/html/draft-ietf-lamps-header-protection-requirements-01#appendix-A.1.1
[2] https://autocrypt.org/