1.1.Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD","SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in thisdocument are to be interpreted as described in BCP 14[RFC2119][RFC8174]when, and only when, they appear in all capitals, as shown here.¶

The following terms are used:¶

client: The endpoint initiating the TLS connection.¶

connection: A transport-layer connection between two endpoints.¶

endpoint: Either the client or server of the connection.¶

handshake: An initial negotiation between client and server that establishes the parameters of their subsequent interactions within TLS.¶

peer: An endpoint. When discussing a particular endpoint, "peer" refers to the endpoint that is not the primary subject of discussion.¶

receiver: An endpoint that is receiving records.¶

sender: An endpoint that is transmitting records.¶

server: The endpoint that did not initiate the TLS connection.¶

1.2.Relationship to RFC 8446

TLS 1.3 was originally specified in[RFC8446]. This document issolely an editorial update. It contains updated text in areas whichwere found to be unclear as well as other editorial improvements.In addition, it removes the use of the term "master" as appliedto secrets in favor of the term "main" or shorter names where noterm was neccessary.¶

1.3.Major Differences from TLS 1.2

The following is a list of the major functional differences betweenTLS 1.2 and TLS 1.3. It is not intended to be exhaustive, and thereare many minor differences.¶

• The list of supported symmetric encryption algorithms has been pruned of all algorithms thatare considered legacy. Those that remain are all Authenticated Encryptionwith Associated Data (AEAD) algorithms. The cipher suite concept has beenchanged to separate the authentication and key exchange mechanisms fromthe record protection algorithm (including secret key length) and a hashto be used with both the key derivation function and handshake messageauthentication code (MAC).¶
• A zero round-trip time (0-RTT) mode was added, saving a round trip at connection setup forsome application data, at the cost of certain security properties.¶
• Static RSA and Diffie-Hellman cipher suites have been removed;all public-key based key exchange mechanisms now provide forward secrecy.¶
• All handshake messages after the ServerHello are now encrypted. Thenewly introduced EncryptedExtensions message allows various extensionspreviously sent in the clear in the ServerHello to also enjoyconfidentiality protection.¶
• The key derivation function has been redesigned. The new design allowseasier analysis by cryptographers due to their improved key separationproperties. The HMAC-based Extract-and-Expand Key Derivation Function (HKDF)is used as an underlying primitive.¶
• The handshake state machine has been significantly restructured tobe more consistent and to remove superfluous messages such asChangeCipherSpec (except when needed for middlebox compatibility).¶
• Elliptic curve algorithms are now in the base spec, and new signaturealgorithms, such as EdDSA, are included. TLS 1.3 removed point formatnegotiation in favor of a single point format for each curve.¶
• Other cryptographic improvements were made, including changing the RSA padding to use the RSA Probabilistic Signature Scheme (RSASSA-PSS), and the removalof compression, the Digital Signature Algorithm (DSA), and custom Ephemeral Diffie-Hellman (DHE) groups.¶
• The TLS 1.2 version negotiation mechanism has been deprecated in favorof a version list in an extension. This increases compatibility withexisting servers that incorrectly implemented version negotiation.¶
• Session resumption with and without server-side state as well as thePSK-based cipher suites of earlier TLS versions have been replaced by asingle new PSK exchange.¶
• References have been updated to point to the updated versions of RFCs, asappropriate (e.g., RFC 5280 rather than RFC 3280).¶

1.4.Updates Affecting TLS 1.2

This document defines several changes that optionally affectimplementations of TLS 1.2, including those which do not alsosupport TLS 1.3:¶

• A version downgrade protection mechanism is described inSection 4.1.3.¶
• RSASSA-PSS signature schemes are defined inSection 4.2.3.¶
• The "supported_versions" ClientHello extension can be used to negotiatethe version of TLS to use, in preference to the legacy_version field ofthe ClientHello.¶
• The "signature_algorithms_cert" extension allows a client to indicatewhich signature algorithms it can validate in X.509 certificates.¶
• The term "master" as applied to secrets has been removed, and the"extended_master_secret" extension[RFC7627] has been renamed to"extended_main_secret".¶

Additionally, this document clarifies some compliance requirements for earlierversions of TLS; seeSection 9.3.¶

2.1.Incorrect DHE Share

If the client has not provided a sufficient "key_share" extension (e.g., itincludes only DHE or ECDHE groups unacceptable to or unsupported by theserver), the server corrects the mismatch with a HelloRetryRequest andthe client needs to restart the handshake with an appropriate"key_share" extension, as shown in Figure 2.If no common cryptographic parameters can be negotiated,the server MUST abort the handshake with an appropriate alert.¶

         Client                                               Server         ClientHello         + key_share             -------->                                                   HelloRetryRequest                                 <--------               + key_share         ClientHello         + key_share             -------->                                                         ServerHello                                                         + key_share                                               {EncryptedExtensions}                                               {CertificateRequest*}                                                      {Certificate*}                                                {CertificateVerify*}                                                          {Finished}                                 <--------       [Application Data*]         {Certificate*}         {CertificateVerify*}         {Finished}              -------->         [Application Data]      <------->        [Application Data]

Note: The handshake transcript incorporates the initialClientHello/HelloRetryRequest exchange; it is not reset with the newClientHello.¶

TLS also allows several optimized variants of the basic handshake, asdescribed in the following sections.¶

2.2.Resumption and Pre-Shared Key (PSK)

Although TLS PSKs can be established externally,PSKs can also be established in a previous connection andthen used to establish a new connection ("session resumption" or "resuming" with a PSK).Once a handshake has completed, the server cansend the client a PSK identity that corresponds to a unique key derived fromthe initial handshake (seeSection 4.6.1). The clientcan then use that PSK identity in future handshakes to negotiate the useof the associated PSK. If the server accepts the PSK, then the security context of thenew connection is cryptographically tied to the original connection and the key derivedfrom the initial handshake is used to bootstrap the cryptographic stateinstead of a full handshake.In TLS 1.2 and below, this functionality was provided by "session IDs" and"session tickets"[RFC5077]. Both mechanisms are obsoleted in TLS 1.3.¶

PSKs can be used with (EC)DHE key exchange in order to provide forwardsecrecy in combination with shared keys, or can be used alone, at thecost of losing forward secrecy for the application data.¶

Figure 3 shows a pair of handshakes in which the first handshake establishesa PSK and the second handshake uses it:¶

       Client                                               ServerInitial Handshake:       ClientHello       + key_share               -------->                                                       ServerHello                                                       + key_share                                             {EncryptedExtensions}                                             {CertificateRequest*}                                                    {Certificate*}                                              {CertificateVerify*}                                                        {Finished}                                 <--------     [Application Data*]       {Certificate*}       {CertificateVerify*}       {Finished}                -------->                                 <--------      [NewSessionTicket]       [Application Data]        <------->      [Application Data]Subsequent Handshake:       ClientHello       + key_share*       + pre_shared_key          -------->                                                       ServerHello                                                  + pre_shared_key                                                      + key_share*                                             {EncryptedExtensions}                                                        {Finished}                                 <--------     [Application Data*]       {Finished}                -------->       [Application Data]        <------->      [Application Data]

As the server is authenticating via a PSK, it does not send aCertificate or a CertificateVerify message. When a client offers resumptionvia a PSK, it SHOULD also supply a "key_share" extension to the server toallow the server to decline resumption and fall backto a full handshake, if needed. The server responds with a "pre_shared_key"extension to negotiate the use of PSK key establishment and can (as shown here)respond with a "key_share" extension to do (EC)DHE key establishment, thusproviding forward secrecy.¶

When PSKs are provisioned externally, the PSK identity and the KDF hashalgorithm tobe used with the PSK MUST also be provisioned.¶

Note:

When using an externally provisioned pre-shared secret, a criticalconsideration is using sufficient entropy during the key generation, asdiscussed in[RFC4086]. Deriving a shared secret from a password or otherlow-entropy sources is not secure. A low-entropy secret, or password, issubject to dictionary attacks based on the PSK binder. The specified PSKauthentication is not a strong password-based authenticated key exchange evenwhen used with Diffie-Hellman key establishment. Specifically, it does notprevent an attacker that can observe the handshake from performinga brute-force attack on the password/pre-shared key.¶

2.3.0-RTT Data

When clients and servers share a PSK (either obtained externally orvia a previous handshake), TLS 1.3 allows clients to send data on thefirst flight ("early data"). The client uses the PSK to authenticatethe server and to encrypt the early data.¶

As shown inFigure 4, the 0-RTT data is just added to the 1-RTThandshake in the first flight. The rest of the handshake uses the same messagesas for a 1-RTT handshake with PSK resumption.¶

         Client                                               Server         ClientHello         + early_data         + key_share*         + psk_key_exchange_modes         + pre_shared_key         (Application Data*)     -------->                                                         ServerHello                                                    + pre_shared_key                                                        + key_share*                                               {EncryptedExtensions}                                                       + early_data*                                                          {Finished}                                 <--------       [Application Data*]         (EndOfEarlyData)         {Finished}              -------->         [Application Data]      <------->        [Application Data]               +  Indicates noteworthy extensions sent in the                  previously noted message.               *  Indicates optional or situation-dependent                  messages/extensions that are not always sent.               () Indicates messages protected using keys                  derived from a client_early_traffic_secret.               {} Indicates messages protected using keys                  derived from a [sender]_handshake_traffic_secret.               [] Indicates messages protected using keys                  derived from [sender]_application_traffic_secret_N.

IMPORTANT NOTE: The security properties for 0-RTT data are weaker thanthose for other kinds of TLS data. Specifically:¶

1. The protocol does not provide any forward secrecy guarantees for this data.The server's behavior determines what forward secrecy guarantees, if any, apply(seeSection 8.1). This behavior is not communicated to the clientas part of the protocol. Therefore, absent out-of-band knowledge of theserver's behavior, the client should assume that this data is not forwardsecret.¶
2. There are no guarantees of non-replay between connections.Protection against replay for ordinary TLS 1.3 1-RTT data isprovided via the server's Random value, but 0-RTT data does not dependon the ServerHello and therefore has weaker guarantees. This is especiallyrelevant if the data is authenticated either with TLS clientauthentication or inside the application protocol. The same warningsapply to any use of the early_exporter_secret.¶

0-RTT data cannot be duplicated within a connection (i.e., the server willnot process the same data twice for the same connection), and anattacker will not be able to make 0-RTT data appear to be 1-RTT data(because it is protected with different keys).Appendix F.5contains a description of potential attacks, andSection 8describes mechanisms which the server can use to limit the impact ofreplay.¶

3.1.Basic Block Size

The representation of all data items is explicitly specified. The basic datablock size is one byte (i.e., 8 bits). Multiple-byte data items areconcatenations of bytes, from left to right, from top to bottom. From the bytestream, a multi-byte item (a numeric in the following example) is formed (using Cnotation) by:¶

   value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |           ... | byte[n-1];

This byte ordering for multi-byte values is the commonplace network byte orderor big-endian format.¶

3.2.Miscellaneous

Comments begin with "/*" and end with "*/".¶

Optional components are denoted by enclosing them in "[[ ]]" (doublebrackets).¶

Single-byte entities containing uninterpreted data are of typeopaque.¶

A type alias T' for an existing type T is defined by:¶

   T T';

3.3.Numbers

The basic numeric data type is an unsigned byte (uint8). All larger numericdata types are constructed from a fixed-length series of bytes concatenated asdescribed inSection 3.1 and are also unsigned. The following numerictypes are predefined.¶

   uint8 uint16[2];   uint8 uint24[3];   uint8 uint32[4];   uint8 uint64[8];

All values, here and elsewhere in the specification, are transmitted in network byte(big-endian) order; the uint32 represented by the hex bytes 01 02 03 04 isequivalent to the decimal value 16909060.¶

3.4.Vectors

A vector (single-dimensioned array) is a stream of homogeneous data elements.For presentation purposes, this specification refers to vectors as lists.The size of the vector may be specified at documentation time or leftunspecified until runtime. In either case, the length declares the number ofbytes, not the number of elements, in the vector. The syntax for specifying anew type, T', that is a fixed-length vector of type T is¶

   T T'[n];

Here, T' occupies n bytes in the data stream, where n is a multiple of the sizeof T. The length of the vector is not included in the encoded stream.¶

In the following example, Datum is defined to be three consecutive bytes thatthe protocol does not interpret, while Data is three consecutive Datum,consuming a total of nine bytes.¶

   opaque Datum[3];      /* three uninterpreted bytes */   Datum Data[9];        /* three consecutive 3-byte vectors */

Variable-length vectors are defined by specifying a subrange of legal lengths,inclusively, using the notation <floor..ceiling>. When these are encoded, theactual length precedes the vector's contents in the byte stream. The lengthwill be in the form of a number consuming as many bytes as required to hold thevector's specified maximum (ceiling) length. A variable-length vector with anactual length field of zero is referred to as an empty vector.¶

   T T'<floor..ceiling>;

In the following example, "mandatory" is a vector that must contain between 300and 400 bytes of type opaque. It can never be empty. The actual length fieldconsumes two bytes, a uint16, which is sufficient to represent the value 400(seeSection 3.3). Similarly, "longer" can represent up to 800 bytes ofdata, or 400 uint16 elements, and it may be empty. Its encoding will include atwo-byte actual length field prepended to the vector. The length of an encodedvector must be an exact multiple of the length of a single element (e.g.,a 17-byte vector of uint16 would be illegal).¶

   opaque mandatory<300..400>;         /* length field is two bytes, cannot be empty */   uint16 longer<0..800>;         /* zero to 400 16-bit unsigned integers */

3.5.Enumerateds

