Encrypting / Signing the mail subject?

[Albrecht Dreß]

A non-text attachment was scrubbed...
Name: not available
Type: text/rfc822-headers
Size: 552 bytes
Desc: not available
URL: </pipermail/attachments/20150322/170660ef/attachment-0001.bin>
-------------- next part --------------
Hi Daniel:

Thanks a lot for your input!

Am 17.03.15 00:28 schrieb(en) Daniel Kahn Gillmor:
> this has now been raised on openpgp at ietf.org, so i'm moving the follow up there.

Thanks for that hint - I also subscribed there.

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

Only in the embedded, signed headers block.

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

Yes, I fully agree with you!

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

Hmmm, yes, thinking again about it, you're right.  The only use of that header would be informing the recipient of a message about the purpose of this part if the MUA does not perform any further action with it (see the attached screen shot as example).

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

Good point, I missed that one.

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

What do you mean with "some dummy block"?

BTW, the Message-Id header may also leak information if uses the recommended form of RFC 5322, sect 3.6.4 (domain or FQDN as right-hand side).  The 'dot-atom-text - "@" - dot-atom-text' format with random data on both sides (which is also explicitly allowed) should be preferred IMHO, as long as it is guaranteed to be unique.

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

I think your definition would try to match the text/rfc822-headers part to the message headers in the following weird case:

multipart/signed
  +- multipart/mixed   <-- message #1 does *not* contain protected headers
  |   +- text/pain
  |   +- message/rfc822   <-- forwarded message #2 *with* protected headers
  |       +- multipart/signed
  |           +- multipart/mixed
  |           |   +- text/rfc822-headers   <-- protected headers of forwarded message #2
  |           |   +- text/plain
  |           +- application/pgp-signature
  +- application/pgp-signature

Here, text/rfc822-headers *is* the first non-multipart part within a multipart/signed, but it doesn't belong to the (top-level) message #1, so it's wrong to compare them.  I think, my definition would catch this case.

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

No, I think that the headers validation should be applied recursively to embedded massages, not only to the top-level message.  Example:

multipart/signed  <-- message #1 w/ genuine headers
  +- multipart/mixed
  |   +- text/rfc822-headers  <-- headers match message #1 headers
  |   +- text/pain
  |   +- message/rfc822  <-- forwarded message #2 w/ modified headers
  |       +- multipart/signed
  |           +- multipart/mixed
  |           |   +- text/rfc822-headers  <-- headers *do not* match message #2 headers
  |           |   +- text/plain
  |           +- application/pgp-signature  <-- correct signature
  +- application/pgp-signature  <-- correct signature

In this case, the MUA might tell the user the following:
  * the signature of the main message #1 verifies
  * the signature of the embedded message #2 verifies
  * the headers of the main message #1 are genuine
  * the headers of the embedded message #2 have been modified by someone

Best,
Albrecht.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Headers.png
Type: image/png
Size: 56905 bytes
Desc: not available
URL: </pipermail/attachments/20150322/170660ef/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: </pipermail/attachments/20150322/170660ef/attachment-0001.sig>