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

[Bernie Hoeneisen <[e-mail]>]

Hi Daniel

Thanks for this great document! I was finally able to read and assess it. 
I believe it is quite useful to assist in finding a solution for our 
chartered work item on Header Protection.

I have some questions related to the S/MIME examples:

1) The examples you provide for S/MIME have a simple structure, i.e. 
the body consist of a single MIME entity. How would an example look with 
the solution your are proposing, if it was a tree of MIME entities (e.g. 
text and html as multipart/alternative)?

2) In the examples (e.g. 9.2.) you are using "Content-Type: text/plain", 
however the content appears to be a full "message/rfc822" email. To me 
this looks like a mismatch between Media-Type and Content. To my 
understanding, whatever is in "Content-Type: text/plain" is unformated and 
is not guaranteed to be parsable. However your proposal suggests to parse 
this to replace the outer header fields. Have I misunderstood anything?

Looking forward to your answer!

cheers,
  Bernie

--

http://ucom.ch/
Modern Telephony Solutions and Tech Consulting for Internet Technology


On Mon, 4 Nov 2019, Daniel Kahn Gillmor wrote:

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