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.