rfc9787v1.txt		rfc9787.txt
	skipping to change at line 18 ¶		skipping to change at line 18 ¶
	May 2025		May 2025
	Guidance on End-to-End Email Security		Guidance on End-to-End Email Security
	Abstract		Abstract
	End-to-end cryptographic protections for email messages can provide		End-to-end cryptographic protections for email messages can provide
	useful security. However, the standards for providing cryptographic		useful security. However, the standards for providing cryptographic
	protection are extremely flexible. That flexibility can trap users		protection are extremely flexible. That flexibility can trap users
	and cause surprising failures. This document offers guidance for		and cause surprising failures. This document offers guidance for
	mail user agent implementers to help mitigate those risks and to make		Mail User Agent (MUA) implementers to help mitigate those risks and
	end-to-end email simple and secure for the end user. It provides a		to make end-to-end email simple and secure for the end user. It
	useful set of vocabulary as well as recommendations to avoid common		provides a useful set of vocabulary as well as recommendations to
	failures. It also identifies a number of currently unsolved		avoid common failures. It also identifies a number of currently
	usability and interoperability problems.		unsolved usability and interoperability problems.
	Status of This Memo		Status of This Memo
	This document is not an Internet Standards Track specification; it is		This document is not an Internet Standards Track specification; it is
	published for informational purposes.		published for informational purposes.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Not all documents		Internet Engineering Steering Group (IESG). Not all documents
	skipping to change at line 163 ¶		skipping to change at line 163 ¶
	Acknowledgements		Acknowledgements
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	End-to-end email security using S/MIME [RFC8551] and PGP/MIME (Pretty		End-to-end email security using S/MIME [RFC8551] and PGP/MIME (Pretty
	Good Privacy with MIME) [RFC3156] cryptographic standards can provide		Good Privacy with MIME) [RFC3156] cryptographic standards can provide
	integrity, authentication, and confidentiality to MIME [RFC4289]		integrity, authentication, and confidentiality to MIME [RFC4289]
	email messages.		email messages.
	However, there are many ways that a receiving mail user agent can		However, there are many ways that a receiving MUA can misinterpret or
	misinterpret or accidentally break these security guarantees. For		accidentally break these security guarantees. For example, as
	example, as described in [EFAIL], the "Direct Exfiltration" attack		described in [EFAIL], the "Direct Exfiltration" attack leaks
	leaks cleartext due to an attack that splices existing ciphertext		cleartext due to an attack that splices existing ciphertext into a
	into a new message, which is then handled optimistically (and		new message, which is then handled optimistically (and wrongly) by
	wrongly) by many mail user agents.		many MUAs.
	A mail user agent that interprets a message with end-to-end		A MUA that interprets a message with end-to-end cryptographic
	cryptographic protections needs to do so defensively, staying alert		protections needs to do so defensively, staying alert to different
	to different ways that these protections can be bypassed by mangling		ways that these protections can be bypassed by mangling (either
	(either malicious or accidental) or a failed user experience.		malicious or accidental) or a failed user experience.
	A mail user agent that generates a message with end-to-end		A MUA that generates a message with end-to-end cryptographic
	cryptographic protections should be aware of these defensive		protections should be aware of these defensive interpretation
	interpretation strategies and should compose any new outbound message		strategies and should compose any new outbound message conservatively
	conservatively if they want the protections to remain intact.		if they want the protections to remain intact.
	This document offers guidance to the implementer of a mail user agent		This document offers guidance to the implementer of a MUA that
	that provides these cryptographic protections, whether for sending or		provides these cryptographic protections, whether for sending or
	receiving mail. An implementation that follows this guidance will		receiving mail. An implementation that follows this guidance will
	provide its users with stronger and easier-to-understand security		provide its users with stronger and easier-to-understand security
	properties and will also offer more reliable interoperability for		properties and will also offer more reliable interoperability for
	messages exchanged with other implementations.		messages exchanged with other implementations.
	In Appendix A, this document also identifies a number of		In Appendix A, this document also identifies a number of
	interoperability and usability concerns for end-to-end cryptographic		interoperability and usability concerns for end-to-end cryptographic
	email that have no current broadly accepted technical standard for		email that have no current broadly accepted technical standard for
	resolution. One major area not covered in this document is the		resolution. One major area not covered in this document is the
	acquisition and long-term maintenance of cryptographic identity		acquisition and long-term maintenance of cryptographic identity
	information and metadata across multiple mail user agents controlled		information and metadata across multiple MUAs controlled by the same
	by the same user.		user.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	1.1. Terminology		1.1. Terminology
	For the purposes of this document, we define the following concepts:		For the purposes of this document, we define the following concepts:
	* _MUA_ is short for Mail User Agent; an email client.		* The _Mail User Agent (MUA)_ is an email client.
	* _Protection_ of message data refers to cryptographic encryption		* _Protection_ of message data refers to cryptographic encryption
	and/or signatures, providing confidentiality, authenticity, and/or		and/or signatures, providing confidentiality, authenticity, and/or
	integrity.		integrity.
	* _Cryptographic Layer_, _Cryptographic Envelope_, _Cryptographic		* _Cryptographic Layer_, _Cryptographic Envelope_, _Cryptographic
	Payload_, _Cryptographic Summary_, and _Errant Cryptographic		Payload_, _Cryptographic Summary_, and _Errant Cryptographic
	Layer_ are defined in Section 4.		Layer_ are defined in Section 4.
	* A _well-formed_ email message with cryptographic protection has		* A _well-formed_ email message with cryptographic protection has
	skipping to change at line 1170 ¶		skipping to change at line 1170 ¶
	section when generating quoted or attributed text, similar to the		section when generating quoted or attributed text, similar to the
	guidance in Section 6.2.2.1.		guidance in Section 6.2.2.1.
	This offers protection against the reply-based attacks described in		This offers protection against the reply-based attacks described in
	[REPLY].		[REPLY].
	6.3. Forwarded Messages with Cryptographic Protection		6.3. Forwarded Messages with Cryptographic Protection
	An incoming email message may include an attached forwarded message,		An incoming email message may include an attached forwarded message,
	typically as a MIME subpart with Content-Type: message/rfc822		typically as a MIME subpart with Content-Type: message/rfc822
	[RFC5322] or Content-Type: message/global [RFC5355].		[RFC5322] or Content-Type: message/global [RFC6532].
	Regardless of the cryptographic protections and structure of the		Regardless of the cryptographic protections and structure of the
	incoming message, the internal forwarded message may have its own		incoming message, the internal forwarded message may have its own
	Cryptographic Envelope.		Cryptographic Envelope.
	The Cryptographic Layers that are part of the Cryptographic Envelope		The Cryptographic Layers that are part of the Cryptographic Envelope
	of the forwarded message are not Errant Cryptographic Layers of the		of the forwarded message are not Errant Cryptographic Layers of the
	surrounding message -- they are simply layers that apply to the		surrounding message -- they are simply layers that apply to the
	forwarded message itself.		forwarded message itself.
	skipping to change at line 1522 ¶		skipping to change at line 1522 ¶
	8.2.1.1. User Certificates for S/MIME		8.2.1.1. User Certificates for S/MIME
	For S/MIME, the user SHOULD have both a signing-capable certificate		For S/MIME, the user SHOULD have both a signing-capable certificate
	and an encryption-capable certificate (and the corresponding secret		and an encryption-capable certificate (and the corresponding secret
	keys). Using the same cryptographic key material for multiple		keys). Using the same cryptographic key material for multiple
	algorithms (i.e., for both encryption and signing) has been the		algorithms (i.e., for both encryption and signing) has been the
	source of vulnerabilities in other (non-email) contexts (e.g.,		source of vulnerabilities in other (non-email) contexts (e.g.,
	[DROWN] and [IKE]). The simplest way to avoid any comparable risk is		[DROWN] and [IKE]). The simplest way to avoid any comparable risk is
	to use distinct key material for each cryptographic algorithm. A		to use distinct key material for each cryptographic algorithm. A
	conformant MUA that generates S/MIME certificates for the user MUST		conformant MUA that generates S/MIME certificates for the user MUST
	generate distinct S/MIME certificates: one for encryption and another		also generate distinct S/MIME certificates to avoid possible cross-
	for signing, to avoid possible cross-protocol key misuse.		protocol key misuse: one for encryption and another for signing.
	The simplest option for an S/MIME-capable MUA is for the MUA to		The simplest option for an S/MIME-capable MUA is for the MUA to
	permit the user to import a PKCS #12 [RFC7292] object that is		permit the user to import a PKCS #12 [RFC7292] object that is
	expected to contain secret key material, end entity certificates for		expected to contain secret key material, end entity certificates for
	the user, and intermediate certification authority certificates that		the user, and intermediate certification authority certificates that
	permit chaining from the end entity certs to widely accepted trust		permit chaining from the end entity certificates to widely accepted
	anchors. A conformant MUA that imports such a PKCS #12 bundle SHOULD		trust anchors. A conformant MUA that imports such a PKCS #12 bundle
	warn the user if the bundle contains an S/MIME certificate and		SHOULD warn the user if the bundle contains an S/MIME certificate and
	corresponding secret key where the same secret key is used for both		corresponding secret key where the same secret key is used for both
	encryption and signing.		encryption and signing.
	An S/MIME-capable MUA that has access to user certificates and their		An S/MIME-capable MUA that has access to user certificates and their
	corresponding secret key material should also offer the ability to		corresponding secret key material should also offer the ability to
	export those objects into a well-formed PKCS #12 object that could be		export those objects into a well-formed PKCS #12 object that could be
	imported into another MUA operated by the same user.		imported into another MUA operated by the same user.
	Manual handling of PKCS #12 objects is challenging for most users.		Manual handling of PKCS #12 objects is challenging for most users.
	Producing the initial PKCS #12 object typically can only be done with		Producing the initial PKCS #12 object typically can only be done with
	skipping to change at line 1843 ¶		skipping to change at line 1843 ¶
	message itself could leak information about the actual recipients,		message itself could leak information about the actual recipients,
	even if the Bcc header field does not mention the recipient. For		even if the Bcc header field does not mention the recipient. For
	example, if the message clearly indicates which certificates it is		example, if the message clearly indicates which certificates it is
	encrypted to, the set of certificates can identify the recipients		encrypted to, the set of certificates can identify the recipients
	even if they are not named in the message header fields.		even if they are not named in the message header fields.
	Because of these complexities, there are several interacting factors		Because of these complexities, there are several interacting factors
	that need to be taken into account when composing an encrypted		that need to be taken into account when composing an encrypted
	message with Bcc'ed recipients.		message with Bcc'ed recipients.
	* Section 3.6.3 of [RFC5322] describes a set of choices about		* Should the Bcc header field be populated explicitly on Bcc'ed
	whether (and how) to populate the Bcc field explicitly on Bcc'ed
	copies of the message and in the copy stored in the sender's Sent		copies of the message and in the copy stored in the sender's Sent
	folder.		folder? See Section 3.6.3 of [RFC5322] for a set of choices.
	* When separate copies are made for Bcc'ed recipients, should each		* When separate copies are made for Bcc'ed recipients, should each
	separate copy _also_ be encrypted to the named recipients or just		separate copy _also_ be encrypted to the named recipients or just
	to the designated Bcc recipient?		to the designated Bcc recipient?
	* When a copy is stored in the Sent folder, should that copy also be		* When a copy is stored in the Sent folder, should that copy also be
	encrypted to Bcc'ed recipients? (See also Section 9.1.)		encrypted to Bcc'ed recipients? (See also Section 9.1.)
	* When a message is encrypted, if there is a mechanism to include		* When a message is encrypted, if there is a mechanism to include
	the certificates of the recipients, whose certificates should be		the certificates of the recipients, whose certificates should be
	skipping to change at line 2016 ¶		skipping to change at line 2015 ¶
	An implementer of end-to-end cryptographic protections may be tempted		An implementer of end-to-end cryptographic protections may be tempted
	by a simple software design that piggybacks off of a mail protocol,		by a simple software design that piggybacks off of a mail protocol,
	like SMTP Submission [RFC6409], IMAP [RFC9051], or JSON Meta		like SMTP Submission [RFC6409], IMAP [RFC9051], or JSON Meta
	Application Protocol (JMAP) [RFC8621], to handle message assembly and		Application Protocol (JMAP) [RFC8621], to handle message assembly and
	interpretation. In such an architecture, a naive MUA speaks		interpretation. In such an architecture, a naive MUA speaks
	something like a "standard" protocol, like SMTP, IMAP, or JMAP, to a		something like a "standard" protocol, like SMTP, IMAP, or JMAP, to a
	local proxy, and the proxy handles signing and encryption (outbound)		local proxy, and the proxy handles signing and encryption (outbound)
	and decryption and verification (inbound) internally on behalf of the		and decryption and verification (inbound) internally on behalf of the
	user. While such a "pluggable" architecture has the advantage of		user. While such a "pluggable" architecture has the advantage of
	likely being easy to apply to any mail user agent, it is problematic		likely being easy to apply to any MUA, it is problematic for the
	for the goals of end-to-end communication, especially in an existing		goals of end-to-end communication, especially in an existing
	cleartext ecosystem like email, where any given message might be		cleartext ecosystem like email, where any given message might be
	unsigned or signed, cleartext or encrypted. In particular:		unsigned or signed, cleartext or encrypted. In particular:
	* the user cannot easily and safely identify what protections any		* the user cannot easily and safely identify what protections any
	particular message has (including messages currently being		particular message has (including messages currently being
	composed) and		composed) and
	* the proxy itself is unaware of subtle nuances about the message		* the proxy itself is unaware of subtle nuances about the message
	that the MUA actually knows.		that the MUA actually knows.
	skipping to change at line 2167 ¶		skipping to change at line 2166 ¶
	form of transport protection rather than end-to-end protection.		form of transport protection rather than end-to-end protection.
	An MUA explicitly under the control of the end user with thoughtful		An MUA explicitly under the control of the end user with thoughtful
	integration can offer UI/UX and security guarantees that a simple		integration can offer UI/UX and security guarantees that a simple
	proxy cannot provide. See also Appendix A.13 for suggestions of		proxy cannot provide. See also Appendix A.13 for suggestions of
	future work that might augment a proxy to make it safer.		future work that might augment a proxy to make it safer.
	9.8. Intervening MUAs Do Not Handle End-to-End Cryptographic		9.8. Intervening MUAs Do Not Handle End-to-End Cryptographic
	Protections		Protections
	Some Mail User Agents (MUAs) will resend a message in identical form		Some MUAs will resend a message in identical form (or very similar
	(or very similar form) to the way that they received it. For		form) to the way that they received it. For example, consider the
	example, consider the following use cases:		following use cases:
	* a mail expander or mailing list that receives a message and		* a mail expander or mailing list that receives a message and
	resends it to all subscribers (see also Appendix A.14 for more		resends it to all subscribers (see also Appendix A.14 for more
	discussion of mailing lists)		discussion of mailing lists)
	* an individual user who reintroduces a message they received into		* an individual user who reintroduces a message they received into
	the mail transport system (see Section 3.6.6 of [RFC5322])		the mail transport system (see Section 3.6.6 of [RFC5322])
	* an automated email intake system that forwards a report to the		* an automated email intake system that forwards a report to the
	mailboxes of responsible staffers		mailboxes of responsible staffers
	skipping to change at line 2456 ¶		skipping to change at line 2455 ¶
	[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access		[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
	Protocol (LDAP): The Protocol", RFC 4511,		Protocol (LDAP): The Protocol", RFC 4511,
	DOI 10.17487/RFC4511, June 2006,		DOI 10.17487/RFC4511, June 2006,
	<https://www.rfc-editor.org/info/rfc4511>.		<https://www.rfc-editor.org/info/rfc4511>.
	[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,		[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
	DOI 10.17487/RFC5322, October 2008,		DOI 10.17487/RFC5322, October 2008,
	<https://www.rfc-editor.org/info/rfc5322>.		<https://www.rfc-editor.org/info/rfc5322>.
	[RFC5355] Stillman, M., Ed., Gopal, R., Guttman, E., Sengodan, S.,
	and M. Holdrege, "Threats Introduced by Reliable Server
	Pooling (RSerPool) and Requirements for Security in
	Response to Threats", RFC 5355, DOI 10.17487/RFC5355,
	September 2008, <https://www.rfc-editor.org/info/rfc5355>.
	[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,		[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
	"DomainKeys Identified Mail (DKIM) Signatures", STD 76,		"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
	RFC 6376, DOI 10.17487/RFC6376, September 2011,		RFC 6376, DOI 10.17487/RFC6376, September 2011,
	<https://www.rfc-editor.org/info/rfc6376>.		<https://www.rfc-editor.org/info/rfc6376>.
	[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",		[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
	STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,		STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
	<https://www.rfc-editor.org/info/rfc6409>.		<https://www.rfc-editor.org/info/rfc6409>.
			[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
			Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
			2012, <https://www.rfc-editor.org/info/rfc6532>.
	[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,		[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,
	and M. Scott, "PKCS #12: Personal Information Exchange		and M. Scott, "PKCS #12: Personal Information Exchange
	Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014,		Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014,
	<https://www.rfc-editor.org/info/rfc7292>.		<https://www.rfc-editor.org/info/rfc7292>.
	[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection		[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
	Most of the Time", RFC 7435, DOI 10.17487/RFC7435,		Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
	December 2014, <https://www.rfc-editor.org/info/rfc7435>.		December 2014, <https://www.rfc-editor.org/info/rfc7435>.
	[RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities		[RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities
	skipping to change at line 2585 ¶		skipping to change at line 2582 ¶
	As described in Section 8.2.3, an incoming email message may have one		As described in Section 8.2.3, an incoming email message may have one
	or more certificates embedded in it. This document currently		or more certificates embedded in it. This document currently
	acknowledges that a receiving MUA should assemble a cache of		acknowledges that a receiving MUA should assemble a cache of
	certificates for future use, but providing more detailed guidance for		certificates for future use, but providing more detailed guidance for
	how to assemble and manage that cache is currently out of scope.		how to assemble and manage that cache is currently out of scope.
	Existing recommendations like [AUTOCRYPT] provide some guidance for		Existing recommendations like [AUTOCRYPT] provide some guidance for
	handling incoming certificates about peers but only in certain		handling incoming certificates about peers but only in certain
	contexts. A future version of this document may describe in more		contexts. A future version of this document may describe in more
	detail how these incoming certs should be handled.		detail how these incoming certificates should be handled.
	A.3.2. Certificate Directories		A.3.2. Certificate Directories
	Some MUAs may have the capability to look up peer certificates in a		Some MUAs may have the capability to look up peer certificates in a
	directory, for example, via the Lightweight Directory Access Protocol		directory, for example, via the Lightweight Directory Access Protocol
	(LDAP) [RFC4511], Web Key Directory (WKD) [WEBKEY-SERVICE], or DNS		(LDAP) [RFC4511], Web Key Directory (WKD) [WEBKEY-SERVICE], or DNS
	(e.g., SMIMEA [RFC8162] or OPENPGPKEY [RFC7929] resource records).		(e.g., SMIMEA [RFC8162] or OPENPGPKEY [RFC7929] resource records).
	A future version of this document may describe in more detail what		A future version of this document may describe in more detail what
	sources an MUA should consider when searching for a peer's		sources an MUA should consider when searching for a peer's
	certificates and what to do with the certificates found by various		certificates and what to do with the certificates found by various
	methods.		methods.
	A.3.3. Checking for Certificate Revocation		A.3.3. Checking for Certificate Revocation
	A future version of this document could discuss how/when to check for		A future version of this document could discuss how/when to check for
	revocation of peer certificates or of the user's own certificate.		revocation of peer certificates or of the user's own certificate.
	Such discussion should address privacy concerns: What information		Such discussion should address privacy concerns: What information
	leaks to whom when checking peer cert revocations?		leaks to whom when checking peer certificate revocations?
	A.3.4. Further Peer Certificate Selection		A.3.4. Further Peer Certificate Selection
	A future version of this document may describe more prescriptions for		A future version of this document may describe more prescriptions for
	deciding whether a peer certificate is acceptable for encrypting a		deciding whether a peer certificate is acceptable for encrypting a
	message. For example, if the SPKI is an Elliptic Curve (EC) Public		message. For example, if the SPKI is an Elliptic Curve (EC) Public
	Key and the keyUsage extension is absent, what should the encrypting		Key and the keyUsage extension is absent, what should the encrypting
	MUA do?		MUA do?
	A future version of this document might also provide guidance on what		A future version of this document might also provide guidance on what
End of changes. 18 change blocks.
	46 lines changed or deleted		43 lines changed or added
This html diff was produced by rfcdiff 1.48.