RFC 9973

RFC 9973: TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key ✨

Okay bestie, let's talk about RFC 9973 🎀 It's a Standards Track document from the IETF (Internet Engineering Task Force), request for comments number 9973, and it's by R. Housley of Vigil Security. It came out in July 2026 and sits in the ISSN 2070-1721 series. The big news is that it obsoletes RFC 8773, which used to be Experimental, so this is the glow-up version 💅 The title block doesn't list anything it updates, so that's the whole plot.

---

Abstract 🌸

So the gist is this: this doc specifies a TLS 1.3 extension that lets TLS clients and servers authenticate with certificates, while also getting confidentiality from encryption using a symmetric key. That key comes from the usual key agreement algorithm plus an external pre-shared key (PSK) 🔐 It's a Standards Track RFC that obsoletes RFC 8773, which was Experimental.

Status of This Memo 📜

This is an Internet Standards Track document, bestie 💖

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, and it went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, peep Section 2 of RFC 7841.

For the current status of this document, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9973.

Copyright Notice 💅

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Revised BSD License.

Table of Contents 🦋

1.  Introduction
2.  Requirements Language
3.  Motivation and Design Rationale
4.  Extension Overview
5.  Certificate with External PSK Extension
  5.1.  Companion Extensions
  5.2.  Authentication
  5.3.  Keying Material
6.  IANA Considerations
7.  Security Considerations
8.  Privacy Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Appendix A.  Changes Since RFC 8773
Acknowledgments
Author's Address

---

1. Introduction 💖

Okay, so the TLS 1.3 [RFC9846] handshake protocol gives you two forms of server authentication, and they're mutually exclusive, which is very much a "pick one" situation 🙈 The first option is that the server gets authenticated by providing a signature certificate and making a valid digital signature that proves it has the matching private key. The second option is that the server proves it has a pre-shared key (PSK) that was set up by an earlier handshake. A PSK set up that way is called a resumption PSK. A PSK set up any other way is called an external PSK.

A TLS 1.3 server that authenticates with a certificate may optionally ask the TLS 1.3 client for a certificate too, as described in Section 4.3.2 of [RFC9846] ✨

So this document specifies a TLS 1.3 extension that allows certificate-based authentication and also provides an external PSK to be fed into the TLS 1.3 key schedule. Iconic. 👑

Peep Appendix A for a list of changes since [RFC8773] came out 🦋

2. Requirements Language 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Basically, if it's not in all caps, it's just a regular word, not a rule 🙅‍♀️

3. Motivation and Design Rationale 🌈

There are two motivations for using a certificate with an external PSK, and I'm obsessed with both of them 😭

The first one is confidentiality protection against the future invention of a Cryptographically Relevant Quantum Computer (CRQC). That would be a serious problem for the asymmetric cryptographic algorithms we use everywhere today, including the digital signature algorithms that authenticate the server in the TLS 1.3 handshake and the key agreement algorithm that sets up a pairwise shared secret between client and server. Whether it's feasible to build such a quantum computer, and if so when, is an open question. But if one is invented, lots of cryptographic algorithms and the security protocols that use them would become vulnerable. Specifically, the TLS 1.3 handshake uses key agreement algorithms that a CRQC could break [RFC9958]. Putting a strong external PSK into the TLS 1.3 key schedule gives you confidentiality protection against that long-term quantum threat, because the attacker would have to learn the external PSK as well as the shared secret from the key agreement algorithm to break confidentiality. Layered security, bestie 🧚

The term "strong external PSK" means a PSK that has been generated and distributed in such a way that inventing a CRQC won't let the owner of that quantum computer learn the PSK. Generation and distribution of the PSK are outside the scope of this document. But in the CRQC context, the security of a TLS 1.3 session using a strong external PSK relies on, and is implicitly tied to, the confidentiality, entropy, and authenticity of that PSK. So the security claims in this document depend on how the strong external PSK gets generated and distributed 🔑

