rfc9788v3.txt | rfc9788.txt | |||
---|---|---|---|---|
Internet Engineering Task Force (IETF) D. K. Gillmor | Internet Engineering Task Force (IETF) D. K. Gillmor | |||
Request for Comments: 9788 American Civil Liberties Union | Request for Comments: 9788 American Civil Liberties Union | |||
Updates: 8551 B. Hoeneisen | Updates: 8551 B. Hoeneisen | |||
Category: Standards Track pEp Project | Category: Standards Track pEp Project | |||
ISSN: 2070-1721 A. Melnikov | ISSN: 2070-1721 A. Melnikov | |||
Isode Ltd | Isode Ltd | |||
May 2025 | June 2025 | |||
Header Protection for Cryptographically Protected Email | Header Protection for Cryptographically Protected Email | |||
Abstract | Abstract | |||
S/MIME version 3.1 introduced a mechanism to provide end-to-end | S/MIME version 3.1 introduced a mechanism to provide end-to-end | |||
cryptographic protection of email message headers. However, few | cryptographic protection of email message headers. However, few | |||
implementations generate messages using this mechanism, and several | implementations generate messages using this mechanism, and several | |||
legacy implementations have revealed rendering or security issues | legacy implementations have revealed rendering or security issues | |||
when handling such a message. | when handling such a message. | |||
skipping to change at line 676 ¶ | skipping to change at line 676 ¶ | |||
C └┬╴multipart/alternative; hp="cipher" | C └┬╴multipart/alternative; hp="cipher" | |||
D ├─╴text/plain; hp-legacy-display="1" | D ├─╴text/plain; hp-legacy-display="1" | |||
E └─╴text/html; hp-legacy-display="1" | E └─╴text/html; hp-legacy-display="1" | |||
Observe that: | Observe that: | |||
* Nodes A and B are collectively called the Cryptographic Envelope. | * Nodes A and B are collectively called the Cryptographic Envelope. | |||
Node C (including its subnodes D and E) is called the | Node C (including its subnodes D and E) is called the | |||
Cryptographic Payload [RFC9787]. | Cryptographic Payload [RFC9787]. | |||
* Node A contains the traditional unprotected ("outer") Header | * Node A contains the unprotected ("outer") Header Fields. Node C | |||
Fields. Node C contains the protected ("inner") Header Fields. | contains the protected ("inner") Header Fields. | |||
* The presence of the hp attribute (see Section 2.1.1) on the | * The presence of the hp attribute (see Section 2.1.1) on the | |||
Content-Type of node C allows the receiver to know that the sender | Content-Type of node C allows the receiver to know that the sender | |||
applied Header Protection. Its value allows the receiver to | applied Header Protection. Its value allows the receiver to | |||
distinguish whether the sender intended for the message to be | distinguish whether the sender intended for the message to be | |||
confidential (hp="cipher") or not (hp="clear"), since encryption | confidential (hp="cipher") or not (hp="clear"), since encryption | |||
may have been added in transit (see Section 10.2). | may have been added in transit (see Section 10.2). | |||
The "outer" Header Section on node A looks as follows: | The "outer" Header Section on node A looks as follows: | |||
skipping to change at line 1498 ¶ | skipping to change at line 1498 ¶ | |||
When responding to a message, an MUA has different ways to populate | When responding to a message, an MUA has different ways to populate | |||
the recipients of the new message. Depending on whether it is a | the recipients of the new message. Depending on whether it is a | |||
Reply, a Reply All, or a Forward, an MUA may populate the composer | Reply, a Reply All, or a Forward, an MUA may populate the composer | |||
view using a combination of the referenced message's From, To, Cc, | view using a combination of the referenced message's From, To, Cc, | |||
Reply-To, or Mail-Followup-To Header Fields or any other signals. | Reply-To, or Mail-Followup-To Header Fields or any other signals. | |||
When responding to a message with Header Protection, an MUA MUST only | When responding to a message with Header Protection, an MUA MUST only | |||
use the protected Header Fields when populating the recipients of the | use the protected Header Fields when populating the recipients of the | |||
new message. | new message. | |||
This avoids compromise of message confidentiality when a man-in-the- | This avoids compromise of message confidentiality when a machine-in- | |||
middle (MITM) attacker modifies the unprotected From address of an | the-middle (MITM) attacker modifies the unprotected From address of | |||
encrypted message, attempting to learn the contents through a | an encrypted message, attempting to learn the contents through a | |||
misdirected reply. Note that with the rendering guidance above, a | misdirected reply. Note that with the rendering guidance above, a | |||
MITM attacker can cause the unprotected From Header Field to be | MITM attacker can cause the unprotected From Header Field to be | |||
displayed. Thus, when responding, the populated To address may | displayed. Thus, when responding, the populated To address may | |||
differ from the rendered From address. However, this change in | differ from the rendered From address. However, this change in | |||
addresses should not cause more user confusion than the address | addresses should not cause more user confusion than the address | |||
change caused by a Reply-To in a Legacy Message does. | change caused by a Reply-To in a Legacy Message does. | |||
4.4.5. Matching addr-specs | 4.4.5. Matching addr-specs | |||
When generating (Section 3.1.1) or consuming (Section 4.4) a | When generating (Section 3.1.1) or consuming (Section 4.4) a | |||
skipping to change at line 1963 ¶ | skipping to change at line 1963 ¶ | |||
5.1. Composing a Cryptographically Protected Message Without Header | 5.1. Composing a Cryptographically Protected Message Without Header | |||
Protection | Protection | |||
For contrast, we first consider the typical message composition | For contrast, we first consider the typical message composition | |||
process of a Legacy Crypto MUA, which does not provide any Header | process of a Legacy Crypto MUA, which does not provide any Header | |||
Protection. | Protection. | |||
This process is described in Section 5.1 of [RFC9787]. We replicate | This process is described in Section 5.1 of [RFC9787]. We replicate | |||
it here for reference. The inputs to the algorithm are: | it here for reference. The inputs to the algorithm are: | |||
* origbody: The traditional unprotected message Body as a well- | * origbody: The unprotected message Body as a well-formed MIME tree | |||
formed MIME tree (possibly just a single MIME leaf part). As a | (possibly just a single MIME leaf part). As a well-formed MIME | |||
well-formed MIME tree, origbody already has Structural Header | tree, origbody already has Structural Header Fields (Content-*) | |||
Fields (Content-*) present. | present. | |||
* origheaders: The intended Non-Structural Header Fields for the | * origheaders: The intended Non-Structural Header Fields for the | |||
message, represented here as a list of (h,v) pairs, where h is a | message, represented here as a list of (h,v) pairs, where h is a | |||
Header Field name and v is the associated value. Note that these | Header Field name and v is the associated value. Note that these | |||
are Header Fields that the MUA intends to be visible to the | are Header Fields that the MUA intends to be visible to the | |||
recipient of the message. In particular, if the MUA uses the Bcc | recipient of the message. In particular, if the MUA uses the Bcc | |||
Header Field during composition but plans to omit it from the | Header Field during composition but plans to omit it from the | |||
message (see Section 3.6.3 of [RFC5322]), it will not be in | message (see Section 3.6.3 of [RFC5322]), it will not be in | |||
origheaders. | origheaders. | |||
skipping to change at line 2425 ¶ | skipping to change at line 2425 ¶ | |||
I. Set result to v1. | I. Set result to v1. | |||
iii. Insert (h,v) -> result into confmap. | iii. Insert (h,v) -> result into confmap. | |||
8. Return a new HCP from confmap that tests whether (name,val_in) is | 8. Return a new HCP from confmap that tests whether (name,val_in) is | |||
in confmap; if so, return confmap[(name,val_in)]; otherwise, | in confmap; if so, return confmap[(name,val_in)]; otherwise, | |||
return val_in. | return val_in. | |||
Note that the key idea here is to reuse the MUA's existing respond | Note that the key idea here is to reuse the MUA's existing respond | |||
function. The algorithm simulates how the MUA would pre-populate a | function. The algorithm simulates how the MUA would pre-populate a | |||
reply to two traditional messages whose Header Fields have the values | reply to two messages whose Header Fields have the values refouter | |||
refouter and refprotected, respectively (independent of any | and refprotected, respectively (independent of any cryptographic | |||
cryptographic protections). Then, it uses the difference to derive a | protections). Then, it uses the difference to derive a one-time HCP. | |||
one-time HCP. This HCP takes into account both the referenced | This HCP takes into account both the referenced message's sender's | |||
message's sender's preferences and the derivations that can happen to | preferences and the derivations that can happen to Header Field | |||
Header Field values when responding. Note that while some of these | values when responding. Note that while some of these derivations | |||
derivations are straightforward (e.g., In-Reply-To is usually derived | are straightforward (e.g., In-Reply-To is usually derived from | |||
from Message-ID), others are non-trivial. For example, the From | Message-ID), others are non-trivial. For example, the From address | |||
address may be derived from To, Cc, or the MUA's local address | may be derived from To, Cc, or the MUA's local address preference | |||
preference (especially when the MUA received the referenced message | (especially when the MUA received the referenced message via Bcc). | |||
via Bcc). Similarly, To may be derived from To, From, and/or Cc | Similarly, To may be derived from To, From, and/or Cc Header Fields | |||
Header Fields depending on the MUA implementation and depending on | depending on the MUA implementation and depending on whether the user | |||
whether the user clicked "Reply", "Reply All", "Forward", or any | clicked "Reply", "Reply All", "Forward", or any other action that | |||
other action that generates a response to a message. Reusing the | generates a response to a message. Reusing the MUA's existing | |||
MUA's existing respond function incorporates these nuances without | respond function incorporates these nuances without requiring any | |||
requiring any extra configuration choices or additional maintenance | extra configuration choices or additional maintenance burden. | |||
burden. | ||||
6.2. Avoid Misdirected Replies | 6.2. Avoid Misdirected Replies | |||
When replying to a message, the composing MUA typically decides who | When replying to a message, the composing MUA typically decides who | |||
to send the reply to based on: | to send the reply to based on: | |||
* the Reply-To, Mail-Followup-To, or From Header Fields | * the Reply-To, Mail-Followup-To, or From Header Fields | |||
* optionally, the other To or Cc Header Fields (if the user chose to | * optionally, the other To or Cc Header Fields (if the user chose to | |||
"Reply All") | "Reply All") | |||
skipping to change at line 3364 ¶ | skipping to change at line 3363 ¶ | |||
version available at <https://www.w3.org/TR/CSS22/>. | version available at <https://www.w3.org/TR/CSS22/>. | |||
[HTML-ESCAPES] | [HTML-ESCAPES] | |||
W3C, "Using character escapes in markup and CSS", 12 | W3C, "Using character escapes in markup and CSS", 12 | |||
August 2010, <https://www.w3.org/International/questions/ | August 2010, <https://www.w3.org/International/questions/ | |||
qa-escapes#use>. | qa-escapes#use>. | |||
[PEP-EMAIL] | [PEP-EMAIL] | |||
Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): | Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): | |||
Email Formats and Protocols", Work in Progress, Internet- | Email Formats and Protocols", Work in Progress, Internet- | |||
Draft, draft-pep-email-02, 16 December 2022, | Draft, draft-pep-email-03, 22 May 2025, | |||
<https://datatracker.ietf.org/doc/html/draft-pep-email- | <https://datatracker.ietf.org/doc/html/draft-pep-email- | |||
02>. | 03>. | |||
[PEP-GENERAL] | [PEP-GENERAL] | |||
Birk, V., Marques, H., and B. Hoeneisen, "pretty Easy | Birk, V., Marques, H., and B. Hoeneisen, "pretty Easy | |||
privacy (pEp): Privacy by Default", Work in Progress, | privacy (pEp): Privacy by Default", Work in Progress, | |||
Internet-Draft, draft-pep-general-02, 16 December 2022, | Internet-Draft, draft-pep-general-03, 22 May 2025, | |||
<https://datatracker.ietf.org/doc/html/draft-pep-general- | <https://datatracker.ietf.org/doc/html/draft-pep-general- | |||
02>. | 03>. | |||
[PGPCONTROL] | [PGPCONTROL] | |||
UUNET Technologies, Inc., "Authentication of Usenet Group | UUNET Technologies, Inc., "Authentication of Usenet Group | |||
Changes", 27 October 2016, | Changes", 27 October 2016, | |||
<https://ftp.isc.org/pub/pgpcontrol/>. | <https://ftp.isc.org/pub/pgpcontrol/>. | |||
[PGPVERIFY-FORMAT] | [PGPVERIFY-FORMAT] | |||
Lawrence, D. C., "Signing Control Messages, Verifying | Lawrence, D. C., "Signing Control Messages, Verifying | |||
Control Messages", | Control Messages", | |||
<https://www.eyrie.org/~eagle/usefor/other/pgpverify>. | <https://www.eyrie.org/~eagle/usefor/other/pgpverify>. | |||
skipping to change at line 3521 ¶ | skipping to change at line 3520 ¶ | |||
with different forms of Header Protection in different Legacy MUAs. | with different forms of Header Protection in different Legacy MUAs. | |||
Different Legacy MUAs demonstrate different subsets of these | Different Legacy MUAs demonstrate different subsets of these | |||
problems. | problems. | |||
A conformant MUA would not exhibit any of these problems. An | A conformant MUA would not exhibit any of these problems. An | |||
implementer updating their Legacy MUA to be compliant with this | implementer updating their Legacy MUA to be compliant with this | |||
specification should consider these concerns and try to avoid them. | specification should consider these concerns and try to avoid them. | |||
Recall that "protected" refers to the "inner" values, e.g., the real | Recall that "protected" refers to the "inner" values, e.g., the real | |||
Subject, and "unprotected" refers to the "outer" values, e.g., the | Subject, and "unprotected" refers to the "outer" values, e.g., the | |||
dummy Subject. | replacement Subject. | |||
B.1. Problems Viewing Messages in a List View | B.1. Problems Viewing Messages in a List View | |||
* Unprotected Subject, Date, From, and To Header Fields are visible | * Unprotected Subject, Date, From, and To Header Fields are visible | |||
(instead of being replaced by protected values) | (instead of being replaced by protected values) | |||
* Threading is not visible | * Threading is not visible | |||
B.2. Problems When Rendering a Message | B.2. Problems When Rendering a Message | |||
End of changes. 10 change blocks. | ||||
32 lines changed or deleted | 31 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |