Encrypting / Signing the mail subject?

[Daniel Kahn Gillmor]

Hi Albrecht--

Sorry for the late followup -- this has now been raised on
openpgp at ietf.org, so i'm moving the follow up there.

On Sun 2015-02-22 13:14:36 -0500, Albrecht Dreß wrote:
> I am currently working on the implementation of your proposal for Balsa [1], and would like to add a few comments.

I'm glad to hear this!

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

yep, this seems correct to me, but i don't know enough about the S/MIME
world to take the proposal there.  Maybe we should find some S/MIME
folks to chime in on this.

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

yep, you're right about this.

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

I think this also makes sense.


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

Are you thinking of having this line in the embedded header or in the
external header?  I'm not sure that this is useful to have in the
external header at all.  In particular, it won't be cryptographically
authenticated, and it won't be encrypted.  So an attacker could (for
example) strip out the external header and cause the MUA to ignore the
embedded part.

As for the embedded header, i'm not sure it's useful there either.  it
seems like a bit of a chicken-and-egg problem.


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

I agree about the ones you mention here. Mail-Followup-To also seems
relevant.

>> encrypted_headers:
>>  * (Subject,"ENCRYPTED SUBJECT")
>>  * (In-Reply-To,<omit>)
>>  * (References,<omit>)
>
> IMHO, the list of encrypted headers could be the same as above.

i think the list of encrypted headers might arguably be *all* of the
headers except for some dummy block that is generated per-message.

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

That seems more narrowly scoped, which is probably a good thing, but it
might be more brittle too; are there specific cases that you're trying
to carve out from my broader suggestion?


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

what kind of verification should an MUA do?  Is there any reason for an
MUA to prefer the external headers where the embedded headers and
external headers differ?

For encrypted headers, we'd *assume* that they would differ, right,
otherwise, there's nothing to gain from stuffing them inside the
encrypted section.

          --dkg