<?xml version='1.0' encoding='utf-8'?> <!DOCTYPE rfc SYSTEM"rfc2629.dtd" [ <!ENTITY RFC2104 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml'> <!ENTITY RFC2119 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'> <!ENTITY RFC4086 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml'> <!ENTITY RFC5246 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml'> <!ENTITY RFC8017 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml'> <!ENTITY RFC8174 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml'> <!ENTITY RFC8446 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml'> <!ENTITY C2PQ PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.hoffman-c2pq.xml'> <!ENTITY IMPORTER PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-external-psk-importer.xml'> ]>"rfc2629-xhtml.ent"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="draft-ietf-tls-tls13-cert-with-extern-psk-07" category="exp"ipr="trust200902"> <?rfc compact="yes"?> <?rfc text-list-symbols="o*+-"?> <?rfc subcompact="no"?> <?rfc sortrefs="yes"?> <?rfc symrefs="yes"?> <?rfc strict="yes"?>ipr="trust200902" obsoletes="" updates="" xml:lang="en" sortRefs="true" symRefs="true" version="3" number="8773" consensus="true" tocInclude="true"> <!-- xml2rfc v2v3 conversion 2.39.0 --> <front> <title abbrev="Certificate with External PSK">TLS 1.3 Extension forCertificate-basedCertificate-Based Authentication with an External Pre-Shared Key</title> <seriesInfo name="RFC" value="8773"/> <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> <dateday="23" month="December" year="2019"/>month="March" year="2020"/> <keyword>cryptography</keyword> <abstract> <t> This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre-shared key (PSK). </t> </abstract> </front> <middle> <sectiontitle="Introduction" anchor="section-intro">anchor="intro" numbered="true" toc="default"> <name>Introduction</name> <t> The TLS 1.3 <xreftarget="RFC8446"/>target="RFC8446" 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. This document specifies a TLS 1.3 extension permitting certificate-based server authentication to be combined with an external PSK as an input to the TLS 1.3 key schedule. </t> <t> Several implementors wanted to gain more experience with this specification before producing astandards-trackStandards Track RFC. As a result, this specification is being published as an Experimental RFC to enable interoperable implementations and gain deployment and operational experience. </t> </section> <sectiontitle="Terminology" anchor="section-term">anchor="term" numbered="true" toc="default"> <name>Terminology</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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> <sectiontitle="Motivationanchor="motive" numbered="true" toc="default"> <name>Motivation and DesignRationale" anchor="motive">Rationale</name> <t> The development of a large-scale quantum computer would pose a serious challenge for the 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. It is an open question whether or not it is feasible to build a large-scale quantum 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. </t> <t> The TLS 1.3 handshake protocol employs key agreement algorithms and digital signature algorithms that could be broken by the development of a large-scale quantum computer <xreftarget="I-D.hoffman-c2pq"/>.target="I-D.hoffman-c2pq" format="default"/>. The key agreement algorithms include Diffie-Hellman (DH) <xreftarget="DH1977"/>target="DH1976" format="default"/> and Elliptic Curve Diffie-Hellman (ECDH) <xreftarget="IEEE1363"/>;target="IEEE1363" format="default"/>; the digital signature algorithms include RSA <xreftarget="RFC8017"/>target="RFC8017" format="default"/> and the Elliptic Curve Digital Signature Algorithm (ECDSA) <xreftarget="FIPS186"/>.target="FIPS186" format="default"/>. As a result, an adversary that stores a TLS 1.3 handshake protocol exchange today could decrypt the associated encrypted communications in the future when a large-scale quantum computer becomes available. </t> <t> In thenear-term,near term, this document describes a TLS 1.3 extension to protect today's communications from the future invention of a large-scale quantum computer by providing a strong external PSK as an input to the TLS 1.3 key schedule while preserving the authentication provided by the existing certificate and digital signature mechanisms. </t> </section> <sectiontitle="Extension Overview" anchor="section-over">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" extensionMUST<bcp14>MUST</bcp14> be accompanied by the"key_share”,"key_share", "psk_key_exchange_modes", and "pre_shared_key" extensions. The clientMAY<bcp14>MAY</bcp14> also find it useful to include the "supported_groups" extension. Since the "tls_cert_with_extern_psk" extension is intended to be used only with initial handshakes, itMUST NOT<bcp14>MUST NOT</bcp14> be sent alongside the "early_data" extension. These extensions are all described inSection 4.2 of<xreftarget="RFC8446"/>,target="RFC8446" sectionFormat="of" section="4.2"/>, which also requires the"pre_shared_key”"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 serverMUST<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”"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" extensionMUST<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 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. </t> <t> Each external PSK is associated with a single hash algorithm, which is required bySection 4.2.11 of<xreftarget="RFC8446"/>.target="RFC8446" sectionFormat="of" section="4.2.11"/>. The hash algorithmMUST<bcp14>MUST</bcp14> be set when the PSK is established, with a default of SHA-256. </t> </section> <sectiontitle="Certificateanchor="extn" numbered="true" toc="default"> <name>Certificate with External PSKExtension" anchor="section-extn">Extension</name> <t> This section specifies the "tls_cert_with_extern_psk" extension, whichMAY<bcp14>MAY</bcp14> appear in the ClientHello message and ServerHello message. ItMUST NOT<bcp14>MUST NOT</bcp14> appear in any other messages. The "tls_cert_with_extern_psk" extensionMUST NOT<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 implementationMUST<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 inSection 4.1.2 of<xreftarget="RFC8446"/>,target="RFC8446" 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 "tls_cert_with_extern_psk" extension affects the key used for encryption, so it cannot be carried in the EncryptedExtensions message. Therefore, 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 <xreftarget="RFC8446"/>;target="RFC8446" format="default"/>; it is repeated here for convenience. </t><figure> <artwork><![CDATA[<sourcecode type="tls-presentation"> struct { ExtensionType extension_type; opaqueextension_data<0..2^16-1>;extension_data<0..2^16-1>; } Extension;]]> </artwork> </figure></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><figure> <artwork> <![CDATA[<sourcecode type="tls-presentation"> enum {tls_cert_with_extern_psk(TBD),tls_cert_with_extern_psk(33), (65535) } ExtensionType;]]> </artwork> </figure></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><figure> <artwork> <![CDATA[<sourcecode type="tls-presentation" > struct { select (Handshake.msg_type) { case client_hello: Empty; case server_hello: Empty; }; } CertWithExternPSK;]]> </artwork> </figure></sourcecode> <sectiontitle="Companion Extensions" anchor="other-extns">anchor="other-extns" numbered="true" toc="default"> <name>Companion Extensions</name> <t>Section 4<xref target="over"/> lists the extensions that are required to accompany the "tls_cert_with_extern_psk" extension. Most of those extensions arearenot 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 inSection 4.2.9of <xreftarget="RFC8446"/>.target="RFC8446" 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, clientsMUST<bcp14>MUST</bcp14> include psk_dhe_ke mode. In addition, clientsMAY<bcp14>MAY</bcp14> also include psk_ke mode to support a subsequent NewSessionTicket. When the "psk_key_exchange_modes" extension is included in the ServerHello message, serversMUST<bcp14>MUST</bcp14> select the psk_dhe_ke mode for the initial handshake. ServersMUST<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 inSection 4.2.11 of<xreftarget="RFC8446"/>.target="RFC8446" sectionFormat="of" section="4.2.11"/>. The syntax is repeated below for convenience. All of the listed PSKsMUST<bcp14>MUST</bcp14> be external PSKs. If a resumption PSK is listed along with the "tls_cert_with_extern_psk" extension, the serverMUST<bcp14>MUST</bcp14> abort the handshake with an "illegal_parameter" alert. </t><figure> <artwork> <![CDATA[<sourcecode type="tls-presentation"> struct { opaqueidentity<1..2^16-1>;identity<1..2^16-1>; uint32 obfuscated_ticket_age; } PskIdentity; opaquePskBinderEntry<32..255>;PskBinderEntry<32..255>; struct { PskIdentityidentities<7..2^16-1>;identities<7..2^16-1>; PskBinderEntrybinders<33..2^16-1>;binders<33..2^16-1>; } OfferedPsks; struct { select (Handshake.msg_type) { case client_hello: OfferedPsks; case server_hello: uint16 selected_identity; }; } PreSharedKeyExtension;]]> </artwork> </figure></sourcecode> <t>The OfferedPsks"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> Theobfuscated_ticket_age"obfuscated_ticket_age" is not used for external PSKs. As stated inSection 4.2.11 of<xreftarget="RFC8446"/>,target="RFC8446" sectionFormat="of" section="4.2.11"/>, clientsSHOULD<bcp14>SHOULD</bcp14> set this value to 0, and serversMUST<bcp14>MUST</bcp14> ignore the value. </t> <t> The binders are a series of HMAC <xreftarget="RFC2104"/>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 inSection 7.1 of<xreftarget="RFC8446"/>.target="RFC8446" sectionFormat="of" section="7.1"/>. The partial transcript of the current handshake includes a partial ClientHello up to and including the PreSharedKeyExtension.identitiesfieldfield, as described inSection 4.2.11.2 of<xreftarget="RFC8446"/>.target="RFC8446" sectionFormat="of" section="4.2.11.2"/>. </t> <t> Theselected_identity"selected_identity" contains the index of the external PSK identity that the server selected from the list offered by the client. As described inSection 4.2.11.2 of<xreftarget="RFC8446"/>,target="RFC8446" sectionFormat="of" section="4.2.11"/>, the serverMUST<bcp14>MUST</bcp14> validate the binder value that corresponds to the selected external PSK, and if the binder does not validate, the serverMUST<bcp14>MUST</bcp14> abort the handshake with an "illegal_parameter" alert. </t> </section> <sectiontitle="Authentication" anchor="authn">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 in the server's certificate. This is accomplished by the server sending the Certificate and CertificateVerifymessagesmessages, as described in Sections4.4.2<xref target="RFC8446" sectionFormat="bare" section="4.4.2"/> and4.4.3<xref target="RFC8446" sectionFormat="bare" section="4.4.3"/> of <xref target="RFC8446"/>. </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 Sections4.4.2<xref target="RFC8446" sectionFormat="bare" section="4.4.2"/> and4.4.3<xref target="RFC8446" sectionFormat="bare" section="4.4.3"/> of <xref target="RFC8446"/>. </t> </section> <sectiontitle="Keying Material" anchor="keying">anchor="keying" numbered="true" toc="default"> <name>Keying Material</name> <t>Section 7.1 of<xreftarget="RFC8446"/>target="RFC8446" sectionFormat="of" section="7.1"/> specifies the TLS 1.3Key Schedule.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> <sectiontitle="IANA Considerations" anchor="section-IANA">anchor="IANA-con" numbered="true" toc="default"> <name>IANA Considerations</name> <t> IANAis requested to updatehas updated theTLS"TLS ExtensionTypeRegistryValues" registry <xreftarget="IANA"/>target="IANA" format="default"/> to include "tls_cert_with_extern_psk" with a value ofTBD33 and the list of messages "CH, SH" in which the "tls_cert_with_extern_psk" extension may appear. </t> </section> <sectiontitle="Security Considerations" anchor="section-security">anchor="security" numbered="true" toc="default"> <name>Security Considerations</name> <t> The Security Considerations in <xreftarget="RFC8446"/>target="RFC8446" format="default"/> remain relevant. </t> <t> TLS 1.3 <xreftarget="RFC8446"/>target="RFC8446" 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 does not alter those restrictions. Thus, a certificateMUST NOT<bcp14>MUST NOT</bcp14> be used with a resumption PSK. </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 large-scale quantum computer. 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 large-scale quantum computer. </t> <t> Implementations must generate external PSKs with a securekey managementkey-management technique, such aspseudo-randompseudorandom generation of the key or derivation of the key from one or more other secure keys. The use of inadequatepseudo-randompseudorandom 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. <xreftarget="RFC4086"/>target="RFC4086" format="default"/> offers important guidance in this area. </t> <t> If the external PSK is known to any party other than the client and the server, then the external PSKMUST NOT<bcp14>MUST NOT</bcp14> be the sole basis for authentication. The reasoning is explained in Section 4.2 of <xreftarget="K2016"/>.target="K2016" format="default"/>. When this extension is used, authentication is based on certificates, not the external PSK. </t> <t> In this extension, the external PSK preserves confidentiality if the (EC)DH key agreement is ever broken by cryptanalysis or the future invention of a large-scale quantum computer. As long as the attacker does not know the PSK and the key derivation algorithm remains unbroken, the attacker cannot derive the sessionsecretssecrets, even if they are able to compute the (EC)DH shared secret. Should the attacker be able compute the (EC)DH shared secret, theforward secrecyforward-secrecy advantages traditionally associated with ephemeral (EC)DH keys will no longer be relevant. Although the ephemeral private keys used during a given TLS session are destroyed at the end of a session, preventing the attacker from later accessing them, these private keys would nevertheless be recoverable due to the break in the 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 algorithms that use the external PSKs remain quantum-safe. </t> <t> TLS 1.3 key derivation makes use of theHKDFHMAC-based Key Derivation Function (HKDF) algorithm, which depends upon the HMAC <xreftarget="RFC2104"/>target="RFC2104" format="default"/> construction and a hash function. This extension provides the desired protection for the sessionsecretssecrets, as long as HMAC with the selected hash function is a pseudorandom function (PRF) <xreftarget="GGM1986"/>.target="GGM1986" format="default"/>. </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. Since confidentiality depends on the shared secret from (EC)DH, knowledge of the external PSK by other parties does not enable eavesdropping. However, group members can record the traffic of othermembers,members and then decrypt it if they ever gain access to a large-scale quantum computer. 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 large-scale quantumcomputercomputer, in the same manner as a legitimate group member. </t> <t> TLS 1.3 <xreftarget="RFC8446"/>target="RFC8446" format="default"/> takes a conservative approach to PSKs; they are bound to a specific hash function and KDF. By contrast, TLS 1.2 <xreftarget="RFC5246"/>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 <xreftarget="I-D.ietf-tls-external-psk-importer"/>.target="I-D.ietf-tls-external-psk-importer" format="default"/>. </t> <t> TLS 1.3 <xreftarget="RFC8446"/>target="RFC8446" 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. This extension requires the use of certificates for authentication, but the processing of certificates is unchanged by this extension. This extension places an external PSK in the key schedule as part of the computation of the Early Secret. In the initial handshake without this extension, the Early Secret is computed as:<figure> <artwork> <![CDATA[</t> <sourcecode> Early Secret = HKDF-Extract(0,0)]]> </artwork> </figure>0) </sourcecode> <t> With this extension, the Early Secret is computed as:<figure> <artwork> <![CDATA[</t> <sourcecode> Early Secret = HKDF-Extract(External PSK,0)]]> </artwork> </figure>0) </sourcecode> <t> Any entropy contributed by the external PSK can only make the Early Secret better; the External PSK cannot make it worse. For these two reasons, TLS 1.3 continues to meet its security goals when this extension is used. </t> </section> <sectiontitle="Privacy Considerations" anchor="section-privacy">anchor="privacy" numbered="true" toc="default"> <name>Privacy Considerations</name> <t>Appendix E.6 of<xreftarget="RFC8446"/>target="RFC8446" sectionFormat="of" section="E.6"/> discussesidentity exposureidentity-exposure attacks on PSKs. The guidance in this section remains relevant. </t> <t> This extension makes use of external PSKs to improve resilience against attackers that gain access to a large-scale quantum computer in the future. 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 attackerto trackin tracking users of this extension. </t> </section><section title="Acknowledgments" anchor="section-acks"> <t> 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; their efforts have improved this document. </t> </section></middle> <back><references title="Normative References"> &RFC2119; &RFC8174; &RFC8446;<displayreference target="I-D.hoffman-c2pq" to="TRANSITION" /> <displayreference target="I-D.ietf-tls-external-psk-importer" to="IMPORT" /> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> </references><references title="Informative References"> &C2PQ;<references> <name>Informative References</name> <!-- draft-hoffman-c2pq-06 exists --> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hoffman-c2pq.xml"/> <referenceanchor="DH1977">anchor="DH1976" target="https://ieeexplore.ieee.org/document/1055638"> <front> <title>New Directions in Cryptography</title> <author initials="W" surname="Diffie" fullname="Whitfield Diffie"/> <author initials="M" surname="Hellman" fullname="Martin Hellman"/> <datemonth="June" year="1977" />month="November" year="1976"/> </front><seriesInfo name="IEEE<refcontent>IEEE Transactions on InformationTheory" value="V.IT-22 n.6"/>Theory</refcontent> <refcontent>Vol. 22, No. 6</refcontent> <seriesInfo name="DOI" value="10.1109/TIT.1976.1055638"/> </reference> <reference anchor="GGM1986"> <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. 33, No. 4</refcontent> <refcontent>pp. 792-807</refcontent> <seriesInfoname="J. ACM" value="1986 (33), pp. 792-807"/>name="DOI" value="10.1145/6490.6503"/> </reference> <reference anchor="FIPS186"> <front> <title>Digital Signature Standard (DSS)</title><author><organization>National Institute of Standards and Technology</organization></author><author> <organization>NIST</organization> </author> <date year="2013"month="July" />month="July"/> </front> <seriesInfo name="Federal Information Processing Standards Publication(FIPS PUB)"(FIPS)" value="186-4"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/> </reference> <reference anchor="IANA" target="https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml"> <front><title>IANA Registry for TLS<title>TLS ExtensionType Values</title><author > <organization></organization><author> <organization>IANA</organization> </author><date year="n.d."/></front> </reference> <referenceanchor="IEEE1363">anchor="IEEE1363" target="https://ieeexplore.ieee.org/document/891000"> <front> <title>IEEE Standard Specifications for Public-Key Cryptography</title><author><organization>Institute of Electrical and Electronics Engineers</organization></author><author> <organization>IEEE</organization> </author> <date year="2000"/>month="August"/> </front> <seriesInfo name="IEEE Std" value="1363-2000"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2000.92292"/> </reference>&IMPORTER;<!-- draft-ietf-tls-external-psk-importer-03 exists --> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-external-psk-importer.xml"/> <referenceanchor="K2016">anchor="K2016" target="https://dl.acm.org/doi/10.1145/2976749.2978325"> <front> <title>A Unilateral-to-Mutual Authentication Compiler for Key Exchange (with Applications to Client Authentication in TLS 1.3)</title> <author initials="H" surname="Krawczyk" fullname="Hugo Krawczyk"/> <dateday="10" month="August" year="2016" />month="October" year="2016"/> </front> <refcontent>CCS '16: Proceedings of the 2016 ACM Communications Security</refcontent> <refcontent>pp. 1438-50</refcontent> <seriesInfoname="IACR ePrint" value="2016/711"/>name="DOI" value="10.1145/2976749.2978325"/> </reference>&RFC2104; &RFC4086; &RFC5246; &RFC8017;<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"/> </references> </references> <section anchor="acks" numbered="false" toc="default"> <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; their efforts have improved this document. </t> </section> </back> </rfc>