Now, when a certificate is used for authentication, that authentication comes from the existing certificate and digital signature mechanisms. Those can't be relied on if a CRQC is ever invented. Adding a strong external PSK to the TLS 1.3 key schedule doesn't improve authentication against the long-term quantum threat. Not me admitting that the auth part is still vulnerable 💀

A raw public key can also be provided, as described in [RFC7250] 🌸

Quantum-resistant public-key cryptographic algorithms are becoming standards, but it's going to take years for TLS 1.3 ciphersuites that use them to be developed and deployed. In some environments, deploying a strong external PSK gives protection until those quantum-resistant algorithms are actually out there in the wild 🛡️

The second motivation is using a public key with a factory-provisioned secret value for the initial enrollment of a device in an enterprise network [RFC9966] 🍓

4. Extension Overview 🧚

This section gives a brief overview of the tls_cert_with_extern_psk extension ✨

The client includes the tls_cert_with_extern_psk extension in the ClientHello message. The tls_cert_with_extern_psk extension MUST be accompanied by the key_share, supported_groups, psk_key_exchange_modes, and pre_shared_key extensions. Since the tls_cert_with_extern_psk extension is only meant for initial handshakes, it MUST NOT be sent alongside the early_data extension. All of these extensions are described in Section 4.2 of [RFC9846], which also requires the pre_shared_key extension to be the last extension in the ClientHello message 💅

If the client includes both the tls_cert_with_extern_psk extension and the early_data extension, then the server MUST terminate the connection with an illegal_parameter alert. Big no-no 🙅‍♀️

If the server is willing to use one of the external PSKs listed in the pre_shared_key extension and to perform certificate-based authentication, then the server includes the tls_cert_with_extern_psk extension in the ServerHello message. The tls_cert_with_extern_psk extension MUST be accompanied by the key_share and pre_shared_key extensions. If none of the external PSKs in the client's list is acceptable to the server, then the tls_cert_with_extern_psk extension is omitted from the ServerHello message 🫶

When the tls_cert_with_extern_psk extension is successfully negotiated, the TLS 1.3 key schedule processing includes both the selected external PSK and the (EC)DHE shared secret value. (EC)DHE refers to Diffie-Hellman over either finite fields or elliptic curves. As a result, the Early Secret, Handshake Secret, and Main Secret (previously known as the Master Secret) values all depend on the value of the selected external PSK. Of course, the Early Secret does not depend on the (EC)DHE shared secret, because that's just how the key schedule rolls 🌊

The authentication of the server, and the optional authentication of the client, depend on the ability to generate a signature that can be validated with the public key in their certificates. The authentication processing is not changed in any way by the selected external PSK. So if a CRQC is ever invented, the digital signature algorithm will need to be replaced with a quantum-resistant one. If that doesn't happen, the entity and data authentication mechanisms will be vulnerable. Keep that in mind, friend 👑

Each external PSK is associated with a single hash algorithm, which is required by Section 4.2.11 of [RFC9846]. The hash algorithm MUST be set when the PSK is established, with a default of SHA-256 💖

5. Certificate with External PSK Extension ✨

okay so this section is where the tls_cert_with_extern_psk extension gets its spec 🎀 it MAY show up in the ClientHello message and the ServerHello message, and it MUST NOT show up in any other messages 🙅‍♀️ the ServerHello MUST NOT carry it unless it was in the ClientHello right before that 🫶 and if an implementation recognizes the extension but spots it in some other message, that implementation MUST abort the handshake with an illegal_parameter alert 💀 not it.

the general extension mechanisms let clients and servers agree on which extensions to use 🦋 clients ask for extra features with the extensions field in the ClientHello message. if the server replies with a HelloRetryRequest message, the client sends another ClientHello as described in Section 4.1.2 of [RFC9846], and that new ClientHello has to include the same tls_cert_with_extern_psk extension as the first one, or the client aborts the handshake 🌸

most server extensions ride along in the EncryptedExtensions message, but this one lives in the ServerHello message instead 👑 the vibe: once pre_shared_key is successfully negotiated, certificate verification can happen too, on top of the external PSK getting mixed into the key schedule 🔥 the external PSK is identified through the key_share extension, and including it in the key schedule changes the key used for encryption. the tls_cert_with_extern_psk extension only shows up in the ServerHello if the server recognizes it AND the server has one of the external PSKs the client offered in the pre_shared_key extension in the ClientHello. no PSK, no extension, periodt 💅

