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

From: Alexey Melnikov <[email-masked]>
Date: Thu, 9 Jul 2020 10:43:42 +0100

Hi Bernie,

Just to close the loop on this:

On 14/06/2020 15:10, Bernie Hoeneisen wrote:
> 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?

So the protected body part in that example is:

    Content-Type: text/plain; charset="us-ascii"; protected-headers="v1"
    From: Alice Lovelace <[email-masked]>
    To: Bob Babbage <[email-masked]>
    Date: Tue, 26 Nov 2019 20:03:00 -0400
    Subject: The FooCorp contract
    Message-ID: <[email-masked]>

    Bob, we need to cancel this contract.

    Please start the necessary processes to make that happen today.

    (this is the 'smime-multipart-signed' message)

    Thanks, Alice
    --
    Alice Lovelace
    President
    Example Corp

This is a correct body part (using RFC 2045 terminology) of media type 
"text/plain". Presence of "From" or "Subject" doesn't change its media 
type. BNF for body part header is described in Section 3 of RFC 2045:

      MIME-part-headers := entity-headers
                           [ fields ]
                           ; Any field not beginning with
                           ; "content-" can have no defined
                           ; meaning and may be ignored.
                           ; The ordering of the header
                           ; fields implied by this BNF
                           ; definition should be ignored.

Best Regards,

Alexey

> 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/
>>
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Bernie Hoeneisen <[email-masked]>
Date: Thu, 9 Jul 2020 12:50:19 +0200 (CEST)

Hi Alexey / Daniel

Thanks for your explanations on the 2nd item.

The 2nd item has been resolved in the meantime, as it was indeed a 
misconception on MIME (as mentioned in my question).

Rg. the 1st item: To better determine, what advantages and drawbacks the 
different options have, I (still) believe more examples would be helpful, 
e.g.:

a) A more complicated example for S/MIME (as suggested in my last mail). 
I guess, this would look like this:

    └─╴application/pkcs7-mime smime-type="enveloped-data"
     ↧ (decrypts to)
     └─╴application/pkcs7-mime smime-type="signed-data"
      ⇩ (unwraps to)
      └┬╴multipart/mixed ← Cryptographic Payload
       ├┬╴multipart/alternative
       │├─╴text/plain
       │└─╴text/html
       └─╴text/x-diff ← attachment

b) More examples that use media type "message/rfc822" as per RFC 8551 
(and the first option in our upcoming I-D). Something along the lines of:

    └─╴application/pkcs7-mime smime-type="enveloped-data"
     ↧ (decrypts to)
     └─╴application/pkcs7-mime smime-type="signed-data"
      ⇩ (unwraps to)
      └┬╴message/rfc822 ← Cryptographic Payload
       └┬╴multipart/mixed
        ├┬╴multipart/alternative
        │├─╴text/plain
        │└─╴text/html
        └─╴text/x-diff ← attachment

c) More examples that use media type "message/rfc822" as per 
RFC 8551 and legacy display part. Something along the lines of:

    └─╴application/pkcs7-mime smime-type="enveloped-data"
     ↧ (decrypts to)
     └─╴application/pkcs7-mime smime-type="signed-data"
      ⇩ (unwraps to)
      └┬╴multipart/mixed ← Cryptographic Payload
       ├─╴text/plain ← Legacy Display Part
       └┬╴message/rfc822
        └┬╴multipart/mixed
         ├┬╴multipart/alternative
         │├─╴text/plain
         │└─╴text/html
         └─╴text/x-diff ← attachment

(Similar examples for PGP would also be helpful.)

@Daniel: Would you be able to provide such examples (similarly as in your 
I-D) that can be tested with different MIME Parsers and MUAs?

cheers
  Bernie

PS: I hope the UTF-8 character used above display well in all your MUAs...

On Thu, 9 Jul 2020, Alexey Melnikov wrote:

>       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.
>
>       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?
> 
> This is a correct body part (using RFC 2045 terminology) of media type "text/plain". Presence of "From" or "Subject" doesn't change its media type. BNF for body part header is described in Section 3 of RFC 2045:
>