<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="en" submissionType="IETF"
     docName="draft-ietf-tls-8773bis-13" docName="draft-ietftls-8773bis-13" number="9973" category="std" ipr="trust200902" sortRefs="true" symRefs="true" consensus="true" tocInclude="true"
     obsoletes="8773"> obsoletes="8773" updates="" version="3">

  <front>
    <title abbrev="Certificate with External PSK">TLS 1.3 Extension for
    Using Certificates with an External Pre-Shared Key</title>
    <seriesInfo name="RFC" value="9973"/>
    <author fullname="Russ Housley" initials="R." surname="Housley">
      <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
      <address>
        <postal>
          <street>516 Dranesville Road</street>
          <city>Herndon</city>
          <region>VA</region>
          <code>20170</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>housley@vigilsec.com</email>
      </address>
    </author>
    <date day="5" month="September" year="2025"/> month="April" year="2026"/>
    <area>SEC</area>
    <workgroup>tls</workgroup>

    <keyword>cryptography</keyword>
    <keyword>pre-shared key</keyword>
    <abstract>
      <t>
        This document specifies a TLS 1.3 extension that allows TLS clients
        and servers to authenticate with certificates and provide confidentiality
        based on encryption with a symmetric key from the usual key
        agreement algorithm and an external pre-shared key (PSK).  This
        Standards Track RFC (once approved) obsoletes RFC 8773, which was
        an Experimental RFC.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        The TLS 1.3 <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" format="default"/>
        handshake protocol provides two mutually exclusive forms of server
        authentication.  First, the server can be authenticated by
        providing a signature certificate and creating a valid digital
        signature to demonstrate that it possesses the corresponding
        private key.  Second, the server can be authenticated
        by demonstrating that it possesses a pre-shared key (PSK) that
        was established by a previous handshake.  A PSK that
        is established in this fashion is called a resumption PSK.  A
        PSK that is established by any other means is called an external
        PSK.
      </t>
      <t>
        A TLS 1.3 server that is authenticating with a certificate may
        optionally request a certificate from the TLS 1.3 client for
        authentication
        authentication, as described in
        <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" sectionFormat="of" section="4.3.2"/>.
      </t>
      <t>
        This document specifies a TLS 1.3 extension permitting
        certificate-based authentication and providing an external PSK
        to be input to the TLS 1.3 key schedule.
      </t>
    <t>
        Please see <xref target="changes"/> for a list of changes since
        the publication of RFC 8773. <xref target="RFC8773"/>.
      </t>
    </section>
    <section anchor="term" numbered="true" toc="default">
      <name>Terminology</name>
      <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in
        BCP 14 BCP&nbsp;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">
      <name>Motivation and Design Rationale</name>
      <t>
        There are two motivations for using a certificate with an external PSK.
      </t>
      <t>
        One motivation is confidentiality protection against the future invention of a
        Cryptographically Relevant Quantum Computer (CRQC), which would pose a serious
        challenge for the asymmetric cryptographic algorithms that are widely deployed
        today, including the digital signature algorithms that are used to authenticate
        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
        open question whether or not it is feasible to build such a quantum computer,
        and computer
        and, if so, when that might happen.  However, if such a quantum computer is
        invented, many of the cryptographic algorithms and the security protocols
        that use them would become vulnerable.  In particular, The the TLS 1.3 handshake
        protocol employs key agreement algorithms that could be broken by the
        invention of a CRQC <xref target="I-D.ietf-pquip-pqc-engineers"/>.  Including a
        strong external PSK in the TLS 1.3 key schedule offers confidentiality protection
        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
        agreement algorithm to break confidentiality.
      </t>
      <t>
        The term strong "strong external PSK PSK" is used to mean that the PSK that has
        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 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 1.3 session using the
        strong external PSK relies on and is implicitly tied to the confidentiality,
        entropy, and authenticity of the PSK.  Thus, the security claims in this
        document depend on generation and distribution of the strong external PSK.
      </t>
      <t>
        When a certificate is used for authentication, the authentication is
        provided by the existing certificate and digital signature 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 key schedule does not offer improvement
        against the long-term quantum computing threat regarding authentication.
      </t>
      <t>
        Likewise, a raw public key can be provided provided, as described in
        <xref target="RFC7250"/>.
      </t>
      <t>
        Quantum-resistant public-key cryptographic algorithms are becoming standards,
        but it will take many years for TLS 1.3 ciphersuites that use these algorithms
        to be developed and deployed.  In some environments, deployment of a strong
        external PSK provides protection until these quantum-resistant algorithms
        are deployed.
      </t>
      <t>
        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 network
        <xref target="I-D.ietf-emu-bootstrapped-tls"/>.
      </t>
    </section>
    <section anchor="over" numbered="true" toc="default">
      <name>Extension Overview</name>
      <t>
        This section provides a brief overview of the "tls_cert_with_extern_psk"
        extension.
      </t>
      <t>
        The client includes the "tls_cert_with_extern_psk" extension in the
        ClientHello message.  The "tls_cert_with_extern_psk" extension <bcp14>MUST</bcp14>
        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 intended to be used only with initial handshakes, it
        <bcp14>MUST NOT</bcp14> be sent alongside the "early_data" extension.  These
        extensions are all described in <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" sectionFormat="of" section="4.2"/>,
        which also requires the "pre_shared_key" extension to be the last extension
        in the ClientHello message.
      </t>
      <t>
        If the client includes both the "tls_cert_with_extern_psk" extension
        and the "early_data" extension, then the server <bcp14>MUST</bcp14> terminate
        the connection with an "illegal_parameter" alert.
      </t>
      <t>
        If the server is willing to use one of the external PSKs listed in the
        "pre_shared_key" extension and 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 <bcp14>MUST</bcp14>
        be accompanied by the "key_share" and "pre_shared_key" extensions.  If none
        of the external PSKs in the list provided by the client is acceptable
        to the server, then the "tls_cert_with_extern_psk" extension is omitted
        from the ServerHello message.
      </t>
      <t>
        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 upon the value of the selected external PSK.  Of course, the
        Early Secret does not depend upon the (EC)DHE shared secret.
      </t>
      <t>
        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.  As a result, if a CRQC is ever invented,
        the digital signature algorithm will need to be replaced with a
        quantum resistant
        quantum-resistant one.  Failure to do so will result in vulnerable
        entity and data authentication mechanisms.
      </t>
      <t>
        Each external PSK is associated with a single hash algorithm, which is required by
        <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" sectionFormat="of" section="4.2.11"/>.  The
        hash algorithm <bcp14>MUST</bcp14> be set when the PSK is established, with a
        default of SHA-256.
      </t>
    </section>
    <section anchor="extn" numbered="true" toc="default">
      <name>Certificate with External PSK Extension</name>
      <t>
        This section specifies the "tls_cert_with_extern_psk" extension, which
        <bcp14>MAY</bcp14> appear in the ClientHello message and ServerHello
        message.  It <bcp14>MUST NOT</bcp14> appear in any other messages.  The
        "tls_cert_with_extern_psk" extension <bcp14>MUST NOT</bcp14> appear in the
        ServerHello message unless the "tls_cert_with_extern_psk" extension appeared
        in the preceding ClientHello message.  If an implementation recognizes the
        "tls_cert_with_extern_psk" extension and receives it in any other message,
        then the implementation <bcp14>MUST</bcp14> abort the handshake with an
        "illegal_parameter" alert.
      </t>
      <t>
        The general extension mechanisms enable clients and servers to negotiate the
        use of specific extensions.  Clients request extended functionality from
        servers with the extensions field in the ClientHello message.  If the server
        responds with a HelloRetryRequest message, then the client sends another
        ClientHello message as described in
        <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" sectionFormat="of" section="4.1.2"/>,
        including the same "tls_cert_with_extern_psk" extension as the original
        ClientHello message, or aborts the handshake.
      </t>
      <t>
        Many server extensions are carried in the EncryptedExtensions
        message; however, the "tls_cert_with_extern_psk" extension is
        carried in the ServerHello message.  Successful negotiation of
        the "pre_shared_key" extension enables certificate verification
        to take place in addition to the inclusion of the external PSK in
        the key schedule.  The external PSK is identified by the
        "key_share" extension, and the inclusion of the external PSK in
        the key schedule affects the key used for encryption.  The
        "tls_cert_with_extern_psk" extension is only present in the
        ServerHello message if 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
        "pre_shared_key" extension in the ClientHello message.
      </t>
      <t>
        The Extension structure is defined in <xref target="I-D.ietf-tls-rfc8446bis"/>; target="RFC9846"/>;
        it is repeated here for convenience.
      </t>
      <sourcecode type="tls-presentation"> type="tls-presentation"><![CDATA[
  struct {
      ExtensionType extension_type;
      opaque extension_data&lt;0..2^16-1&gt;; extension_data<0..2^16-1>;
  } Extension;
</sourcecode>
]]></sourcecode>
      <t>
        The "extension_type" identifies the particular extension type,
        and the "extension_data" contains information specific to the
        particular extension type.
      </t>
      <t>
        This document specifies the "tls_cert_with_extern_psk" extension,
        adding one new type to ExtensionType:
      </t>
      <sourcecode type="tls-presentation"> type="tls-presentation"><![CDATA[
  enum {
      tls_cert_with_extern_psk(33), (65535)
  } ExtensionType;
</sourcecode>
]]></sourcecode>
      <t>
        The "tls_cert_with_extern_psk" extension is relevant when the
        client and server possess an external PSK in common that can be
        used as an input to the TLS 1.3 key schedule.  The
        "tls_cert_with_extern_psk" extension is essentially a flag to
        use the external PSK in the key schedule, and it has the
        following syntax:
      </t>
      <sourcecode type="tls-presentation" > type="tls-presentation"><![CDATA[
  struct {
      select (Handshake.msg_type) {
          case client_hello: Empty;
          case server_hello: Empty;
      };
  } CertWithExternPSK;
</sourcecode>
]]></sourcecode>
      <section anchor="other-extns" numbered="true" toc="default">
        <name>Companion Extensions</name>
        <t>
          <xref target="over"/> lists the extensions that are required to accompany
          the "tls_cert_with_extern_psk" extension.  Most of those extensions
          are not impacted in any way by this specification.  However, this
          section discusses the extensions that require additional consideration.
        </t>
        <t>
          The "psk_key_exchange_modes" extension is defined in
          <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" sectionFormat="of" section="4.2.9"/>.  The
	      "psk_key_exchange_modes" extension restricts the use of both the PSKs
	      offered in this ClientHello and those that the server might supply via
	      a subsequent NewSessionTicket.  As a result, when the "psk_key_exchange_modes"
          extension is included in the ClientHello message, clients <bcp14>MUST</bcp14>
          include psk_dhe_ke mode.  In addition, clients <bcp14>MAY</bcp14> also include
          psk_ke mode to support a subsequent NewSessionTicket.  When the
          "psk_key_exchange_modes" extension is included in the ClientHello
          message, servers <bcp14>MUST</bcp14> select the psk_dhe_ke mode for the
          initial handshake.  Servers <bcp14>MUST</bcp14> select a key exchange mode
          that is listed by the client for subsequent handshakes that include the
          resumption PSK from the initial handshake.
        </t>
        <t>
          The "pre_shared_key" extension is defined in
          <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" sectionFormat="of" section="4.2.11"/>.  The
	      syntax is repeated below for convenience.  All of the listed PSKs
	      <bcp14>MUST</bcp14> be external PSKs.  If a resumption PSK is listed along
	      with the "tls_cert_with_extern_psk" extension, the server <bcp14>MUST</bcp14>
	      abort the handshake with an "illegal_parameter" alert.
        </t>
        <sourcecode type="tls-presentation"> type="tls-presentation"><![CDATA[
  struct {
      opaque identity&lt;1..2^16-1&gt;; identity<1..2^16-1>;
      uint32 obfuscated_ticket_age;
  } PskIdentity;

  opaque PskBinderEntry&lt;32..255&gt;; PskBinderEntry<32..255>;

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

  struct {
      select (Handshake.msg_type) {
          case client_hello: OfferedPsks;
          case server_hello: uint16 selected_identity;
      };
  } PreSharedKeyExtension;
</sourcecode>
]]></sourcecode>
        <t>
          "OfferedPsks" contains the list of PSK identities and
          associated binders for the external PSKs that the client is
          willing to use with the server.
        </t>
        <t>
          The identities are a list of external PSK identities that the
          client 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 identities may be known to other
          parties as well.  In addition, the binder validation (see below)
          confirms that the client and server have the same key associated
          with the identity.
        </t>
        <t>
          The "obfuscated_ticket_age" is not used for external PSKs.  As
          stated in <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" sectionFormat="of" section="4.2.11"/>,
          clients <bcp14>SHOULD</bcp14> set this value to 0, and servers
          <bcp14>MUST</bcp14> ignore the value.
        </t>
        <t>
          The binders are a series of HMAC <xref target="RFC2104" format="default"/>
          values, one for each external PSK offered by the client, in the same order
          as the identities list.  The HMAC value is computed using the binder_key,
          which is derived from the external PSK, and a partial transcript of the
          current handshake.  Generation of the binder_key from the external PSK is described
          in <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" sectionFormat="of" section="7.1"/>.  The
          partial transcript of the current handshake includes a partial ClientHello
          up to and including the PreSharedKeyExtension.identities field, as described
          in <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" sectionFormat="of" section="4.2.11.2"/>.
        </t>
        <t>
          The "selected_identity" contains the index of the external PSK identity
          that the server selected from the list offered by the client.  As described
          in <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" sectionFormat="of" section="4.2.11"/>, the
          server <bcp14>MUST</bcp14> validate the binder value that corresponds
          to the selected external PSK, and if the binder does not validate, the
          server <bcp14>MUST</bcp14> abort the handshake with an "illegal_parameter"
          alert.
        </t>
      </section>
      <section anchor="authn" numbered="true" toc="default">
        <name>Authentication</name>
        <t>
          When the "tls_cert_with_extern_psk" extension is successfully
          negotiated, authentication of the server depends upon the ability to
          generate a signature that can be validated with the public key.  When
          the server uses a certificate, this is accomplished by the server
          sending the Certificate and CertificateVerify messages, as described
          in Sections <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" sectionFormat="bare" section="4.4.2"/>
          and <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" sectionFormat="bare" section="4.4.3"/> of
          <xref target="I-D.ietf-tls-rfc8446bis"/>. target="RFC9846"/>.  Alternatively, the server can use a raw public
          key
          key, as described in <xref target="RFC7250" format="default"/>.
        </t>
        <t>
          TLS 1.3 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 negotiated, allowing
          certificate-based authentication for both the client and the server.  If
          certificate-based client authentication is desired, this is accomplished
          by the client sending the Certificate and CertificateVerify messages as
          described in Sections <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" sectionFormat="bare" section="4.4.2"/>
          and <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" sectionFormat="bare" section="4.4.3"/> of
          <xref target="I-D.ietf-tls-rfc8446bis"/>. target="RFC9846"/>.
        </t>
      </section>
      <section anchor="keying" numbered="true" toc="default">
        <name>Keying Material</name>
        <t>
          <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" sectionFormat="of" section="7.1"/>
          specifies the TLS 1.3 key schedule.  The successful negotiation of the
          "tls_cert_with_extern_psk" extension requires the key schedule
          processing to include both the external PSK and the (EC)DHE
	      shared secret value.
        </t>
        <t>
          If the client and the server have different values associated
          with the selected external PSK identifier, then the client and
          the server will compute different values for every entry in the
          key schedule, which will lead to the client aborting the
          handshake with a "decrypt_error" alert.
        </t>
      </section>
    </section>
    <section anchor="IANA-con" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
        Once this document is approved,
        IANA is asked to update has updated the
        "TLS ExtensionType Values" registry <xref target="IANA" format="default"/>
        entry for the "tls_cert_with_extern_psk" extension to reference this document.
      </t>
    </section>
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
        The Security Considerations in <xref target="I-D.ietf-tls-rfc8446bis"/> target="RFC9846"/> remain relevant.
      </t>
      <t>
        TLS 1.3 <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" format="default"/> 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.
      </t>
      <t>
        Implementations must protect the external pre-shared key (PSK).
        Compromise of the external PSK will make the encrypted session
        content vulnerable to the future development of a Cryptographically
        Relevant Quantum Computer (CRQC).  However, the generation, distribution,
        and management of the external PSKs is out of scope for this specification.
      </t>
      <t>
        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.
      </t>
      <t>
        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.  <xref target="RFC4086" format="default"/> offers
        important guidance in this area.
      </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>
        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 Grover's algorithm (described in
        <xref target="I-D.ietf-pquip-pqc-engineers" sectionFormat="of" section="2.1"/>) section="3.1"/>)
        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 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 Grover's algorithm must be performed
        in series.  However, attacks on cryptography use massively parallel processing, processing;
        the advantage of Grover's algorithm will be smaller.
      </t>
      <t>
        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.
      </t>
      <t>
        TLS 1.3 <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" format="default"/> 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 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 <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" format="default"/>,
        the Early Secret is computed as:
      </t>