An additional sparse data type, called "enum" or"enumerated", is available. Each definition is a different type. Only enumerateds ofthe same type may be assigned or compared. Every element of anenumerated must be assigned a value, as demonstrated in the followingexample. Since the elements of the enumerated are not ordered, theycan be assigned any unique value, in any order.¶

   enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;

Future extensions or additions to the protocol may define new values.Implementations need to be able to parse and ignore unknown values unless thedefinition of the field states otherwise.¶

An enumerated occupies as much space in the byte stream as would its maximaldefined ordinal value. The following definition would cause one byte to be usedto carry fields of type Color.¶

   enum { red(3), blue(5), white(7) } Color;

One may optionally specify a value without its associated tag to force thewidth definition without defining a superfluous element.¶

In the following example, Taste will consume two bytes in the data stream butcan only assume the values 1, 2, or 4 in the current version of the protocol.¶

   enum { sweet(1), sour(2), bitter(4), (32000) } Taste;

The names of the elements of an enumeration are scoped within the defined type.In the first example, a fully qualified reference to the second element of theenumeration would be Color.blue. Such qualification is not required if thetarget of the assignment is well specified.¶

   Color color = Color.blue;     /* overspecified, legal */   Color color = blue;           /* correct, type implicit */

The names assigned to enumerateds do not need to be unique. The numerical valuecan describe a range over which the same name applies. The value includes theminimum and maximum inclusive values in that range, separated by two periodcharacters. This is principally useful for reserving regions of the space.¶

   enum { sad(0), meh(1..254), happy(255) } Mood;

3.6.Constructed Types

Structure types may be constructed from primitive types for convenience. Eachspecification declares a new, unique type. The syntax used for definitions is muchlike that of C.¶

   struct {       T1 f1;       T2 f2;       ...       Tn fn;   } T;

Fixed- and variable-length list (vector) fields are allowed using the standard listsyntax. Structures V1 and V2 in the variants example (Section 3.8) demonstrate this.¶

The fields within a structure may be qualified using the type's name, with asyntax much like that available for enumerateds. For example, T.f2 refers tothe second field of the previous declaration.¶

3.7.Constants

Fields and variables may be assigned a fixed value using "=", as in:¶

   struct {       T1 f1 = 8;  /* T.f1 must always be 8 */       T2 f2;   } T;

3.8.Variants

Defined structures may have variants based on some knowledge that isavailable within the environment. The selector must be an enumeratedtype that defines the possible variants the structure defines. Eacharm of the select (below) specifies the type of that variant's field and anoptional field label. The mechanism by which the variant is selectedat runtime is not prescribed by the presentation language.¶

   struct {       T1 f1;       T2 f2;       ....       Tn fn;       select (E) {           case e1: Te1 [[fe1]];           case e2: Te2 [[fe2]];           ....           case en: Ten [[fen]];       };   } Tv;

For example:¶

   enum { apple(0), orange(1) } VariantTag;   struct {       uint16 number;       opaque string<0..10>; /* variable length */   } V1;   struct {       uint32 number;       opaque string[10];    /* fixed length */   } V2;   struct {       VariantTag type;       select (VariantRecord.type) {           case apple:  V1;           case orange: V2;       };   } VariantRecord;

4.1.Key Exchange Messages

The key exchange messages are used to determine the security capabilitiesof the client and the server and to establish shared secrets, includingthe traffic keys used to protect the rest of the handshake and the data.¶

   uint16 ProtocolVersion;   opaque Random[32];   uint8 CipherSuite[2];    /* Cryptographic suite selector */   struct {       ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */       Random random;       opaque legacy_session_id<0..32>;       CipherSuite cipher_suites<2..2^16-2>;       opaque legacy_compression_methods<1..2^8-1>;       Extension extensions<8..2^16-1>;   } ClientHello;

   struct {       ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */       Random random;       opaque legacy_session_id_echo<0..32>;       CipherSuite cipher_suite;       uint8 legacy_compression_method = 0;       Extension extensions<6..2^16-1>;   } ServerHello;

  CF 21 AD 74 E5 9A 61 11 BE 1D 8C 02 1E 65 B8 91  C2 A2 11 16 7A BB 8C 5E 07 9E 09 E2 C8 A8 33 9C

  44 4F 57 4E 47 52 44 01

  44 4F 57 4E 47 52 44 00

4.2.Extensions

A number of TLS messages contain tag-length-value encoded extensions structures.¶

   struct {       ExtensionType extension_type;       opaque extension_data<0..2^16-1>;   } Extension;   enum {       server_name(0),                             /* RFC 6066 */       max_fragment_length(1),                     /* RFC 6066 */       status_request(5),                          /* RFC 6066 */       supported_groups(10),                       /* RFC 8422, 7919 */       signature_algorithms(13),                   /* RFC 8446 */       use_srtp(14),                               /* RFC 5764 */       heartbeat(15),                              /* RFC 6520 */       application_layer_protocol_negotiation(16), /* RFC 7301 */       signed_certificate_timestamp(18),           /* RFC 6962 */       client_certificate_type(19),                /* RFC 7250 */       server_certificate_type(20),                /* RFC 7250 */       padding(21),                                /* RFC 7685 */       pre_shared_key(41),                         /* RFC 8446 */       early_data(42),                             /* RFC 8446 */       supported_versions(43),                     /* RFC 8446 */       cookie(44),                                 /* RFC 8446 */       psk_key_exchange_modes(45),                 /* RFC 8446 */       certificate_authorities(47),                /* RFC 8446 */       oid_filters(48),                            /* RFC 8446 */       post_handshake_auth(49),                    /* RFC 8446 */       signature_algorithms_cert(50),              /* RFC 8446 */       key_share(51),                              /* RFC 8446 */       (65535)   } ExtensionType;

Here:¶

• "extension_type" identifies the particular extension type.¶
• "extension_data" contains information specific to the particularextension type.¶

The contents of the "extension_data" field are typically defined by anextension-specific structure defined in the TLS presentation language. Unlessotherwise specified, trailing data is forbidden. That is, senders MUST NOTinclude data after the structure in the "extension_data" field. Whenprocessing an extension, receivers MUST abort the handshake with a"decode_error" alert if there is data left over after parsing the structure.This does not apply if the receiver does not implement or is configured toignore an extension.¶

The list of extension types is maintained by IANA as described inSection 11.¶

Extensions are generally structured in a request/response fashion,though some extensions are just requests with no correspondingresponse (i.e., indications). The client sends its extension requestsin the ClientHello message, and the server sends its extensionresponses in the ServerHello, EncryptedExtensions, HelloRetryRequest,and Certificate messages. The server sends extension requests in theCertificateRequest message which a client MAY respond to with aCertificate message. The server MAY also send unsolicited extensionsin the NewSessionTicket, though the client does not respond directlyto these.¶

Implementations MUST NOT send extension responsesif the remote endpoint did not send the corresponding extension requests,with the exception of the "cookie" extension in the HelloRetryRequest.Upon receiving such an extension, an endpoint MUST abort the handshake with an"unsupported_extension" alert.¶

The table below indicates the messages where a given extension mayappear, using the following notation: CH (ClientHello), SH(ServerHello), EE (EncryptedExtensions), CT (Certificate), CR(CertificateRequest), NST (NewSessionTicket), and HRR(HelloRetryRequest). If an implementation receives an extension whichit recognizes and which is not specified for the message in which itappears, it MUST abort the handshake with an "illegal_parameter" alert.¶

When multiple extensions of different types are present, theextensions MAY appear in any order, with the exception of"pre_shared_key" (Section 4.2.11) which MUST bethe last extension in the ClientHello (but can appear anywhere inthe ServerHello extensions block).There MUST NOT be more than one extension of the same type in a givenextension block.¶

In TLS 1.3, unlike TLS 1.2, extensions are negotiated for eachhandshake even when in resumption-PSK mode. However, 0-RTT parameters arethose negotiated in the previous handshake; mismatches may requirerejecting 0-RTT (seeSection 4.2.10).¶

There are subtle (and not so subtle) interactions that may occur in thisprotocol between new features and existing features which may result in asignificant reduction in overall security. The following considerations shouldbe taken into account when designing new extensions:¶

• Some cases where a server does not agree to an extension are errorconditions (e.g., the handshake cannot continue), and some aresimply refusals to support particular features. In general, erroralerts should be used for the former and a field in the serverextension response for the latter.¶
• Extensions should, as far as possible, be designed to prevent any attack thatforces use (or non-use) of a particular feature by manipulation of handshakemessages. This principle should be followed regardless of whether the featureis believed to cause a security problem.Often the fact that the extension fields are included in the inputs to theFinished message hashes will be sufficient, but extreme care is needed whenthe extension changes the meaning of messages sent in the handshake phase.Designers and implementors should be aware of the fact that until thehandshake has been authenticated, active attackers can modify messages andinsert, remove, or replace extensions.¶

   struct {       select (Handshake.msg_type) {           case client_hello:                ProtocolVersion versions<2..254>;           case server_hello: /* and HelloRetryRequest */                ProtocolVersion selected_version;       };   } SupportedVersions;

   struct {       opaque cookie<1..2^16-1>;   } Cookie;

   enum {       /* RSASSA-PKCS1-v1_5 algorithms */       rsa_pkcs1_sha256(0x0401),       rsa_pkcs1_sha384(0x0501),       rsa_pkcs1_sha512(0x0601),       /* ECDSA algorithms */       ecdsa_secp256r1_sha256(0x0403),       ecdsa_secp384r1_sha384(0x0503),       ecdsa_secp521r1_sha512(0x0603),       /* RSASSA-PSS algorithms with public key OID rsaEncryption */       rsa_pss_rsae_sha256(0x0804),       rsa_pss_rsae_sha384(0x0805),       rsa_pss_rsae_sha512(0x0806),       /* EdDSA algorithms */       ed25519(0x0807),       ed448(0x0808),       /* RSASSA-PSS algorithms with public key OID RSASSA-PSS */       rsa_pss_pss_sha256(0x0809),       rsa_pss_pss_sha384(0x080a),       rsa_pss_pss_sha512(0x080b),       /* Legacy algorithms */       rsa_pkcs1_sha1(0x0201),       ecdsa_sha1(0x0203),       /* Reserved Code Points */       private_use(0xFE00..0xFFFF),       (0xFFFF)   } SignatureScheme;   struct {       SignatureScheme supported_signature_algorithms<2..2^16-2>;   } SignatureSchemeList;

   opaque DistinguishedName<1..2^16-1>;   struct {       DistinguishedName authorities<3..2^16-1>;   } CertificateAuthoritiesExtension;

   struct {       opaque certificate_extension_oid<1..2^8-1>;       opaque certificate_extension_values<0..2^16-1>;   } OIDFilter;   struct {       OIDFilter filters<0..2^16-1>;   } OIDFilterExtension;

   struct {} PostHandshakeAuth;

   enum {       /* Elliptic Curve Groups (ECDHE) */       secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),       x25519(0x001D), x448(0x001E),       /* Finite Field Groups (DHE) */       ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),       ffdhe6144(0x0103), ffdhe8192(0x0104),       /* Reserved Code Points */       ffdhe_private_use(0x01FC..0x01FF),       ecdhe_private_use(0xFE00..0xFEFF),       (0xFFFF)   } NamedGroup;   struct {       NamedGroup named_group_list<2..2^16-1>;   } NamedGroupList;

   struct {       NamedGroup group;       opaque key_exchange<1..2^16-1>;   } KeyShareEntry;

   struct {       KeyShareEntry client_shares<0..2^16-1>;   } KeyShareClientHello;

   struct {       NamedGroup selected_group;   } KeyShareHelloRetryRequest;

   struct {       KeyShareEntry server_share;   } KeyShareServerHello;

   struct {       uint8 legacy_form = 4;       opaque X[coordinate_length];       opaque Y[coordinate_length];   } UncompressedPointRepresentation;

   enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;   struct {       PskKeyExchangeMode ke_modes<1..255>;   } PskKeyExchangeModes;

   struct {} Empty;   struct {       select (Handshake.msg_type) {           case new_session_ticket:   uint32 max_early_data_size;           case client_hello:         Empty;           case encrypted_extensions: Empty;       };   } EarlyDataIndication;

   struct {       opaque identity<1..2^16-1>;       uint32 obfuscated_ticket_age;   } PskIdentity;   opaque PskBinderEntry<32..255>;   struct {       PskIdentity identities<7..2^16-1>;       PskBinderEntry binders<33..2^16-1>;   } OfferedPsks;   struct {       select (Handshake.msg_type) {           case client_hello: OfferedPsks;           case server_hello: uint16 selected_identity;       };   } PreSharedKeyExtension;

   Transcript-Hash(Truncate(ClientHello1))

   Transcript-Hash(ClientHello1,                   HelloRetryRequest,                   Truncate(ClientHello2))

4.3.Server Parameters

The next two messages from the server, EncryptedExtensions andCertificateRequest, contain information from the serverthat determines the rest of the handshake. These messagesare encrypted with keys derived from the server_handshake_traffic_secret.¶

   struct {       Extension extensions<0..2^16-1>;   } EncryptedExtensions;

   struct {       opaque certificate_request_context<0..2^8-1>;       Extension extensions<0..2^16-1>;   } CertificateRequest;

4.4.Authentication Messages

As discussed inSection 2, TLS generally uses a commonset of messages for authentication, key confirmation, and handshakeintegrity: Certificate, CertificateVerify, and Finished.(The PSK binders also perform key confirmation, in asimilar fashion.) These threemessages are always sent as the last messages in their handshakeflight. The Certificate and CertificateVerify messages are onlysent under certain circumstances, as defined below. The Finishedmessage is always sent as part of the Authentication Block.These messages are encrypted under keys derived from the[sender]_handshake_traffic_secret.¶

The computations for the Authentication messages all uniformlytake the following inputs:¶

