Appendix A.  State Machine

   This appendix provides a summary of the legal state transitions for
   the client and server handshakes.  State names (in all capitals,
   e.g., START) have no formal meaning but are provided for ease of
   comprehension.  Actions which are taken only in certain circumstances
   are indicated in [].  The notation "K_{send,recv} = foo" means "set
   the send/recv key to the given key".

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
   alerts that derive from post-ServerHello messages in the clear or
   with the early data keys.  If clients need to send such alerts, they
   SHOULD first 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 Finished
 after   -->                    | K_send = application
 here                  +--------+--------+
              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 |                 | 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

Appendix B.  Protocol Data Structures and Constant Values

   This appendix provides the normative protocol types and the
   definitions for constants.  Values listed as "_RESERVED" were used in
   previous versions of TLS and are listed here for completeness.
   TLS 1.3 implementations MUST NOT send them but might receive them
   from older TLS implementations.

B.1.  Record Layer

      enum {
          invalid(0),
          change_cipher_spec(20),
          alert(21),
          handshake(22),
          application_data(23),
          heartbeat(24),  /* RFC 6520 */
          (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;             /* 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;

B.3.1.  Key Exchange Messages

    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 */
        RESERVED(40),                               /* Used but never
                                                       assigned */
        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 */
        RESERVED(46),                               /* Used but never
                                                       assigned */
        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;

B.3.1.1.  Version Extension

      struct {
          select (Handshake.msg_type) {
              case client_hello:
                   ProtocolVersion versions<2..254>;

              case server_hello: /* and HelloRetryRequest */
                   ProtocolVersion selected_version;
          };
      } SupportedVersions;

B.3.1.2.  Cookie Extension

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

B.3.1.3.  Signature Algorithm Extension

      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;

B.3.1.4.  Supported Groups Extension

      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;

   Values within "obsolete_RESERVED" ranges are used in previous
   versions of TLS and MUST NOT be offered or negotiated by TLS 1.3
   implementations.  The obsolete curves have various known/theoretical
   weaknesses or have had very little usage, in some cases only due to
   unintentional server configuration issues.  They are no longer
   considered appropriate for general use and should be assumed to be
   potentially unsafe.  The set of curves specified here is sufficient
   for interoperability with all currently deployed and properly
   configured TLS implementations.

B.3.2.  Server Parameters Messages

      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<2..2^16-1>;
      } CertificateRequest;

B.3.3.  Authentication Messages

      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;

B.3.4.  Ticket Establishment

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

B.3.5.  Updating Keys

      struct {} EndOfEarlyData;

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

      struct {
          KeyUpdateRequest request_update;
      } KeyUpdate;

B.4.  Cipher Suites

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

      CipherSuite TLS_AEAD_HASH = VALUE;

      +-----------+------------------------------------------------+
      | Component | Contents                                       |
      +-----------+------------------------------------------------+
      | TLS       | The string "TLS"                               |
      |           |                                                |
      | AEAD      | The AEAD algorithm used for record protection  |
      |           |                                                |
      | HASH      | The hash algorithm used with HKDF              |
      |           |                                                |
      | VALUE     | The two-byte ID assigned for this cipher suite |
      +-----------+------------------------------------------------+

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

              +------------------------------+-------------+
              | Description                  | Value       |
              +------------------------------+-------------+
              | TLS_AES_128_GCM_SHA256       | {0x13,0x01} |
              |                              |             |
              | TLS_AES_256_GCM_SHA384       | {0x13,0x02} |
              |                              |             |
              | TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
              |                              |             |
              | TLS_AES_128_CCM_SHA256       | {0x13,0x04} |
              |                              |             |
              | TLS_AES_128_CCM_8_SHA256     | {0x13,0x05} |
              +------------------------------+-------------+

   The corresponding AEAD algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM,
   and AEAD_AES_128_CCM are defined in [RFC5116].
   AEAD_CHACHA20_POLY1305 is defined in [RFC8439].  AEAD_AES_128_CCM_8
   is defined in [RFC6655].  The corresponding hash algorithms are
   defined in [SHS].

   Although TLS 1.3 uses the same cipher suite space as previous
   versions of TLS, TLS 1.3 cipher suites are defined differently, only
   specifying the 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 in
   Section 11.

Appendix C.  Implementation Notes

   The TLS protocol cannot prevent many common security mistakes.  This
   appendix provides several recommendations to assist implementors.
   [TLS13-TRACES] provides test vectors for TLS 1.3 handshakes.

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 such as /dev/urandom, which should be used
   absent other (e.g., performance) concerns.  It is RECOMMENDED to use
   an existing CSPRNG implementation in preference to crafting a new
   one.  Many adequate cryptographic libraries are already available
   under favorable license terms.  Should those prove unsatisfactory,
   [RFC4086] provides guidance on the generation of random values.

   TLS uses random values (1) in public protocol fields such as the
   public Random values in the ClientHello and ServerHello and (2) to
   generate keying material.  With a properly functioning CSPRNG, this
   does not present a security problem, as it is not feasible to
   determine the CSPRNG state from its output.  However, with a broken
   CSPRNG, it may be possible for an attacker to use the public output
   to determine the CSPRNG internal state and thereby predict the keying
   material, as documented in [CHECKOWAY].  Implementations can provide
   extra security against this form of attack by using separate CSPRNGs
   to generate public and private values.

C.2.  Certificates and Authentication

   Implementations are responsible for verifying the integrity of
   certificates and should generally support certificate revocation
   messages.  Absent a specific indication from an application profile,
   certificates should always 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 or 224-bit ECDSA are not appropriate for secure
   applications.

C.3.  Implementation Pitfalls

   Implementation experience has shown that certain parts of earlier TLS
   specifications are not easy to understand and have been a source of
   interoperability and security problems.  Many of these areas have
   been clarified in this document, but this appendix contains a short
   list of the most important things that require special attention from
   implementors.

   TLS protocol issues:

   -  Do you correctly handle handshake messages that are fragmented to
      multiple TLS records (see Section 5.1)?  Do you correctly handle
      corner cases like a ClientHello that is split into several small
      fragments?  Do you fragment handshake messages that exceed the
      maximum fragment size?  In particular, the Certificate and
      CertificateRequest handshake messages can be large enough to
      require fragmentation.

   -  Do you ignore the TLS record layer version number in all
      unencrypted TLS records (see Appendix D)?

   -  Have you ensured that all support for SSL, RC4, EXPORT ciphers,
      and MD5 (via the "signature_algorithms" extension) is completely
      removed from all possible configurations that support TLS 1.3 or
      later, and that attempts to use these obsolete capabilities fail
      correctly (see Appendix D)?

   -  Do you handle TLS extensions in ClientHellos correctly, including
      unknown extensions?

   -  When the server has requested a client certificate but no suitable
      certificate is available, do you correctly send an empty
      Certificate message, instead of omitting the whole message (see
      Section 4.4.2)?

   -  When processing the plaintext fragment produced by AEAD-Decrypt
      and scanning from the end for the ContentType, do you avoid
      scanning past the start of the cleartext in the event that the
      peer has sent a 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 the ClientHello?

   -  As a server, do you send a HelloRetryRequest to clients which
      support a compatible (EC)DHE group but do not predict it in the
      "key_share" extension?  As a client, do you correctly handle a
      HelloRetryRequest from the server?

   Cryptographic details:

   -  What countermeasures do you use to prevent timing attacks
      [TIMING]?

   -  When using Diffie-Hellman key exchange, do you correctly preserve
      leading zero bytes in the negotiated key (see Section 7.4.1)?

   -  Does your TLS client check that the Diffie-Hellman parameters sent
      by the server are acceptable (see Section 4.2.8.1)?

   -  Do you use a strong and, most importantly, properly seeded random
      number generator (see Appendix C.1) when generating Diffie-Hellman
      private values, the ECDSA "k" parameter, and other security-
      critical values?  It is RECOMMENDED that implementations implement
      "deterministic ECDSA" as specified in [RFC6979].

   -  Do you zero-pad Diffie-Hellman public key values and shared
      secrets to the group size (see Section 4.2.8.1 and Section 7.4.1)?

   -  Do you verify signatures after making them, to protect against
      RSA-CRT key leaks [FW15]?

C.4.  Client Tracking Prevention

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

C.5.  Unauthenticated Operation

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

   -  Raw public keys [RFC7250].

   -  Using a public key contained in a certificate but without
      validation of the certificate chain or any of its contents.

   Either technique used alone is vulnerable to man-in-the-middle
   attacks and therefore unsafe for general use.  However, it is also
   possible to bind such connections to an external authentication
   mechanism via out-of-band validation of the server's public key,
   trust on first use, or a mechanism such as channel bindings (though
   the channel bindings described in [RFC5929] are not defined for
   TLS 1.3).  If no such mechanism is used, then the connection has no
   protection against active man-in-the-middle attack; applications
   MUST NOT use TLS in such a way absent explicit configuration or a
   specific application profile.

Appendix D.  Backward Compatibility

   The TLS protocol provides a built-in mechanism for version
   negotiation between endpoints potentially supporting different
   versions of TLS.

   TLS 1.x and SSL 3.0 use compatible ClientHello messages.  Servers can
   also handle clients trying to use future versions of TLS as long as
   the ClientHello format remains compatible and there is at least one
   protocol version supported by both the client and the server.

   Prior versions of TLS used the record layer version number
   (TLSPlaintext.legacy_record_version and
   TLSCiphertext.legacy_record_version) for various purposes.  As of
   TLS 1.3, this field is deprecated.  The value of
   TLSPlaintext.legacy_record_version MUST be ignored by all
   implementations.  The value of TLSCiphertext.legacy_record_version is
   included in the additional data for deprotection but MAY otherwise be
   ignored or MAY be validated to match the fixed constant value.
   Version negotiation is performed using only the handshake versions
   (ClientHello.legacy_version and ServerHello.legacy_version, as well
   as the ClientHello, HelloRetryRequest, and ServerHello
   "supported_versions" extensions).  In order to maximize
   interoperability with older endpoints, implementations that negotiate
   the use of TLS 1.0-1.2 SHOULD set the record layer version number to
   the negotiated version for the ServerHello and all records
   thereafter.

   For maximum compatibility with previously non-standard behavior and
   misconfigured deployments, all implementations SHOULD support
   validation of certification paths based on the expectations in this
   document, even when handling prior TLS versions' handshakes (see
   Section 4.4.2.2).

   TLS 1.2 and prior supported an "Extended Master Secret" [RFC7627]
   extension which digested large parts of the handshake transcript into
   the master secret.  Because TLS 1.3 always hashes in the transcript
   up to the server Finished, implementations which support both TLS 1.3
   and earlier versions SHOULD indicate the use of the Extended Master
   Secret extension in their APIs whenever TLS 1.3 is used.

