rfc9973v1.txt		rfc9973.txt
	skipping to change at line 75 ¶		skipping to change at line 75 ¶
	Acknowledgments		Acknowledgments
	Author's Address		Author's Address
	1. Introduction		1. Introduction
	The TLS 1.3 [RFC9846] handshake protocol provides two mutually		The TLS 1.3 [RFC9846] handshake protocol provides two mutually
	exclusive forms of server authentication. First, the server can be		exclusive forms of server authentication. First, the server can be
	authenticated by providing a signature certificate and creating a		authenticated by providing a signature certificate and creating a
	valid digital signature to demonstrate that it possesses the		valid digital signature to demonstrate that it possesses the
	corresponding private key. Second, the server can be authenticated		corresponding private key. Second, the server can be authenticated
	by demonstrating that it possesses a pre-shared key (PSK) that was		by demonstrating that it possesses a PSK that was established by a
	established by a previous handshake. A PSK that is established in		previous handshake. A PSK that is established in this fashion is
	this fashion is called a resumption PSK. A PSK that is established		called a resumption PSK. A PSK that is established by any other
	by any other means is called an external PSK.		means is called an external PSK.
	A TLS 1.3 server that is authenticating with a certificate may		A TLS 1.3 server that is authenticating with a certificate may
	optionally request a certificate from the TLS 1.3 client for		optionally request a certificate from the TLS 1.3 client for
	authentication, as described in Section 4.3.2 of [RFC9846].		authentication, as described in Section 4.3.2 of [RFC9846].
	This document specifies a TLS 1.3 extension permitting certificate-		This document specifies a TLS 1.3 extension permitting certificate-
	based authentication and providing an external PSK to be input to the		based authentication and providing an external PSK to be input to the
	TLS 1.3 key schedule.		TLS 1.3 key schedule.
	Please see Appendix A for a list of changes since the publication of		Please see Appendix A for a list of changes since the publication of
	skipping to change at line 397 ¶		skipping to change at line 397 ¶
	The Security Considerations in [RFC9846] remain relevant.		The Security Considerations in [RFC9846] remain relevant.
	TLS 1.3 [RFC9846] does not permit the server to send a		TLS 1.3 [RFC9846] does not permit the server to send a
	CertificateRequest message when a PSK is being used. This		CertificateRequest message when a PSK is being used. This
	restriction is removed when the "tls_cert_with_extern_psk" extension		restriction is removed when the "tls_cert_with_extern_psk" extension
	is offered by the client and accepted by the server. However, TLS		is offered by the client and accepted by the server. However, TLS
	1.3 does not permit an external PSK to be used in the same fashion as		1.3 does not permit an external PSK to be used in the same fashion as
	a resumption PSK, and this extension preserves that restriction.		a resumption PSK, and this extension preserves that restriction.
	Implementations must protect the external pre-shared key (PSK).		Implementations must protect the external PSK. Compromise of the
	Compromise of the external PSK will make the encrypted session		external PSK will make the encrypted session content vulnerable to
	content vulnerable to the future development of a Cryptographically		the future development of a CRQC. However, the generation,
	Relevant Quantum Computer (CRQC). However, the generation,
	distribution, and management of the external PSKs is out of scope for		distribution, and management of the external PSKs is out of scope for
	this specification.		this specification.
	Implementers should not transmit the same content on a connection		Implementers should not transmit the same content on a connection
	that is protected with an external PSK and a connection that is not.		that is protected with an external PSK and a connection that is not.
	Doing so may allow an eavesdropper to correlate the connections,		Doing so may allow an eavesdropper to correlate the connections,
	making the content vulnerable to the future invention of a CRQC.		making the content vulnerable to the future invention of a CRQC.
	Implementations must generate external PSKs with a secure key-		Implementations must generate external PSKs with a secure key-
	management technique, such as pseudorandom generation of the key or		management technique, such as pseudorandom generation of the key or
	skipping to change at line 488 ¶		skipping to change at line 487 ¶
	the end of a session, the (EC)DH private key would nevertheless be		the end of a session, the (EC)DH private key would nevertheless be
	recoverable due to the break of the (EC)DH algorithm. However, a		recoverable due to the break of the (EC)DH algorithm. However, a
	more general notion of "secrecy after key material is destroyed"		more general notion of "secrecy after key material is destroyed"
	would still be achievable using external PSKs, if they are managed in		would still be achievable using external PSKs, if they are managed in
	a way that ensures their destruction when they are no longer needed,		a way that ensures their destruction when they are no longer needed,
	and with the assumption that the symmetric algorithms remain safe		and with the assumption that the symmetric algorithms remain safe
	against the invention of a CRQC.		against the invention of a CRQC.
	The forward-secrecy advantages traditionally associated with		The forward-secrecy advantages traditionally associated with
	ephemeral (EC)DH keys are not easily replaced by external PSKs. The		ephemeral (EC)DH keys are not easily replaced by external PSKs. The
	confidentially and authentication provided by the external PSK depend		confidentiality and authentication provided by the external PSK
	on whether the external PSK is used for more than one TLS 1.3 session		depend on whether the external PSK is used for more than one TLS 1.3
	and the parties that know the external PSK. Assuming the (EC)DH key		session and the parties that know the external PSK. Assuming the
	agreement is broken:		(EC)DH key agreement is broken:
	* If the external PSK is used for a single TLS 1.3 session and it is		* If the external PSK is used for a single TLS 1.3 session and it is
	known only by the client and server, then the usual TLS 1.3		known only by the client and server, then the usual TLS 1.3
	confidentially and authentication is provided, including the		confidentiality and authentication is provided, including the
	cryptographic separation between TLS 1.3 sessions. Of course,		cryptographic separation between TLS 1.3 sessions. Of course,
	this places a significant burden on the generation and		this places a significant burden on the generation and
	distribution of external PSKs.		distribution of external PSKs.
	* If the external PSK is used for more than one TLS 1.3 session and		* If the external PSK is used for more than one TLS 1.3 session and
	it is known only by the client and server, then the confidentially		it is known only by the client and server, then the
	is limited to the client and server, but there is no cryptographic		confidentiality is limited to the client and server, but there is
	separation between TLS 1.3 sessions.		no cryptographic separation between TLS 1.3 sessions.
	* If the external PSK is used for more than one TLS 1.3 session and		* If the external PSK is used for more than one TLS 1.3 session and
	it is known by the client, server, and others, then the		it is known by the client, server, and others, then the
	confidentially is limited to the group that knows the external		confidentiality is limited to the group that knows the external
	PSK, but there is no cryptographic separation between TLS 1.3		PSK, but there is no cryptographic separation between TLS 1.3
	sessions.		sessions.
	This specification does not require that the external PSK is known		This specification does not require that the external PSK is known
	only by the client and server. The external PSK may be known to a		only by the client and server. The external PSK may be known to a
	group. Since authentication depends on the public key in a		group. Since authentication depends on the public key in a
	certificate, knowledge of the external PSK by other parties does not		certificate, knowledge of the external PSK by other parties does not
	enable impersonation. The authentication of the server and optional		enable impersonation. The authentication of the server and optional
	authentication of the client depend upon the ability to generate a		authentication of the client depend upon the ability to generate a
	signature that can be validated with the public key in their		signature that can be validated with the public key in their
	certificates. The authentication processing is not changed in any		certificates. The authentication processing is not changed in any
	way by the selected external PSK.		way by the selected external PSK.
	Confidentiality depends on the shared secret from (EC)DH, so		Confidentiality depends on the shared secret from (EC)DH, so
	knowledge of the external PSK by other parties does not enable		knowledge of the external PSK by other parties does not enable
	eavesdropping. However, group members can record the traffic of		eavesdropping. However, group members can record the traffic of
	other members and then decrypt that traffic if they ever gain access		other members and then decrypt that traffic if they ever gain access
	to a CRQC. Also, when many parties know the external PSK, there are		to a CRQC. Also, when many parties know the external PSK, there are
	many opportunities for theft of the external PSK by an attacker.		many opportunities for theft of the external PSK by an attacker.
	Once an attacker has the external PSK, they can decrypt stored		Once an attacker has the external PSK, if they ever gain access to a
	traffic if they ever gain access to a CRQC, in the same manner as a		CRQC, they can decrypt stored traffic in the same manner as a
	legitimate group member.		legitimate group member.
	TLS 1.3 key derivation makes use of the HMAC-based Key Derivation		TLS 1.3 key derivation makes use of the HMAC-based Key Derivation
	Function (HKDF) algorithm, which depends upon the HMAC [RFC2104]		Function (HKDF) algorithm, which depends upon the HMAC [RFC2104]
	construction and a hash function. This extension provides the		construction and a hash function. This extension provides the
	desired protection for the session secrets, as long as HMAC with the		desired protection for the session secrets, as long as HMAC with the
	selected hash function is a pseudorandom function (PRF) [GGM1986].		selected hash function is a pseudorandom function (PRF) [GGM1986].
	TLS 1.3 [RFC9846] takes a conservative approach to PSKs; they are		TLS 1.3 [RFC9846] takes a conservative approach to PSKs; they are
	bound to a specific hash function and KDF. By contrast, TLS 1.2		bound to a specific hash function and KDF. By contrast, TLS 1.2
	skipping to change at line 555 ¶		skipping to change at line 554 ¶
	8. Privacy Considerations		8. Privacy Considerations
	Appendix F.6 of [RFC9846] discusses identity-exposure attacks on		Appendix F.6 of [RFC9846] discusses identity-exposure attacks on
	PSKs. Also, Appendix C.4 of [RFC9846] discusses tracking prevention.		PSKs. Also, Appendix C.4 of [RFC9846] discusses tracking prevention.
	The guidance in these sections remain relevant.		The guidance in these sections remain relevant.
	If an external PSK identity is used for multiple connections, then an		If an external PSK identity is used for multiple connections, then an
	observer will generally be able track clients and/or servers across		observer will generally be able track clients and/or servers across
	connections. The rotation of the external PSK identity or the use of		connections. The rotation of the external PSK identity or the use of
	the Encrypted Client Hello extension [RFC9849] can mitigate this		the "encrypted_client_hello" extension [RFC9849] can mitigate this
	risk.		risk.
	This extension makes use of external PSKs to improve resilience		This extension makes use of external PSKs to improve resilience
	against attackers that gain access to a CRQC in the future and		against attackers that gain access to a CRQC in the future and
	provides authentication for initial enrollment of devices in an		provides authentication for initial enrollment of devices in an
	enterprise network. This extension is always accompanied by the		enterprise network. This extension is always accompanied by the
	"pre_shared_key" extension to provide the PSK identities in plaintext		"pre_shared_key" extension to provide the PSK identities in plaintext
	in the ClientHello message. Passive observation of the these PSK		in the ClientHello message. Passive observation of the these PSK
	identities will aid an attacker in tracking users or devices that		identities will aid an attacker in tracking users or devices that
	make use of this extension.		make use of this extension.
	skipping to change at line 666 ¶		skipping to change at line 665 ¶
	In addition to minor editorial updates, which include a change to the		In addition to minor editorial updates, which include a change to the
	title, the following changes were made:		title, the following changes were made:
	* Correct the order of the arguments to HKDF-Extract when an		* Correct the order of the arguments to HKDF-Extract when an
	external PSK is present.		external PSK is present.
	* The client must include the "supported_groups" extension in the		* The client must include the "supported_groups" extension in the
	ClientHello message.		ClientHello message.
	* Expand the motivation discussion to talk about protection against		* Expand the motivation discussion to talk about protection against
	the future development of a Cryptographically Relevant Quantum		the future development of a CRQC and enrollment in enterprise
	Computer (CRQC) and enrollment in enterprise networks.		networks.
	* Separate the discussion of confidentiality and authentication.		* Separate the discussion of confidentiality and authentication.
	The inclusion of the external PSK offers some confidentiality		The inclusion of the external PSK offers some confidentiality
	protection against the future invention of a CRQC, but the		protection against the future invention of a CRQC, but the
	external PSK does not improve authentication.		external PSK does not improve authentication.
	* Correct RFC Erratum 7598 [Err7598].		* Correct RFC Erratum 7598 [Err7598].
	* Add a discussion of TLS Encrypted Client Hello to the Privacy		* Add a discussion of TLS Encrypted Client Hello to the Privacy
	Considerations section.		Considerations section.
	skipping to change at line 692 ¶		skipping to change at line 691 ¶
	* Provide URLs for all references.		* Provide URLs for all references.
	Acknowledgments		Acknowledgments
	Many thanks to Liliya Akhmetzyanova, Roman Danyliw, Christian		Many thanks to Liliya Akhmetzyanova, Roman Danyliw, Christian
	Huitema, Ben Kaduk, Geoffrey Keating, Hugo Krawczyk, Mirja Kühlewind,		Huitema, Ben Kaduk, Geoffrey Keating, Hugo Krawczyk, Mirja Kühlewind,
	Nikos Mavrogiannopoulos, Nick Sullivan, Martin Thomson, and Peter Yee		Nikos Mavrogiannopoulos, Nick Sullivan, Martin Thomson, and Peter Yee
	for their review and comments on the Internet-Drafts that eventually		for their review and comments on the Internet-Drafts that eventually
	became RFC 8773; their efforts have improved the document.		became RFC 8773; their efforts have improved the document.
	Many thanks to Dan Harkins, Owen Friel, John Preuß Mattsson,		Many thanks to Mike Bishop, Deb Cooley, Owen Friel, Britta Hale, Dan
	Christian Huitema, Joe Salowey, Britta Hale, Peter Yee, Joe Mandel,		Harkins, Christian Huitema, Joe Mandel, John Preuß Mattsson, Eric
	Muhammad Usama Sardar, Paul Wouters, Mike Bishop, Deb Cooley, and		Rescorla, Joe Salowey, Muhammad Usama Sardar, Paul Wouters, and Peter
	Eric Rescorla for their review and comments on the updates to RFC		Yee for their review and comments on the updates to RFC 8773 that
	8773 that became this document; their efforts have improved the		became this document; their efforts have improved the document.
	document.
	Author's Address		Author's Address
	Russ Housley		Russ Housley
	Vigil Security, LLC		Vigil Security, LLC
	516 Dranesville Road		516 Dranesville Road
	Herndon, VA 20170		Herndon, VA 20170
	United States of America		United States of America
	Email: housley@vigilsec.com		Email: housley@vigilsec.com
End of changes. 10 change blocks.
	28 lines changed or deleted		26 lines changed or added
This html diff was produced by rfcdiff 1.48.