• The certificate and signing key to be used.¶
• A Handshake Context consisting of the list of messages to beincluded in the transcript hash.¶
• A Base Key to be used to compute a MAC key.¶

Based on these inputs, the messages then contain:¶

Certificate

The certificate to be used for authentication, and anysupporting certificates in the chain. Note that certificate-basedclient authentication is not available in PSK handshake flows(including 0-RTT).¶

CertificateVerify:

A signature over the value Transcript-Hash(Handshake Context, Certificate)¶

Finished:

A MAC over the value Transcript-Hash(Handshake Context, Certificate, CertificateVerify)using a MAC key derived from the Base Key.¶

The following table defines the Handshake Context and MAC Base Keyfor each scenario:¶

 Transcript-Hash(M1, M2, ... Mn) = Hash(M1 || M2 || ... || Mn)

 Transcript-Hash(ClientHello1, HelloRetryRequest, ... Mn) =     Hash(message_hash ||        /* Handshake type */          00 00 Hash.length  ||   /* Handshake message length (bytes) */          Hash(ClientHello1) ||  /* Hash of ClientHello1 */          HelloRetryRequest  || ... || Mn)

   enum {       X509(0),       RawPublicKey(2),       (255)   } CertificateType;   struct {       select (certificate_type) {           case RawPublicKey:             /* From RFC 7250 ASN.1_subjectPublicKeyInfo */             opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;           case X509:             opaque cert_data<1..2^24-1>;       };       Extension extensions<0..2^16-1>;   } CertificateEntry;   struct {       opaque certificate_request_context<0..2^8-1>;       CertificateEntry certificate_list<0..2^24-1>;   } Certificate;

   struct {       SignatureScheme algorithm;       opaque signature<0..2^16-1>;   } CertificateVerify;

   Transcript-Hash(Handshake Context, Certificate)

   2020202020202020202020202020202020202020202020202020202020202020   2020202020202020202020202020202020202020202020202020202020202020   544c5320312e332c207365727665722043657274696669636174655665726966   79   00   0101010101010101010101010101010101010101010101010101010101010101

finished_key =    HKDF-Expand-Label(BaseKey, "finished", "", Hash.length)

   struct {       opaque verify_data[Hash.length];   } Finished;

   verify_data =       HMAC(finished_key,            Transcript-Hash(Handshake Context,                            Certificate*, CertificateVerify*))   * Only included if present.

4.5.End of Early Data

   struct {} EndOfEarlyData;

If the server sent an "early_data" extension in EncryptedExtensions, the client MUST send anEndOfEarlyData message after receiving the server Finished. If the server doesnot send an "early_data" extension in EncryptedExtensions, then the client MUST NOT send anEndOfEarlyData message. This message indicates that all0-RTT application_data messages, if any, have been transmitted andthat the following records are protected under handshake traffic keys.Servers MUST NOT send this message, and clients receiving itMUST terminate the connection with an "unexpected_message" alert.This message is encrypted under keys derived from the client_early_traffic_secret.¶

4.6.Post-Handshake Messages

TLS also allows other messages to be sent after the main handshake.These messages use a handshake content type and are encrypted under theappropriate application traffic key.¶

   struct {       uint32 ticket_lifetime;       uint32 ticket_age_add;       opaque ticket_nonce<0..255>;       opaque ticket<1..2^16-1>;       Extension extensions<0..2^16-1>;   } NewSessionTicket;

    HKDF-Expand-Label(resumption_secret,                      "resumption", ticket_nonce, Hash.length)

   enum {       update_not_requested(0), update_requested(1), (255)   } KeyUpdateRequest;   struct {       KeyUpdateRequest request_update;   } KeyUpdate;

5.1.Record Layer

The record layer fragments information blocks into TLSPlaintextrecords carrying data in chunks of 2^14 bytes or less. Messageboundaries are handled differently depending on the underlyingContentType. Any future content types MUST specify appropriaterules.Note that these rules are stricter than what was enforced in TLS 1.2.¶

Handshake messages MAY be coalesced into a single TLSPlaintextrecord or fragmented across several records, provided that:¶

• Handshake messages MUST NOT be interleaved with other recordtypes. That is, if a handshake message is split over two or morerecords, there MUST NOT be any other records between them.¶
• Handshake messages MUST NOT span key changes. Implementations MUST verify thatall messages immediately preceding a key change align with a record boundary;if not, then they MUST terminate the connection with an "unexpected_message"alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, andKeyUpdate messages can immediately precede a key change, implementations MUSTsend these messages in alignment with a record boundary.¶

Implementations MUST NOT send zero-length fragments of Handshaketypes, even if those fragments contain padding.¶

Alert messages (Section 6) MUST NOT be fragmented acrossrecords, and multiple alert messages MUST NOT be coalesced into asingle TLSPlaintext record. In other words, a record with an Alerttype MUST contain exactly one message.¶

Application Data messages contain data that is opaque toTLS. Application Data messages are always protected. Zero-lengthfragments of Application Data MAY be sent, as they are potentiallyuseful as a traffic analysis countermeasure. Application Data fragmentsMAY be split across multiple records or coalesced into a single record.¶

   enum {       invalid(0),       change_cipher_spec(20),       alert(21),       handshake(22),       application_data(23),       (255)   } ContentType;   struct {       ContentType type;       ProtocolVersion legacy_record_version;       uint16 length;       opaque fragment[TLSPlaintext.length];   } TLSPlaintext;

type:

The higher-level protocol used to process the enclosed fragment.¶

legacy_record_version:

MUST be set to 0x0303 for all records generated by aTLS 1.3 implementation other than an initial ClientHello (i.e., onenot generated after a HelloRetryRequest), where itMAY also be 0x0301 for compatibility purposes.This field is deprecated and MUST be ignored for all purposes.Previous versions of TLS would use other values in this fieldunder some circumstances.¶

length:

The length (in bytes) of the following TLSPlaintext.fragment. Thelength MUST NOT exceed 2^14 bytes. An endpoint that receives a recordthat exceeds this length MUST terminate the connection with a"record_overflow" alert.¶

fragment

The data being transmitted. This value is transparent and is treated as anindependent block to be dealt with by the higher-level protocolspecified by the type field.¶

This document describes TLS 1.3, which uses the version 0x0304.This version value is historical, deriving from the use of 0x0301for TLS 1.0 and 0x0300 for SSL 3.0. In order to maximize backwardcompatibility, a record containing an initial ClientHello SHOULD have version0x0301 (reflecting TLS 1.0) and a record containing a second ClientHello ora ServerHello MUST have version0x0303 (reflecting TLS 1.2).When negotiating prior versions of TLS, endpointsfollow the procedure and requirements provided inAppendix E.¶

When record protection has not yet been engaged, TLSPlaintextstructures are written directly onto the wire. Once record protectionhas started, TLSPlaintext records are protected and sent asdescribed in the following section. Note that Application Datarecords MUST NOT be written to the wire unprotected (seeSection 2 for details).¶

5.2.Record Payload Protection

The record protection functions translate a TLSPlaintext structure into aTLSCiphertext structure. The deprotection functions reverse the process. In TLS 1.3,as opposed to previous versions of TLS, all ciphers are modeled as"Authenticated Encryption with Associated Data" (AEAD)[RFC5116].AEAD functions provide a unified encryption and authenticationoperation which turns plaintext into authenticated ciphertext andback again. Each encrypted record consists of a plaintext header followedby an encrypted body, which itself contains a type and optional padding.¶

   struct {       opaque content[TLSPlaintext.length];       ContentType type;       uint8 zeros[length_of_padding];   } TLSInnerPlaintext;   struct {       ContentType opaque_type = application_data; /* 23 */       ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */       uint16 length;       opaque encrypted_record[TLSCiphertext.length];   } TLSCiphertext;

content:

The TLSPlaintext.fragment value, containing the byte encoding of ahandshake or an alert message, or the raw bytes of the application'sdata to send.¶

type:

The TLSPlaintext.type value containing the content type of the record.¶

zeros:

An arbitrary-length run of zero-valued bytes mayappear in the cleartext after the type field. This provides anopportunity for senders to pad any TLS record by a chosen amount aslong as the total stays within record size limits. SeeSection 5.4 for more details.¶

opaque_type:

The outer opaque_type field of a TLSCiphertext record is always set to thevalue 23 (application_data) for outward compatibility withmiddleboxes accustomed to parsing previous versions of TLS. Theactual content type of the record is found in TLSInnerPlaintext.type afterdecryption.¶

legacy_record_version:

The legacy_record_version field is always 0x0303. TLS 1.3 TLSCiphertextsare not generated until after TLS 1.3 has been negotiated, so there areno historical compatibility concerns where other values might be received.Note that the handshake protocol, including the ClientHello and ServerHellomessages, authenticates the protocol version, so this value is redundant.¶

length:

The length (in bytes) of the following TLSCiphertext.encrypted_record, whichis the sum of the lengths of the content and the padding, plus onefor the inner content type, plus any expansion added by the AEAD algorithm.The length MUST NOT exceed 2^14 + 256 bytes.An endpoint that receives a record that exceeds this length MUSTterminate the connection with a "record_overflow" alert.¶

encrypted_record:

The AEAD-encrypted form of the serialized TLSInnerPlaintext structure.¶

AEAD algorithms take as input a single key, a nonce, a plaintext, and "additionaldata" to be included in the authentication check, as described in Section 2.1of[RFC5116]. The key is either the client_write_key or the server_write_key,the nonce is derived from the sequence number and theclient_write_iv or server_write_iv (seeSection 5.3), and the additional data input is therecord header. I.e.,¶

   additional_data = TLSCiphertext.opaque_type ||                     TLSCiphertext.legacy_record_version ||                     TLSCiphertext.length

The plaintext input to the AEAD algorithm is the encoded TLSInnerPlaintext structure.Derivation of traffic keys is defined inSection 7.3.¶

The AEAD output consists of the ciphertext output from the AEADencryption operation. The length of the plaintext is greater than thecorresponding TLSPlaintext.length due to the inclusion of TLSInnerPlaintext.type andany padding supplied by the sender. The length of theAEAD output will generally be larger than the plaintext, but by anamount that varies with the AEAD algorithm. Since the ciphers mightincorporate padding, the amount of overhead could vary with differentlengths of plaintext. Symbolically,¶

   AEADEncrypted =       AEAD-Encrypt(write_key, nonce, additional_data, plaintext)

The encrypted_record field of TLSCiphertext is set to AEADEncrypted.¶

In order to decrypt and verify, the cipher takes as input the key, nonce,additional data, and the AEADEncrypted value. The output is either the plaintextor an error indicating that the decryption failed. There is no separateintegrity check. Symbolically,¶

   plaintext of encrypted_record =       AEAD-Decrypt(peer_write_key, nonce, additional_data, AEADEncrypted)

If the decryption fails, the receiver MUST terminate the connectionwith a "bad_record_mac" alert.¶

An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion greater than255 octets. An endpoint that receives a record from its peer withTLSCiphertext.length larger than 2^14 + 256 octets MUST terminatethe connection with a "record_overflow" alert.This limit is derived from the maximum TLSInnerPlaintext length of2^14 octets + 1 octet for ContentType + the maximum AEAD expansion of 255 octets.¶

5.3.Per-Record Nonce

A 64-bit sequence number is maintained separately for reading and writingrecords. The appropriate sequence number is incremented by one afterreading or writing each record. Each sequence number is set to zeroat the beginning of a connection and whenever the key is changed; thefirst record transmitted under a particular traffic key MUST usesequence number 0.¶

Because the size of sequence numbers is 64-bit, they should notwrap. If a TLS implementation would need towrap a sequence number, it MUST either rekey (Section 4.6.3) orterminate the connection.¶

Each AEAD algorithm will specify a range of possible lengths for theper-record nonce, from N_MIN bytes to N_MAX bytes of input[RFC5116].The length of the TLS per-record nonce (iv_length) is set to the larger of8 bytes and N_MIN for the AEAD algorithm (see[RFC5116], Section 4).An AEAD algorithm where N_MAX is less than 8 bytes MUST NOT be used with TLS.The per-record nonce for the AEAD construction is formed as follows:¶

1. The 64-bit record sequence number is encoded in network byte orderand padded to the left with zeros to iv_length.¶
2. The padded sequence number is XORed with either the static client_write_ivor server_write_iv (depending on the role).¶

The resulting quantity (of length iv_length) is used as the per-record nonce.¶

Note: This is a different construction from that in TLS 1.2, whichspecified a partially explicit nonce.¶

5.4.Record Padding

All encrypted TLS records can be padded to inflate the size of theTLSCiphertext. This allows the sender to hide the size of thetraffic from an observer.¶

When generating a TLSCiphertext record, implementations MAY choose to pad.An unpadded record is just a record with a padding length of zero.Padding is a string of zero-valued bytes appended to the ContentTypefield before encryption. Implementations MUST set the padding octetsto all zeros before encrypting.¶

Application Data records may contain a zero-length TLSInnerPlaintext.content ifthe sender desires. This permits generation of plausibly sized covertraffic in contexts where the presence or absence of activity may besensitive. Implementations MUST NOT send Handshake and Alert recordsthat have a zero-length TLSInnerPlaintext.content; if such a messageis received, the receiving implementation MUST terminate the connectionwith an "unexpected_message" alert.¶

The padding sent is automatically verified by the record protectionmechanism; upon successful decryption of a TLSCiphertext.encrypted_record,the receiving implementation scans the field from the end toward thebeginning until it finds a non-zero octet. This non-zero octet is thecontent type of the message.This padding scheme was selected because it allows padding of any encryptedTLS record by an arbitrary size (from zero up to TLS record sizelimits) without introducing new content types. The design alsoenforces all-zero padding octets, which allows for quick detection ofpadding errors.¶

