RFC3552]. Even under these conditions, the handshake should provide the properties listed below. Note that these properties are not necessarily independent, but reflect the protocol consumers' needs. Establishing the same session keys: The handshake needs to output the same set of session keys on both sides of the handshake, provided that it completes successfully on each endpoint (see [CK01], Definition 1, part 1). Secrecy of the session keys: The shared session keys should be known only to the communicating parties and not to the attacker (see [CK01], Definition 1, part 2). Note that in a unilaterally authenticated connection, the attacker can establish its own session keys with the server, but those session keys are distinct from those established by the client. Peer authentication: The client's view of the peer identity should reflect the server's identity. If the client is authenticated, the server's view of the peer identity should match the client's identity.
Uniqueness of the session keys: Any two distinct handshakes should produce distinct, unrelated session keys. Individual session keys produced by a handshake should also be distinct and independent. Downgrade protection: The cryptographic parameters should be the same on both sides and should be the same as if the peers had been communicating in the absence of an attack (see [BBFGKZ16], Definitions 8 and 9). Forward secret with respect to long-term keys: If the long-term keying material (in this case the signature keys in certificate- based authentication modes or the external/resumption PSK in PSK with (EC)DHE modes) is compromised after the handshake is complete, this does not compromise the security of the session key (see [DOW92]), as long as the session key itself has been erased. The forward secrecy property is not satisfied when PSK is used in the "psk_ke" PskKeyExchangeMode. Key Compromise Impersonation (KCI) resistance: In a mutually authenticated connection with certificates, compromising the long-term secret of one actor should not break that actor's authentication of their peer in the given connection (see [HGFS15]). For example, if a client's signature key is compromised, it should not be possible to impersonate arbitrary servers to that client in subsequent handshakes. Protection of endpoint identities: The server's identity (certificate) should be protected against passive attackers. The client's identity should be protected against both passive and active attackers. Informally, the signature-based modes of TLS 1.3 provide for the establishment of a unique, secret, shared key established by an (EC)DHE key exchange and authenticated by the server's signature over the handshake transcript, as well as tied to the server's identity by a MAC. If the client is authenticated by a certificate, it also signs over the handshake transcript and provides a MAC tied to both identities. [SIGMA] describes the design and analysis of this type of key exchange protocol. If fresh (EC)DHE keys are used for each connection, then the output keys are forward secret. The external PSK and resumption PSK bootstrap from a long-term shared secret into a unique per-connection set of short-term session keys. This secret may have been established in a previous handshake. If PSK with (EC)DHE key establishment is used, these session keys will also be forward secret. The resumption PSK has been designed so that the resumption master secret computed by connection N and needed to form connection N+1 is separate from the traffic keys used by
connection N, thus providing forward secrecy between the connections. In addition, if multiple tickets are established on the same connection, they are associated with different keys, so compromise of the PSK associated with one ticket does not lead to the compromise of connections established with PSKs associated with other tickets. This property is most interesting if tickets are stored in a database (and so can be deleted) rather than if they are self-encrypted. The PSK binder value forms a binding between a PSK and the current handshake, as well as between the session where the PSK was established and the current session. This binding transitively includes the original handshake transcript, because that transcript is digested into the values which produce the resumption master secret. This requires that both the KDF used to produce the resumption master secret and the MAC used to compute the binder be collision resistant. See Appendix E.1.1 for more on this. Note: The binder does not cover the binder values from other PSKs, though they are included in the Finished MAC. TLS does not currently permit the server to send a certificate_request message in non-certificate-based handshakes (e.g., PSK). If this restriction were to be relaxed in future, the client's signature would not cover the server's certificate directly. However, if the PSK was established through a NewSessionTicket, the client's signature would transitively cover the server's certificate through the PSK binder. [PSK-FINISHED] describes a concrete attack on constructions that do not bind to the server's certificate (see also [Kraw16]). It is unsafe to use certificate-based client authentication when the client might potentially share the same PSK/key-id pair with two different endpoints. Implementations MUST NOT combine external PSKs with certificate-based authentication of either the client or the server unless negotiated by some extension. If an exporter is used, then it produces values which are unique and secret (because they are generated from a unique session key). Exporters computed with different labels and contexts are computationally independent, so it is not feasible to compute one from another or the session secret from the exported value. Note: Exporters can produce arbitrary-length values; if exporters are to be used as channel bindings, the exported value MUST be large enough to provide collision resistance. The exporters provided in TLS 1.3 are derived from the same Handshake Contexts as the early traffic keys and the application traffic keys, respectively, and thus have similar security properties. Note that they do not include the client's certificate; future applications which wish to bind to the client's certificate may need to define a new exporter that includes the full handshake transcript.
For all handshake modes, the Finished MAC (and, where present, the signature) prevents downgrade attacks. In addition, the use of certain bytes in the random nonces as described in Section 4.1.3 allows the detection of downgrade to previous TLS versions. See [BBFGKZ16] for more details on TLS 1.3 and downgrade. As soon as the client and the server have exchanged enough information to establish shared keys, the remainder of the handshake is encrypted, thus providing protection against passive attackers, even if the computed shared key is not authenticated. Because the server authenticates before the client, the client can ensure that if it authenticates to the server, it only reveals its identity to an authenticated server. Note that implementations must use the provided record-padding mechanism during the handshake to avoid leaking information about the identities due to length. The client's proposed PSK identities are not encrypted, nor is the one that the server selects. RFC5869] and its two components, HKDF-Extract and HKDF-Expand. The full rationale for the HKDF construction can be found in [Kraw10] and the rationale for the way it is used in TLS 1.3 in [KW16]. Throughout this document, each application of HKDF-Extract is followed by one or more invocations of HKDF-Expand. This ordering should always be followed (including in future revisions of this document); in particular, one SHOULD NOT use an output of HKDF-Extract as an input to another application of HKDF-Extract without an HKDF-Expand in between. Multiple applications of HKDF-Expand to some of the same inputs are allowed as long as these are differentiated via the key and/or the labels. Note that HKDF-Expand implements a pseudorandom function (PRF) with both inputs and outputs of variable length. In some of the uses of HKDF in this document (e.g., for generating exporters and the resumption_master_secret), it is necessary that the application of HKDF-Expand be collision resistant; namely, it should be infeasible to find two different inputs to HKDF-Expand that output the same value. This requires the underlying hash function to be collision resistant and the output length from HKDF-Expand to be of size at least 256 bits (or as much as needed for the hash function to prevent finding collisions).
CHHSV17] for details. In addition, the analysis of post-handshake authentication from [Kraw16] shows that the client identified by the certificate sent in the post-handshake phase possesses the traffic key. This party is therefore the client that participated in the original handshake or one to whom the original client delegated the traffic key (assuming that the traffic key has not been compromised). Section 8 for mechanisms to limit the exposure to replay. CCG16], sometimes also referred to as backward or future secrecy. This is in contrast to KCI resistance, which describes the security guarantees that a party has after its own long-term secret has been compromised.
DFGS15], [CHSV16], [DFGS16], [KW16], [Kraw16], [FGSW16], [LXZFH16], [FG17], and [BBK17]. Section 5.5, then the record layer should provide the following guarantees: Confidentiality: An attacker should not be able to determine the plaintext contents of a given record. Integrity: An attacker should not be able to craft a new record which is different from an existing record which will be accepted by the receiver. Order protection/non-replayability: An attacker should not be able to cause the receiver to accept a record which it has already accepted or cause the receiver to accept record N+1 without having first processed record N. Length concealment: Given a record with a given external length, the attacker should not be able to determine the amount of the record that is content versus padding. Forward secrecy after key change: If the traffic key update mechanism described in Section 4.6.3 has been used and the previous generation key is deleted, an attacker who compromises the endpoint should not be able to decrypt traffic encrypted with the old key. Informally, TLS 1.3 provides these properties by AEAD-protecting the plaintext with a strong key. AEAD encryption [RFC5116] provides confidentiality and integrity for the data. Non-replayability is provided by using a separate nonce for each record, with the nonce being derived from the record sequence number (Section 5.3), with the sequence number being maintained independently at both sides; thus, records which are delivered out of order result in AEAD deprotection failures. In order to prevent mass cryptanalysis when the same plaintext is repeatedly encrypted by different users under the same key (as is commonly the case for HTTP), the nonce is formed by mixing
the sequence number with a secret per-connection initialization vector derived along with the traffic keys. See [BT16] for analysis of this construction. The rekeying technique in TLS 1.3 (see Section 7.2) follows the construction of the serial generator as discussed in [REKEY], which shows that rekeying can allow keys to be used for a larger number of encryptions than without rekeying. This relies on the security of the HKDF-Expand-Label function as a pseudorandom function (PRF). In addition, as long as this function is truly one way, it is not possible to compute traffic keys from prior to a key change (forward secrecy). TLS does not provide security for data which is communicated on a connection after a traffic secret of that connection is compromised. That is, TLS does not provide post-compromise security/future secrecy/backward secrecy with respect to the traffic secret. Indeed, an attacker who learns a traffic secret can compute all future traffic secrets on that connection. Systems which want such guarantees need to do a fresh handshake and establish a new connection with an (EC)DHE exchange. BMMRT15], [BT16], [BDFKPPRSZZ16], [BBK17], and [PS18]. CLINIC] [HCJC16]. This is particularly easy when there is a small set of possible messages to be distinguished, such as for a video server hosting a fixed corpus of content, but still provides usable information even in more complicated scenarios. TLS does not provide any specific defenses against this form of attack but does include a padding mechanism for use by applications: The plaintext protected by the AEAD function consists of content plus variable-length padding, which allows the application to produce arbitrary-length encrypted records as well as padding-only cover traffic to conceal the difference between periods of transmission and periods of silence. Because the padding is encrypted alongside the actual content, an attacker cannot directly determine the length of the padding but may be able to measure it indirectly by the use of timing channels exposed during record processing (i.e., seeing how long it takes to process a record or trickling in records to see
which ones elicit a response from the server). In general, it is not known how to remove all of these channels because even a constant-time padding removal function will likely feed the content into data-dependent functions. At minimum, a fully constant-time server or client would require close cooperation with the application-layer protocol implementation, including making that higher-level protocol constant time. Note: Robust traffic analysis defenses will likely lead to inferior performance due to delays in transmitting packets and increased traffic volume.
Mac17]. Ultimately, servers have the responsibility to protect themselves against attacks employing 0-RTT data replication. The mechanisms described in Section 8 are intended to prevent replay at the TLS layer but do not provide complete protection against receiving multiple copies of client data. TLS 1.3 falls back to the 1-RTT handshake when the server does not have any information about the client, e.g., because it is in a different cluster which does not share state or because the ticket has been deleted as described in Section 8.1. If the application-layer protocol retransmits data in this setting, then it is possible for an attacker to induce message duplication by sending the ClientHello to both the original cluster (which processes the data immediately) and another cluster which will fall back to 1-RTT and process the data upon application-layer replay. The scale of this attack is limited by the client's willingness to retry transactions and therefore only allows a limited amount of duplication, with each copy appearing as a new connection at the server.
If implemented correctly, the mechanisms described in Sections 8.1 and 8.2 prevent a replayed ClientHello and its associated 0-RTT data from being accepted multiple times by any cluster with consistent state; for servers which limit the use of 0-RTT to one cluster for a single ticket, then a given ClientHello and its associated 0-RTT data will only be accepted once. However, if state is not completely consistent, then an attacker might be able to have multiple copies of the data be accepted during the replication window. Because clients do not know the exact details of server behavior, they MUST NOT send messages in early data which are not safe to have replayed and which they would not be willing to retry across multiple 1-RTT connections. Application protocols MUST NOT use 0-RTT data without a profile that defines its use. That profile needs to identify which messages or interactions are safe to use with 0-RTT and how to handle the situation when the server rejects 0-RTT and falls back to 1-RTT. In addition, to avoid accidental misuse, TLS implementations MUST NOT enable 0-RTT (either sending or accepting) unless specifically requested by the application and MUST NOT automatically resend 0-RTT data if it is rejected by the server unless instructed by the application. Server-side applications may wish to implement special processing for 0-RTT data for some kinds of application traffic (e.g., abort the connection, request that data be resent at the application layer, or delay processing until the handshake completes). In order to allow applications to implement this kind of processing, TLS implementations MUST provide a way for the application to determine if the handshake has completed.
Blei98], if TLS 1.3 servers also support static RSA in the context of previous versions of TLS, then it may be possible to impersonate the server for TLS 1.3 connections [JSS15]. TLS 1.3 implementations can prevent this attack by disabling support for static RSA across all versions of TLS. In principle, implementations might also be able to separate certificates with different keyUsage bits for static RSA decryption and RSA signature, but this technique relies on clients refusing to accept signatures using keys in certificates that do not have the digitalSignature bit set, and many clients do not enforce this restriction.
Matt Caswell OpenSSL email@example.com Stephen Checkoway University of Illinois at Chicago firstname.lastname@example.org Pete Chown Skygate Technology Ltd email@example.com Katriel Cohn-Gordon University of Oxford firstname.lastname@example.org Cas Cremers University of Oxford email@example.com Antoine Delignat-Lavaud (co-author of [RFC7627]) INRIA firstname.lastname@example.org Tim Dierks (co-author of TLS 1.0, co-editor of TLS 1.1 and 1.2) Independent email@example.com Roelof DuToit Symantec Corporation firstname.lastname@example.org Taher Elgamal Securify email@example.com Pasi Eronen Nokia firstname.lastname@example.org Cedric Fournet Microsoft email@example.com
Anil Gangolli firstname.lastname@example.org David M. Garrett email@example.com Illya Gerasymchuk Independent firstname.lastname@example.org Alessandro Ghedini Cloudflare Inc. email@example.com Daniel Kahn Gillmor ACLU firstname.lastname@example.org Matthew Green Johns Hopkins University email@example.com Jens Guballa ETAS firstname.lastname@example.org Felix Guenther TU Darmstadt email@example.com Vipul Gupta (co-author of [RFC4492]) Sun Microsystems Laboratories firstname.lastname@example.org Chris Hawk (co-author of [RFC4492]) Corriente Networks LLC email@example.com Kipp Hickman Alfred Hoenes David Hopwood Independent Consultant firstname.lastname@example.org
Marko Horvat MPI-SWS email@example.com Jonathan Hoyland Royal Holloway, University of London firstname.lastname@example.org Subodh Iyengar Facebook email@example.com Benjamin Kaduk Akamai Technologies firstname.lastname@example.org Hubert Kario Red Hat Inc. email@example.com Phil Karlton (co-author of SSL 3.0) Leon Klingele Independent firstname.lastname@example.org Paul Kocher (co-author of SSL 3.0) Cryptography Research email@example.com Hugo Krawczyk IBM firstname.lastname@example.org Adam Langley (co-author of [RFC7627]) Google email@example.com Olivier Levillain ANSSI firstname.lastname@example.org
Xiaoyin Liu University of North Carolina at Chapel Hill email@example.com Ilari Liusvaara Independent firstname.lastname@example.org Atul Luykx K.U. Leuven email@example.com Colm MacCarthaigh Amazon Web Services firstname.lastname@example.org Carl Mehner USAA email@example.com Jan Mikkelsen Transactionware firstname.lastname@example.org Bodo Moeller (co-author of [RFC4492]) Google email@example.com Kyle Nekritz Facebook firstname.lastname@example.org Erik Nygren Akamai Technologies email@example.com Magnus Nystrom Microsoft firstname.lastname@example.org Kazuho Oku DeNA Co., Ltd. email@example.com
Kenny Paterson Royal Holloway, University of London firstname.lastname@example.org Christopher Patton University of Florida email@example.com Alfredo Pironti (co-author of [RFC7627]) INRIA firstname.lastname@example.org Andrei Popov Microsoft email@example.com Marsh Ray (co-author of [RFC7627]) Microsoft firstname.lastname@example.org Robert Relyea Netscape Communications email@example.com Kyle Rose Akamai Technologies firstname.lastname@example.org Jim Roskind Amazon email@example.com Michael Sabin Joe Salowey Tableau Software firstname.lastname@example.org Rich Salz Akamai email@example.com David Schinazi Apple Inc. firstname.lastname@example.org
Sam Scott Royal Holloway, University of London email@example.com Thomas Shrimpton University of Florida firstname.lastname@example.org Dan Simon Microsoft, Inc. email@example.com Brian Smith Independent firstname.lastname@example.org Brian Sniffen Akamai Technologies email@example.com Nick Sullivan Cloudflare Inc. firstname.lastname@example.org Bjoern Tackmann University of California, San Diego email@example.com Tim Taubert Mozilla firstname.lastname@example.org Martin Thomson Mozilla email@example.com Hannes Tschofenig Arm Limited Hannes.Tschofenig@arm.com Sean Turner sn3rd firstname.lastname@example.org Steven Valdez Google email@example.com
Filippo Valsorda Cloudflare Inc. firstname.lastname@example.org Thyla van der Merwe Royal Holloway, University of London email@example.com Victor Vasiliev Google firstname.lastname@example.org Hoeteck Wee Ecole Normale Superieure, Paris email@example.com Tom Weinstein David Wong NCC Group firstname.lastname@example.org Christopher A. Wood Apple Inc. email@example.com Tim Wright Vodafone firstname.lastname@example.org Peter Wu Independent email@example.com Kazu Yamamoto Internet Initiative Japan Inc. firstname.lastname@example.org