Diff: rfc9973xml2.original.xml

	rfc9973xml2.original.xml	rfc9973.xml

	<?xml version='1.0' encoding='utf-8'?>	<?xml version='1.0' encoding='UTF-8'?>
	<!DOCTYPE rfc [ <!ENTITY nbsp " "> ]>


	<rfc xmlns:xi="http://www.w3.org/2001/XInclude"	<!DOCTYPE rfc [
	xml:lang="en"	<!ENTITY nbsp " ">
	submissionType="IETF"	<!ENTITY zwsp "">
	docName="draft-ietf-tls-8773bis-13"	<!ENTITY nbhy "‑">
	category="std"	<!ENTITY wj "⁠">
	ipr="trust200902"	]>
	sortRefs="true"
	symRefs="true"	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="en" submissionType="IE
	consensus="true"	TF" docName="draft-ietftls-8773bis-13" number="9973" category="std" ipr="trust20
	tocInclude="true"	0902" sortRefs="true" symRefs="true" consensus="true" tocInclude="true" obsolete
	obsoletes="8773">	s="8773" updates="" version="3">

	<front>	<front>
	<title abbrev="Certificate with External PSK">TLS 1.3 Extension for	<title abbrev="Certificate with External PSK">TLS 1.3 Extension for
	Using Certificates with an External Pre-Shared Key</title>	Using Certificates with an External Pre-Shared Key</title>

		<seriesInfo name="RFC" value="9973"/>
	<author fullname="Russ Housley" initials="R." surname="Housley">	<author fullname="Russ Housley" initials="R." surname="Housley">
	<organization abbrev="Vigil Security">Vigil Security, LLC</organization>	<organization abbrev="Vigil Security">Vigil Security, LLC</organization>
	<address>	<address>
	<postal>	<postal>
	<street>516 Dranesville Road</street>	<street>516 Dranesville Road</street>
	<city>Herndon</city>	<city>Herndon</city>
	<region>VA</region>	<region>VA</region>
	<code>20170</code>	<code>20170</code>

	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>housley@vigilsec.com</email>	<email>housley@vigilsec.com</email>
	</address>	</address>
	</author>	</author>

		<date month="April" year="2026"/>
	<date day="5" month="September" year="2025"/>	<area>SEC</area>
		<workgroup>tls</workgroup>

	<keyword>cryptography</keyword>	<keyword>cryptography</keyword>
	<keyword>pre-shared key</keyword>	<keyword>pre-shared key</keyword>


	<abstract>	<abstract>
	<t>	<t>
	This document specifies a TLS 1.3 extension that allows TLS clients	This document specifies a TLS 1.3 extension that allows TLS clients
	and servers to authenticate with certificates and provide confidentialit y	and servers to authenticate with certificates and provide confidentialit y
	based on encryption with a symmetric key from the usual key	based on encryption with a symmetric key from the usual key
	agreement algorithm and an external pre-shared key (PSK). This	agreement algorithm and an external pre-shared key (PSK). This

	Standards Track RFC (once approved) obsoletes RFC 8773, which was	Standards Track RFC obsoletes RFC 8773, which was
	an Experimental RFC.	an Experimental RFC.
	</t>	</t>
	</abstract>	</abstract>
	</front>	</front>


	<middle>	<middle>
	<section anchor="intro" numbered="true" toc="default">	<section anchor="intro" numbered="true" toc="default">
	<name>Introduction</name>	<name>Introduction</name>
	<t>	<t>

	The TLS 1.3 <xref target="I-D.ietf-tls-rfc8446bis" format="default"/>	The TLS 1.3 <xref target="RFC9846" format="default"/>
	handshake protocol provides two mutually exclusive forms of server	handshake protocol provides two mutually exclusive forms of server
	authentication. First, the server can be authenticated by	authentication. First, the server can be authenticated by
	providing a signature certificate and creating a valid digital	providing a signature certificate and creating a valid digital
	signature to demonstrate that it possesses the corresponding	signature to demonstrate that it possesses the corresponding
	private key. Second, the server can be authenticated	private key. Second, the server can be authenticated
	by demonstrating that it possesses a pre-shared key (PSK) that	by demonstrating that it possesses a pre-shared key (PSK) that
	was established by a previous handshake. A PSK that	was established by a previous handshake. A PSK that
	is established in this fashion is called a resumption PSK. A	is established in this fashion is called a resumption PSK. A
	PSK that is established by any other means is called an external	PSK that is established by any other means is called an external
	PSK.	PSK.
	</t>	</t>
	<t>	<t>
	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	authentication, as described in
	<xref target="I-D.ietf-tls-rfc8446bis" sectionFormat="of" section="4.3.2	<xref target="RFC9846" sectionFormat="of" section="4.3.2"/>.
	"/>.
	</t>	</t>
	<t>	<t>
	This document specifies a TLS 1.3 extension permitting	This document specifies a TLS 1.3 extension permitting
	certificate-based authentication and providing an external PSK	certificate-based authentication and providing an external PSK
	to be input to the TLS 1.3 key schedule.	to be input to the TLS 1.3 key schedule.
	</t>	</t>

	<t>	<t>
	Please see <xref target="changes"/> for a list of changes since	Please see <xref target="changes"/> for a list of changes since

	the publication of RFC 8773.	the publication of <xref target="RFC8773"/>.
	</t>	</t>
	</section>	</section>


	<section anchor="term" numbered="true" toc="default">	<section anchor="term" numbered="true" toc="default">

	<name>Terminology</name>	<name>Requirements Language</name>
	<t>	<t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	"OPTIONAL" in this document are to be interpreted as described in	",
	BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and	"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	only when, they appear in all capitals, as shown here.	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	</t>	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	</section>	be
		interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
		target="RFC8174"/> when, and only when, they appear in all capitals, as
		shown here.
		</t>


		</section>
	<section anchor="motive" numbered="true" toc="default">	<section anchor="motive" numbered="true" toc="default">
	<name>Motivation and Design Rationale</name>	<name>Motivation and Design Rationale</name>
	<t>	<t>
	There are two motivations for using a certificate with an external PSK.	There are two motivations for using a certificate with an external PSK.
	</t>	</t>
	<t>	<t>
	One motivation is confidentiality protection against the future inventio n of a	One motivation is confidentiality protection against the future inventio n of a
	Cryptographically Relevant Quantum Computer (CRQC), which would pose a s erious	Cryptographically Relevant Quantum Computer (CRQC), which would pose a s erious
	challenge for the asymmetric cryptographic algorithms that are widely de ployed	challenge for the asymmetric cryptographic algorithms that are widely de ployed
	today, including the digital signature algorithms that are used to authe nticate	today, including the digital signature algorithms that are used to authe nticate
	the server in the TLS 1.3 handshake protocol and key agreement algorithm used	the server in the TLS 1.3 handshake protocol and key agreement algorithm used
	to establish a pairwise shared secret between the client and server. It is an	to establish a pairwise shared secret between the client and server. It is an

	open question whether or not it is feasible to build such a quantum comp	open question whether or not it is feasible to build such a quantum comp
	uter,	uter
	and if so, when that might happen. However, if such a quantum computer	and, if so, when that might happen. However, if such a quantum computer
	is	is
	invented, many of the cryptographic algorithms and the security protocol s	invented, many of the cryptographic algorithms and the security protocol s

	that use them would become vulnerable. In particular, The TLS 1.3 hands hake	that use them would become vulnerable. In particular, the TLS 1.3 hands hake
	protocol employs key agreement algorithms that could be broken by the	protocol employs key agreement algorithms that could be broken by the
	invention of a CRQC <xref target="I-D.ietf-pquip-pqc-engineers"/>. Incl uding a	invention of a CRQC <xref target="I-D.ietf-pquip-pqc-engineers"/>. Incl uding a
	strong external PSK in the TLS 1.3 key schedule offers confidentiality p rotection	strong external PSK in the TLS 1.3 key schedule offers confidentiality p rotection
	against the long-term quantum computing threat; it requires the attacker to	against the long-term quantum computing threat; it requires the attacker to
	learn the external PSK as well as the shared secret produced by the key	learn the external PSK as well as the shared secret produced by the key
	agreement algorithm to break confidentiality.	agreement algorithm to break confidentiality.
	</t>	</t>
	<t>	<t>

	The term strong external PSK is used to mean that the PSK that has	The term "strong external PSK" is used to mean that the PSK that has
	been generated and distributed in such a way that the invention of a CRQ C	been generated and distributed in such a way that the invention of a CRQ C
	will not allow the owner of that quantum computer to learn the PSK. Whi le	will not allow the owner of that quantum computer to learn the PSK. Whi le
	generation and distribution of the PSK are outside the scope of this doc ument,	generation and distribution of the PSK are outside the scope of this doc ument,
	in the context of a CRQC, security of the TLS 1.3 session using the	in the context of a CRQC, security of the TLS 1.3 session using the

	strong external PSK relies on and implicitly tied to the confidentiality ,	strong external PSK relies on and is implicitly tied to the confidential ity,
	entropy, and authenticity of the PSK. Thus, the security claims in this	entropy, and authenticity of the PSK. Thus, the security claims in this
	document depend on generation and distribution of the strong external PS K.	document depend on generation and distribution of the strong external PS K.
	</t>	</t>
	<t>	<t>
	When a certificate is used for authentication, the authentication is	When a certificate is used for authentication, the authentication is
	provided by the existing certificate and digital signature mechanisms. This	provided by the existing certificate and digital signature mechanisms. This
	authentication cannot be relied upon if a CRQC is ever invented. The ad dition	authentication cannot be relied upon if a CRQC is ever invented. The ad dition
	of a strong external PSK in the TLS 1.3 key schedule does not offer impr ovement	of a strong external PSK in the TLS 1.3 key schedule does not offer impr ovement
	against the long-term quantum computing threat regarding authentication.	against the long-term quantum computing threat regarding authentication.
	</t>	</t>
	<t>	<t>

	Likewise, a raw public key can be provided as described in	Likewise, a raw public key can be provided, as described in
	<xref target="RFC7250"/>.	<xref target="RFC7250"/>.
	</t>	</t>
	<t>	<t>
	Quantum-resistant public-key cryptographic algorithms are becoming stand ards,	Quantum-resistant public-key cryptographic algorithms are becoming stand ards,
	but it will take many years for TLS 1.3 ciphersuites that use these algo rithms	but it will take many years for TLS 1.3 ciphersuites that use these algo rithms
	to be developed and deployed. In some environments, deployment of a str ong	to be developed and deployed. In some environments, deployment of a str ong
	external PSK provides protection until these quantum-resistant algorithm s	external PSK provides protection until these quantum-resistant algorithm s
	are deployed.	are deployed.
	</t>	</t>
	<t>	<t>

	skipping to change at line 152 ¶	skipping to change at line 149 ¶
	to be developed and deployed. In some environments, deployment of a str ong	to be developed and deployed. In some environments, deployment of a str ong
	external PSK provides protection until these quantum-resistant algorithm s	external PSK provides protection until these quantum-resistant algorithm s
	are deployed.	are deployed.
	</t>	</t>
	<t>	<t>
	Another motivation is the use of a public key with a factory-provisioned	Another motivation is the use of a public key with a factory-provisioned
	secret value for the initial enrollment of a device in an enterprise net work	secret value for the initial enrollment of a device in an enterprise net work
	<xref target="I-D.ietf-emu-bootstrapped-tls"/>.	<xref target="I-D.ietf-emu-bootstrapped-tls"/>.
	</t>	</t>
	</section>	</section>


	<section anchor="over" numbered="true" toc="default">	<section anchor="over" numbered="true" toc="default">
	<name>Extension Overview</name>	<name>Extension Overview</name>
	<t>	<t>
	This section provides a brief overview of the "tls_cert_with_extern_psk"	This section provides a brief overview of the "tls_cert_with_extern_psk"
	extension.	extension.
	</t>	</t>
	<t>	<t>
	The client includes the "tls_cert_with_extern_psk" extension in the	The client includes the "tls_cert_with_extern_psk" extension in the
	ClientHello message. The "tls_cert_with_extern_psk" extension <bcp14>MU ST</bcp14>	ClientHello message. The "tls_cert_with_extern_psk" extension <bcp14>MU ST</bcp14>
	be accompanied by the "key_share", "supported_groups", "psk_key_exchange _modes",	be accompanied by the "key_share", "supported_groups", "psk_key_exchange _modes",
	and "pre_shared_key" extensions. Since the "tls_cert_with_extern_psk"	and "pre_shared_key" extensions. Since the "tls_cert_with_extern_psk"
	extension is intended to be used only with initial handshakes, it	extension is intended to be used only with initial handshakes, it
	<bcp14>MUST NOT</bcp14> be sent alongside the "early_data" extension. T hese	<bcp14>MUST NOT</bcp14> be sent alongside the "early_data" extension. T hese

	extensions are all described in <xref target="I-D.ietf-tls-rfc8446bis" s ectionFormat="of" section="4.2"/>,	extensions are all described in <xref target="RFC9846" sectionFormat="of " section="4.2"/>,
	which also requires the "pre_shared_key" extension to be the last extens ion	which also requires the "pre_shared_key" extension to be the last extens ion
	in the ClientHello message.	in the ClientHello message.
	</t>	</t>
	<t>	<t>
	If the client includes both the "tls_cert_with_extern_psk" extension	If the client includes both the "tls_cert_with_extern_psk" extension
	and the "early_data" extension, then the server <bcp14>MUST</bcp14> term inate	and the "early_data" extension, then the server <bcp14>MUST</bcp14> term inate
	the connection with an "illegal_parameter" alert.	the connection with an "illegal_parameter" alert.
	</t>	</t>
	<t>	<t>
	If the server is willing to use one of the external PSKs listed in the	If the server is willing to use one of the external PSKs listed in the

	skipping to change at line 202 ¶	skipping to change at line 198 ¶
	all depend upon the value of the selected external PSK. Of course, the	all depend upon the value of the selected external PSK. Of course, the
	Early Secret does not depend upon the (EC)DHE shared secret.	Early Secret does not depend upon the (EC)DHE shared secret.
	</t>	</t>
	<t>	<t>
	The authentication of the server and optional authentication of	The authentication of the server and optional authentication of
	the client depend upon the ability to generate a signature that	the client depend upon the ability to generate a signature that
	can be validated with the public key in their certificates. The	can be validated with the public key in their certificates. The
	authentication processing is not changed in any way by the	authentication processing is not changed in any way by the
	selected external PSK. As a result, if a CRQC is ever invented,	selected external PSK. As a result, if a CRQC is ever invented,
	the digital signature algorithm will need to be replaced with a	the digital signature algorithm will need to be replaced with a

	quantum resistant one. Failure to do so will result in vulnerable	quantum-resistant one. Failure to do so will result in vulnerable
	entity and data authentication mechanisms.	entity and data authentication mechanisms.
	</t>	</t>
	<t>	<t>
	Each external PSK is associated with a single hash algorithm, which is r equired by	Each external PSK is associated with a single hash algorithm, which is r equired by

	<xref target="I-D.ietf-tls-rfc8446bis" sectionFormat="of" section="4.2.1 1"/>. The	<xref target="RFC9846" sectionFormat="of" section="4.2.11"/>. The
	hash algorithm <bcp14>MUST</bcp14> be set when the PSK is established, w ith a	hash algorithm <bcp14>MUST</bcp14> be set when the PSK is established, w ith a
	default of SHA-256.	default of SHA-256.
	</t>	</t>
	</section>	</section>


	<section anchor="extn" numbered="true" toc="default">	<section anchor="extn" numbered="true" toc="default">
	<name>Certificate with External PSK Extension</name>	<name>Certificate with External PSK Extension</name>
	<t>	<t>
	This section specifies the "tls_cert_with_extern_psk" extension, which	This section specifies the "tls_cert_with_extern_psk" extension, which
	<bcp14>MAY</bcp14> appear in the ClientHello message and ServerHello	<bcp14>MAY</bcp14> appear in the ClientHello message and ServerHello
	message. It <bcp14>MUST NOT</bcp14> appear in any other messages. The	message. It <bcp14>MUST NOT</bcp14> appear in any other messages. The
	"tls_cert_with_extern_psk" extension <bcp14>MUST NOT</bcp14> appear in t he	"tls_cert_with_extern_psk" extension <bcp14>MUST NOT</bcp14> appear in t he
	ServerHello message unless the "tls_cert_with_extern_psk" extension appe ared	ServerHello message unless the "tls_cert_with_extern_psk" extension appe ared
	in the preceding ClientHello message. If an implementation recognizes t he	in the preceding ClientHello message. If an implementation recognizes t he
	"tls_cert_with_extern_psk" extension and receives it in any other messag e,	"tls_cert_with_extern_psk" extension and receives it in any other messag e,
	then the implementation <bcp14>MUST</bcp14> abort the handshake with an	then the implementation <bcp14>MUST</bcp14> abort the handshake with an
	"illegal_parameter" alert.	"illegal_parameter" alert.
	</t>	</t>
	<t>	<t>
	The general extension mechanisms enable clients and servers to negotiate the	The general extension mechanisms enable clients and servers to negotiate the
	use of specific extensions. Clients request extended functionality from	use of specific extensions. Clients request extended functionality from
	servers with the extensions field in the ClientHello message. If the se rver	servers with the extensions field in the ClientHello message. If the se rver
	responds with a HelloRetryRequest message, then the client sends another	responds with a HelloRetryRequest message, then the client sends another
	ClientHello message as described in	ClientHello message as described in

	<xref target="I-D.ietf-tls-rfc8446bis" sectionFormat="of" section="4.1.2 "/>,	<xref target="RFC9846" sectionFormat="of" section="4.1.2"/>,
	including the same "tls_cert_with_extern_psk" extension as the original	including the same "tls_cert_with_extern_psk" extension as the original
	ClientHello message, or aborts the handshake.	ClientHello message, or aborts the handshake.
	</t>	</t>
	<t>	<t>
	Many server extensions are carried in the EncryptedExtensions	Many server extensions are carried in the EncryptedExtensions
	message; however, the "tls_cert_with_extern_psk" extension is	message; however, the "tls_cert_with_extern_psk" extension is
	carried in the ServerHello message. Successful negotiation of	carried in the ServerHello message. Successful negotiation of
	the "pre_shared_key" extension enables certificate verification	the "pre_shared_key" extension enables certificate verification
	to take place in addition to the inclusion of the external PSK in	to take place in addition to the inclusion of the external PSK in
	the key schedule. The external PSK is identified by the	the key schedule. The external PSK is identified by the
	"key_share" extension, and the inclusion of the external PSK in	"key_share" extension, and the inclusion of the external PSK in
	the key schedule affects the key used for encryption. The	the key schedule affects the key used for encryption. The
	"tls_cert_with_extern_psk" extension is only present in the	"tls_cert_with_extern_psk" extension is only present in the
	ServerHello message if the server recognizes the	ServerHello message if the server recognizes the
	"tls_cert_with_extern_psk" extension and the server possesses one	"tls_cert_with_extern_psk" extension and the server possesses one
	of the external PSKs offered by the client in the	of the external PSKs offered by the client in the
	"pre_shared_key" extension in the ClientHello message.	"pre_shared_key" extension in the ClientHello message.
	</t>	</t>
	<t>	<t>

	The Extension structure is defined in <xref target="I-D.ietf-tls-rfc8446 bis"/>;	The Extension structure is defined in <xref target="RFC9846"/>;
	it is repeated here for convenience.	it is repeated here for convenience.
	</t>	</t>

		<sourcecode type="tls-presentation"><![CDATA[
	<sourcecode type="tls-presentation"> struct {	struct {
	ExtensionType extension_type;	ExtensionType extension_type;

	opaque extension_data<0..2^16-1>;	opaque extension_data<0..2^16-1>;
	} Extension;	} Extension;

	</sourcecode>	]]></sourcecode>

	<t>	<t>
	The "extension_type" identifies the particular extension type,	The "extension_type" identifies the particular extension type,
	and the "extension_data" contains information specific to the	and the "extension_data" contains information specific to the
	particular extension type.	particular extension type.
	</t>	</t>
	<t>	<t>
	This document specifies the "tls_cert_with_extern_psk" extension,	This document specifies the "tls_cert_with_extern_psk" extension,
	adding one new type to ExtensionType:	adding one new type to ExtensionType:
	</t>	</t>

		<sourcecode type="tls-presentation"><![CDATA[
	<sourcecode type="tls-presentation"> enum {	enum {
	tls_cert_with_extern_psk(33), (65535)	tls_cert_with_extern_psk(33), (65535)
	} ExtensionType;	} ExtensionType;

	</sourcecode>	]]></sourcecode>

	<t>	<t>
	The "tls_cert_with_extern_psk" extension is relevant when the	The "tls_cert_with_extern_psk" extension is relevant when the
	client and server possess an external PSK in common that can be	client and server possess an external PSK in common that can be
	used as an input to the TLS 1.3 key schedule. The	used as an input to the TLS 1.3 key schedule. The
	"tls_cert_with_extern_psk" extension is essentially a flag to	"tls_cert_with_extern_psk" extension is essentially a flag to
	use the external PSK in the key schedule, and it has the	use the external PSK in the key schedule, and it has the
	following syntax:	following syntax:
	</t>	</t>

		<sourcecode type="tls-presentation"><![CDATA[
	<sourcecode type="tls-presentation" > struct {	struct {
	select (Handshake.msg_type) {	select (Handshake.msg_type) {
	case client_hello: Empty;	case client_hello: Empty;
	case server_hello: Empty;	case server_hello: Empty;
	};	};
	} CertWithExternPSK;	} CertWithExternPSK;

	</sourcecode>	]]></sourcecode>

	<section anchor="other-extns" numbered="true" toc="default">	<section anchor="other-extns" numbered="true" toc="default">
	<name>Companion Extensions</name>	<name>Companion Extensions</name>
	<t>	<t>
	<xref target="over"/> lists the extensions that are required to accomp any	<xref target="over"/> lists the extensions that are required to accomp any
	the "tls_cert_with_extern_psk" extension. Most of those extensions	the "tls_cert_with_extern_psk" extension. Most of those extensions
	are not impacted in any way by this specification. However, this	are not impacted in any way by this specification. However, this
	section discusses the extensions that require additional consideration .	section discusses the extensions that require additional consideration .
	</t>	</t>
	<t>	<t>
	The "psk_key_exchange_modes" extension is defined in	The "psk_key_exchange_modes" extension is defined in

	<xref target="I-D.ietf-tls-rfc8446bis" sectionFormat="of" section="4.2 .9"/>. The	<xref target="RFC9846" sectionFormat="of" section="4.2.9"/>. The
	"psk_key_exchange_modes" extension restricts the use of both the PS Ks	"psk_key_exchange_modes" extension restricts the use of both the PS Ks
	offered in this ClientHello and those that the server might supply via	offered in this ClientHello and those that the server might supply via
	a subsequent NewSessionTicket. As a result, when the "psk_key_exch ange_modes"	a subsequent NewSessionTicket. As a result, when the "psk_key_exch ange_modes"
	extension is included in the ClientHello message, clients <bcp14>MUST< /bcp14>	extension is included in the ClientHello message, clients <bcp14>MUST< /bcp14>
	include psk_dhe_ke mode. In addition, clients <bcp14>MAY</bcp14> also include	include psk_dhe_ke mode. In addition, clients <bcp14>MAY</bcp14> also include
	psk_ke mode to support a subsequent NewSessionTicket. When the	psk_ke mode to support a subsequent NewSessionTicket. When the
	"psk_key_exchange_modes" extension is included in the ClientHello	"psk_key_exchange_modes" extension is included in the ClientHello
	message, servers <bcp14>MUST</bcp14> select the psk_dhe_ke mode for th e	message, servers <bcp14>MUST</bcp14> select the psk_dhe_ke mode for th e
	initial handshake. Servers <bcp14>MUST</bcp14> select a key exchange mode	initial handshake. Servers <bcp14>MUST</bcp14> select a key exchange mode
	that is listed by the client for subsequent handshakes that include th e	that is listed by the client for subsequent handshakes that include th e
	resumption PSK from the initial handshake.	resumption PSK from the initial handshake.
	</t>	</t>
	<t>	<t>
	The "pre_shared_key" extension is defined in	The "pre_shared_key" extension is defined in

	<xref target="I-D.ietf-tls-rfc8446bis" sectionFormat="of" section="4.2 .11"/>. The	<xref target="RFC9846" sectionFormat="of" section="4.2.11"/>. The
	syntax is repeated below for convenience. All of the listed PSKs	syntax is repeated below for convenience. All of the listed PSKs
	<bcp14>MUST</bcp14> be external PSKs. If a resumption PSK is liste d along	<bcp14>MUST</bcp14> be external PSKs. If a resumption PSK is liste d along
	with the "tls_cert_with_extern_psk" extension, the server <bcp14>MU ST</bcp14>	with the "tls_cert_with_extern_psk" extension, the server <bcp14>MU ST</bcp14>
	abort the handshake with an "illegal_parameter" alert.	abort the handshake with an "illegal_parameter" alert.
	</t>	</t>

		<sourcecode type="tls-presentation"><![CDATA[
	<sourcecode type="tls-presentation"> struct {	struct {
	opaque identity<1..2^16-1>;	opaque identity<1..2^16-1>;
	uint32 obfuscated_ticket_age;	uint32 obfuscated_ticket_age;
	} PskIdentity;	} PskIdentity;


	opaque PskBinderEntry<32..255>;	opaque PskBinderEntry<32..255>;

	struct {	struct {

	PskIdentity identities<7..2^16-1>;	PskIdentity identities<7..2^16-1>;
	PskBinderEntry binders<33..2^16-1>;	PskBinderEntry binders<33..2^16-1>;
	} OfferedPsks;	} OfferedPsks;

	struct {	struct {
	select (Handshake.msg_type) {	select (Handshake.msg_type) {
	case client_hello: OfferedPsks;	case client_hello: OfferedPsks;
	case server_hello: uint16 selected_identity;	case server_hello: uint16 selected_identity;
	};	};
	} PreSharedKeyExtension;	} PreSharedKeyExtension;

	</sourcecode>	]]></sourcecode>

	<t>	<t>
	"OfferedPsks" contains the list of PSK identities and	"OfferedPsks" contains the list of PSK identities and
	associated binders for the external PSKs that the client is	associated binders for the external PSKs that the client is
	willing to use with the server.	willing to use with the server.
	</t>	</t>
	<t>	<t>
	The identities are a list of external PSK identities that the	The identities are a list of external PSK identities that the
	client is willing to negotiate with the server. Each external	client is willing to negotiate with the server. Each external
	PSK has an associated identity that is known to the client	PSK has an associated identity that is known to the client
	and the server; the associated identities may be known to other	and the server; the associated identities may be known to other
	parties as well. In addition, the binder validation (see below)	parties as well. In addition, the binder validation (see below)
	confirms that the client and server have the same key associated	confirms that the client and server have the same key associated
	with the identity.	with the identity.
	</t>	</t>
	<t>	<t>
	The "obfuscated_ticket_age" is not used for external PSKs. As	The "obfuscated_ticket_age" is not used for external PSKs. As

	stated in <xref target="I-D.ietf-tls-rfc8446bis" sectionFormat="of" se ction="4.2.11"/>,	stated in <xref target="RFC9846" sectionFormat="of" section="4.2.11"/> ,
	clients <bcp14>SHOULD</bcp14> set this value to 0, and servers	clients <bcp14>SHOULD</bcp14> set this value to 0, and servers
	<bcp14>MUST</bcp14> ignore the value.	<bcp14>MUST</bcp14> ignore the value.
	</t>	</t>
	<t>	<t>
	The binders are a series of HMAC <xref target="RFC2104" format="defaul t"/>	The binders are a series of HMAC <xref target="RFC2104" format="defaul t"/>
	values, one for each external PSK offered by the client, in the same o rder	values, one for each external PSK offered by the client, in the same o rder
	as the identities list. The HMAC value is computed using the binder_k ey,	as the identities list. The HMAC value is computed using the binder_k ey,
	which is derived from the external PSK, and a partial transcript of th e	which is derived from the external PSK, and a partial transcript of th e
	current handshake. Generation of the binder_key from the external PSK is described	current handshake. Generation of the binder_key from the external PSK is described

	in <xref target="I-D.ietf-tls-rfc8446bis" sectionFormat="of" section=" 7.1"/>. The	in <xref target="RFC9846" sectionFormat="of" section="7.1"/>. The
	partial transcript of the current handshake includes a partial ClientH ello	partial transcript of the current handshake includes a partial ClientH ello
	up to and including the PreSharedKeyExtension.identities field, as des cribed	up to and including the PreSharedKeyExtension.identities field, as des cribed

	in <xref target="I-D.ietf-tls-rfc8446bis" sectionFormat="of" section=" 4.2.11.2"/>.	in <xref target="RFC9846" sectionFormat="of" section="4.2.11.2"/>.
	</t>	</t>
	<t>	<t>
	The "selected_identity" contains the index of the external PSK identit y	The "selected_identity" contains the index of the external PSK identit y
	that the server selected from the list offered by the client. As desc ribed	that the server selected from the list offered by the client. As desc ribed

	in <xref target="I-D.ietf-tls-rfc8446bis" sectionFormat="of" section=" 4.2.11"/>, the	in <xref target="RFC9846" sectionFormat="of" section="4.2.11"/>, the
	server <bcp14>MUST</bcp14> validate the binder value that corresponds	server <bcp14>MUST</bcp14> validate the binder value that corresponds
	to the selected external PSK, and if the binder does not validate, the	to the selected external PSK, and if the binder does not validate, the
	server <bcp14>MUST</bcp14> abort the handshake with an "illegal_parame ter"	server <bcp14>MUST</bcp14> abort the handshake with an "illegal_parame ter"
	alert.	alert.
	</t>	</t>
	</section>	</section>


	<section anchor="authn" numbered="true" toc="default">	<section anchor="authn" numbered="true" toc="default">
	<name>Authentication</name>	<name>Authentication</name>
	<t>	<t>
	When the "tls_cert_with_extern_psk" extension is successfully	When the "tls_cert_with_extern_psk" extension is successfully
	negotiated, authentication of the server depends upon the ability to	negotiated, authentication of the server depends upon the ability to
	generate a signature that can be validated with the public key. When	generate a signature that can be validated with the public key. When
	the server uses a certificate, this is accomplished by the server	the server uses a certificate, this is accomplished by the server
	sending the Certificate and CertificateVerify messages, as described	sending the Certificate and CertificateVerify messages, as described

	in Sections <xref target="I-D.ietf-tls-rfc8446bis" sectionFormat="bare	in Sections <xref target="RFC9846" sectionFormat="bare" section="4.4.2
	" section="4.4.2"/>	"/>
	and <xref target="I-D.ietf-tls-rfc8446bis" sectionFormat="bare" sectio	and <xref target="RFC9846" sectionFormat="bare" section="4.4.3"/> of
	n="4.4.3"/> of	<xref target="RFC9846"/>. Alternatively, the server can use a raw pub
	<xref target="I-D.ietf-tls-rfc8446bis"/>. Alternatively, the server c	lic
	an use a raw public	key, as described in <xref target="RFC7250" format="default"/>.
	key as described in <xref target="RFC7250" format="default"/>.
	</t>	</t>
	<t>	<t>
	TLS 1.3 does not permit the server to send a CertificateRequest messag e	TLS 1.3 does not permit the server to send a CertificateRequest messag e
	when a PSK is being used. This restriction is removed when the	when a PSK is being used. This restriction is removed when the
	"tls_cert_with_extern_psk" extension is negotiated, allowing	"tls_cert_with_extern_psk" extension is negotiated, allowing
	certificate-based authentication for both the client and the server. If	certificate-based authentication for both the client and the server. If
	certificate-based client authentication is desired, this is accomplish ed	certificate-based client authentication is desired, this is accomplish ed
	by the client sending the Certificate and CertificateVerify messages a s	by the client sending the Certificate and CertificateVerify messages a s

	described in Sections <xref target="I-D.ietf-tls-rfc8446bis" sectionFo	described in Sections <xref target="RFC9846" sectionFormat="bare" sect
	rmat="bare" section="4.4.2"/>	ion="4.4.2"/>
	and <xref target="I-D.ietf-tls-rfc8446bis" sectionFormat="bare" sectio	and <xref target="RFC9846" sectionFormat="bare" section="4.4.3"/> of
	n="4.4.3"/> of	<xref target="RFC9846"/>.
	<xref target="I-D.ietf-tls-rfc8446bis"/>.
	</t>	</t>
	</section>	</section>


	<section anchor="keying" numbered="true" toc="default">	<section anchor="keying" numbered="true" toc="default">
	<name>Keying Material</name>	<name>Keying Material</name>
	<t>	<t>

	<xref target="I-D.ietf-tls-rfc8446bis" sectionFormat="of" section="7.1 "/>	<xref target="RFC9846" sectionFormat="of" section="7.1"/>
	specifies the TLS 1.3 key schedule. The successful negotiation of the	specifies the TLS 1.3 key schedule. The successful negotiation of the
	"tls_cert_with_extern_psk" extension requires the key schedule	"tls_cert_with_extern_psk" extension requires the key schedule
	processing to include both the external PSK and the (EC)DHE	processing to include both the external PSK and the (EC)DHE
	shared secret value.	shared secret value.
	</t>	</t>
	<t>	<t>
	If the client and the server have different values associated	If the client and the server have different values associated
	with the selected external PSK identifier, then the client and	with the selected external PSK identifier, then the client and
	the server will compute different values for every entry in the	the server will compute different values for every entry in the
	key schedule, which will lead to the client aborting the	key schedule, which will lead to the client aborting the

	skipping to change at line 432 ¶	skipping to change at line 421 ¶
	</t>	</t>
	<t>	<t>
	If the client and the server have different values associated	If the client and the server have different values associated
	with the selected external PSK identifier, then the client and	with the selected external PSK identifier, then the client and
	the server will compute different values for every entry in the	the server will compute different values for every entry in the
	key schedule, which will lead to the client aborting the	key schedule, which will lead to the client aborting the
	handshake with a "decrypt_error" alert.	handshake with a "decrypt_error" alert.
	</t>	</t>
	</section>	</section>
	</section>	</section>


	<section anchor="IANA-con" numbered="true" toc="default">	<section anchor="IANA-con" numbered="true" toc="default">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>
	<t>	<t>

	Once this document is approved, IANA is asked to update the	IANA has updated the
	"TLS ExtensionType Values" registry <xref target="IANA" format="default" />	"TLS ExtensionType Values" registry <xref target="IANA" format="default" />
	entry for the "tls_cert_with_extern_psk" extension to reference this doc ument.	entry for the "tls_cert_with_extern_psk" extension to reference this doc ument.
	</t>	</t>
	</section>	</section>


	<section anchor="security" numbered="true" toc="default">	<section anchor="security" numbered="true" toc="default">
	<name>Security Considerations</name>	<name>Security Considerations</name>
	<t>	<t>

	The Security Considerations in <xref target="I-D.ietf-tls-rfc8446bis"/> remain relevant.	The Security Considerations in <xref target="RFC9846"/> remain relevant.
	</t>	</t>
	<t>	<t>

	TLS 1.3 <xref target="I-D.ietf-tls-rfc8446bis" format="default"/> does n ot permit	TLS 1.3 <xref target="RFC9846" format="default"/> does not permit
	the server to send a CertificateRequest message when a PSK	the server to send a CertificateRequest message when a PSK
	is being used. This restriction is removed when the	is being used. This restriction is removed when the
	"tls_cert_with_extern_psk" extension is offered by the client	"tls_cert_with_extern_psk" extension is offered by the client
	and accepted by the server. However, TLS 1.3 does not	and accepted by the server. However, TLS 1.3 does not
	permit an external PSK to be used in the same fashion as a	permit an external PSK to be used in the same fashion as a
	resumption PSK, and this extension preserves that restriction.	resumption PSK, and this extension preserves that restriction.
	</t>	</t>
	<t>	<t>
	Implementations must protect the external pre-shared key (PSK).	Implementations must protect the external pre-shared key (PSK).
	Compromise of the external PSK will make the encrypted session	Compromise of the external PSK will make the encrypted session

	skipping to change at line 482 ¶	skipping to change at line 469 ¶
	technique, such as pseudorandom generation of the key or derivation of	technique, such as pseudorandom generation of the key or derivation of
	the key from one or more other secure keys. The use of inadequate	the key from one or more other secure keys. The use of inadequate
	pseudorandom number generators (PRNGs) to generate external PSKs can	pseudorandom number generators (PRNGs) to generate external PSKs can
	result in little or no security. An attacker may find it much easier	result in little or no security. An attacker may find it much easier
	to reproduce the PRNG environment that produced the external PSKs and	to reproduce the PRNG environment that produced the external PSKs and
	search the resulting small set of possibilities, rather than brute-force	search the resulting small set of possibilities, rather than brute-force
	searching the whole key space. The generation of quality random	searching the whole key space. The generation of quality random
	numbers is difficult. <xref target="RFC4086" format="default"/> offers	numbers is difficult. <xref target="RFC4086" format="default"/> offers
	important guidance in this area.	important guidance in this area.
	</t>	</t>


		<!--[rfced] FYI - We have updated the citation below from Section 2.1 to
		Section 3.1, as the document cited does not contain a Section 2.1.
		Please review.

		Original:
		While Grover's algorithm (described in
		Section 2.1 of [I-D.ietf-pquip-pqc-engineers]) allows a quantum
		computer to perform a brute force key search using quadratically
		fewer steps than would be required with classical computers...

		Current:
		While Grover's algorithm (described in
		Section 3.1 of [PQC]) allows a quantum computer to perform a brute
		force key search using quadratically fewer steps than would be
		required with classical computers...
		-->

	<t>	<t>
	Implementations must use a ciphersuite that includes a symmetric	Implementations must use a ciphersuite that includes a symmetric
	encryption algorithm with sufficiently large keys. For protection again st	encryption algorithm with sufficiently large keys. For protection again st
	the future invention of a CRQC, the symmetric key needs to be at least 1 28	the future invention of a CRQC, the symmetric key needs to be at least 1 28

	bits. While Grover’s algorithm (described in	bits. While Grover's algorithm (described in
	<xref target="I-D.ietf-pquip-pqc-engineers" sectionFormat="of" section="	<xref target="I-D.ietf-pquip-pqc-engineers" sectionFormat="of" section="
	2.1"/>)	3.1"/>)
	allows a quantum computer to perform a brute force key search using	allows a quantum computer to perform a brute force key search using
	quadratically fewer steps than would be required with classical computer s,	quadratically fewer steps than would be required with classical computer s,

	there are a number of mitigating factors suggesting that Grover’s algori	there are a number of mitigating factors suggesting that Grover's algori
	thm	thm
	will not speed up brute force symmetric key search as dramatically as on	will not speed up a brute force symmetric key search as dramatically as
	e	one
	might suspect. First, quantum computing hardware will likely be more	might suspect. First, quantum computing hardware will likely be more
	expensive to build and use than classical hardware. Second, to obtain t he	expensive to build and use than classical hardware. Second, to obtain t he

	full quadratic speedup, all the steps of Grover’s algorithm must be perf	full quadratic speedup, all the steps of Grover's algorithm must be perf
	ormed	ormed
	in series. However, attacks on cryptography use massively parallel proc	in series. However, attacks on cryptography use massively parallel proc
	essing,	essing;
	the advantage of Grover's algorithm will be smaller.	the advantage of Grover's algorithm will be smaller.
	</t>	</t>
	<t>	<t>
	Implementations must use sufficiently large external PSKs. For protecti on	Implementations must use sufficiently large external PSKs. For protecti on
	against the future invention of a CRQC, the external PSK needs to be at	against the future invention of a CRQC, the external PSK needs to be at
	least 128 bits.	least 128 bits.
	</t>	</t>
	<t>	<t>

	TLS 1.3 <xref target="I-D.ietf-tls-rfc8446bis" format="default"/> has re ceived careful	TLS 1.3 <xref target="RFC9846" format="default"/> has received careful
	security analysis, and the following informal reasoning shows that the	security analysis, and the following informal reasoning shows that the
	addition of this extension does not introduce any security	addition of this extension does not introduce any security

	defects in the threat model of a traditional adversary, that is	defects in the threat model of a traditional adversary, that is,
	an adversary that does not have access to a CRQC. This extension	an adversary that does not have access to a CRQC. This extension
	requires the use of certificates for authentication, but the	requires the use of certificates for authentication, but the
	processing of certificates is unchanged by this extension. This	processing of certificates is unchanged by this extension. This
	extension requires an external PSK in the key schedule as part of	extension requires an external PSK in the key schedule as part of
	the computation of the Early Secret. In the initial handshake	the computation of the Early Secret. In the initial handshake

	without an external PSK in <xref target="I-D.ietf-tls-rfc8446bis" format ="default"/>,	without an external PSK in <xref target="RFC9846" format="default"/>,
	the Early Secret is computed as:	the Early Secret is computed as:
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	Early Secret = HKDF-Extract(0, 0)	Early Secret = HKDF-Extract(0, 0)

	</sourcecode>	]]></sourcecode>
	<t>	<t>
	With this extension, the Early Secret is computed as:	With this extension, the Early Secret is computed as:
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	Early Secret = HKDF-Extract(0, External PSK)	Early Secret = HKDF-Extract(0, External PSK)

	</sourcecode>	]]></sourcecode>
	<t>	<t>
	Any entropy contributed by the external PSK can only make the Early	Any entropy contributed by the external PSK can only make the Early

	Secret better; the External PSK cannot make it worse. Thus, TLS 1.3	Secret better; the external PSK cannot make it worse. Thus, TLS 1.3
	continues to meet well-studied confidentiality goals when this extension	continues to meet well-studied confidentiality goals when this extension
	is used.	is used.
	</t>	</t>
	<t>	<t>
	Even when the external PSK is not known to any party other than the clie nt	Even when the external PSK is not known to any party other than the clie nt

	and the server, then the external PSK <bcp14>MUST NOT</bcp14> be the sol e	and the server, the external PSK <bcp14>MUST NOT</bcp14> be the sole
	basis for authentication. The reasoning is explained in Section 4.2 of	basis for authentication. The reasoning is explained in Section 4.2 of
	<xref target="K2016" format="default"/>. The authentication of the serv er	<xref target="K2016" format="default"/>. The authentication of the serv er
	and optional authentication of the client depend upon the ability to gen erate	and optional authentication of the client depend upon the ability to gen erate
	a signature that can be validated with the public key in their certifica tes. The	a signature that can be validated with the public key in their certifica tes. The
	authentication processing is not changed in any way by the selected exte rnal PSK.	authentication processing is not changed in any way by the selected exte rnal PSK.
	</t>	</t>
	<t>	<t>
	This external PSK preserves some confidentiality and authentication	This external PSK preserves some confidentiality and authentication
	even if the (EC)DH key agreement is broken by cryptanalysis or the futur e	even if the (EC)DH key agreement is broken by cryptanalysis or the futur e
	invention of a CRQC. As long as the attacker does not know the PSK and the	invention of a CRQC. As long as the attacker does not know the PSK and the

	skipping to change at line 555 ¶	skipping to change at line 560 ¶
	session secrets, even if the attacker is able to compute the (EC)DH shar ed	session secrets, even if the attacker is able to compute the (EC)DH shar ed
	secret. While the ephemeral (EC)DH private key used during a given TLS 1 .3	secret. While the ephemeral (EC)DH private key used during a given TLS 1 .3
	session is destroyed before the end of a session, the (EC)DH private key	session is destroyed before the end of a session, the (EC)DH private key
	would nevertheless be recoverable due to the break of the (EC)DH	would nevertheless be recoverable due to the break of the (EC)DH
	algorithm. However, a more general notion of "secrecy after key materia l	algorithm. However, a more general notion of "secrecy after key materia l
	is destroyed" would still be achievable using external PSKs, if they are	is destroyed" would still be achievable using external PSKs, if they are
	managed in a way that ensures their destruction when they are no longer	managed in a way that ensures their destruction when they are no longer
	needed, and with the assumption that the symmetric algorithms remain saf e	needed, and with the assumption that the symmetric algorithms remain saf e
	against the invention of a CRQC.	against the invention of a CRQC.
	</t>	</t>


		<!--[rfced] Per usage throughout the document, should the following instances
		of "confidentially" be updated to "confidentiality"?

		Original:
		The confidentially and authentication provided by the external PSK depend
		on whether the external PSK is used for more than one TLS 1.3 session
		and the parties that know the external PSK.
		...
		* 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
		confidentially and authentication is provided, including the
		cryptographic separation between TLS 1.3 sessions.
		...
		* 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
		is limited to the client and server, but there is no cryptographic
		separation between TLS 1.3 sessions.
		...
		* 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
		confidentially is limited to the group that knows the external
		PSK, but there is no cryptographic separation between TLS 1.3
		sessions.
		-->

	<t>	<t>
	The forward-secrecy advantages traditionally associated with ephemeral	The forward-secrecy advantages traditionally associated with ephemeral
	(EC)DH keys are not easily replaced by external PSKs. The confidentially	(EC)DH keys are not easily replaced by external PSKs. The confidentially
	and authentication provided by the external PSK depend on whether the	and authentication provided by the external PSK depend on whether the
	external PSK is used for more than one TLS 1.3 session and the parties	external PSK is used for more than one TLS 1.3 session and the parties
	that know the external PSK. Assuming the (EC)DH key agreement is broken:	that know the external PSK. Assuming the (EC)DH key agreement is broken:

	<ul>	</t>
	<li>	<ul>
		<li>
	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	confidentially and authentication is provided, including the
	cryptographic separation between TLS 1.3 sessions. Of course, this	cryptographic separation between TLS 1.3 sessions. Of course, this
	places a significant burden on the generation and distribution of	places a significant burden on the generation and distribution of
	external PSKs.	external PSKs.
	</li>	</li>

	<li>	<li>
	If the external PSK is used for more than one TLS 1.3 session and it is	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 is limi ted	known only by the client and server, then the confidentially is limi ted
	to the client and server, but there is no cryptographic separation	to the client and server, but there is no cryptographic separation
	between TLS 1.3 sessions.	between TLS 1.3 sessions.
	</li>	</li>

	<li>	<li>
	If the external PSK is used for more than one TLS 1.3 session and it is	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 confidentially is l imited	known by the client, server, and others, then the confidentially is limited
	to the group that knows the external PSK, but there is no cryptograp hic	to the group that knows the external PSK, but there is no cryptograp hic
	separation between TLS 1.3 sessions.	separation between TLS 1.3 sessions.
	</li>	</li>

	</ul>	</ul>
	</t>
	<t>	<t>
	This specification does not require that the external PSK is known only by	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 group. Since	the client and server. The external PSK may be known to a group. Since
	authentication depends on the public key in a certificate, knowledge of	authentication depends on the public key in a certificate, knowledge of
	the external PSK by other parties does not enable impersonation. The	the external PSK by other parties does not enable impersonation. The
	authentication of the server and optional authentication of the client	authentication of the server and optional authentication of the client
	depend upon the ability to generate a signature that can be validated wi th	depend upon the ability to generate a signature that can be validated wi th
	the public key in their certificates. The authentication processing is not	the public key in their certificates. The authentication processing is not
	changed in any way by the selected external PSK.	changed in any way by the selected external PSK.
	</t>	</t>


		<!--[rfced] To improve readability, may we rephrase this sentence as
		follows?

		Original:
		Once an attacker has the external PSK, they can decrypt stored
		traffic if they ever gain access to a CRQC, in the same manner as a
		legitimate group member.

		Perhaps:
		Once an attacker has the external PSK, they can decrypt stored
		traffic in the same manner as a legitimate group member, if they ever
		gain access to a CRQC
		-->

	<t>	<t>
	Confidentiality depends on the shared secret from (EC)DH, so knowledge o f	Confidentiality depends on the shared secret from (EC)DH, so knowledge o f
	the external PSK by other parties does not enable eavesdropping. Howeve r,	the external PSK by other parties does not enable eavesdropping. Howeve r,
	group members can record the traffic of other members and then decrypt t hat	group members can record the traffic of other members and then decrypt t hat
	traffic if they ever gain access to a CRQC. Also, when many parties kno w the	traffic if they ever gain access to a CRQC. Also, when many parties kno w the
	external PSK, there are many opportunities for theft of the external PSK by an	external PSK, there are many opportunities for theft of the external PSK by an
	attacker. Once an attacker has the external PSK, they can decrypt store d	attacker. Once an attacker has the external PSK, they can decrypt store d
	traffic if they ever gain access to a CRQC, in the same manner as a	traffic if they ever gain access to a CRQC, in the same manner as a
	legitimate group member.	legitimate group member.
	</t>	</t>
	<t>	<t>
	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	Function (HKDF) algorithm, which depends upon the HMAC
	<xref target="RFC2104" format="default"/> construction and a hash	<xref target="RFC2104" format="default"/> construction and a hash
	function. This extension provides the desired protection for the	function. This extension provides the desired protection for the
	session secrets, as long as HMAC with the selected hash function is	session secrets, as long as HMAC with the selected hash function is
	a pseudorandom function (PRF) <xref target="GGM1986" format="default"/>.	a pseudorandom function (PRF) <xref target="GGM1986" format="default"/>.
	</t>	</t>
	<t>	<t>

	TLS 1.3 <xref target="I-D.ietf-tls-rfc8446bis" format="default"/> takes a conservative	TLS 1.3 <xref target="RFC9846" format="default"/> takes a conservative
	approach to PSKs; they are bound to a specific hash function and KDF. B y	approach to PSKs; they are bound to a specific hash function and KDF. B y
	contrast, TLS 1.2 <xref target="RFC5246" format="default"/> allows PSKs to be	contrast, TLS 1.2 <xref target="RFC5246" format="default"/> allows PSKs to be
	used with any hash function and the TLS 1.2 PRF. Thus, the safest appro ach is	used with any hash function and the TLS 1.2 PRF. Thus, the safest appro ach is
	to use a PSK exclusively with TLS 1.2 or exclusively with TLS 1.3. Give n one	to use a PSK exclusively with TLS 1.2 or exclusively with TLS 1.3. Give n one
	PSK, one can derive a PSK for exclusive use with TLS 1.2 and derive anot her	PSK, one can derive a PSK for exclusive use with TLS 1.2 and derive anot her
	PSK for exclusive use with TLS 1.3 using the mechanism specified in	PSK for exclusive use with TLS 1.3 using the mechanism specified in
	<xref target="RFC9258" format="default"/>.	<xref target="RFC9258" format="default"/>.
	</t>	</t>
	</section>	</section>


	<section anchor="privacy" numbered="true" toc="default">	<section anchor="privacy" numbered="true" toc="default">
	<name>Privacy Considerations</name>	<name>Privacy Considerations</name>
	<t>	<t>

	<xref target="I-D.ietf-tls-rfc8446bis" sectionFormat="of" section="F.6"/ > discusses	<xref target="RFC9846" sectionFormat="of" section="F.6"/> discusses
	identity-exposure attacks on PSKs. Also,	identity-exposure attacks on PSKs. Also,

	<xref target="I-D.ietf-tls-rfc8446bis" sectionFormat="of" section="C.4"/ >	<xref target="RFC9846" sectionFormat="of" section="C.4"/>
	discusses tracking prevention. The guidance in these sections remain re levant.	discusses tracking prevention. The guidance in these sections remain re levant.
	</t>	</t>


		<!--[rfced] To reflect RFC 9849, should "Encrypted Client Hello
		extension" be updated to "'encrypted_client_hello' extension"?

		Original:
		The rotation of the external PSK identity or the use of
		the Encrypted Client Hello extension [I-D.ietf-tls-esni] can mitigate
		this risk.

		Perhaps:
		The rotation of the external PSK identity or the use of
		the "encrypted_client_hello" extension [I-D.ietf-tls-esni] can mitigate
		this risk.
		-->

	<t>	<t>
	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 th e	connections. The rotation of the external PSK identity or the use of th e

	Encrypted Client Hello extension <xref target="I-D.ietf-tls-esni"/> can	Encrypted Client Hello extension <xref target="RFC9849"/> can
	mitigate this risk.	mitigate this risk.
	</t>	</t>
	<t>	<t>
	This extension makes use of external PSKs to improve resilience against	This extension makes use of external PSKs to improve resilience against
	attackers that gain access to a CRQC in the future and provides authenti cation	attackers that gain access to a CRQC in the future and provides authenti cation
	for initial enrollment of devices in an enterprise network. This extens ion is	for initial enrollment of devices in an enterprise network. This extens ion is
	always accompanied by the "pre_shared_key" extension to provide the PSK	always accompanied by the "pre_shared_key" extension to provide the PSK
	identities in plaintext in the ClientHello message. Passive observation of	identities in plaintext in the ClientHello message. Passive observation of
	the these PSK identities will aid an attacker in tracking users or devic es	the these PSK identities will aid an attacker in tracking users or devic es
	that make use of this extension.	that make use of this extension.

	skipping to change at line 649 ¶	skipping to change at line 709 ¶
	<t>	<t>
	This extension makes use of external PSKs to improve resilience against	This extension makes use of external PSKs to improve resilience against
	attackers that gain access to a CRQC in the future and provides authenti cation	attackers that gain access to a CRQC in the future and provides authenti cation
	for initial enrollment of devices in an enterprise network. This extens ion is	for initial enrollment of devices in an enterprise network. This extens ion is
	always accompanied by the "pre_shared_key" extension to provide the PSK	always accompanied by the "pre_shared_key" extension to provide the PSK
	identities in plaintext in the ClientHello message. Passive observation of	identities in plaintext in the ClientHello message. Passive observation of
	the these PSK identities will aid an attacker in tracking users or devic es	the these PSK identities will aid an attacker in tracking users or devic es
	that make use of this extension.	that make use of this extension.
	</t>	</t>
	</section>	</section>


	</middle>	</middle>


	<back>	<back>

	<references title="Normative References">	<displayreference target="I-D.ietf-pquip-pqc-engineers" to="PQC"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen	<displayreference target="I-D.ietf-emu-bootstrapped-tls" to="TLS-POK"/>
	ce.RFC.2119.xml"/>	<references>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen	<name>References</name>
	ce.RFC.7250.xml"/>	<references>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen	<name>Normative References</name>
	ce.RFC.8174.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere	119.xml"/>
	nce.I-D.ietf-tls-rfc8446bis.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	</references>	250.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<references title="Informative References">	174.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.2104.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.4086.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.5246.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.9258.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
	nce.I-D.ietf-tls-esni.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
	nce.I-D.ietf-pquip-pqc-engineers.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
	nce.I-D.ietf-emu-bootstrapped-tls.xml"/>


	<reference anchor="GGM1986" target="https://dl.acm.org/doi/10.1145/6490.65	<!-- [RFC9846]
	03">	draft-ietf-tls-rfc8446bis-14
	<front>	companion doc RFC 9846
	<title>How to construct random functions</title>	in AUTH48 as of 12/15/25
	<author initials="O" surname="Goldreich" fullname="Oded Goldreich"/>	-->
	<author initials="S" surname="Goldwasser" fullname="Shafi Goldwasser"/
	>
	<author initials="S" surname="Micali" fullname="Silvio Micali"/>
	<date year="1986" month="August"/>
	</front>
	<refcontent>Journal of the ACM</refcontent>
	<refcontent>Vol. 33, No. 4</refcontent>
	<refcontent>pp. 792-807</refcontent>
	<seriesInfo name="DOI" value="10.1145/6490.6503"/>
	</reference>


	<reference anchor="IANA" target="https://www.iana.org/assignments/tls-exte	<reference anchor="RFC9846" target="https://www.rfc-editor.org/info/rfc9846">
	nsiontype-values/tls-extensiontype-values.xhtml">	<front>
	<front>	<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
	<title>TLS ExtensionType Values</title>	<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
	<author><organization>IANA</organization></author>	<organization>Independent</organization>
	</front>	</author>
	</reference>	<date month='January' year='2026'/>
		</front>
		<seriesInfo name="RFC" value="9846"/>
		<seriesInfo name="DOI" value="10.17487/RFC9846"/>
		</reference>


	<reference anchor="Err7598" target="https://www.rfc-editor.org/errata/eid7	</references>
	598">	<references>
	<front>	<name>Informative References</name>
	<title>RFC Errata 7598</title>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<author><organization>RFC Editor</organization></author>	773.xml"/>
	</front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	</reference>	104.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
		086.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
		246.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		258.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		849.xml"/>


	<reference anchor="K2016" target="https://eprint.iacr.org/2016/711">	<!-- [I-D.ietf-pquip-pqc-engineers]
	<front>	draft-ietf-pquip-pqc-engineers-14 (in queue)
	<title>A Unilateral-to-Mutual Authentication Compiler for Key Exchange	-->
	(with Applications to Client Authentication in TLS1.3)</title>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pqu
	<author initials="H" surname="Krawczyk" fullname="Hugo Krawczyk"/>	ip-pqc-engineers.xml"/>
	<date day="1" month="September" year="2016"/>
	</front>
	<seriesInfo name="cryptoeprint" value="2016/711"/>
	</reference>


		<!-- [I-D.ietf-emu-bootstrapped-tls]
		draft-ietf-emu-bootstrapped-tls-11 (in queue)
		-->
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
		ietf-emu-bootstrapped-tls.xml"/>
		<reference anchor="GGM1986" target="https://dl.acm.org/doi/10.1145/6490.
		6503">
		<front>
		<title>How to construct random functions</title>
		<author initials="O" surname="Goldreich" fullname="Oded Goldreich"/>
		<author initials="S" surname="Goldwasser" fullname="Shafi Goldwasser
		"/>
		<author initials="S" surname="Micali" fullname="Silvio Micali"/>
		<date year="1986" month="August"/>
		</front>
		<refcontent>Journal of the ACM (JACM)</refcontent>
		<refcontent>vol. 33, no. 4</refcontent>
		<refcontent>pp. 792-807</refcontent>
		<seriesInfo name="DOI" value="10.1145/6490.6503"/>
		</reference>
		<reference anchor="IANA" target="https://www.iana.org/assignments/tls-ex
		tensiontype-values">
		<front>
		<title>TLS ExtensionType Values</title>
		<author>
		<organization>IANA</organization>
		</author>
		</front>
		</reference>
		<reference anchor="Err7598" quote-title="false" target="https://www.rfc-
		editor.org/errata/eid7598">
		<front>
		<title>Erratum ID 7598</title>
		<author>
		<organization>RFC Errata</organization>
		</author>
		</front>
		<refcontent>RFC 8773</refcontent>
		</reference>
		<reference anchor="K2016" target="https://eprint.iacr.org/2016/711">
		<front>
		<title>A Unilateral-to-Mutual Authentication Compiler for Key Exchan
		ge
		(with Applications to Client Authentication in TLS 1.3)</title>
		<author initials="H" surname="Krawczyk" fullname="Hugo Krawczyk"/>
		<date year="2016"/>
		</front>
		<refcontent>Cryptology ePrint Archive, Paper 2016/711</refcontent>
		</reference>
		</references>
	</references>	</references>

		<section anchor="changes" numbered="true">
	<section anchor="changes" numbered="true" >
	<name>Changes Since RFC 8773</name>	<name>Changes Since RFC 8773</name>
	<t>	<t>
	The status elevation from Experimental RFC to Standards Track RFC is the most	The status elevation from Experimental RFC to Standards Track RFC is the most
	significant change in this document.	significant change in this document.
	</t>	</t>
	<t>	<t>
	In addition to minor editorial updates, which include a change to the ti tle,	In addition to minor editorial updates, which include a change to the ti tle,
	the following changes were made:	the following changes were made:

	<ul>	</t>
	<li>	<ul>
		<li>
	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.
	</li>	</li>

	<li>	<li>
	The client must include the "supported_groups" extension in the	The client must include the "supported_groups" extension in the
	ClientHello message.	ClientHello message.
	</li>	</li>

	<li>	<li>
	Expand the motivation discussion to talk about protection against th e	Expand the motivation discussion to talk about protection against th e
	future development of a Cryptographically Relevant Quantum Computer (CRQC)	future development of a Cryptographically Relevant Quantum Computer (CRQC)
	and enrollment in enterprise networks.	and enrollment in enterprise networks.
	</li>	</li>

	<li>	<li>
	Separate the discussion of confidentiality and authentication. The	Separate the discussion of confidentiality and authentication. The
	inclusion of the external PSK offers some confidentiality protection	inclusion of the external PSK offers some confidentiality protection
	against the future invention of a CRQC, but the external PSK does no t	against the future invention of a CRQC, but the external PSK does no t
	improve authentication.	improve authentication.
	</li>	</li>

	<li>	<li>
	Correct RFC Errata 7598 <xref target="Err7598"/>.	Correct RFC Erratum 7598 <xref target="Err7598"/>.
	</li>	</li>

	<li>	<li>
	Add a discussion of TLS Encrypted Client Hello to the	Add a discussion of TLS Encrypted Client Hello to the

	Privacy Considerations.	Privacy Considerations section.
	</li>	</li>

	<li>	<li>
	Adopt terminology that has become widely accepted, such as CRQC and	Adopt terminology that has become widely accepted, such as CRQC and
	Main Secret (instead of Master Secret).	Main Secret (instead of Master Secret).
	</li>	</li>

	<li>	<li>
	Provide URLs for all references.	Provide URLs for all references.
	</li>	</li>

	</ul>	</ul>
	</t>
	</section>	</section>

		<section numbered="false">
	<section title="Acknowledgments" numbered="false">	<name>Acknowledgments</name>
	<t>	<t>
	Many thanks to	Many thanks to
	<contact fullname="Liliya Akhmetzyanova"/>,	<contact fullname="Liliya Akhmetzyanova"/>,
	<contact fullname="Roman Danyliw"/>,	<contact fullname="Roman Danyliw"/>,
	<contact fullname="Christian Huitema"/>,	<contact fullname="Christian Huitema"/>,
	<contact fullname="Ben Kaduk"/>,	<contact fullname="Ben Kaduk"/>,
	<contact fullname="Geoffrey Keating"/>,	<contact fullname="Geoffrey Keating"/>,
	<contact fullname="Hugo Krawczyk"/>,	<contact fullname="Hugo Krawczyk"/>,
	<contact fullname="Mirja Kühlewind"/>,	<contact fullname="Mirja Kühlewind"/>,
	<contact fullname="Nikos Mavrogiannopoulos"/>,	<contact fullname="Nikos Mavrogiannopoulos"/>,
	<contact fullname="Nick Sullivan"/>,	<contact fullname="Nick Sullivan"/>,
	<contact fullname="Martin Thomson"/>, and	<contact fullname="Martin Thomson"/>, and
	<contact fullname="Peter Yee"/>	<contact fullname="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.
	</t>	</t>


		<!--[rfced] Would you like the names listed in the second paragraph
		in the Acknowledgments section be listed in alphabetical order, like
		the first paragraph of the section?
		-->

	<t>	<t>
	Many thanks to	Many thanks to
	<contact fullname="Dan Harkins"/>,	<contact fullname="Dan Harkins"/>,
	<contact fullname="Owen Friel"/>,	<contact fullname="Owen Friel"/>,
	<contact fullname="John Preuß Mattsson"/>,	<contact fullname="John Preuß Mattsson"/>,
	<contact fullname="Christian Huitema"/>,	<contact fullname="Christian Huitema"/>,
	<contact fullname="Joe Salowey"/>,	<contact fullname="Joe Salowey"/>,
	<contact fullname="Britta Hale"/>,	<contact fullname="Britta Hale"/>,
	<contact fullname="Peter Yee"/>,	<contact fullname="Peter Yee"/>,
	<contact fullname="Joe Mandel"/>,	<contact fullname="Joe Mandel"/>,
	<contact fullname="Muhammad Usama Sardar"/>,	<contact fullname="Muhammad Usama Sardar"/>,
	<contact fullname="Paul Wouters"/>,	<contact fullname="Paul Wouters"/>,
	<contact fullname="Mike Bishop"/>,	<contact fullname="Mike Bishop"/>,
	<contact fullname="Deb Cooley"/>, and	<contact fullname="Deb Cooley"/>, and
	<contact fullname="Eric Rescorla"/>	<contact fullname="Eric Rescorla"/>
	for their review and comments on the updates to RFC 8773 that became	for their review and comments on the updates to RFC 8773 that became
	this document; their efforts have improved the document.	this document; their efforts have improved the document.
	</t>	</t>
	</section>	</section>

	</back>


		<!--[rfced] Both the expansion and the acronym for the following terms
		are used throughout the document. Would you like to update to using
		the expansion upon first usage and the acronym for the rest of the
		document for consistency?

		Cryptographically Relevant Quantum Computer (CRQC)
		pre-shared key (PSK)
		-->

		<!-- [rfced] Please review the "Inclusive Language" portion of the online
		Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
		and let us know if any changes are needed. Updates of this nature typically
		result in more precise language, which is helpful for readers.

		Note that our script did not flag any words in particular, but this should
		still be reviewed as a best practice.

		In addition, please consider whether "traditional" or "traditionally" should
		be updated for clarity. This term is ambiguous, as "tradition" is subjective bec
		ause it does not mean the same thing for everyone.
		-->

		</back>
	</rfc>	</rfc>

End of changes. 103 change blocks.
	214 lines changed or deleted	335 lines changed or added
This html diff was produced by rfcdiff 1.48.