Implementations MUST limit their scanning to the cleartext returnedfrom the AEAD decryption. If a receiving implementation does not finda non-zero octet in the cleartext, it MUST terminate theconnection with an "unexpected_message" alert.¶

The presence of padding does not change the overall record size limitations:the full encoded TLSInnerPlaintext MUST NOT exceed 2^14 + 1 octets. If themaximum fragment length is reduced -- as for example by the record_size_limitextension from[RFC8449] -- then the reduced limit applies to the full plaintext,including the content type and padding.¶

Selecting a padding policy that suggests when and how much to pad is acomplex topic and is beyond the scope of this specification. If theapplication-layer protocol on top of TLS has its own padding, it may bepreferable to pad Application Data TLS records within the applicationlayer. Padding for encrypted Handshake or Alert records muststill be handled at the TLS layer, though. Later documents may definepadding selection algorithms or define a padding policy requestmechanism through TLS extensions or some other means.¶

5.5.Limits on Key Usage

There are cryptographic limits on the amount of plaintext which can besafely encrypted under a given set of keys.[AEAD-LIMITS] providesan analysis of these limits under the assumption that the underlyingprimitive (AES or ChaCha20) has no weaknesses. Implementations SHOULDdo a key update as described inSection 4.6.3 prior to reaching these limits.¶

For AES-GCM, up to 2^24.5 full-size records (about 24 million)may be encrypted on a given connection while keeping a safetymargin of approximately 2^-57 for Authenticated Encryption (AE) security.For ChaCha20/Poly1305, the record sequence number would wrap before thesafety limit is reached.¶

6.1.Closure Alerts

The client and the server must share knowledge that the connection is ending inorder to avoid a truncation attack.¶

close_notify:

This alert notifies the recipient that the sender will not sendany more messages on this connection. Any data received after aclosure alert has been received MUST be ignored.¶

user_canceled:

This alert notifies the recipient that the sender is canceling thehandshake for some reason unrelated to a protocol failure. If a usercancels an operation after the handshake is complete, just closing theconnection by sending a "close_notify" is more appropriate. This alertSHOULD be followed by a "close_notify". This alert generallyhas AlertLevel=warning.¶

Either party MAY initiate a close of its write side of the connection bysending a "close_notify" alert. Any data received after a closure alert hasbeen received MUST be ignored. If a transport-level close is received priorto a "close_notify", the receiver cannot know that all the data that was senthas been received.¶

Each party MUST send a "close_notify" alert before closing its write sideof the connection, unless it has already sent some error alert. Thisdoes not have any effect on its read side of the connection. Note that this isa change from versions of TLS prior to TLS 1.3 in which implementations wererequired to react to a "close_notify" by discarding pending writes andsending an immediate "close_notify" alert of their own. That previousrequirement could cause truncation in the read side. Both parties need notwait to receive a "close_notify" alert before closing their read side of theconnection, though doing so would introduce the possibility of truncation.¶

If the application protocol using TLS provides that any data may be carriedover the underlying transport after the TLS connection is closed, the TLSimplementation MUST receive a "close_notify" alert before indicatingend-of-data to the application layer. No part of thisstandard should be taken to dictate the manner in which a usage profile for TLSmanages its data transport, including when connections are opened or closed.¶

Note: It is assumed that closing the write side of a connection reliablydelivers pending data before destroying the transport.¶

6.2.Error Alerts

Error handling in TLS is very simple. When anerror is detected, the detecting party sends a message to itspeer. Upon transmission or receipt of a fatal alert message, bothparties MUST immediately close the connection.¶

Whenever an implementation encounters a fatal error condition, itSHOULD send an appropriate fatal alert and MUST close the connectionwithout sending or receiving any additional data. Throughout thisspecification, when the phrases "terminate the connection" and "abort thehandshake" are used without a specific alert it means that theimplementation SHOULD send the alert indicated by the descriptionsbelow. The phrases "terminate the connection with an X alert" and"abort the handshake with an X alert" mean that the implementationMUST send alert X if it sends any alert. Allalerts defined below in this section, as well as all unknown alerts,are universally considered fatal as of TLS 1.3 (seeSection 6).The implementation SHOULD provide a way to facilitate loggingthe sending and receiving of alerts.¶

The following error alerts are defined:¶

unexpected_message:

An inappropriate message (e.g., the wrong handshake message, prematureApplication Data, etc.) was received. This alert should never beobserved in communication between proper implementations.¶

bad_record_mac:

This alert is returned if a record is received which cannot bedeprotected. Because AEAD algorithms combine decryption andverification, and also to avoid side-channel attacks,this alert is used for all deprotection failures.This alert should never be observed in communication betweenproper implementations, except when messages were corruptedin the network.¶

record_overflow:

A TLSCiphertext record was received that had a length more than2^14 + 256 bytes, or a record decrypted to a TLSPlaintext recordwith more than 2^14 bytes (or some other negotiated limit).This alert should never be observed in communication betweenproper implementations, except when messages were corruptedin the network.¶

handshake_failure:

Receipt of a "handshake_failure" alert message indicates that thesender was unable to negotiate an acceptable set of securityparameters given the options available.¶

bad_certificate:

A certificate was corrupt, contained signatures that did notverify correctly, etc.¶

unsupported_certificate:

A certificate was of an unsupported type.¶

certificate_revoked:

A certificate was revoked by its signer.¶

certificate_expired:

A certificate has expired or is not currently valid.¶

certificate_unknown:

Some other (unspecified) issue arose in processing thecertificate, rendering it unacceptable.¶

illegal_parameter:

A field in the handshake was incorrect or inconsistent withother fields. This alert is used for errors which conform tothe formal protocol syntax but are otherwise incorrect.¶

unknown_ca:

A valid certificate chain or partial chain was received, but thecertificate was not accepted because the CA certificate could notbe located or could not be matched with a known trust anchor.¶

access_denied:

A valid certificate or PSK was received, but when access control wasapplied, the sender decided not to proceed with negotiation.¶

decode_error:

A message could not be decoded because some field was out of thespecified range or the length of the message was incorrect.This alert is used for errors where the message does not conformto the formal protocol syntax.This alert should never be observed in communication betweenproper implementations, except when messages were corruptedin the network.¶

decrypt_error:

A handshake (not record layer) cryptographic operation failed, including being unableto correctly verify a signature or validate a Finished messageor a PSK binder.¶

protocol_version:

The protocol version the peer has attempted to negotiate isrecognized but not supported (seeAppendix E).¶

insufficient_security:

Returned instead of "handshake_failure" when a negotiation hasfailed specifically because the server requires parameters moresecure than those supported by the client.¶

internal_error:

An internal error unrelated to the peer or the correctness of theprotocol (such as a memory allocation failure) makes it impossibleto continue.¶

inappropriate_fallback:

Sent by a server in response to an invalid connection retry attemptfrom a client (see[RFC7507]).¶

missing_extension:

Sent by endpoints that receive a handshake message not containing anextension that is mandatory to send for the offered TLS versionor other negotiated parameters.¶

unsupported_extension:

Sent by endpoints receiving any handshake message containing an extensionknown to be prohibited for inclusion in the given handshake message, or includingany extensions in a ServerHello or Certificate not first offered in thecorresponding ClientHello or CertificateRequest.¶

unrecognized_name:

Sent by servers when no server exists identified by the nameprovided by the client via the "server_name" extension(see[RFC6066]).¶

bad_certificate_status_response:

Sent by clients when an invalid or unacceptable OCSP response isprovided by the server via the "status_request" extension(see[RFC6066]).¶

unknown_psk_identity:

Sent by servers when PSK key establishment is desired but no acceptable PSK identity is provided by the client. Sending this alert is OPTIONAL; servers MAY instead choose to send a "decrypt_error" alert to merely indicate an invalid PSK identity.¶

certificate_required:

Sent by servers when a client certificate is desired but none was provided bythe client.¶

no_application_protocol:

Sent by servers when a client"application_layer_protocol_negotiation" extension advertisesonly protocols that the server does not support(see[RFC7301]).¶

New Alert values are assigned by IANA as described inSection 11.¶

7.1.Key Schedule

The key derivation process makes use of the HKDF-Extract and HKDF-Expandfunctions as defined for HKDF[RFC5869], as well as the functionsdefined below:¶

    HKDF-Expand-Label(Secret, Label, Context, Length) =         HKDF-Expand(Secret, HkdfLabel, Length)    Where HkdfLabel is specified as:    struct {        uint16 length = Length;        opaque label<7..255> = "tls13 " + Label;        opaque context<0..255> = Context;    } HkdfLabel;    Derive-Secret(Secret, Label, Messages) =         HKDF-Expand-Label(Secret, Label,                           Transcript-Hash(Messages), Hash.length)

The Hash function used by Transcript-Hash and HKDF is the cipher suite hashalgorithm.Hash.length is its output length in bytes. Messages is the concatenation of theindicated handshake messages, including the handshake message typeand length fields, but not including record layer headers. Note thatin some cases a zero-length Context (indicated by "") is passed toHKDF-Expand-Label. The labels specified in this document are allASCII strings and do not include a trailing NUL byte.¶

Note: With common hash functions, any label longer than 12 charactersrequires an additional iteration of the hash function to compute.The labels in this specification have all been chosen to fit withinthis limit.¶

Keys are derived from two input secrets usingthe HKDF-Extract and Derive-Secret functions. The general patternfor adding a new secret is to use HKDF-Extract with the Saltbeing the current secret state and the Input Keying Material (IKM) being the newsecret to be added. In this version of TLS 1.3, the twoinput secrets are:¶

• PSK (a pre-shared key established externally or derived fromthe resumption_secret value from a previous connection)¶
• (EC)DHE shared secret (Section 7.4)¶

This produces a full key derivation schedule shown in the diagram below.In this diagram, the following formatting conventions apply:¶

• HKDF-Extract is drawn as taking the Salt argument from the top andthe IKM argument from the left, with its output to the bottom andthe name of the output on the right.¶
• Derive-Secret's Secret argument is indicated by the incomingarrow. For instance, the Early Secret is the Secret forgenerating the client_early_traffic_secret.¶
• "0" indicates a string of Hash.length bytes set to zero.¶

Note: the key derivation labels use the string "master" even thoughthe values are referred to as "main" secrets. This mismatch is aresult of renaming the values while retaining compatibility.¶

[[OPEN ISSUE: Replace the strings with hex value?]]¶

                 0                 |                 v   PSK ->  HKDF-Extract = Early Secret                 |                 +-----> Derive-Secret(.,                 |                     "ext binder" |                 |                     "res binder",                 |                     "")                 |                     = binder_key                 |                 +-----> Derive-Secret(., "c e traffic",                 |                     ClientHello)                 |                     = client_early_traffic_secret                 |                 +-----> Derive-Secret(., "e exp master",                 |                     ClientHello)                 |                     = early_exporter_secret                 v           Derive-Secret(., "derived", "")                 |                 v(EC)DHE -> HKDF-Extract = Handshake Secret                 |                 +-----> Derive-Secret(., "c hs traffic",                 |                     ClientHello...ServerHello)                 |                     = client_handshake_traffic_secret                 |                 +-----> Derive-Secret(., "s hs traffic",                 |                     ClientHello...ServerHello)                 |                     = server_handshake_traffic_secret                 v           Derive-Secret(., "derived", "")                 |                 v      0 -> HKDF-Extract = Main Secret                 |                 +-----> Derive-Secret(., "c ap traffic",                 |                     ClientHello...server Finished)                 |                     = client_application_traffic_secret_0                 |                 +-----> Derive-Secret(., "s ap traffic",                 |                     ClientHello...server Finished)                 |                     = server_application_traffic_secret_0                 |                 +-----> Derive-Secret(., "exp master",                 |                     ClientHello...server Finished)                 |                     = exporter_secret                 |                 +-----> Derive-Secret(., "res master",                                       ClientHello...client Finished)                                       = resumption_secret

The general pattern here is that the secrets shown down the left sideof the diagram are just raw entropy without context, whereas thesecrets down the right side include Handshake Context and thereforecan be used to derive working keys without additional context.Note that the differentcalls to Derive-Secret may take different Messages arguments,even with the same secret. In a 0-RTT exchange, Derive-Secret iscalled with four distinct transcripts; in a 1-RTT-only exchange,it is called with three distinct transcripts.¶

If a given secret is not available, then the 0-value consisting ofa string of Hash.length bytes set to zeros is used. Note that this does not mean skippingrounds, so if PSK is not in use, Early Secret will still beHKDF-Extract(0, 0). For the computation of the binder_key, the label is"ext binder" for external PSKs (those provisioned outside of TLS)and "res binder" for resumption PSKs (those provisioned as the resumptionsecret of a previous handshake). The different labels preventthe substitution of one type of PSK for the other.¶

There are multiple potential Early Secret values, depending onwhich PSK the server ultimately selects. The client will need to computeone for each potential PSK; if no PSK is selected, it will then need tocompute the Early Secret corresponding to the zero PSK.¶

Once all the values which are to be derived from a given secret havebeen computed, that secret SHOULD be erased.¶

7.2.Updating Traffic Secrets

Once the handshake is complete, it is possible for either side toupdate its sending traffic keys using the KeyUpdate handshake messagedefined inSection 4.6.3. The next generation of traffic keys is computed bygenerating client_/server_application_traffic_secret_N+1 fromclient_/server_application_traffic_secret_N as described inthis section and then re-deriving the traffic keys as described inSection 7.3.¶

The next-generation application_traffic_secret is computed as:¶

    application_traffic_secret_N+1 =        HKDF-Expand-Label(application_traffic_secret_N,                          "traffic upd", "", Hash.length)

