The Security Considerations in [RFC 8446
] remain relevant.
TLS 1.3 [RFC 8446
] 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 certificate MUST NOT
be used with a resumption PSK.
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.
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.
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. [RFC 4086
] offers important guidance in this area.
If the external PSK is known to any party other than the client and the server, then the external PSK MUST NOT
be the sole basis for authentication. The reasoning is explained in Section 4.2 of [K2016
]. When this extension is used, authentication is based on certificates, not the external PSK.
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 session secrets, even if they are able to compute the (EC)DH shared secret. Should the attacker be able compute the (EC)DH shared secret, the forward-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.
TLS 1.3 key derivation makes use of the HMAC-based Key Derivation Function (HKDF) algorithm, which depends upon the HMAC [RFC 2104
] 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
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 other 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 quantum computer, in the same manner as a legitimate group member.
TLS 1.3 [RFC 8446
] takes a conservative approach to PSKs; they are bound to a specific hash function and KDF. By contrast, TLS 1.2 [RFC 5246
] 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 [IMPORT
TLS 1.3 [RFC 8446
] 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:
Early Secret = HKDF-Extract(0, 0)
With this extension, the Early Secret is computed as:
Early Secret = HKDF-Extract(External PSK, 0)
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.