Encrypting / Signing the mail subject?

[Albrecht Dreß]

A non-text attachment was scrubbed...
Name: not available
Type: text/rfc822-headers
Size: 460 bytes
Desc: not available
URL: </pipermail/attachments/20150222/274b1d6e/attachment-0001.bin>
-------------- next part --------------
Hi Daniel:

I am currently working on the implementation of your proposal for Balsa [1], and would like to add a few comments.

Am 16.01.15 21:29 schrieb(en) Daniel Kahn Gillmor:
> PGP/MIME messages are the only reliably structured mail OpenPGP e-mail messages anyway [0].

As your proposal is fully transparent, I think it could also be used for RFC 2633 S/MIME (i.e. multipart/signed; application/pkcs7-signature as well as for application/pkcs7-mime).

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

In your example, you added a "charset" parameter to the mime type.  IMHO, this contradicts the RFC 6522 statement that it shall have neither required nor optional parameters.  I think it's unneeded anyway, as all headers shall be encoded as required by RFC 2047.  Applying the "usual" header parsing rules will of course decode them properly.

The whole part /should/ be encoded quoted-printable, though, as required by RFC 3156, sect. 3.  The headers /should/ be 7-bit clean, but you never know for sure...

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

What do you think about always adding a header, e.g. "X-Protected-Headers", which includes a short info about the purpose of that part (as in this example)?  Otherwise, it might be somewhat confusing if such a MUA displays the header twice.  If we can agree on a standard name, it also assists MUA's to detect the block.

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

As including more headers doesn't cost much, I propose to also add the following:
- Reply-To: and Disposition-Notification-To:.  Rationale: an attacker might tamper them as to provoke sending information to arbitrary recipients (at least for inattentive users, or for MUA's sending MDN's automatically).
- References: and In-Reply-To:.  Rationale: avoids breaking the threading information by an attacker.

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

IMHO, the list of encrypted headers could be the same as above.

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

I think this should read: "if the text/rfc822-headers part is
* the first part of a multipart/mixed, which in turn is the first part of the top-level multipart/signed or application/pkcs7-mime, or
* the first part of the top-level decrypted multipart/mixed for unsigned, but encrypted messages."

> This prevents the receiving MUA from applying text/rfc822-headers from a forwarded (attached) signed/encrypted message.

It would make sense, though, to verify if the headers of forwarded and signed message/rfc822 parts against the (embedded) text/rfc822-headers parts.

> 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)?

IMHO, a whitelist is easier to handle.

Any comments?  Just my €0.01...

Cheers,
Albrecht.

[1] <https://pawsa.fedorapeople.org/balsa/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: </pipermail/attachments/20150222/274b1d6e/attachment-0001.sig>