Once client_/server_application_traffic_secret_N+1 and its associatedtraffic keys have been computed, implementations SHOULD deleteclient_/server_application_traffic_secret_N and its associated traffic keys.¶

7.3.Traffic Key Calculation

The traffic keying material is generated from the following input values:¶

• A secret value¶
• A purpose value indicating the specific value being generated¶
• The length of the key being generated¶

The traffic keying material is generated from an input traffic secret value using:¶

    [sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length)    [sender]_write_iv  = HKDF-Expand-Label(Secret, "iv", "", iv_length)

[sender] denotes the sending side. The value of Secret for each record typeis shown in the table below.¶

All the traffic keying material is recomputed whenever theunderlying Secret changes (e.g., when changing from the handshake toApplication Data keys or upon a key update).¶

7.4.(EC)DHE Shared Secret Calculation

7.5.Exporters

[RFC5705] defines keying material exporters for TLS in terms of the TLSpseudorandom function (PRF). This document replaces the PRF with HKDF, thusrequiring a new construction. The exporter interface remains the same.¶

The exporter value is computed as:¶

TLS-Exporter(label, context_value, key_length) =    HKDF-Expand-Label(Derive-Secret(Secret, label, ""),                      "exporter", Hash(context_value), key_length)

Where Secret is either the early_exporter_secret or theexporter_secret. Implementations MUST use the exporter_secret unlessexplicitly specified by the application. The early_exporter_secret isdefined for use in settings where an exporter is needed for 0-RTT data.A separate interface for the early exporter is RECOMMENDED; this avoidsthe exporter user accidentally using an early exporter when a regularone is desired or vice versa.¶

If no context is provided, the context_value is zero length. Consequently,providing no context computes the same value as providing an empty context.This is a change from previous versions of TLS where an empty context produced adifferent output than an absent context. As of this document's publication, noallocated exporter label is used both with and without a context. Futurespecifications MUST NOT define a use of exporters that permit both an emptycontext and no context with the same label. New uses of exporters SHOULD providea context in all exporter computations, though the value could be empty.¶

Requirements for the format of exporter labels are defined in Section 4of[RFC5705].¶

8.1.Single-Use Tickets

The simplest form of anti-replay defense is for the server to onlyallow each session ticket to be used once. For instance, the servercan maintain a database of all outstanding valid tickets, deleting eachticket from the database as it is used. If an unknown ticket isprovided, the server would then fall back to a full handshake.¶

If the tickets are not self-contained but rather are database keys,and the corresponding PSKs are deleted upon use, then connections establishedusing PSKs enjoy not only anti-replay protection, but also forward secrecy onceall copies of the PSK from the database entry have been deleted.This mechanism also improves security for PSK usage when PSK is used without(EC)DHE.¶

Because this mechanism requires sharing the session database betweenserver nodes in environments with multiple distributed servers,it may be hard to achieve high rates of successful PSK 0-RTTconnections when compared to self-encrypted tickets. Unlikesession databases, session tickets can successfully do PSK-basedsession establishment even without consistent storage, though when0-RTT is allowed they still require consistent storage for anti-replayof 0-RTT data, as detailed in the followingsection.¶

8.2.Client Hello Recording

An alternative form of anti-replay is to record a unique value derivedfrom the ClientHello (generally either the random value or the PSKbinder) and reject duplicates. Recording all ClientHellos causes stateto grow without bound, but a server can instead record ClientHellos withina given time window and use the "obfuscated_ticket_age" to ensure thattickets aren't reused outside that window.¶

In order to implement this, when a ClientHello is received, the serverfirst verifies the PSK binder as described inSection 4.2.11. It then computes theexpected_arrival_time as described in the next section and rejects0-RTT if it is outside the recording window, falling back to the1-RTT handshake.¶

If the expected_arrival_time is in the window, then the serverchecks to see if it has recorded a matching ClientHello. If oneis found, it either aborts the handshake with an "illegal_parameter" alertor accepts the PSK but rejects 0-RTT. If no matching ClientHellois found, then it accepts 0-RTT and then stores the ClientHello foras long as the expected_arrival_time is inside the window.Servers MAY also implement data stores with false positives, such asBloom filters, in which case they MUST respond to apparent replay byrejecting 0-RTT but MUST NOT abort the handshake.¶

The server MUST derive the storage key only from validated sectionsof the ClientHello. If the ClientHello contains multiplePSK identities, then an attacker can create multiple ClientHelloswith different binder values for the less-preferred identity on theassumption that the server will not verify it (as recommendedbySection 4.2.11).I.e., if theclient sends PSKs A and B but the server prefers A, then theattacker can change the binder for B without affecting the binderfor A. If the binder for B is part of the storage key,then this ClientHello will not appear as a duplicate,which will cause the ClientHello to be accepted, and maycause side effects such as replay cache pollution, although any0-RTT data will not be decryptable because it will use differentkeys. If the validated binder or the ClientHello.randomis used as the storage key, then this attack is not possible.¶

Because this mechanism does not require storing all outstandingtickets, it may be easier to implement in distributed systems withhigh rates of resumption and 0-RTT, at the cost of potentiallyweaker anti-replay defense because of the difficulty of reliablystoring and retrieving the received ClientHello messages.In many such systems, it is impractical to have globallyconsistent storage of all the received ClientHellos.In this case, the best anti-replay protection is provided byhaving a single storage zone beauthoritative for a given ticket and refusing 0-RTT for thatticket in any other zone. This approach prevents simplereplay by the attacker because only one zone will accept0-RTT data. A weaker design is to implement separate storage foreach zone but allow 0-RTT in any zone. This approach limitsthe number of replays to once per zone. Application messageduplication of course remains possible with either design.¶

When implementations are freshly started, they SHOULDreject 0-RTT as long as any portion of their recording window overlapsthe startup time. Otherwise, they run the risk of acceptingreplays which were originally sent during that period.¶

Note: If the client's clock is running much faster than the server's,then a ClientHello may be received that is outside the window in thefuture, in which case it might be accepted for 1-RTT, causing a client retry,and then acceptable later for 0-RTT. This is another variant ofthe second form of attack described inSection 8.¶

8.3.Freshness Checks

Because the ClientHello indicates the time at which the client sentit, it is possible to efficiently determine whether a ClientHello waslikely sent reasonably recently and only accept 0-RTT for such aClientHello, otherwise falling back to a 1-RTT handshake.This is necessary for the ClientHello storage mechanismdescribed inSection 8.2 because otherwise the serverneeds to store an unlimited number of ClientHellos, and is a useful optimization forself-contained single-use tickets because it allows efficient rejection of ClientHelloswhich cannot be used for 0-RTT.¶

In order to implement this mechanism, a server needs to store the timethat the server generated the session ticket, offset by an estimate ofthe round-trip time between client and server. I.e.,¶

    adjusted_creation_time = creation_time + estimated_RTT

This value can be encoded in the ticket, thus avoiding the need tokeep state for each outstanding ticket. The server can determine theclient's view of the age of the ticket by subtracting the ticket's"ticket_age_add" value from the "obfuscated_ticket_age" parameter inthe client's "pre_shared_key" extension. The server can determine theexpected_arrival_time of the ClientHello as:¶

    expected_arrival_time = adjusted_creation_time + clients_ticket_age

When a new ClientHello is received, the expected_arrival_time is thencompared against the current server wall clock time and if they differby more than a certain amount, 0-RTT is rejected, though the 1-RTThandshake can be allowed to complete.¶

There are several potential sources of error that might causemismatches between the expected_arrival_time and the measuredtime. Variations in client and server clockrates are likely to be minimal, though potentially the absolutetimes may be off by large values.Network propagation delays are the most likely causes ofa mismatch in legitimate values for elapsed time. Both theNewSessionTicket and ClientHello messages might be retransmitted andtherefore delayed, which might be hidden by TCP. For clientson the Internet, this implies windowson the order of ten seconds to account for errors in clocks andvariations in measurements; other deployment scenariosmay have different needs. Clock skew distributions are notsymmetric, so the optimal tradeoff may involve an asymmetric rangeof permissible mismatch values.¶

Note that freshness checking alone is not sufficient to preventreplays because it does not detect them during the error window,which -- depending on bandwidth and system capacity -- could includebillions of replays in real-world settings. In addition, thisfreshness checking is only done at the time the ClientHello isreceived, and not when subsequent early Application Data records arereceived. After early data is accepted, records may continue to bestreamed to the server over a longer time period.¶

9.1.Mandatory-to-Implement Cipher Suites

In the absence of an application profile standard specifying otherwise:¶

A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256[GCM]cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384[GCM] andTLS_CHACHA20_POLY1305_SHA256[RFC8439] cipher suites (seeAppendix B.4).¶

A TLS-compliant application MUST support digital signatures withrsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (forCertificateVerify and certificates), and ecdsa_secp256r1_sha256. ATLS-compliant application MUST support key exchange with secp256r1(NIST P-256) and SHOULD support key exchange with X25519[RFC7748].¶

9.2.Mandatory-to-Implement Extensions

In the absence of an application profile standard specifying otherwise, aTLS-compliant application MUST implement the following TLS extensions:¶

• Supported Versions ("supported_versions";Section 4.2.1)¶
• Cookie ("cookie";Section 4.2.2)¶
• Signature Algorithms ("signature_algorithms";Section 4.2.3)¶
• Signature Algorithms Certificate ("signature_algorithms_cert";Section 4.2.3)¶
• Negotiated Groups ("supported_groups";Section 4.2.7)¶
• Key Share ("key_share";Section 4.2.8)¶
• Server Name Indication ("server_name"; Section 3 of[RFC6066])¶

All implementations MUST send and use these extensions when offeringapplicable features:¶

• "supported_versions" is REQUIRED for all ClientHello, ServerHello, and HelloRetryRequest messages.¶
• "signature_algorithms" is REQUIRED for certificate authentication.¶
• "supported_groups" is REQUIRED for ClientHello messages using DHE or ECDHE key exchange.¶
• "key_share" is REQUIRED for DHE or ECDHE key exchange.¶
• "pre_shared_key" is REQUIRED for PSK key agreement.¶
• "psk_key_exchange_modes" is REQUIRED for PSK key agreement.¶

A client is considered to be attempting to negotiate using thisspecification if the ClientHello contains a "supported_versions"extension with 0x0304 contained in its body.Such a ClientHello message MUST meet the following requirements:¶

• If not containing a "pre_shared_key" extension, it MUST contain botha "signature_algorithms" extension and a "supported_groups" extension.¶
• If containing a "supported_groups" extension, it MUST also contain a"key_share" extension, and vice versa. An empty KeyShare.client_shareslist is permitted.¶

Servers receiving a ClientHello which does not conform to theserequirements MUST abort the handshake with a "missing_extension"alert.¶

Additionally, all implementations MUST support the use of the "server_name"extension with applications capable of using it.Servers MAY require clients to send a valid "server_name" extension.Servers requiring this extension SHOULD respond to a ClientHellolacking a "server_name" extension by terminating the connection with a"missing_extension" alert.¶

9.3.Protocol Invariants

This section describes invariants that TLS endpoints and middleboxes MUSTfollow. It also applies to earlier versions of TLS.¶

TLS is designed to be securely and compatibly extensible. Newer clients orservers, when communicating with newer peers, should negotiate themost preferred common parameters. The TLS handshake provides downgradeprotection: Middleboxes passing traffic between a newer client andnewer server without terminating TLS should be unable to influence thehandshake (seeAppendix F.1). At the same time, deploymentsupdate at different rates, so a newer client or server MAY continue tosupport older parameters, which would allow it to interoperate witholder endpoints.¶

For this to work, implementations MUST correctly handle extensible fields:¶

• A client sending a ClientHello MUST support all parameters advertised in it.Otherwise, the server may fail to interoperate by selecting one of thoseparameters.¶
• A server receiving a ClientHello MUST correctly ignore all unrecognizedcipher suites, extensions, and other parameters. Otherwise, it may fail tointeroperate with newer clients. In TLS 1.3, a client receiving aCertificateRequest or NewSessionTicket MUST also ignore all unrecognizedextensions.¶

• A middlebox which terminates a TLS connection MUST behave as a compliantTLS server (to the original client), including having a certificatewhich the client is willing to accept, and also as a compliant TLS client (to theoriginal server), including verifying the original server's certificate.In particular, it MUST generate its own ClientHellocontaining only parameters it understands, and it MUST generate a freshServerHello random value, rather than forwarding the endpoint's value.¶

  Note that TLS's protocol requirements and security analysis only apply to thetwo connections separately. Safely deploying a TLS terminator requiresadditional security considerations which are beyond the scope of this document.¶

• A middlebox which forwards ClientHello parameters it does not understand MUSTNOT process any messages beyond that ClientHello. It MUST forward allsubsequent traffic unmodified. Otherwise, it may fail to interoperate withnewer clients and servers.¶

  Forwarded ClientHellos may contain advertisements for features not supportedby the middlebox, so the response may include future TLS additions themiddlebox does not recognize. These additions MAY change any message beyondthe ClientHello arbitrarily. In particular, the values sent in the ServerHellomight change, the ServerHello format might change, and the TLSCiphertext formatmight change.¶

The design of TLS 1.3 was constrained by widely deployed non-compliant TLSmiddleboxes (seeAppendix E.4); however, it does not relax the invariants.Those middleboxes continue to be non-compliant.¶