D.1.  Negotiating with an Older Server

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

   Note that 0-RTT data is not compatible with older servers and
   SHOULD NOT be sent absent knowledge that the server supports TLS 1.3.
   See Appendix D.3.

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

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

D.2.  Negotiating with an Older Client

   A TLS server can also receive a ClientHello indicating a version
   number smaller than its highest supported version.  If the
   "supported_versions" extension is present, the server MUST negotiate
   using that extension as described in Section 4.2.1.  If the
   "supported_versions" extension is not present, the server MUST
   negotiate the minimum of ClientHello.legacy_version and 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 supports versions greater than
   ClientHello.legacy_version, the server MUST abort the handshake with
   a "protocol_version" alert.

   Note that earlier versions of TLS did not clearly specify the record
   layer version number value in all cases
   (TLSPlaintext.legacy_record_version).  Servers will receive various
   TLS 1.x versions in this field, but its value MUST always be ignored.

D.3.  0-RTT Backward Compatibility

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

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

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

D.4.  Middlebox Compatibility Mode

   Field measurements [Ben17a] [Ben17b] [Res17a] [Res17b] have found
   that a significant number of middleboxes misbehave when a TLS
   client/server pair negotiates TLS 1.3.  Implementations can increase
   the chance of making connections through those middleboxes by 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 of
      Section 4.1.2.

   -  If not offering early data, the client sends a dummy
      change_cipher_spec record (see the third paragraph of Section 5)
      immediately before its second flight.  This may either be before
      its second ClientHello or before its encrypted handshake flight.
      If offering early data, the record is placed immediately after the
      first ClientHello.

   -  The server sends a dummy change_cipher_spec record immediately
      after its first handshake message.  This may either be after a
      ServerHello or a HelloRetryRequest.

   When put together, these changes make the TLS 1.3 handshake resemble
   TLS 1.2 session resumption, which improves the chance of successfully
   connecting through middleboxes.  This "compatibility mode" is
   partially negotiated: the client can opt to provide a session ID or
   not, and the server has to echo it.  Either side can send

   change_cipher_spec at 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 send the change_cipher_spec as described in this
   appendix.

D.5.  Security Restrictions Related to Backward Compatibility

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

   The security of RC4 cipher suites is considered insufficient for the
   reasons cited in [RFC7465].  Implementations MUST NOT offer or
   negotiate RC4 cipher suites for 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 or
   negotiated for any version of TLS for any reason.

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

   The security of SSL 2.0 [SSL2] is considered insufficient for the
   reasons enumerated in [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 compatible CLIENT-HELLO.  Implementations
   are NOT RECOMMENDED to accept an SSL version 2.0 compatible
   CLIENT-HELLO in order to negotiate older versions of TLS.

   Implementations MUST NOT send a ClientHello.legacy_version or
   ServerHello.legacy_version set to 0x0300 or less.  Any endpoint
   receiving a Hello message with ClientHello.legacy_version or
   ServerHello.legacy_version set to 0x0300 MUST abort 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 in
   Section 7 of [RFC6066], as it is not applicable to AEAD algorithms
   and has been shown to be insecure in some scenarios.