rfc9973.original   rfc9973.txt 
Network Working Group R. Housley Internet Engineering Task Force (IETF) R. Housley
Internet-Draft Vigil Security Request for Comments: 9973 Vigil Security
Obsoletes: 8773 (if approved) 5 September 2025 Obsoletes: 8773 April 2026
Intended status: Standards Track Category: Standards Track
Expires: 9 March 2026 ISSN: 2070-1721
TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key
draft-ietf-tls-8773bis-13
Abstract Abstract
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 and servers to authenticate with certificates and provide
confidentiality based on encryption with a symmetric key from the confidentiality based on encryption with a symmetric key from the
usual key agreement algorithm and an external pre-shared key (PSK). usual key agreement algorithm and an external pre-shared key (PSK).
This Standards Track RFC (once approved) obsoletes RFC 8773, which This Standards Track RFC obsoletes RFC 8773, which was an
was an Experimental RFC. Experimental RFC.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 9 March 2026. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9973.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language
3. Motivation and Design Rationale . . . . . . . . . . . . . . . 3 3. Motivation and Design Rationale
4. Extension Overview . . . . . . . . . . . . . . . . . . . . . 4 4. Extension Overview
5. Certificate with External PSK Extension . . . . . . . . . . . 5 5. Certificate with External PSK Extension
5.1. Companion Extensions . . . . . . . . . . . . . . . . . . 6 5.1. Companion Extensions
5.2. Authentication . . . . . . . . . . . . . . . . . . . . . 8 5.2. Authentication
5.3. Keying Material . . . . . . . . . . . . . . . . . . . . . 9 5.3. Keying Material
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 8. Privacy Considerations
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9.2. Informative References
Appendix A. Changes Since RFC 8773 . . . . . . . . . . . . . . . 15 Appendix A. Changes Since RFC 8773
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 Acknowledgments
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address
1. Introduction 1. Introduction
The TLS 1.3 [I-D.ietf-tls-rfc8446bis] handshake protocol provides two The TLS 1.3 [RFC9846] handshake protocol provides two mutually
mutually exclusive forms of server authentication. First, the server exclusive forms of server authentication. First, the server can be
can be authenticated by providing a signature certificate and authenticated by providing a signature certificate and creating a
creating a valid digital signature to demonstrate that it possesses valid digital signature to demonstrate that it possesses the
the corresponding private key. Second, the server can be corresponding private key. Second, the server can be authenticated
authenticated by demonstrating that it possesses a pre-shared key by demonstrating that it possesses a pre-shared key (PSK) that was
(PSK) that was established by a previous handshake. A PSK that is established by a previous handshake. A PSK that is established in
established in this fashion is called a resumption PSK. A PSK that this fashion is called a resumption PSK. A PSK that is established
is established by any other means is called an external PSK. by any other 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 authentication, as described in Section 4.3.2 of [RFC9846].
[I-D.ietf-tls-rfc8446bis].
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
RFC 8773. [RFC8773].
2. Terminology 2. Requirements Language
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
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Motivation and Design Rationale 3. Motivation and Design Rationale
There are two motivations for using a certificate with an external There are two motivations for using a certificate with an external
PSK. PSK.
One motivation is confidentiality protection against the future One motivation is confidentiality protection against the future
invention of a Cryptographically Relevant Quantum Computer (CRQC), invention of a Cryptographically Relevant Quantum Computer (CRQC),
which would pose a serious challenge for the asymmetric cryptographic which would pose a serious challenge for the asymmetric cryptographic
algorithms that are widely deployed today, including the digital algorithms that are widely deployed today, including the digital
signature algorithms that are used to authenticate the server in the signature algorithms that are used to authenticate the server in the
TLS 1.3 handshake protocol and key agreement algorithm used to TLS 1.3 handshake protocol and key agreement algorithm used to
establish a pairwise shared secret between the client and server. It 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 is an open question whether or not it is feasible to build such a
quantum computer, and if so, when that might happen. However, if quantum computer and, if so, when that might happen. However, if
such a quantum computer is invented, many of the cryptographic such a quantum computer is invented, many of the cryptographic
algorithms and the security protocols that use them would become algorithms and the security protocols that use them would become
vulnerable. In particular, The TLS 1.3 handshake protocol employs vulnerable. In particular, the TLS 1.3 handshake protocol employs
key agreement algorithms that could be broken by the invention of a key agreement algorithms that could be broken by the invention of a
CRQC [I-D.ietf-pquip-pqc-engineers]. Including a strong external PSK CRQC [PQC]. Including a strong external PSK in the TLS 1.3 key
in the TLS 1.3 key schedule offers confidentiality protection against schedule offers confidentiality protection against the long-term
the long-term quantum computing threat; it requires the attacker to quantum computing threat; it requires the attacker to learn the
learn the external PSK as well as the shared secret produced by the external PSK as well as the shared secret produced by the key
key agreement algorithm to break confidentiality. agreement algorithm to break confidentiality.
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 been generated and distributed in such a way that the invention of a
CRQC will not allow the owner of that quantum computer to learn the CRQC will not allow the owner of that quantum computer to learn the
PSK. While generation and distribution of the PSK are outside the PSK. While generation and distribution of the PSK are outside the
scope of this document, in the context of a CRQC, security of the TLS scope of this document, in the context of a CRQC, security of the TLS
1.3 session using the strong external PSK relies on and implicitly 1.3 session using the strong external PSK relies on and is implicitly
tied to the confidentiality, entropy, and authenticity of the PSK. tied to the confidentiality, entropy, and authenticity of the PSK.
Thus, the security claims in this document depend on generation and Thus, the security claims in this document depend on generation and
distribution of the strong external PSK. distribution of the strong external PSK.
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 provided by the existing certificate and digital signature
mechanisms. This authentication cannot be relied upon if a CRQC is mechanisms. This authentication cannot be relied upon if a CRQC is
ever invented. The addition of a strong external PSK in the TLS 1.3 ever invented. The addition of a strong external PSK in the TLS 1.3
key schedule does not offer improvement against the long-term quantum key schedule does not offer improvement against the long-term quantum
computing threat regarding authentication. computing threat regarding authentication.
Likewise, a raw public key can be provided as described in [RFC7250]. Likewise, a raw public key can be provided, as described in
[RFC7250].
Quantum-resistant public-key cryptographic algorithms are becoming Quantum-resistant public-key cryptographic algorithms are becoming
standards, but it will take many years for TLS 1.3 ciphersuites that standards, but it will take many years for TLS 1.3 ciphersuites that
use these algorithms to be developed and deployed. In some use these algorithms to be developed and deployed. In some
environments, deployment of a strong external PSK provides protection environments, deployment of a strong external PSK provides protection
until these quantum-resistant algorithms are deployed. until these quantum-resistant algorithms are deployed.
Another motivation is the use of a public key with a factory- Another motivation is the use of a public key with a factory-
provisioned secret value for the initial enrollment of a device in an provisioned secret value for the initial enrollment of a device in an
enterprise network [I-D.ietf-emu-bootstrapped-tls]. enterprise network [TLS-POK].
4. Extension Overview 4. Extension Overview
This section provides a brief overview of the This section provides a brief overview of the
"tls_cert_with_extern_psk" extension. "tls_cert_with_extern_psk" extension.
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 MUST ClientHello message. The "tls_cert_with_extern_psk" extension MUST
be accompanied by the "key_share", "supported_groups", be accompanied by the "key_share", "supported_groups",
"psk_key_exchange_modes", and "pre_shared_key" extensions. Since the "psk_key_exchange_modes", and "pre_shared_key" extensions. Since the
"tls_cert_with_extern_psk" extension is intended to be used only with "tls_cert_with_extern_psk" extension is intended to be used only with
initial handshakes, it MUST NOT be sent alongside the "early_data" initial handshakes, it MUST NOT be sent alongside the "early_data"
extension. These extensions are all described in Section 4.2 of extension. These extensions are all described in Section 4.2 of
[I-D.ietf-tls-rfc8446bis], which also requires the "pre_shared_key" [RFC9846], which also requires the "pre_shared_key" extension to be
extension to be the last extension in the ClientHello message. the last extension in the ClientHello message.
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 MUST terminate the and the "early_data" extension, then the server MUST terminate the
connection with an "illegal_parameter" alert. connection with an "illegal_parameter" alert.
If the server is willing to use one of the external PSKs listed in If the server is willing to use one of the external PSKs listed in
the "pre_shared_key" extension and perform certificate-based the "pre_shared_key" extension and perform certificate-based
authentication, then the server includes the authentication, then the server includes the
"tls_cert_with_extern_psk" extension in the ServerHello message. The "tls_cert_with_extern_psk" extension in the ServerHello message. The
"tls_cert_with_extern_psk" extension MUST be accompanied by the "tls_cert_with_extern_psk" extension MUST be accompanied by the
skipping to change at page 5, line 19 skipping to change at line 196
curves. As a result, the Early Secret, Handshake Secret, and Main curves. As a result, the Early Secret, Handshake Secret, and Main
Secret (previously known as the Master Secret) values all depend upon Secret (previously known as the Master Secret) values all depend upon
the value of the selected external PSK. Of course, the Early Secret the value of the selected external PSK. Of course, the Early Secret
does not depend upon the (EC)DHE shared secret. does not depend upon the (EC)DHE shared secret.
The authentication of the server and optional authentication of the The authentication of the server and optional authentication of the
client depend upon the ability to generate a signature that can be client depend upon the ability to generate a signature that can be
validated with the public key in their certificates. The validated with the public key in their certificates. The
authentication processing is not changed in any way by the selected authentication processing is not changed in any way by the selected
external PSK. As a result, if a CRQC is ever invented, the digital external PSK. As a result, if a CRQC is ever invented, the digital
signature algorithm will need to be replaced with a quantum resistant signature algorithm will need to be replaced with a quantum-resistant
one. Failure to do so will result in vulnerable entity and data one. Failure to do so will result in vulnerable entity and data
authentication mechanisms. authentication mechanisms.
Each external PSK is associated with a single hash algorithm, which Each external PSK is associated with a single hash algorithm, which
is required by Section 4.2.11 of [I-D.ietf-tls-rfc8446bis]. The hash is required by Section 4.2.11 of [RFC9846]. The hash algorithm MUST
algorithm MUST be set when the PSK is established, with a default of be set when the PSK is established, with a default of SHA-256.
SHA-256.
5. Certificate with External PSK Extension 5. Certificate with External PSK Extension
This section specifies the "tls_cert_with_extern_psk" extension, This section specifies the "tls_cert_with_extern_psk" extension,
which MAY appear in the ClientHello message and ServerHello message. which MAY appear in the ClientHello message and ServerHello message.
It MUST NOT appear in any other messages. The It MUST NOT appear in any other messages. The
"tls_cert_with_extern_psk" extension MUST NOT appear in the "tls_cert_with_extern_psk" extension MUST NOT appear in the
ServerHello message unless the "tls_cert_with_extern_psk" extension ServerHello message unless the "tls_cert_with_extern_psk" extension
appeared in the preceding ClientHello message. If an implementation appeared in the preceding ClientHello message. If an implementation
recognizes the "tls_cert_with_extern_psk" extension and receives it recognizes the "tls_cert_with_extern_psk" extension and receives it
in any other message, then the implementation MUST abort the in any other message, then the implementation MUST abort the
handshake with an "illegal_parameter" alert. handshake with an "illegal_parameter" alert.
The general extension mechanisms enable clients and servers to The general extension mechanisms enable clients and servers to
negotiate the use of specific extensions. Clients request extended negotiate the use of specific extensions. Clients request extended
functionality from servers with the extensions field in the functionality from servers with the extensions field in the
ClientHello message. If the server responds with a HelloRetryRequest ClientHello message. If the server responds with a HelloRetryRequest
message, then the client sends another ClientHello message as message, then the client sends another ClientHello message as
described in Section 4.1.2 of [I-D.ietf-tls-rfc8446bis], including described in Section 4.1.2 of [RFC9846], including the same
the same "tls_cert_with_extern_psk" extension as the original "tls_cert_with_extern_psk" extension as the original ClientHello
ClientHello message, or aborts the handshake. message, or aborts the handshake.
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 carried message; however, the "tls_cert_with_extern_psk" extension is carried
in the ServerHello message. Successful negotiation of the in the ServerHello message. Successful negotiation of the
"pre_shared_key" extension enables certificate verification to take "pre_shared_key" extension enables certificate verification to take
place in addition to the inclusion of the external PSK in the key place in addition to the inclusion of the external PSK in the key
schedule. The external PSK is identified by the "key_share" schedule. The external PSK is identified by the "key_share"
extension, and the inclusion of the external PSK in the key schedule extension, and the inclusion of the external PSK in the key schedule
affects the key used for encryption. The "tls_cert_with_extern_psk" affects the key used for encryption. The "tls_cert_with_extern_psk"
extension is only present in the ServerHello message if the server extension is only present in the ServerHello message if the server
recognizes the "tls_cert_with_extern_psk" extension and the server recognizes the "tls_cert_with_extern_psk" extension and the server
possesses one of the external PSKs offered by the client in the possesses one 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.
The Extension structure is defined in [I-D.ietf-tls-rfc8446bis]; it The Extension structure is defined in [RFC9846]; it is repeated here
is repeated here for convenience. for convenience.
struct { struct {
ExtensionType extension_type; ExtensionType extension_type;
opaque extension_data<0..2^16-1>; opaque extension_data<0..2^16-1>;
} Extension; } Extension;
The "extension_type" identifies the particular extension type, and The "extension_type" identifies the particular extension type, and
the "extension_data" contains information specific to the particular the "extension_data" contains information specific to the particular
extension type. extension type.
skipping to change at page 7, line 6 skipping to change at line 278
} CertWithExternPSK; } CertWithExternPSK;
5.1. Companion Extensions 5.1. Companion Extensions
Section 4 lists the extensions that are required to accompany the Section 4 lists the extensions that are required to accompany the
"tls_cert_with_extern_psk" extension. Most of those extensions are "tls_cert_with_extern_psk" extension. Most of those extensions are
not impacted in any way by this specification. However, this section not impacted in any way by this specification. However, this section
discusses the extensions that require additional consideration. discusses the extensions that require additional consideration.
The "psk_key_exchange_modes" extension is defined in Section 4.2.9 of The "psk_key_exchange_modes" extension is defined in Section 4.2.9 of
[I-D.ietf-tls-rfc8446bis]. The "psk_key_exchange_modes" extension [RFC9846]. The "psk_key_exchange_modes" extension restricts the use
restricts the use of both the PSKs offered in this ClientHello and of both the PSKs offered in this ClientHello and those that the
those that the server might supply via a subsequent NewSessionTicket. server might supply via a subsequent NewSessionTicket. As a result,
As a result, when the "psk_key_exchange_modes" extension is included when the "psk_key_exchange_modes" extension is included in the
in the ClientHello message, clients MUST include psk_dhe_ke mode. In ClientHello message, clients MUST include psk_dhe_ke mode. In
addition, clients MAY also include psk_ke mode to support a addition, clients MAY also include psk_ke mode to support a
subsequent NewSessionTicket. When the "psk_key_exchange_modes" subsequent NewSessionTicket. When the "psk_key_exchange_modes"
extension is included in the ClientHello message, servers MUST select extension is included in the ClientHello message, servers MUST select
the psk_dhe_ke mode for the initial handshake. Servers MUST select a the psk_dhe_ke mode for the initial handshake. Servers MUST select a
key exchange mode that is listed by the client for subsequent key exchange mode that is listed by the client for subsequent
handshakes that include the resumption PSK from the initial handshakes that include the resumption PSK from the initial
handshake. handshake.
The "pre_shared_key" extension is defined in Section 4.2.11 of The "pre_shared_key" extension is defined in Section 4.2.11 of
[I-D.ietf-tls-rfc8446bis]. The syntax is repeated below for [RFC9846]. The syntax is repeated below for convenience. All of the
convenience. All of the listed PSKs MUST be external PSKs. If a listed PSKs MUST be external PSKs. If a resumption PSK is listed
resumption PSK is listed along with the "tls_cert_with_extern_psk" along with the "tls_cert_with_extern_psk" extension, the server MUST
extension, the server MUST abort the handshake with an abort the handshake with an "illegal_parameter" alert.
"illegal_parameter" alert.
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>;
skipping to change at page 8, line 13 skipping to change at line 328
the server. the server.
The identities are a list of external PSK identities that the client The identities are a list of external PSK identities that the client
is willing to negotiate with the server. Each external PSK has an is willing to negotiate with the server. Each external PSK has an
associated identity that is known to the client and the server; the associated identity that is known to the client and the server; the
associated identities may be known to other parties as well. In associated identities may be known to other parties as well. In
addition, the binder validation (see below) confirms that the client addition, the binder validation (see below) confirms that the client
and server have the same key associated with the identity. and server have the same key associated with the identity.
The "obfuscated_ticket_age" is not used for external PSKs. As stated The "obfuscated_ticket_age" is not used for external PSKs. As stated
in Section 4.2.11 of [I-D.ietf-tls-rfc8446bis], clients SHOULD set in Section 4.2.11 of [RFC9846], clients SHOULD set this value to 0,
this value to 0, and servers MUST ignore the value. and servers MUST ignore the value.
The binders are a series of HMAC [RFC2104] values, one for each The binders are a series of HMAC [RFC2104] values, one for each
external PSK offered by the client, in the same order as the external PSK offered by the client, in the same order as the
identities list. The HMAC value is computed using the binder_key, identities list. The HMAC value is computed using the binder_key,
which is derived from the external PSK, and a partial transcript of which is derived from the external PSK, and a partial transcript of
the current handshake. Generation of the binder_key from the the current handshake. Generation of the binder_key from the
external PSK is described in Section 7.1 of external PSK is described in Section 7.1 of [RFC9846]. The partial
[I-D.ietf-tls-rfc8446bis]. The partial transcript of the current transcript of the current handshake includes a partial ClientHello up
handshake includes a partial ClientHello up to and including the to and including the PreSharedKeyExtension.identities field, as
PreSharedKeyExtension.identities field, as described in described in Section 4.2.11.2 of [RFC9846].
Section 4.2.11.2 of [I-D.ietf-tls-rfc8446bis].
The "selected_identity" contains the index of the external PSK The "selected_identity" contains the index of the external PSK
identity that the server selected from the list offered by the identity that the server selected from the list offered by the
client. As described in Section 4.2.11 of [I-D.ietf-tls-rfc8446bis], client. As described in Section 4.2.11 of [RFC9846], the server MUST
the server MUST validate the binder value that corresponds to the validate the binder value that corresponds to the selected external
selected external PSK, and if the binder does not validate, the PSK, and if the binder does not validate, the server MUST abort the
server MUST abort the handshake with an "illegal_parameter" alert. handshake with an "illegal_parameter" alert.
5.2. Authentication 5.2. Authentication
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 4.4.2 and 4.4.3 of [I-D.ietf-tls-rfc8446bis]. in Sections 4.4.2 and 4.4.3 of [RFC9846]. Alternatively, the server
Alternatively, the server can use a raw public key as described in can use a raw public key, as described in [RFC7250].
[RFC7250].
TLS 1.3 does not permit the server to send a CertificateRequest TLS 1.3 does not permit the server to send a CertificateRequest
message when a PSK is being used. This restriction is removed when message when a PSK is being used. This restriction is removed when
the "tls_cert_with_extern_psk" extension is negotiated, allowing the "tls_cert_with_extern_psk" extension is negotiated, allowing
certificate-based authentication for both the client and the server. certificate-based authentication for both the client and the server.
If certificate-based client authentication is desired, this is If certificate-based client authentication is desired, this is
accomplished by the client sending the Certificate and accomplished by the client sending the Certificate and
CertificateVerify messages as described in Sections 4.4.2 and 4.4.3 CertificateVerify messages as described in Sections 4.4.2 and 4.4.3
of [I-D.ietf-tls-rfc8446bis]. of [RFC9846].
5.3. Keying Material 5.3. Keying Material
Section 7.1 of [I-D.ietf-tls-rfc8446bis] specifies the TLS 1.3 key Section 7.1 of [RFC9846] specifies the TLS 1.3 key schedule. The
schedule. The successful negotiation of the successful negotiation of the "tls_cert_with_extern_psk" extension
"tls_cert_with_extern_psk" extension requires the key schedule requires the key schedule processing to include both the external PSK
processing to include both the external PSK and the (EC)DHE shared and the (EC)DHE shared secret value.
secret value.
If the client and the server have different values associated with If the client and the server have different values associated with
the selected external PSK identifier, then the client and the server the selected external PSK identifier, then the client and the server
will compute different values for every entry in the key schedule, will compute different values for every entry in the key schedule,
which will lead to the client aborting the handshake with a which will lead to the client aborting the handshake with a
"decrypt_error" alert. "decrypt_error" alert.
6. IANA Considerations 6. IANA Considerations
Once this document is approved, IANA is asked to update the "TLS IANA has updated the "TLS ExtensionType Values" registry [IANA] entry
ExtensionType Values" registry [IANA] entry for the for the "tls_cert_with_extern_psk" extension to reference this
"tls_cert_with_extern_psk" extension to reference this document. document.
7. Security Considerations 7. Security Considerations
The Security Considerations in [I-D.ietf-tls-rfc8446bis] remain The Security Considerations in [RFC9846] remain relevant.
relevant.
TLS 1.3 [I-D.ietf-tls-rfc8446bis] does not permit the server to send TLS 1.3 [RFC9846] does not permit the server to send a
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 pre-shared key (PSK).
Compromise of the external PSK will make the encrypted session Compromise of the external PSK will make the encrypted session
content vulnerable to the future development of a Cryptographically content vulnerable to the future development of a Cryptographically
Relevant Quantum Computer (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
skipping to change at page 10, line 14 skipping to change at line 423
external PSKs can result in little or no security. An attacker may external PSKs can result in little or no security. An attacker may
find it much easier to reproduce the PRNG environment that produced find it much easier to reproduce the PRNG environment that produced
the external PSKs and search the resulting small set of the external PSKs and search the resulting small set of
possibilities, rather than brute-force searching the whole key space. possibilities, rather than brute-force searching the whole key space.
The generation of quality random numbers is difficult. [RFC4086] The generation of quality random numbers is difficult. [RFC4086]
offers important guidance in this area. offers important guidance in this area.
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 encryption algorithm with sufficiently large keys. For protection
against the future invention of a CRQC, the symmetric key needs to be against the future invention of a CRQC, the symmetric key needs to be
at least 128 bits. While Grover’s algorithm (described in at least 128 bits. While Grover's algorithm (described in
Section 2.1 of [I-D.ietf-pquip-pqc-engineers]) allows a quantum Section 3.1 of [PQC]) allows a quantum computer to perform a brute
computer to perform a brute force key search using quadratically force key search using quadratically fewer steps than would be
fewer steps than would be required with classical computers, there required with classical computers, there are a number of mitigating
are a number of mitigating factors suggesting that Grover’s algorithm factors suggesting that Grover's algorithm will not speed up a brute
will not speed up brute force symmetric key search as dramatically as force symmetric key search as dramatically as one might suspect.
one might suspect. First, quantum computing hardware will likely be First, quantum computing hardware will likely be more expensive to
more expensive to build and use than classical hardware. Second, to build and use than classical hardware. Second, to obtain the full
obtain the full quadratic speedup, all the steps of Grover’s quadratic speedup, all the steps of Grover's algorithm must be
algorithm must be performed in series. However, attacks on performed in series. However, attacks on cryptography use massively
cryptography use massively parallel processing, the advantage of parallel processing; the advantage of Grover's algorithm will be
Grover's algorithm will be smaller. smaller.
Implementations must use sufficiently large external PSKs. For Implementations must use sufficiently large external PSKs. For
protection against the future invention of a CRQC, the external PSK protection against the future invention of a CRQC, the external PSK
needs to be at least 128 bits. needs to be at least 128 bits.
TLS 1.3 [I-D.ietf-tls-rfc8446bis] has received careful security TLS 1.3 [RFC9846] has received careful security analysis, and the
analysis, and the following informal reasoning shows that the following informal reasoning shows that the addition of this
addition of this extension does not introduce any security defects in extension does not introduce any security defects in the threat model
the threat model of a traditional adversary, that is an adversary of a traditional adversary, that is, an adversary that does not have
that does not have access to a CRQC. This extension requires the use access to a CRQC. This extension requires the use of certificates
of certificates for authentication, but the processing of for authentication, but the processing of certificates is unchanged
certificates is unchanged by this extension. This extension requires by this extension. This extension requires an external PSK in the
an external PSK in the key schedule as part of the computation of the key schedule as part of the computation of the Early Secret. In the
Early Secret. In the initial handshake without an external PSK in initial handshake without an external PSK in [RFC9846], the Early
[I-D.ietf-tls-rfc8446bis], the Early Secret is computed as: Secret is computed as:
Early Secret = HKDF-Extract(0, 0) Early Secret = HKDF-Extract(0, 0)
With this extension, the Early Secret is computed as: With this extension, the Early Secret is computed as:
Early Secret = HKDF-Extract(0, External PSK) Early Secret = HKDF-Extract(0, External PSK)
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 continues to meet well-studied confidentiality goals when this
extension is used. extension is used.
Even when the external PSK is not known to any party other than the Even when the external PSK is not known to any party other than the
client and the server, then the external PSK MUST NOT be the sole client and the server, the external PSK MUST NOT be the sole basis
basis for authentication. The reasoning is explained in Section 4.2 for authentication. The reasoning is explained in Section 4.2 of
of [K2016]. The authentication of the server and optional [K2016]. 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.
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 even if the (EC)DH key agreement is broken by cryptanalysis or the
future invention of a CRQC. As long as the attacker does not know future invention of a CRQC. As long as the attacker does not know
the PSK and the key derivation algorithm remains unbroken, the the PSK and the key derivation algorithm remains unbroken, the
attacker cannot derive the session secrets, even if the attacker is attacker cannot derive the session secrets, even if the attacker is
skipping to change at page 11, line 49 skipping to change at line 506
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 confidentially
is limited to the client and server, but there is no cryptographic is limited to the client and server, but there is no cryptographic
separation between TLS 1.3 sessions. 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 confidentially 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
skipping to change at page 12, line 31 skipping to change at line 537
Once an attacker has the external PSK, they can decrypt stored 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 traffic if they ever gain access to a CRQC, 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 [I-D.ietf-tls-rfc8446bis] takes a conservative approach to TLS 1.3 [RFC9846] takes a conservative approach to PSKs; they are
PSKs; they are bound to a specific hash function and KDF. By bound to a specific hash function and KDF. By contrast, TLS 1.2
contrast, TLS 1.2 [RFC5246] allows PSKs to be used with any hash [RFC5246] allows PSKs to be used with any hash function and the TLS
function and the TLS 1.2 PRF. Thus, the safest approach is to use a 1.2 PRF. Thus, the safest approach is to use a PSK exclusively with
PSK exclusively with TLS 1.2 or exclusively with TLS 1.3. Given one TLS 1.2 or exclusively with TLS 1.3. Given one PSK, one can derive a
PSK, one can derive a PSK for exclusive use with TLS 1.2 and derive PSK for exclusive use with TLS 1.2 and derive another PSK for
another PSK for exclusive use with TLS 1.3 using the mechanism exclusive use with TLS 1.3 using the mechanism specified in
specified in [RFC9258]. [RFC9258].
8. Privacy Considerations 8. Privacy Considerations
Appendix F.6 of [I-D.ietf-tls-rfc8446bis] discusses identity-exposure Appendix F.6 of [RFC9846] discusses identity-exposure attacks on
attacks on PSKs. Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] PSKs. Also, Appendix C.4 of [RFC9846] discusses tracking prevention.
discusses tracking prevention. The guidance in these sections remain The guidance in these sections remain relevant.
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 [I-D.ietf-tls-esni] can mitigate the Encrypted Client Hello extension [RFC9849] can mitigate this
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.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-tls-rfc8446bis]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", Work in Progress, Internet-Draft, draft-
ietf-tls-rfc8446bis-13, 21 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
rfc8446bis-13>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>. June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 9846, DOI 10.17487/RFC9846, January
2026, <https://www.rfc-editor.org/info/rfc9846>.
9.2. Informative References 9.2. Informative References
[Err7598] RFC Editor, "RFC Errata 7598", [Err7598] RFC Errata, Erratum ID 7598, RFC 8773,
<https://www.rfc-editor.org/errata/eid7598>. <https://www.rfc-editor.org/errata/eid7598>.
[GGM1986] Goldreich, O., Goldwasser, S., and S. Micali, "How to [GGM1986] Goldreich, O., Goldwasser, S., and S. Micali, "How to
construct random functions", Journal of the ACM, Vol. 33, construct random functions", Journal of the ACM (JACM),
No. 4, pp. 792-807, DOI 10.1145/6490.6503, August 1986, vol. 33, no. 4, pp. 792-807, DOI 10.1145/6490.6503, August
<https://dl.acm.org/doi/10.1145/6490.6503>. 1986, <https://dl.acm.org/doi/10.1145/6490.6503>.
[I-D.ietf-emu-bootstrapped-tls] [IANA] IANA, "TLS ExtensionType Values",
Friel, O. and D. Harkins, "Bootstrapped TLS Authentication <https://www.iana.org/assignments/tls-extensiontype-
with Proof of Knowledge (TLS-POK)", Work in Progress, values>.
Internet-Draft, draft-ietf-emu-bootstrapped-tls-08, 6
February 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-emu-bootstrapped-tls-08>.
[I-D.ietf-pquip-pqc-engineers] [K2016] Krawczyk, H., "A Unilateral-to-Mutual Authentication
Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek, Compiler for Key Exchange (with Applications to Client
Authentication in TLS 1.3)", Cryptology ePrint Archive,
Paper 2016/711, 2016, <https://eprint.iacr.org/2016/711>.
[PQC] Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek,
T., and M. Ounsworth, "Post-Quantum Cryptography for T., and M. Ounsworth, "Post-Quantum Cryptography for
Engineers", Work in Progress, Internet-Draft, draft-ietf- Engineers", Work in Progress, Internet-Draft, draft-ietf-
pquip-pqc-engineers-14, 25 August 2025, pquip-pqc-engineers-14, 25 August 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-pquip- <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
pqc-engineers-14>. pqc-engineers-14>.
[I-D.ietf-tls-esni]
Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", Work in Progress, Internet-Draft,
draft-ietf-tls-esni-25, 14 June 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
esni-25>.
[IANA] IANA, "TLS ExtensionType Values",
<https://www.iana.org/assignments/tls-extensiontype-
values/tls-extensiontype-values.xhtml>.
[K2016] Krawczyk, H., "A Unilateral-to-Mutual Authentication
Compiler for Key Exchange (with Applications to Client
Authentication in TLS1.3)", cryptoeprint 2016/711, 1
September 2016, <https://eprint.iacr.org/2016/711>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC8773] Housley, R., "TLS 1.3 Extension for Certificate-Based
Authentication with an External Pre-Shared Key", RFC 8773,
DOI 10.17487/RFC8773, March 2020,
<https://www.rfc-editor.org/info/rfc8773>.
[RFC9258] Benjamin, D. and C. A. Wood, "Importing External Pre- [RFC9258] Benjamin, D. and C. A. Wood, "Importing External Pre-
Shared Keys (PSKs) for TLS 1.3", RFC 9258, Shared Keys (PSKs) for TLS 1.3", RFC 9258,
DOI 10.17487/RFC9258, July 2022, DOI 10.17487/RFC9258, July 2022,
<https://www.rfc-editor.org/info/rfc9258>. <https://www.rfc-editor.org/info/rfc9258>.
[RFC9849] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849,
March 2026, <https://www.rfc-editor.org/info/rfc9849>.
[TLS-POK] Friel, O. and D. Harkins, "Bootstrapped TLS Authentication
with Proof of Knowledge (TLS-POK)", Work in Progress,
Internet-Draft, draft-ietf-emu-bootstrapped-tls-11, 1
October 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-emu-bootstrapped-tls-11>.
Appendix A. Changes Since RFC 8773 Appendix A. Changes Since RFC 8773
The status elevation from Experimental RFC to Standards Track RFC is The status elevation from Experimental RFC to Standards Track RFC is
the most significant change in this document. the most significant change in this document.
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.
skipping to change at page 15, line 28 skipping to change at line 674
* 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 Cryptographically Relevant Quantum
Computer (CRQC) and enrollment in enterprise networks. Computer (CRQC) and enrollment in enterprise 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 Errata 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. Considerations section.
* Adopt terminology that has become widely accepted, such as CRQC * Adopt terminology that has become widely accepted, such as CRQC
and Main Secret (instead of Master Secret). and Main Secret (instead of Master Secret).
* 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,
 End of changes. 56 change blocks. 
197 lines changed or deleted 184 lines changed or added

This html diff was produced by rfcdiff 1.48.