A.1.Client

                           START <----+            Send ClientHello |        | Recv HelloRetryRequest       [K_send = early data] |        |                             v        |        /                 WAIT_SH ----+        |                    | Recv ServerHello        |                    | K_recv = handshake    Can |                    V   send |                 WAIT_EE  early |                    | Recv EncryptedExtensions   data |           +--------+--------+        |     Using |                 | Using certificate        |       PSK |                 v        |           |            WAIT_CERT_CR        |           |        Recv |       | Recv CertificateRequest        |           | Certificate |       v        |           |             |    WAIT_CERT        |           |             |       | Recv Certificate        |           |             v       v        |           |              WAIT_CV        |           |                 | Recv CertificateVerify        |           +> WAIT_FINISHED <+        |                  | Recv Finished        \                  | [Send EndOfEarlyData]                           | K_send = handshake                           | [Send Certificate [+ CertificateVerify]] Can send                  | Send Finished app data   -->            | K_send = K_recv = application after here                v                       CONNECTED

Note that with the transitions as shown above, clients may send alertsthat derive from post-ServerHello messages in the clear or with theearly data keys. If clients need to send such alerts, they SHOULDfirst rekey to the handshake keys if possible.¶

A.2.Server

                             START <-----+              Recv ClientHello |         | Send HelloRetryRequest                               v         |                            RECVD_CH ----+                               | Select parameters                               v                            NEGOTIATED                               | Send ServerHello                               | K_send = handshake                               | Send EncryptedExtensions                               | [Send CertificateRequest]Can send                       | [Send Certificate + CertificateVerify]app data                       | Send Finishedafter   -->                    | K_send = applicationhere                  +--------+--------+             No 0-RTT |                 | 0-RTT                      |                 |  K_recv = handshake  |                 | K_recv = early data[Skip decrypt errors] |    +------> WAIT_EOED -+                      |    |       Recv |      | Recv EndOfEarlyData                      |    | early data |      | K_recv = handshake                      |    +------------+      |                      |                        |                      +> WAIT_FLIGHT2 <--------+                               |                      +--------+--------+              No auth |                 | Cert-based client auth                      |                 |                      |                 v                      |             WAIT_CERT                      |        Recv |       | Recv Certificate                      |       empty |       v                      | Certificate |    WAIT_CV                      |             |       | Recv                      |             v       | CertificateVerify                      +-> WAIT_FINISHED <---+                               | Recv Finished                               | K_recv = application                               v                           CONNECTED

B.1.Record Layer

   enum {       invalid(0),       change_cipher_spec(20),       alert(21),       handshake(22),       application_data(23),       (255)   } ContentType;   struct {       ContentType type;       ProtocolVersion legacy_record_version;       uint16 length;       opaque fragment[TLSPlaintext.length];   } TLSPlaintext;   struct {       opaque content[TLSPlaintext.length];       ContentType type;       uint8 zeros[length_of_padding];   } TLSInnerPlaintext;   struct {       ContentType opaque_type = application_data; /* 23 */       ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */       uint16 length;       opaque encrypted_record[TLSCiphertext.length];   } TLSCiphertext;

B.2.Alert Messages

   enum { warning(1), fatal(2), (255) } AlertLevel;   enum {       close_notify(0),       unexpected_message(10),       bad_record_mac(20),       decryption_failed_RESERVED(21),       record_overflow(22),       decompression_failure_RESERVED(30),       handshake_failure(40),       no_certificate_RESERVED(41),       bad_certificate(42),       unsupported_certificate(43),       certificate_revoked(44),       certificate_expired(45),       certificate_unknown(46),       illegal_parameter(47),       unknown_ca(48),       access_denied(49),       decode_error(50),       decrypt_error(51),       export_restriction_RESERVED(60),       protocol_version(70),       insufficient_security(71),       internal_error(80),       inappropriate_fallback(86),       user_canceled(90),       no_renegotiation_RESERVED(100),       missing_extension(109),       unsupported_extension(110),       certificate_unobtainable_RESERVED(111),       unrecognized_name(112),       bad_certificate_status_response(113),       bad_certificate_hash_value_RESERVED(114),       unknown_psk_identity(115),       certificate_required(116),       no_application_protocol(120),       (255)   } AlertDescription;   struct {       AlertLevel level;       AlertDescription description;   } Alert;

B.3.Handshake Protocol

   enum {       hello_request_RESERVED(0),       client_hello(1),       server_hello(2),       hello_verify_request_RESERVED(3),       new_session_ticket(4),       end_of_early_data(5),       hello_retry_request_RESERVED(6),       encrypted_extensions(8),       certificate(11),       server_key_exchange_RESERVED(12),       certificate_request(13),       server_hello_done_RESERVED(14),       certificate_verify(15),       client_key_exchange_RESERVED(16),       finished(20),       certificate_url_RESERVED(21),       certificate_status_RESERVED(22),       supplemental_data_RESERVED(23),       key_update(24),       message_hash(254),       (255)   } HandshakeType;   struct {       HandshakeType msg_type;    /* handshake type */       uint24 length;             /* remaining bytes in message */       select (Handshake.msg_type) {           case client_hello:          ClientHello;           case server_hello:          ServerHello;           case end_of_early_data:     EndOfEarlyData;           case encrypted_extensions:  EncryptedExtensions;           case certificate_request:   CertificateRequest;           case certificate:           Certificate;           case certificate_verify:    CertificateVerify;           case finished:              Finished;           case new_session_ticket:    NewSessionTicket;           case key_update:            KeyUpdate;       };   } Handshake;

   uint16 ProtocolVersion;   opaque Random[32];   uint8 CipherSuite[2];    /* Cryptographic suite selector */   struct {       ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */       Random random;       opaque legacy_session_id<0..32>;       CipherSuite cipher_suites<2..2^16-2>;       opaque legacy_compression_methods<1..2^8-1>;       Extension extensions<8..2^16-1>;   } ClientHello;   struct {       ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */       Random random;       opaque legacy_session_id_echo<0..32>;       CipherSuite cipher_suite;       uint8 legacy_compression_method = 0;       Extension extensions<6..2^16-1>;   } ServerHello;   struct {       ExtensionType extension_type;       opaque extension_data<0..2^16-1>;   } Extension;   enum {       server_name(0),                             /* RFC 6066 */       max_fragment_length(1),                     /* RFC 6066 */       status_request(5),                          /* RFC 6066 */       supported_groups(10),                       /* RFC 8422, 7919 */       signature_algorithms(13),                   /* RFC 8446 */       use_srtp(14),                               /* RFC 5764 */       heartbeat(15),                              /* RFC 6520 */       application_layer_protocol_negotiation(16), /* RFC 7301 */       signed_certificate_timestamp(18),           /* RFC 6962 */       client_certificate_type(19),                /* RFC 7250 */       server_certificate_type(20),                /* RFC 7250 */       padding(21),                                /* RFC 7685 */       pre_shared_key(41),                         /* RFC 8446 */       early_data(42),                             /* RFC 8446 */       supported_versions(43),                     /* RFC 8446 */       cookie(44),                                 /* RFC 8446 */       psk_key_exchange_modes(45),                 /* RFC 8446 */       certificate_authorities(47),                /* RFC 8446 */       oid_filters(48),                            /* RFC 8446 */       post_handshake_auth(49),                    /* RFC 8446 */       signature_algorithms_cert(50),              /* RFC 8446 */       key_share(51),                              /* RFC 8446 */       (65535)   } ExtensionType;   struct {       NamedGroup group;       opaque key_exchange<1..2^16-1>;   } KeyShareEntry;   struct {       KeyShareEntry client_shares<0..2^16-1>;   } KeyShareClientHello;   struct {       NamedGroup selected_group;   } KeyShareHelloRetryRequest;   struct {       KeyShareEntry server_share;   } KeyShareServerHello;   struct {       uint8 legacy_form = 4;       opaque X[coordinate_length];       opaque Y[coordinate_length];   } UncompressedPointRepresentation;   enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;   struct {       PskKeyExchangeMode ke_modes<1..255>;   } PskKeyExchangeModes;   struct {} Empty;   struct {       select (Handshake.msg_type) {           case new_session_ticket:   uint32 max_early_data_size;           case client_hello:         Empty;           case encrypted_extensions: Empty;       };   } EarlyDataIndication;   struct {       opaque identity<1..2^16-1>;       uint32 obfuscated_ticket_age;   } PskIdentity;   opaque PskBinderEntry<32..255>;   struct {       PskIdentity identities<7..2^16-1>;       PskBinderEntry binders<33..2^16-1>;   } OfferedPsks;   struct {       select (Handshake.msg_type) {           case client_hello: OfferedPsks;           case server_hello: uint16 selected_identity;       };   } PreSharedKeyExtension;

   struct {       select (Handshake.msg_type) {           case client_hello:                ProtocolVersion versions<2..254>;           case server_hello: /* and HelloRetryRequest */                ProtocolVersion selected_version;       };   } SupportedVersions;

   struct {       opaque cookie<1..2^16-1>;   } Cookie;

   enum {       /* RSASSA-PKCS1-v1_5 algorithms */       rsa_pkcs1_sha256(0x0401),       rsa_pkcs1_sha384(0x0501),       rsa_pkcs1_sha512(0x0601),       /* ECDSA algorithms */       ecdsa_secp256r1_sha256(0x0403),       ecdsa_secp384r1_sha384(0x0503),       ecdsa_secp521r1_sha512(0x0603),       /* RSASSA-PSS algorithms with public key OID rsaEncryption */       rsa_pss_rsae_sha256(0x0804),       rsa_pss_rsae_sha384(0x0805),       rsa_pss_rsae_sha512(0x0806),       /* EdDSA algorithms */       ed25519(0x0807),       ed448(0x0808),       /* RSASSA-PSS algorithms with public key OID RSASSA-PSS */       rsa_pss_pss_sha256(0x0809),       rsa_pss_pss_sha384(0x080a),       rsa_pss_pss_sha512(0x080b),       /* Legacy algorithms */       rsa_pkcs1_sha1(0x0201),       ecdsa_sha1(0x0203),       /* Reserved Code Points */       obsolete_RESERVED(0x0000..0x0200),       dsa_sha1_RESERVED(0x0202),       obsolete_RESERVED(0x0204..0x0400),       dsa_sha256_RESERVED(0x0402),       obsolete_RESERVED(0x0404..0x0500),       dsa_sha384_RESERVED(0x0502),       obsolete_RESERVED(0x0504..0x0600),       dsa_sha512_RESERVED(0x0602),       obsolete_RESERVED(0x0604..0x06FF),       private_use(0xFE00..0xFFFF),       (0xFFFF)   } SignatureScheme;   struct {       SignatureScheme supported_signature_algorithms<2..2^16-2>;   } SignatureSchemeList;

   enum {       unallocated_RESERVED(0x0000),       /* Elliptic Curve Groups (ECDHE) */       obsolete_RESERVED(0x0001..0x0016),       secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),       obsolete_RESERVED(0x001A..0x001C),       x25519(0x001D), x448(0x001E),       /* Finite Field Groups (DHE) */       ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),       ffdhe6144(0x0103), ffdhe8192(0x0104),       /* Reserved Code Points */       ffdhe_private_use(0x01FC..0x01FF),       ecdhe_private_use(0xFE00..0xFEFF),       obsolete_RESERVED(0xFF01..0xFF02),       (0xFFFF)   } NamedGroup;   struct {       NamedGroup named_group_list<2..2^16-1>;   } NamedGroupList;

   opaque DistinguishedName<1..2^16-1>;   struct {       DistinguishedName authorities<3..2^16-1>;   } CertificateAuthoritiesExtension;   struct {       opaque certificate_extension_oid<1..2^8-1>;       opaque certificate_extension_values<0..2^16-1>;   } OIDFilter;   struct {       OIDFilter filters<0..2^16-1>;   } OIDFilterExtension;   struct {} PostHandshakeAuth;   struct {       Extension extensions<0..2^16-1>;   } EncryptedExtensions;   struct {       opaque certificate_request_context<0..2^8-1>;       Extension extensions<0..2^16-1>;   } CertificateRequest;

   enum {       X509(0),       OpenPGP_RESERVED(1),       RawPublicKey(2),       (255)   } CertificateType;   struct {       select (certificate_type) {           case RawPublicKey:             /* From RFC 7250 ASN.1_subjectPublicKeyInfo */             opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;           case X509:             opaque cert_data<1..2^24-1>;       };       Extension extensions<0..2^16-1>;   } CertificateEntry;   struct {       opaque certificate_request_context<0..2^8-1>;       CertificateEntry certificate_list<0..2^24-1>;   } Certificate;   struct {       SignatureScheme algorithm;       opaque signature<0..2^16-1>;   } CertificateVerify;   struct {       opaque verify_data[Hash.length];   } Finished;

   struct {       uint32 ticket_lifetime;       uint32 ticket_age_add;       opaque ticket_nonce<0..255>;       opaque ticket<1..2^16-1>;       Extension extensions<0..2^16-1>;   } NewSessionTicket;

   struct {} EndOfEarlyData;   enum {       update_not_requested(0), update_requested(1), (255)   } KeyUpdateRequest;   struct {       KeyUpdateRequest request_update;   } KeyUpdate;

B.4.Cipher Suites

A cipher suite defines the pair of the AEAD algorithm and hashalgorithm to be used with HKDF.Cipher suite names follow the naming convention:¶

   CipherSuite TLS_AEAD_HASH = VALUE;

This specification defines the following cipher suites for use with TLS 1.3.¶

The corresponding AEAD algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, andAEAD_AES_128_CCM are defined in[RFC5116]. AEAD_CHACHA20_POLY1305 is definedin[RFC8439]. AEAD_AES_128_CCM_8 is defined in[RFC6655]. The correspondinghash algorithms are defined in[SHS].¶

Although TLS 1.3 uses the same cipher suite space as previous versionsof TLS, TLS 1.3 cipher suites are defined differently, only specifyingthe symmetric ciphers, and cannot be used for TLS 1.2. Similarly,cipher suites for TLS 1.2 and lower cannot be used with TLS 1.3.¶

