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.