<sourcecode>
      <sourcecode><![CDATA[
   Early Secret = HKDF-Extract(0, 0)
</sourcecode>
]]></sourcecode>
      <t>
        With this extension, the Early Secret is computed as:
      </t>
<sourcecode>
      <sourcecode><![CDATA[
   Early Secret = HKDF-Extract(0, External PSK)
</sourcecode>
]]></sourcecode>
      <t>
        Any entropy contributed by the external PSK can only make the Early
        Secret better; the External external PSK cannot make it worse.  Thus, TLS 1.3
        continues to meet well-studied confidentiality goals when this extension
        is used.
      </t>
      <t>
        Even when the external PSK is not known to any party other than the client
        and the server, then the external PSK <bcp14>MUST NOT</bcp14> be the sole
        basis for authentication.  The reasoning is explained in Section 4.2 of
        <xref target="K2016" format="default"/>.  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.
      </t>
      <t>
        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.
      </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>
        The forward-secrecy advantages traditionally associated with ephemeral
        (EC)DH keys are not easily replaced by external PSKs. 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. Assuming the (EC)DH key agreement is broken:
      </t>
      <ul>
        <li>
            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. Of course, this
            places a significant burden on the generation and distribution of
            external PSKs.
          </li>
        <li>
            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.
          </li>
        <li>
            If the external PSK is used for more than one TLS 1.3 session and it is
            known by the client, server 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.
          </li>
      </ul>
      </t>
      <t>
        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.
      </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>
        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, they can decrypt stored
        traffic if they ever gain access to a CRQC, in the same manner as a
        legitimate group member.
      </t>
      <t>
        TLS 1.3 key derivation makes use of the HMAC-based Key Derivation
	    Function (HKDF) algorithm, which depends upon the HMAC
	    <xref target="RFC2104" format="default"/> 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) <xref target="GGM1986" format="default"/>.
      </t>
      <t>
        TLS 1.3 <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" format="default"/> takes a conservative
        approach to PSKs; they are bound to a specific hash function and KDF.  By
        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 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
        <xref target="RFC9258" format="default"/>.
      </t>
    </section>
    <section anchor="privacy" numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>
        <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" sectionFormat="of" section="F.6"/> discusses
        identity-exposure attacks on PSKs.  Also,
        <xref target="I-D.ietf-tls-rfc8446bis" target="RFC9846" sectionFormat="of" section="C.4"/>
        discusses tracking prevention.  The guidance in these sections remain relevant.
      </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>
        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 <xref target="I-D.ietf-tls-esni"/> target="RFC9849"/> can
        mitigate this risk.
      </t>
      <t>
        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.
      </t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
    <displayreference target="I-D.ietf-pquip-pqc-engineers" to="PQC"/>
    <displayreference target="I-D.ietf-emu-bootstrapped-tls" to="TLS-POK"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7250.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7250.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-rfc8446bis.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