New cipher suite values are assigned by IANA as described inSection 11.¶

C.1.Random Number Generation and Seeding

TLS requires a cryptographically secure pseudorandom number generator (CSPRNG).In most cases, the operating system provides an appropriate facility suchas /dev/urandom, which should be used absent other (e.g., performance) concerns.It is RECOMMENDED to use an existing CSPRNG implementation inpreference to crafting a new one. Many adequate cryptographic librariesare already available under favorable license terms. Should those proveunsatisfactory,[RFC4086] provides guidance on the generation of random values.¶

TLS uses random values (1) in public protocol fields such as thepublic Random values in the ClientHello and ServerHello and (2) togenerate keying material. With a properly functioning CSPRNG, thisdoes not present a security problem, as it is not feasible to determinethe CSPRNG state from its output. However, with a broken CSPRNG, itmay be possible for an attacker to use the public output to determinethe CSPRNG internal state and thereby predict the keying material, asdocumented in[CHECKOWAY] and[DSA-1571-1].¶

Implementations can provide extra security againstthis form of attack by using separate CSPRNGs to generate public andprivate values.¶

[RFC8937] describes a way way for security protocol implementationsto augment their (pseudo)random number generators using a long-term private keyand a deterministic signature function. This improves randomness from broken orotherwise subverted random number generators.¶

C.2.Certificates and Authentication

Implementations are responsible for verifying the integrity of certificates andshould generally support certificate revocation messages. Absent a specificindication from an application profile, certificates shouldalways be verified to ensure proper signing by a trusted certificate authority(CA). The selection and addition of trust anchors should be done very carefully.Users should be able to view information about the certificate and trust anchor.Applications SHOULD also enforce minimum and maximum key sizes. For example,certification paths containing keys or signatures weaker than 2048-bit RSA or224-bit ECDSA are not appropriate for secure applications.¶

C.3.Implementation Pitfalls

Implementation experience has shown that certain parts of earlier TLSspecifications are not easy to understand and have been a source ofinteroperability and security problems. Many of these areas have been clarifiedin this document but this appendix contains a short list of the most importantthings that require special attention from implementors.¶

TLS protocol issues:¶

• Do you correctly handle handshake messages that are fragmented tomultiple TLS records (seeSection 5.1)? Do you correctly handlecorner cases like a ClientHello that is split into several small fragments? Doyou fragment handshake messages that exceed the maximum fragmentsize? In particular, the Certificate and CertificateRequesthandshake messages can be large enough to require fragmentation.Certificate compression as defined in[RFC8879] can be usedto reduce the risk of fragmentation.¶
• Do you ignore the TLS record layer version number in all unencrypted TLSrecords (seeAppendix E)?¶
• Have you ensured that all support for SSL, RC4, EXPORT ciphers, andMD5 (via the "signature_algorithms" extension) is completely removed fromall possible configurations that support TLS 1.3 or later, and thatattempts to use these obsolete capabilities fail correctly?(seeAppendix E)?¶
• Do you handle TLS extensions in ClientHellos correctly, includingunknown extensions?¶
• When the server has requested a client certificate but nosuitable certificate is available, do you correctly send an emptyCertificate message, instead of omitting the whole message (seeSection 4.4.2)?¶
• When processing the plaintext fragment produced by AEAD-Decrypt andscanning from the end for the ContentType, do you avoid scanningpast the start of the cleartext in the event that the peer has senta malformed plaintext of all zeros?¶
• Do you properly ignore unrecognized cipher suites(Section 4.1.2), hello extensions (Section 4.2), named groups(Section 4.2.7), key shares (Section 4.2.8),supported versions (Section 4.2.1),and signature algorithms (Section 4.2.3) in theClientHello?¶
• As a server, do you send a HelloRetryRequest to clients whichsupport a compatible (EC)DHE group but do not predict it in the"key_share" extension? As a client, do you correctly handle aHelloRetryRequest from the server?¶

Cryptographic details:¶

• What countermeasures do you use to prevent timing attacks[TIMING]?¶
• When using Diffie-Hellman key exchange, do you correctly preserveleading zero bytes in the negotiated key (seeSection 7.4.1)?¶
• Does your TLS client check that the Diffie-Hellman parameters sentby the server are acceptable (seeSection 4.2.8.1)?¶
• Do you use a strong and, most importantly, properly seeded random numbergenerator (seeAppendix C.1) when generating Diffie-Hellmanprivate values, the ECDSA "k" parameter, and other security-critical values?It is RECOMMENDED that implementations implement "deterministic ECDSA"as specified in[RFC6979]. Note that purely deterministic ECC signatures such asdeterministic ECDSA and EdDSA may be vulnerable to certain side-channel and faultinjection attacks in easily accessible IoT devices.¶
• Do you zero-pad Diffie-Hellman public key values and sharedsecrets to the group size (seeSection 4.2.8.1 andSection 7.4.1)?¶
• Do you verify signatures after making them, to protect against RSA-CRTkey leaks[FW15]?¶

C.4.Client Tracking Prevention

Clients SHOULD NOT reuse a ticket for multiple connections. Reuseof a ticket allows passive observers to correlate different connections.Servers that issue tickets SHOULD offer at least as many ticketsas the number of connections that a client might use; for example, a web browserusing HTTP/1.1[RFC7230] might open six connections to a server. Servers SHOULDissue new tickets with every connection. This ensures that clients arealways able to use a new ticket when creating a new connection.¶

Offering a ticket to a server additionally allows the server to correlatedifferent connections. This is possible independent of ticket reuse. Clientapplications SHOULD NOT offer tickets across connections that are meant to beuncorrelated. For example,[FETCH] defines network partition keys to separatecache lookups in web browsers.¶

C.5.Unauthenticated Operation

Previous versions of TLS offered explicitly unauthenticated cipher suites basedon anonymous Diffie-Hellman. These modes have been deprecated in TLS 1.3.However, it is still possible to negotiate parameters that do not provideverifiable server authentication by several methods, including:¶

• Raw public keys[RFC7250].¶
• Using a public key contained in a certificate but withoutvalidation of the certificate chain or any of its contents.¶

Either technique used alone is vulnerable to man-in-the-middle attacksand therefore unsafe for general use. However, it is also possible tobind such connections to an external authentication mechanism viaout-of-band validation of the server's public key, trust on firstuse, or a mechanism such as channel bindings (though thechannel bindings described in[RFC5929] are not defined forTLS 1.3). If no such mechanism is used, then the connection has no protectionagainst active man-in-the-middle attack; applications MUST NOT use TLSin such a way absent explicit configuration or a specific applicationprofile.¶

E.1.Negotiating with an Older Server

A TLS 1.3 client who wishes to negotiate with servers that do notsupport TLS 1.3 will send anormal TLS 1.3 ClientHello containing 0x0303 (TLS 1.2) inClientHello.legacy_version but with the correct version(s) in the"supported_versions" extension. If the server does not support TLS 1.3, itwill respond with a ServerHello containing an older version number. If theclient agrees to use this version, the negotiation will proceed as appropriatefor the negotiated protocol. A client using a ticket for resumption SHOULD initiate theconnection using the version that was previously negotiated.¶

Note that 0-RTT data is not compatible with older servers and SHOULD NOTbe sent absent knowledge that the server supports TLS 1.3.SeeAppendix E.3.¶

If the version chosen by the server is not supported by the client (or is notacceptable), the client MUST abort the handshake with a "protocol_version" alert.¶

Some legacy server implementations are known to not implement the TLSspecification properly and might abort connections upon encounteringTLS extensions or versions which they are not aware of. Interoperabilitywith buggy servers is a complex topic beyond the scope of this document.Multiple connection attempts may be required in order to negotiatea backward-compatible connection; however, this practice is vulnerableto downgrade attacks and is NOT RECOMMENDED.¶

E.2.Negotiating with an Older Client

A TLS server can also receive a ClientHello indicating a version number smallerthan its highest supported version. If the "supported_versions" extensionis present, the server MUST negotiate using that extension as described inSection 4.2.1. If the "supported_versions" extension is notpresent, the server MUST negotiate the minimum of ClientHello.legacy_versionand TLS 1.2. For example, if the server supports TLS 1.0, 1.1, and 1.2,and legacy_version is TLS 1.0, the server will proceed with a TLS 1.0 ServerHello.If the "supported_versions" extension is absent and the server only supportsversions greater than ClientHello.legacy_version, the server MUST abort the handshakewith a "protocol_version" alert.¶

Note that earlier versions of TLS did not clearly specify the record layerversion number value in all cases (TLSPlaintext.legacy_record_version). Serverswill receive various TLS 1.x versions in this field, but its valueMUST always be ignored.¶

E.3.0-RTT Backward Compatibility

0-RTT data is not compatible with older servers. An older server will respondto the ClientHello with an older ServerHello, but it will not correctly skipthe 0-RTT data and will fail to complete the handshake. This can cause issues whena client attempts to use 0-RTT, particularly against multi-server deployments. Forexample, a deployment could deploy TLS 1.3 gradually with some serversimplementing TLS 1.3 and some implementing TLS 1.2, or a TLS 1.3 deploymentcould be downgraded to TLS 1.2.¶

A client that attempts to send 0-RTT data MUST fail a connection if it receivesa ServerHello with TLS 1.2 or older. It can then retrythe connection with 0-RTT disabled. To avoid a downgrade attack, theclient SHOULD NOT disable TLS 1.3, only 0-RTT.¶

To avoid this error condition, multi-server deployments SHOULD ensure a uniformand stable deployment of TLS 1.3 without 0-RTT prior to enabling 0-RTT.¶

E.4.Middlebox Compatibility Mode

Field measurements[Ben17a][Ben17b][Res17a][Res17b] have found that a significant number of middleboxesmisbehave when a TLS client/server pair negotiates TLS 1.3. Implementationscan increase the chance of making connections through those middleboxesby making the TLS 1.3 handshake look more like a TLS 1.2 handshake:¶

• The client always provides a non-empty session ID in the ClientHello,as described in the legacy_session_id section ofSection 4.1.2.¶
• If not offering early data, the client sends a dummychange_cipher_spec record (see the third paragraph ofSection 5)immediately before its second flight. Thismay either be before its second ClientHello or before its encryptedhandshake flight. If offering early data, the record is placedimmediately after the first ClientHello.¶
• The server sends a dummy change_cipher_spec record immediatelyafter its first handshake message. This may either be after aServerHello or a HelloRetryRequest.¶

When put together, these changes make the TLS 1.3 handshake resembleTLS 1.2 session resumption, which improves the chance of successfullyconnecting through middleboxes. This "compatibility mode" is partiallynegotiated: the client can opt to provide a session ID or not,and the server has to echo it. Either side can send change_cipher_specat any time during the handshake, as they must be ignored by the peer,but if the client sends a non-empty session ID, the server MUST sendthe change_cipher_spec as described in this appendix.¶

E.5.Security Restrictions Related to Backward Compatibility

Implementations negotiating the use of older versions of TLS SHOULD preferforward secret and AEAD cipher suites, when available.¶

The security of RC4 cipher suites is considered insufficient for the reasonscited in[RFC7465]. Implementations MUST NOT offer or negotiate RC4 cipher suitesfor any version of TLS for any reason.¶

Old versions of TLS permitted the use of very low strength ciphers.Ciphers with a strength less than 112 bits MUST NOT be offered ornegotiated for any version of TLS for any reason.¶

The security of SSL 3.0[RFC6101] is considered insufficient for the reasons enumeratedin[RFC7568], and it MUST NOT be negotiated for any reason.¶

The security of SSL 2.0[SSL2] is considered insufficient for the reasons enumeratedin[RFC6176], and it MUST NOT be negotiated for any reason.¶

Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-HELLO.Implementations MUST NOT negotiate TLS 1.3 or later using an SSL version 2.0 compatibleCLIENT-HELLO. Implementations are NOT RECOMMENDED to accept an SSL version 2.0 compatibleCLIENT-HELLO in order to negotiate older versions of TLS.¶

Implementations MUST NOT send a ClientHello.legacy_version or ServerHello.legacy_versionset to 0x0300 or less. Any endpoint receiving a Hello message withClientHello.legacy_version or ServerHello.legacy_version set to 0x0300 MUSTabort the handshake with a "protocol_version" alert.¶

Implementations MUST NOT send any records with a version less than 0x0300.Implementations SHOULD NOT accept any records with a version less than 0x0300(but may inadvertently do so if the record version number is ignored completely).¶

Implementations MUST NOT use the Truncated HMAC extension, defined inSection 7 of[RFC6066], as it is not applicable to AEAD algorithms and hasbeen shown to be insecure in some scenarios.¶

F.1.Handshake

The TLS handshake is an Authenticated Key Exchange (AKE) protocol whichis intended to provide both one-way authenticated (server-only) andmutually authenticated (client and server) functionality. At the completionof the handshake, each side outputs its view of the following values:¶

• A set of "session keys" (the various secrets derived from the main secret)from which can be derived a set of working keys.¶
• A set of cryptographic parameters (algorithms, etc.).¶
• The identities of the communicating parties.¶

We assume the attacker to be an active network attacker, which means ithas complete control over the network used to communicate between the parties[RFC3552].Even under these conditions, the handshake should provide the properties listed below.Note that these properties are not necessarily independent, but reflectthe protocol consumers' needs.¶

Establishing the same session keys:

The handshake needs to output the same set of session keys on both sides ofthe 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 communicatingparties and not to the attacker (see[CK01]; Definition 1, part 2).Note that in a unilaterally authenticated connection, the attacker can establishits own session keys with the server, but those session keys are distinct fromthose established by the client.¶

Peer Authentication:

The client's view of the peer identity should reflect the server'sidentity. If the client is authenticated, the server's view of thepeer identity should match the client's identity.¶