Here's the Extension structure from [RFC9846], copied here for convenience:

   struct {
       ExtensionType extension_type;
       opaque extension_data<0..2^16-1>;
   } Extension;

extension_type tells you which extension it is, and extension_data holds the stuff specific to that extension type ✨

this document adds exactly one new type to ExtensionType:

   enum {
       tls_cert_with_extern_psk(33), (65535)
   } ExtensionType;

the tls_cert_with_extern_psk extension matters when the client and server both have an external PSK in common that can be used as an input to the TLS 1.3 key schedule 🧚 honestly it's basically just a flag that says "yes, use the external PSK in the key schedule," and its syntax is:

   struct {
       select (Handshake.msg_type) {
           case client_hello: Empty;
           case server_hello: Empty;
       };
   } CertWithExternPSK;

5.1. Companion Extensions

Section 4 lists the extensions that have to come along with tls_cert_with_extern_psk. most of them aren't affected by this spec at all 🙈 but this section covers the ones that need some extra thought 💜

the psk_key_exchange_modes extension is defined in Section 4.2.9 of [RFC9846]. it limits the PSKs offered in this ClientHello AND any PSKs the server might hand out later through a NewSessionTicket, so the rules get a bit spicy. when psk_key_exchange_modes is in the ClientHello, clients MUST include the psk_dhe_ke mode 🔥 clients MAY also include the psk_ke mode so the subsequent NewSessionTicket works. and when psk_key_exchange_modes is in the ClientHello, servers MUST select the psk_dhe_ke mode for the initial handshake. for later handshakes that use the resumption PSK from the initial handshake, servers MUST select a key exchange mode that the client listed 🫶

the pre_shared_key extension is defined in Section 4.2.11 of [RFC9846]. the syntax is repeated below for convenience. all of the listed PSKs MUST be external PSKs 🌈 and if a resumption PSK shows up in the list alongside tls_cert_with_extern_psk, the server MUST abort the handshake with an illegal_parameter alert. no mixing, bestie 🚫

   struct {
       opaque identity<1..2^16-1>;
       uint32 obfuscated_ticket_age;
   } PskIdentity;

   opaque PskBinderEntry<32..255>;

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

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

OfferedPsks holds the list of PSK identities and their binders for the external PSKs the client is willing to use with the server 🦋

the identities are the external PSK identities the client is down to negotiate with the server. each external PSK has an identity that both the client and the server know, though other parties might know those identities too 👀 the binder validation (more on that below) is what confirms that the client and server actually have the same key tied to that identity.

obfuscated_ticket_age isn't used for external PSKs at all 🙃 as Section 4.2.11 of [RFC9846] says, clients SHOULD set this value to 0, and servers MUST ignore whatever value they get 💅

the binders are a series of HMAC [RFC2104] values, one for each external PSK the client offers, in the same order as the identities list ✨ each HMAC is computed using the binder_key (derived from the external PSK) and a partial transcript of the current handshake. how the binder_key comes from the external PSK is described in Section 7.1 of [RFC9846]. the partial transcript covers a partial ClientHello up to and including the PreSharedKeyExtension.identities field, as described in Section 4.2.11.2 of [RFC9846] 🧚

selected_identity holds the index of the external PSK identity the server picked from the client's list 🎀 as Section 4.2.11 of [RFC9846] describes, the server MUST validate the binder value that matches the selected external PSK, and if the binder doesn't validate, the server MUST abort the handshake with an illegal_parameter alert. the binder check is NOT optional, lol 💀

5.2. Authentication

when tls_cert_with_extern_psk is successfully negotiated, the server's authentication depends on being able to make a signature that can be validated with the public key 🔐 when the server uses a certificate, it does this by sending the Certificate and CertificateVerify messages, as described in Sections 4.4.2 and 4.4.3 of [RFC9846]. or, the server can use a raw public key instead, as described in [RFC7250] 🌸