<!-- [RFC9846]
draft-ietf-tls-rfc8446bis-14
companion doc RFC 9846
in AUTH48 as of 12/15/25
-->

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

      </references>

    <references title="Informative References">
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8773.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9258.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-esni.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9258.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pquip-pqc-engineers.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9849.xml"/>

<!-- [I-D.ietf-pquip-pqc-engineers]
draft-ietf-pquip-pqc-engineers-14 (in queue)
-->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-emu-bootstrapped-tls.xml"/> href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pquip-pqc-engineers.xml"/>

<!-- [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</refcontent>
	    <refcontent>Vol. ACM (JACM)</refcontent>
          <refcontent>vol. 33, No. 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-extensiontype-values/tls-extensiontype-values.xhtml"> target="https://www.iana.org/assignments/tls-extensiontype-values">
          <front>
            <title>TLS ExtensionType Values</title>
          <author><organization>IANA</organization></author>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="Err7598" quote-title="false" target="https://www.rfc-editor.org/errata/eid7598">
          <front>
          <title>RFC Errata
            <title>Erratum ID 7598</title>
          <author><organization>RFC Editor</organization></author>
            <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 Exchange
           (with Applications to Client Authentication in TLS1.3)</title> TLS 1.3)</title>
            <author initials="H" surname="Krawczyk" fullname="Hugo Krawczyk"/>
            <date day="1" month="September" year="2016"/>
          </front>
	    <seriesInfo name="cryptoeprint" value="2016/711"/>
          <refcontent>Cryptology ePrint Archive, Paper 2016/711</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="changes" numbered="true" > numbered="true">
      <name>Changes Since RFC 8773</name>
      <t>
        The status elevation from Experimental RFC to Standards Track RFC is the most
        significant change in this document.
      </t>
      <t>
        In addition to minor editorial updates, which include a change to the title,
        the following changes were made:
      </t>
      <ul>
        <li>
            Correct the order of the arguments to HKDF-Extract when an
            external PSK is present.
          </li>
        <li>
            The client must include the "supported_groups" extension in the
            ClientHello message.
          </li>
        <li>
            Expand the motivation discussion to talk about protection against the
            future development of a Cryptographically Relevant Quantum Computer (CRQC)
            and enrollment in enterprise networks.
          </li>
        <li>
            Separate the discussion of confidentiality and authentication.  The
            inclusion of the external PSK offers some confidentiality protection
            against the future invention of a CRQC, but the external PSK does not
            improve authentication.
          </li>
        <li>
            Correct RFC Errata Erratum 7598 <xref target="Err7598"/>.
          </li>
        <li>
            Add a discussion of TLS Encrypted Client Hello to the
            Privacy Considerations. Considerations section.
          </li>
        <li>
            Adopt terminology that has become widely accepted, such as CRQC and
            Main Secret (instead of Master Secret).
          </li>
        <li>
            Provide URLs for all references.
          </li>
      </ul>
      </t>
    </section>
    <section title="Acknowledgments" numbered="false">
      <name>Acknowledgments</name>
      <t>
        Many thanks to
        <contact fullname="Liliya Akhmetzyanova"/>,
        <contact fullname="Roman Danyliw"/>,
        <contact fullname="Christian Huitema"/>,
        <contact fullname="Ben Kaduk"/>,
        <contact fullname="Geoffrey Keating"/>,
        <contact fullname="Hugo Krawczyk"/>,
        <contact fullname="Mirja Kühlewind"/>,
        <contact fullname="Nikos Mavrogiannopoulos"/>,
        <contact fullname="Nick Sullivan"/>,
        <contact fullname="Martin Thomson"/>, and
        <contact fullname="Peter Yee"/>
        for their review and comments on the Internet-Drafts that eventually
        became RFC 8773; their efforts have improved the document.
      </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>
        Many thanks to
        <contact fullname="Dan Harkins"/>,
        <contact fullname="Owen Friel"/>,
        <contact fullname="John Preuß Mattsson"/>,
        <contact fullname="Christian Huitema"/>,
        <contact fullname="Joe Salowey"/>,
        <contact fullname="Britta Hale"/>,
        <contact fullname="Peter Yee"/>,
        <contact fullname="Joe Mandel"/>,
        <contact fullname="Muhammad Usama Sardar"/>,
        <contact fullname="Paul Wouters"/>,
        <contact fullname="Mike Bishop"/>,
        <contact fullname="Deb Cooley"/>, and
        <contact fullname="Eric Rescorla"/>
        for their review and comments on the updates to RFC 8773 that became
        this document; their efforts have improved the document.
      </t>
    </section>

<!--[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 because it does not mean the same thing for everyone.
-->

  </back>
</rfc>