Uniqueness of the session keys:

Any two distinct handshakes should produce distinct, unrelated sessionkeys. Individual session keys produced by a handshake should also be distinctand independent.¶

Downgrade Protection:

The cryptographic parameters should be the same on both sides andshould be the same as if the peers had been communicating in theabsence 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-basedauthentication modes or the external/resumption PSK in PSK with (EC)DHE modes) is compromised afterthe handshake is complete, this does not compromise the security of thesession key (see[DOW92]), as long as the session key itself hasbeen erased. The forward secrecy property is not satisfiedwhen PSK is used in the "psk_ke" PskKeyExchangeMode.¶

Key Compromise Impersonation (KCI) resistance:

In a mutually authenticated connection with certificates, compromising the long-termsecret of one actor should not break that actor's authentication of their peer inthe given connection (see[HGFS15]). For example, if a client's signature key iscompromised, it should not be possible to impersonate arbitrary servers to that clientin subsequent handshakes.¶

Protection of endpoint identities:

The server's identity (certificate) should be protected against passiveattackers. The client's identity (certificate) should be protected againstboth passive and active attackers. This property does not hold for ciphersuites without confidentiality; while this specification does not define any such cipher suites,other documents may do so.¶

Informally, the signature-based modes of TLS 1.3 provide for theestablishment of a unique, secret, shared key established by an(EC)DHE key exchange and authenticated by the server's signature overthe handshake transcript, as well as tied to the server's identity bya MAC. If the client is authenticated by a certificate, it also signsover the handshake transcript and provides a MAC tied to bothidentities.[SIGMA] describes the design and analysis of this type of keyexchange 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 sharedsecret into a unique per-connection set of short-term session keys. Thissecret may have been established in a previous handshake. IfPSK with (EC)DHE key establishment is used, these session keys will also be forwardsecret. The resumption PSK has been designed so that theresumption secret computed by connection N and needed to formconnection 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 sameconnection, they are associated with different keys, so compromise ofthe PSK associated with one ticket does not lead to the compromise ofconnections 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 PSKand the current handshake, as well as between the session where thePSK was established and the current session. This bindingtransitively includes the original handshake transcript, because thattranscript is digested into the values which produce the resumptionsecret. This requires that both the KDF used to produce theresumption secret and the MAC used to compute the binder be collisionresistant. SeeAppendix F.1.1 for more on this.Note: The binder does not cover the binder values from otherPSKs, though they are included in the Finished MAC.¶

Note: TLS does not currently permit the server to send a certificate_requestmessage in non-certificate-based handshakes (e.g., PSK).If this restriction were to be relaxed in future, theclient's signature would not cover the server's certificate directly.However, if the PSK was established through a NewSessionTicket, the client'ssignature would transitively cover the server's certificate throughthe PSK binder.[PSK-FINISHED]describes a concrete attack on constructions that do not bind tothe server's certificate (see also[Kraw16]). It is unsafe to use certificate-based clientauthentication when the client might potentially share the samePSK/key-id pair with two different endpoints. Implementations MUSTNOT combine external PSKs with certificate-based authentication ofeither the client or server. Future specifications MAY provide anextension to permit this.¶

If an exporter is used, then it produces values which are uniqueand secret (because they are generated from a unique session key).Exporters computed with different labels and contexts are computationallyindependent, so it is not feasible to compute one from another orthe session secret from the exported value.Note: Exporters canproduce arbitrary-length values; if exporters are to beused as channel bindings, the exported value MUST be largeenough to provide collision resistance. The exporters provided inTLS 1.3 are derived from the same Handshake Contexts as theearly traffic keys and the application traffic keys, respectively,and thus have similar security properties. Note that they donot include the client's certificate; future applicationswhich wish to bind to the client's certificate may needto define a new exporter that includes the full handshaketranscript.¶

For all handshake modes, the Finished MAC (and, where present, thesignature) prevents downgrade attacks. In addition, the use ofcertain bytes in the random nonces as described inSection 4.1.3allows 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 informationto establish shared keys, the remainder of the handshake is encrypted,thus providing protection against passive attackers, even if thecomputed shared key is not authenticated. Because the serverauthenticates before the client, the client can ensure that if itauthenticates to the server, it onlyreveals its identity to an authenticated server. Note that implementationsmust use the provided record-padding mechanism during the handshaketo avoid leaking information about the identities due to length.The client's proposed PSK identities are not encrypted, nor is theone that the server selects.¶

F.2.Record Layer

The record layer depends on the handshake producing strong traffic secretswhich can be used to derive bidirectional encryption keys and nonces.Assuming that is true, and the keys are used for no more data thanindicated inSection 5.5, then the record layer should provide the followingguarantees:¶

Confidentiality:

An attacker should not be able to determine the plaintext contentsof a given record.¶

Integrity:

An attacker should not be able to craft a new record which isdifferent 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 arecord which it has already accepted or cause the receiver to acceptrecord N+1 without having first processed record N.¶

Length concealment:

Given a record with a given external length, the attacker should not be ableto determine the amount of the record that is content versus padding.¶

Forward secrecy after key change:

If the traffic key update mechanism described inSection 4.6.3 has beenused and the previous generation key is deleted, an attacker who compromisesthe endpoint should not be able to decrypt traffic encrypted with the old key.¶

Informally, TLS 1.3 provides these properties by AEAD-protecting theplaintext with a strong key. AEAD encryption[RFC5116] provides confidentialityand integrity for the data. Non-replayability is provided by usinga separate nonce for each record, with the nonce being derived fromthe record sequence number (Section 5.3), with the sequencenumber being maintained independently at both sides; thus records whichare delivered out of order result in AEAD deprotection failures.In order to prevent mass cryptanalysis when the same plaintext isrepeatedly encrypted by different users under the same key(as is commonly the case for HTTP), the nonce is formed by mixingthe sequence number with a secret per-connection initializationvector derived along with the traffic keys.See[BT16] for analysis of this construction.¶

The rekeying technique in TLS 1.3 (seeSection 7.2) follows theconstruction of the serial generator as discussed in[REKEY], which shows that rekeying canallow keys to be used for a larger number of encryptions than withoutrekeying. This relies on the security of the HKDF-Expand-Label function as apseudorandom function (PRF). In addition, as long as this function is trulyone 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 connectionafter a traffic secret of that connection is compromised. That is, TLS does notprovide post-compromise security/future secrecy/backward secrecy with respectto the traffic secret. Indeed, an attacker who learns a traffic secret cancompute all future traffic secrets on that connection. Systems which want suchguarantees need to do a fresh handshake and establish a new connection with an(EC)DHE exchange.¶

F.3.Traffic Analysis

TLS is susceptible to a variety of traffic analysis attacks based onobserving the length and timing of encrypted packets[CLINIC][HCJC16].This is particularly easy when there is a smallset of possible messages to be distinguished, such as for a videoserver hosting a fixed corpus of content, but still provides usableinformation even in more complicated scenarios.¶

TLS does not provide any specific defenses against this form of attackbut does include a padding mechanism for use by applications: Theplaintext protected by the AEAD function consists of content plusvariable-length padding, which allows the application to producearbitrary-length encrypted records as well as padding-only cover traffic toconceal the difference between periods of transmission and periodsof silence. Because thepadding is encrypted alongside the actual content, an attacker cannotdirectly determine the length of the padding, but may be able tomeasure it indirectly by the use of timing channels exposed duringrecord processing (i.e., seeing how long it takes to process arecord or trickling in records to see which ones elicit a responsefrom the server). In general, it is not known how to remove all ofthese channels because even a constant-time padding removal function willlikely feed the content into data-dependent functions.At minimum, a fully constant-time server or client would require closecooperation with the application-layer protocol implementation, includingmaking that higher-level protocol constant time.¶

Note: Robusttraffic analysis defenses will likely lead to inferior performancedue to delays in transmitting packets and increased traffic volume.¶

F.4.Side Channel Attacks

In general, TLS does not have specific defenses against side-channelattacks (i.e., those which attack the communications via secondarychannels such as timing), leaving those to the implementation of the relevantcryptographic primitives. However, certain features of TLS aredesigned to make it easier to write side-channel resistant code:¶

• Unlike previous versions of TLS which used a compositeMAC-then-encrypt structure, TLS 1.3 only uses AEAD algorithms,allowing implementations to use self-contained constant-timeimplementations of those primitives.¶
• TLS uses a uniform "bad_record_mac" alert for all decryptionerrors, which is intended to prevent an attacker from gainingpiecewise insight into portions of the message. Additional resistanceis provided by terminating the connection on such errors; a newconnection will have different cryptographic material, preventingattacks against the cryptographic primitives that require multipletrials.¶

Information leakage through side channels can occur at layers aboveTLS, in application protocols and the applications that usethem. Resistance to side-channel attacks depends on applications andapplication protocols separately ensuring that confidentialinformation is not inadvertently leaked.¶

F.5.Replay Attacks on 0-RTT

Replayable 0-RTT data presents a number of security threats toTLS-using applications, unless those applications are specificallyengineered to be safe under replay(minimally, this means idempotent, but in many cases mayalso require other stronger conditions, such as constant-timeresponse). Potential attacks include:¶

• Duplication of actions which cause side effects (e.g., purchasing anitem or transferring money) to be duplicated, thus harming the site orthe user.¶
• Attackers can store and replay 0-RTT messages in order toreorder them with respect to other messages (e.g., movinga delete to after a create).¶
• Exploiting cache timing behavior to discover the content of 0-RTTmessages by replaying a 0-RTT message to a different cache nodeand then using a separate connection to measure request latency,to see if the two requests address the same resource.¶

If data can be replayed a large number of times, additional attacksbecome possible, such as making repeated measurements of thespeed of cryptographic operations. In addition, they maybe able to overload rate-limiting systems. For a further description ofthese attacks, see[Mac17].¶

Ultimately, servers have the responsibility to protect themselvesagainst attacks employing 0-RTT data replication. The mechanismsdescribed inSection 8 are intended toprevent replay at the TLS layer but do not provide complete protectionagainst receiving multiple copies of client data.TLS 1.3 falls back to the 1-RTThandshake when the server does not have any information about theclient, e.g., because it is in a different cluster which does notshare state or because the ticket has been deleted as described inSection 8.1. If the application-layer protocol retransmitsdata in this setting, then it is possible for an attacker to inducemessage duplication by sending the ClientHello to both the original cluster(which processes the data immediately) and another cluster which willfall back to 1-RTT and process the data upon application-layerreplay. The scale of this attack is limited by the client'swillingness to retry transactions and therefore only allows a limited amountof duplication, with each copy appearing as a new connection atthe server.¶

If implemented correctly, the mechanisms described inSection 8.1 andSection 8.2 prevent areplayed ClientHello and its associated 0-RTT data from being acceptedmultiple times by any cluster with consistent state; for serverswhich limit the use of 0-RTT to one cluster for a single ticket, then a givenClientHello 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 beaccepted during the replication window.Because clients do not know the exact details of server behavior, theyMUST NOT send messages in early data which are not safe to havereplayed and which they would not be willing to retry across multiple1-RTT connections.¶

Application protocols MUST NOT use 0-RTT data without a profile thatdefines its use. That profile needs to identify which messages orinteractions are safe to use with 0-RTT and how to handle thesituation when the server rejects 0-RTT and falls back to 1-RTT.¶

In addition, to avoid accidental misuse, TLS implementations MUST NOTenable 0-RTT (either sending or accepting) unless specificallyrequested by the application and MUST NOT automatically resend 0-RTTdata if it is rejected by the server unless instructed by theapplication. Server-side applications may wish to implement specialprocessing for 0-RTT data for some kinds of application traffic (e.g.,abort the connection, request that data be resent at the applicationlayer, or delay processing until the handshake completes). In order toallow applications to implement this kind of processing, TLSimplementations MUST provide a way for the application to determine ifthe handshake has completed.¶

F.6.PSK Identity Exposure

Because implementations respond to an invalid PSK binder by abortingthe handshake, it may be possible for an attacker to verify whethera given PSK identity is valid. Specifically, if a server acceptsboth external-PSK and certificate-based handshakes, a valid PSK identitywill result in a failed handshake, whereas an invalid identity willjust be skipped and result in a successful certificate handshake.Servers which solely support PSK handshakes may be able to resistthis form of attack by treating the cases where there is novalid PSK identity and where there is an identity but it has aninvalid binder identically.¶

F.7.Sharing PSKs

TLS 1.3 takes a conservative approach to PSKs by binding them to aspecific KDF. By contrast, TLS 1.2 allows PSKs to be used with anyhash function and the TLS 1.2 PRF. Thus, any PSK which is used withboth TLS 1.2 and TLS 1.3 must be used with only one hash in TLS 1.3,which is less than optimal if users want to provision a single PSK.The constructions in TLS 1.2 and TLS 1.3 are different, although theyare both based on HMAC. While there is no known way in which thesame PSK might produce related output in both versions, only limitedanalysis has been done. Implementations can ensure safety fromcross-protocol related output by not reusing PSKs between TLS 1.3 andTLS 1.2.¶

F.8.Attacks on Static RSA

Although TLS 1.3 does not use RSA key transport and so is notdirectly susceptible to Bleichenbacher-type attacks[Blei98]if TLS 1.3servers also support static RSA in the context of previousversions of TLS, then it may be possible to impersonate the serverfor TLS 1.3 connections[JSS15]. TLS1.3 implementations can prevent this attack by disabling supportfor static RSA across all versions of TLS. In principle, implementationsmight also be able to separate certificates with different keyUsagebits for static RSA decryption and RSA signature, but this techniquerelies on clients refusing to accept signatures using keysin certificates that do not have the digitalSignature bit set,and many clients do not enforce this restriction.¶