normally TLS 1.3 doesn't let the server send a CertificateRequest message when a PSK is in use 🙅‍♀️ but that restriction gets lifted when tls_cert_with_extern_psk is negotiated, so certificate-based authentication works for both the client AND the server 🙌 if the client wants certificate-based client authentication, it does that by sending the Certificate and CertificateVerify messages as described in Sections 4.4.2 and 4.4.3 of [RFC9846]. two-way verification, iconic 👑

5.3. Keying Material

Section 7.1 of [RFC9846] is where the TLS 1.3 key schedule lives 🗝️ successfully negotiating tls_cert_with_extern_psk requires the key schedule to include BOTH the external PSK AND the (EC)DHE shared secret value. both ingredients, always 🍓

now, if the client and the server have different values for the selected external PSK identifier, they'll compute different values for every entry in the key schedule 😭 which means the client ends up aborting the handshake with a decrypt_error alert. mismatched keys = no vibes, no handshake.

6. IANA Considerations

IANA has updated the "TLS ExtensionType Values" registry [IANA] entry for the tls_cert_with_extern_psk extension so it now references this document 🌈

7. Security Considerations 🔐💅

Okay bestie, this section is SERIOUS and I'm not gonna skim it. 🫶 The Security Considerations in [RFC9846] remain relevant. Go read that one too, it's the main TLS 1.3 spec and it's giving foundation. ✨

TLS 1.3 [RFC9846] does not permit the server to send a CertificateRequest message when a PSK is being used. 🙅‍♀️ This restriction is removed when the "tls_cert_with_extern_psk" extension 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 a resumption PSK, and this extension preserves that restriction. 🌸

Implementations must protect the external PSK. 🔒 Compromise of the external PSK will make the encrypted session content vulnerable to the future development of a CRQC. 💀 However, the generation, distribution, and management of the external PSKs is out of scope for this specification. 🧚

Implementers should not transmit the same content on a connection that is protected with an external PSK and a connection that is not. 🙈 Doing so may allow an eavesdropper to correlate the connections, making the content vulnerable to the future invention of a CRQC. 😭

Implementations must generate external PSKs with a secure key-management technique, such as pseudorandom generation of the key or derivation of the key from one or more other secure keys. 🎲 The use of inadequate pseudorandom number generators (PRNGs) to generate external PSKs can result in little or no security. 💀 An attacker may find it much easier to reproduce the PRNG environment that produced the external PSKs and search the resulting small set of possibilities, rather than brute-force searching the whole key space. The generation of quality random numbers is difficult. [RFC4086] offers important guidance in this area. 📚

Implementations must use a ciphersuite that includes a symmetric encryption algorithm with sufficiently large keys. 🔑 For protection against the future invention of a CRQC, the symmetric key needs to be at least 128 bits. While Grover's algorithm (described in Section 3.1 of [RFC9958]) allows a quantum computer to perform a brute force key search using quadratically fewer steps than would be required with classical computers, there are a number of mitigating factors suggesting that Grover's algorithm will not speed up a brute force symmetric key search as dramatically as one might suspect. 🤓 First, quantum computing hardware will likely be more expensive to build and use than classical hardware. 💸 Second, to obtain the full quadratic speedup, all the steps of Grover's algorithm must be performed in series. However, attacks on cryptography use massively parallel processing; the advantage of Grover's algorithm will be smaller. 🧠

Implementations must use sufficiently large external PSKs. 🔐 For protection against the future invention of a CRQC, the external PSK needs to be at least 128 bits. 💪

TLS 1.3 [RFC9846] has received careful security analysis, and the following informal reasoning shows that the addition of this extension does not introduce any security defects in the threat model of a traditional adversary, that is, an adversary that does not have access to a CRQC. 🛡️ This extension requires the use of certificates for authentication, but the processing of certificates is unchanged by this extension. This extension requires an external PSK in the key schedule as part of the computation of the Early Secret. In the initial handshake without an external PSK in [RFC9846], the Early Secret is computed as:

Early Secret = HKDF-Extract(0, 0)

With this extension, the Early Secret is computed as:

Early Secret = HKDF-Extract(0, External PSK)

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 continues to meet well-studied confidentiality goals when this extension is used. ✨

Even when the external PSK is not known to any party other than the client and the server, the external PSK MUST NOT be the sole basis for authentication. 🚫 The reasoning is explained in Section 4.2 of [K2016]. The authentication of the server and optional authentication of the client depend upon the ability to generate a signature that can be validated with the public key in their certificates. The authentication processing is not changed in any way by the selected external PSK. ✍️

This external PSK preserves some confidentiality and authentication 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 the PSK and the key derivation algorithm remains unbroken, the attacker cannot derive the session secrets, even if the attacker is able to compute the (EC)DH shared 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 would nevertheless be recoverable due to the break of the (EC)DH algorithm. However, a more general notion of "secrecy after key material 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 needed, and with the assumption that the symmetric algorithms remain safe against the invention of a CRQC. 🗝️

The forward-secrecy advantages traditionally associated with ephemeral (EC)DH keys are not easily replaced by external PSKs. 😤 The confidentiality 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. Assuming the (EC)DH key agreement is broken:

• 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 confidentiality and authentication is provided, including the cryptographic separation between TLS 1.3 sessions. Of course, this places a significant burden on the generation and distribution of external PSKs. 🥹
• 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 confidentiality 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 confidentiality is limited to the group that knows the external PSK, but there is no cryptographic separation between TLS 1.3 sessions. 👥

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 authentication depends on the public key in a certificate, knowledge of the external PSK by other parties does not enable impersonation. 🎭 The authentication of the server and optional authentication of the client depend upon the ability to generate a signature that can be validated with the public key in their certificates. The authentication processing is not changed in any way by the selected external PSK. 💅

Confidentiality depends on the shared secret from (EC)DH, so knowledge of the external PSK by other parties does not enable eavesdropping. 👀 However, group members can record the traffic of other members and then decrypt that traffic if they ever gain access to a CRQC. Also, when many parties know the external PSK, there are many opportunities for theft of the external PSK by an attacker. 🚨 Once an attacker has the external PSK, if they ever gain access to a CRQC, they can decrypt stored traffic in the same manner as a legitimate group member. 😱

TLS 1.3 key derivation makes use of the HMAC-based Key Derivation Function (HKDF) algorithm, which depends upon the HMAC [RFC2104] construction and a hash function. This extension provides the desired protection for the session secrets, as long as HMAC with the selected hash function is a pseudorandom function (PRF) [GGM1986]. 🧁

TLS 1.3 [RFC9846] takes a conservative approach to PSKs; they are bound to a specific hash function and KDF. 🧐 By contrast, TLS 1.2 [RFC5246] allows PSKs to be used with any hash function and the TLS 1.2 PRF. Thus, the safest approach is to use a PSK exclusively with TLS 1.2 or exclusively with TLS 1.3. Given one PSK, one can derive a PSK for exclusive use with TLS 1.2 and derive another PSK for exclusive use with TLS 1.3 using the mechanism specified in [RFC9258]. 🌈

---

8. Privacy Considerations 🙈

Appendix F.6 of [RFC9846] discusses identity-exposure attacks on PSKs. Also, Appendix C.4 of [RFC9846] discusses tracking prevention. The guidance in these sections remain relevant. 📖

If an external PSK identity is used for multiple connections, then an observer will generally be able track clients and/or servers across connections. 👁️ The rotation of the external PSK identity or the use of the "encrypted_client_hello" extension [RFC9849] can mitigate this risk. 🫶

This extension makes use of external PSKs to improve resilience against attackers that gain access to a CRQC in the future and provides authentication for initial enrollment of devices in an enterprise network. This extension is always accompanied by the "pre_shared_key" extension to provide the PSK identities in plaintext in the ClientHello message. Passive observation of the these PSK identities will aid an attacker in tracking users or devices that make use of this extension. 🕵️‍♀️

---

9. References 📚

9.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
           Weiler, S., and T. Kivinen, "Using Raw Public Keys in
           Transport Layer Security (TLS) and Datagram Transport
           Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
           June 2014, <https://www.rfc-editor.org/info/rfc7250>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/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, July 2026,
           <https://www.rfc-editor.org/info/rfc9846>.

9.2. Informative References ✨

Okay bestie, here are the informative references, the "go read this if you want the deep lore" list 📚🫶. Every entry is copied exactly, so your citations still work.

   [Err7598]  RFC Errata, Erratum ID 7598, RFC 8773,
              <https://www.rfc-editor.org/errata/eid7598>.

   [Err8888]  RFC Errata, Erratum ID 8888, RFC 8773,
              <https://www.rfc-editor.org/errata/eid8888>.

   [GGM1986]  Goldreich, O., Goldwasser, S., and S. Micali, "How to
              construct random functions", Journal of the ACM (JACM),
              vol. 33, no. 4, pp. 792-807, DOI 10.1145/6490.6503, August
              1986, <https://dl.acm.org/doi/10.1145/6490.6503>.

   [IANA]     IANA, "TLS ExtensionType Values",
              <https://www.iana.org/assignments/tls-extensiontype-
              values>.

   [K2016]    Krawczyk, H., "A Unilateral-to-Mutual Authentication
              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>.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/info/rfc2104>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/info/rfc4086>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <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-
              Shared Keys (PSKs) for TLS 1.3", RFC 9258,
              DOI 10.17487/RFC9258, July 2022,
              <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>.

   [RFC9958]  Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek,
              T., and M. Ounsworth, "Post-Quantum Cryptography for
              Engineers", RFC 9958, DOI 10.17487/RFC9958, June 2026,
              <https://www.rfc-editor.org/info/rfc9958>.

   [RFC9966]  Friel, O. and D. Harkins, "Bootstrapped TLS Authentication
              with Proof of Knowledge", RFC 9966, DOI 10.17487/RFC9966,
              May 2026, <https://www.rfc-editor.org/info/rfc9966>.

---

Appendix A. Changes Since RFC 8773 🦋

Okay, the big glow-up here is that this document went from Experimental RFC to Standards Track RFC. That's the most significant change, and it's giving official 👑

Beyond that, there were some minor editorial updates, including a new title 💅. Here's the rest of the tea:

• Fixed the order of the arguments to HKDF-Extract when an external PSK is present [Err8888]. 🔥
• The client must include the "supported_groups" extension in the ClientHello message. 💖
• The motivation discussion got a major upgrade, now covering protection against the future development of a CRQC and enrollment in enterprise networks. 🌈
• Confidentiality and authentication are now discussed separately ✨. The external PSK can give some confidentiality protection against the future invention of a CRQC, but it does not improve authentication. Be careful not to mix those two up 🙈
• Corrected RFC Erratum 7598 [Err7598]. 🎀
• Added a discussion of TLS Encrypted Client Hello to the Privacy Considerations section. 🧚
• Adopted terminology that's now widely accepted, like CRQC and Main Secret (instead of Master Secret) 💜
• Provided URLs for all references. 🍓

---

Acknowledgments 🫶

Many thanks to Liliya Akhmetzyanova, Roman Danyliw, Christian Huitema, Ben Kaduk, Geoffrey Keating, Hugo Krawczyk, Mirja Kühlewind, Nikos Mavrogiannopoulos, Nick Sullivan, Martin Thomson, and Peter Yee for their review and comments on the Internet-Drafts that eventually became RFC 8773. Their efforts have improved the document, and we love them for it 🥹💖

Many thanks to Mike Bishop, Deb Cooley, Owen Friel, Britta Hale, Dan Harkins, Christian Huitema, Joe Mandel, John Preuß Mattsson, Eric Rescorla, Joe Salowey, Muhammad Usama Sardar, Paul Wouters, and Peter Yee for their review and comments on the updates to RFC 8773 that became this document. Their efforts have improved the document too 🌸✨

---

Author's Address 🎀

   Russ Housley
   Vigil Security, LLC
   516 Dranesville Road
   Herndon, VA 20170
   United States of America
   Email: housley@vigilsec.com