4.  Handshake Protocol

   The handshake protocol is used to negotiate the security parameters
   of a connection.  Handshake messages are supplied to the TLS record
   layer, where they are encapsulated within one or more TLSPlaintext or
   TLSCiphertext structures which are processed and transmitted as
   specified by the current active connection state.

      enum {
          client_hello(1),
          server_hello(2),
          new_session_ticket(4),
          end_of_early_data(5),
          encrypted_extensions(8),
          certificate(11),
          certificate_request(13),
          certificate_verify(15),
          finished(20),
          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;

   Protocol messages MUST be sent in the order defined in Section 4.4.1
   and shown in the diagrams in Section 2.  A peer which receives a
   handshake message in an unexpected order MUST abort the handshake
   with an "unexpected_message" alert.

   New handshake message types are assigned by IANA as described in
   Section 11.

4.1.  Key Exchange Messages

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

4.1.1.  Cryptographic Negotiation

   In TLS, the cryptographic negotiation proceeds by the client offering
   the following four sets of options in its ClientHello:

   -  A list of cipher suites which indicates the AEAD algorithm/HKDF
      hash pairs which the client supports.

   -  A "supported_groups" (Section 4.2.7) extension which indicates the
      (EC)DHE groups which the client supports and a "key_share"
      (Section 4.2.8) extension which contains (EC)DHE shares for some
      or all of these groups.

   -  A "signature_algorithms" (Section 4.2.3) extension which indicates
      the signature algorithms which the client can accept.  A
      "signature_algorithms_cert" extension (Section 4.2.3) may also be
      added to indicate certificate-specific signature algorithms.

   -  A "pre_shared_key" (Section 4.2.11) extension which contains a
      list of symmetric key identities known to the client and a
      "psk_key_exchange_modes" (Section 4.2.9) extension which indicates
      the key exchange modes that may be used with PSKs.

   If the server does not select a PSK, then the first three of these
   options are entirely orthogonal: the server independently selects a
   cipher suite, an (EC)DHE group and key share for key establishment,
   and a signature algorithm/certificate pair to authenticate itself to
   the client.  If there is no overlap between the received
   "supported_groups" and the groups supported by the server, then the
   server MUST abort the handshake with a "handshake_failure" or an
   "insufficient_security" alert.

   If the server selects a PSK, then it MUST also select a key
   establishment mode from the set indicated by the client's
   "psk_key_exchange_modes" extension (at present, PSK alone or with
   (EC)DHE).  Note that if the PSK can be used without (EC)DHE, then
   non-overlap in the "supported_groups" parameters need not be fatal,
   as it is in the non-PSK case discussed in the previous paragraph.

   If the server selects an (EC)DHE group and the client did not offer a
   compatible "key_share" extension in the initial ClientHello, the
   server MUST respond with a HelloRetryRequest (Section 4.1.4) message.

   If the server successfully selects parameters and does not require a
   HelloRetryRequest, it indicates the selected parameters in the
   ServerHello as follows:

   -  If PSK is being used, then the server will send a "pre_shared_key"
      extension indicating the selected key.

   -  When (EC)DHE is in use, the server will also provide a "key_share"
      extension.  If PSK is not being used, then (EC)DHE and
      certificate-based authentication are always used.

   -  When authenticating via a certificate, the server will send the
      Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3)
      messages.  In TLS 1.3 as defined by this document, either a PSK or
      a certificate is always used, but not both.  Future documents may
      define how to use them together.

   If the server is unable to negotiate a supported set of parameters
   (i.e., there is no overlap between the client and server parameters),
   it MUST abort the handshake with either a "handshake_failure" or
   "insufficient_security" fatal alert (see Section 6).

4.1.2.  Client Hello

   When a client first connects to a server, it is REQUIRED to send the
   ClientHello as its first TLS message.  The client will also send a
   ClientHello when the server has responded to its ClientHello with a
   HelloRetryRequest.  In that case, the client MUST send the same
   ClientHello without modification, except as follows:

   -  If a "key_share" extension was supplied in the HelloRetryRequest,
      replacing the list of shares with a list containing a single
      KeyShareEntry from the indicated group.

   -  Removing the "early_data" extension (Section 4.2.10) if one was
      present.  Early data is not permitted after a HelloRetryRequest.

   -  Including a "cookie" extension if one was provided in the
      HelloRetryRequest.

   -  Updating the "pre_shared_key" extension if present by recomputing
      the "obfuscated_ticket_age" and binder values and (optionally)
      removing any PSKs which are incompatible with the server's
      indicated cipher suite.

   -  Optionally adding, removing, or changing the length of the
      "padding" extension [RFC7685].

   -  Other modifications that may be allowed by an extension defined in
      the future and present in the HelloRetryRequest.

   Because TLS 1.3 forbids renegotiation, if a server has negotiated
   TLS 1.3 and receives a ClientHello at any other time, it MUST
   terminate the connection with an "unexpected_message" alert.

   If a server established a TLS connection with a previous version of
   TLS and receives a TLS 1.3 ClientHello in a renegotiation, it MUST
   retain the previous protocol version.  In particular, it MUST NOT
   negotiate TLS 1.3.

   Structure of this message:

      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;

   legacy_version:  In previous versions of TLS, this field was used for
      version negotiation and represented the highest version number
      supported by the client.  Experience has shown that many servers
      do not properly implement version negotiation, leading to "version
      intolerance" in which the server rejects an otherwise acceptable
      ClientHello with a version number higher than it supports.  In
      TLS 1.3, the client indicates its version preferences in the
      "supported_versions" extension (Section 4.2.1) and the
      legacy_version field MUST be set to 0x0303, which is the version
      number for TLS 1.2.  TLS 1.3 ClientHellos are identified as having
      a legacy_version of 0x0303 and a supported_versions extension
      present with 0x0304 as the highest version indicated therein.
      (See Appendix D for details about backward compatibility.)

   random:  32 bytes generated by a secure random number generator.  See
      Appendix C for additional information.

   legacy_session_id:  Versions of TLS before TLS 1.3 supported a
      "session resumption" feature which has been merged with pre-shared
      keys in this version (see Section 2.2).  A client which has a
      cached session ID set by a pre-TLS 1.3 server SHOULD set this
      field to that value.  In compatibility mode (see Appendix D.4),
      this field MUST be non-empty, so a client not offering a
      pre-TLS 1.3 session MUST generate a new 32-byte value.  This value
      need not be random but SHOULD be unpredictable to avoid
      implementations fixating on a specific value (also known as
      ossification).  Otherwise, it MUST be set as a zero-length vector
      (i.e., a zero-valued single byte length field).

   cipher_suites:  A list of the symmetric cipher options supported by
      the client, specifically the record protection algorithm
      (including secret key length) and a hash to be used with HKDF, in
      descending order of client preference.  Values are defined in
      Appendix B.4.  If the list contains cipher suites that the server
      does not recognize, support, or wish to use, the server MUST
      ignore those cipher suites and process the remaining ones as
      usual.  If the client is attempting a PSK key establishment, it
      SHOULD advertise at least one cipher suite indicating a Hash
      associated with the PSK.

   legacy_compression_methods:  Versions of TLS before 1.3 supported
      compression with the list of supported compression methods being
      sent in this field.  For every TLS 1.3 ClientHello, this vector
      MUST contain exactly one byte, set to zero, which corresponds to
      the "null" compression method in prior versions of TLS.  If a
      TLS 1.3 ClientHello is received with any other value in this
      field, the server MUST abort the handshake with an
      "illegal_parameter" alert.  Note that TLS 1.3 servers might
      receive TLS 1.2 or prior ClientHellos which contain other
      compression methods and (if negotiating such a prior version) MUST
      follow the procedures for the appropriate prior version of TLS.

   extensions:  Clients request extended functionality from servers by
      sending data in the extensions field.  The actual "Extension"
      format is defined in Section 4.2.  In TLS 1.3, the use of certain
      extensions is mandatory, as functionality has moved into
      extensions to preserve ClientHello compatibility with previous
      versions of TLS.  Servers MUST ignore unrecognized extensions.

   All versions of TLS allow an extensions field to optionally follow
   the compression_methods field.  TLS 1.3 ClientHello messages always
   contain extensions (minimally "supported_versions", otherwise, they
   will be interpreted as TLS 1.2 ClientHello messages).  However,
   TLS 1.3 servers might receive ClientHello messages without an
   extensions field from prior versions of TLS.  The presence of
   extensions can be detected by determining whether there are bytes
   following the compression_methods field at the end of the
   ClientHello.  Note that this method of detecting optional data
   differs from the normal TLS method of having a variable-length field,
   but it is used for compatibility with TLS before extensions were
   defined.  TLS 1.3 servers will need to perform this check first and
   only attempt to negotiate TLS 1.3 if the "supported_versions"
   extension is present.  If negotiating a version of TLS prior to 1.3,
   a server MUST check that the message either contains no data after
   legacy_compression_methods or that it contains a valid extensions
   block with no data following.  If not, then it MUST abort the
   handshake with a "decode_error" alert.

   In the event that a client requests additional functionality using
   extensions and this functionality is not supplied by the server, the
   client MAY abort the handshake.

   After sending the ClientHello message, the client waits for a
   ServerHello or HelloRetryRequest message.  If early data is in use,
   the client may transmit early Application Data (Section 2.3) while
   waiting for the next handshake message.

4.1.3.  Server Hello

   The server will send this message in response to a ClientHello
   message to proceed with the handshake if it is able to negotiate an
   acceptable set of handshake parameters based on the ClientHello.

   Structure of this message:

      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;

   legacy_version:  In previous versions of TLS, this field was used for
      version negotiation and represented the selected version number
      for the connection.  Unfortunately, some middleboxes fail when
      presented with new values.  In TLS 1.3, the TLS server indicates
      its version using the "supported_versions" extension
      (Section 4.2.1), and the legacy_version field MUST be set to
      0x0303, which is the version number for TLS 1.2.  (See Appendix D
      for details about backward compatibility.)

   random:  32 bytes generated by a secure random number generator.  See
      Appendix C for additional information.  The last 8 bytes MUST be
      overwritten as described below if negotiating TLS 1.2 or TLS 1.1,
      but the remaining bytes MUST be random.  This structure is
      generated by the server and MUST be generated independently of the
      ClientHello.random.

   legacy_session_id_echo:  The contents of the client's
      legacy_session_id field.  Note that this field is echoed even if
      the client's value corresponded to a cached pre-TLS 1.3 session
      which the server has chosen not to resume.  A client which
      receives a legacy_session_id_echo field that does not match what
      it sent in the ClientHello MUST abort the handshake with an
      "illegal_parameter" alert.

   cipher_suite:  The single cipher suite selected by the server from
      the list in ClientHello.cipher_suites.  A client which receives a
      cipher suite that was not offered MUST abort the handshake with an
      "illegal_parameter" alert.

   legacy_compression_method:  A single byte which MUST have the
      value 0.

   extensions:  A list of extensions.  The ServerHello MUST only include
      extensions which are required to establish the cryptographic
      context and negotiate the protocol version.  All TLS 1.3
      ServerHello messages MUST contain the "supported_versions"
      extension.  Current ServerHello messages additionally contain
      either the "pre_shared_key" extension or the "key_share"
      extension, or both (when using a PSK with (EC)DHE key
      establishment).  Other extensions (see Section 4.2) are sent
      separately in the EncryptedExtensions message.

   For reasons of backward compatibility with middleboxes (see
   Appendix D.4), the HelloRetryRequest message uses the same structure
   as the ServerHello, but with Random set to the special value of the
   SHA-256 of "HelloRetryRequest":

     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

   Upon receiving a message with type server_hello, implementations MUST
   first examine the Random value and, if it matches this value, process
   it as described in Section 4.1.4).

   TLS 1.3 has a downgrade protection mechanism embedded in the server's
   random value.  TLS 1.3 servers which negotiate TLS 1.2 or below in
   response to a ClientHello MUST set the last 8 bytes of their Random
   value specially in their ServerHello.

   If negotiating TLS 1.2, TLS 1.3 servers MUST set the last 8 bytes of
   their Random value to the bytes:

     44 4F 57 4E 47 52 44 01

   If negotiating TLS 1.1 or below, TLS 1.3 servers MUST, and TLS 1.2
   servers SHOULD, set the last 8 bytes of their ServerHello.Random
   value to the bytes:

     44 4F 57 4E 47 52 44 00

   TLS 1.3 clients receiving a ServerHello indicating TLS 1.2 or below
   MUST check that the last 8 bytes are not equal to either of these
   values.  TLS 1.2 clients SHOULD also check that the last 8 bytes are
   not equal to the second value if the ServerHello indicates TLS 1.1 or
   below.  If a match is found, the client MUST abort the handshake with
   an "illegal_parameter" alert.  This mechanism provides limited
   protection against downgrade attacks over and above what is provided
   by the Finished exchange: because the ServerKeyExchange, a message
   present in TLS 1.2 and below, includes a signature over both random
   values, it is not possible for an active attacker to modify the

   random values without detection as long as ephemeral ciphers are
   used.  It does not provide downgrade protection when static RSA
   is used.

   Note: This is a change from [RFC5246], so in practice many TLS 1.2
   clients and servers will not behave as specified above.

   A legacy TLS client performing renegotiation with TLS 1.2 or prior
   and which receives a TLS 1.3 ServerHello during renegotiation MUST
   abort the handshake with a "protocol_version" alert.  Note that
   renegotiation is not possible when TLS 1.3 has been negotiated.

4.1.4.  Hello Retry Request

   The server will send this message in response to a ClientHello
   message if it is able to find an acceptable set of parameters but the
   ClientHello does not contain sufficient information to proceed with
   the handshake.  As discussed in Section 4.1.3, the HelloRetryRequest
   has the same format as a ServerHello message, and the legacy_version,
   legacy_session_id_echo, cipher_suite, and legacy_compression_method
   fields have the same meaning.  However, for convenience we discuss
   "HelloRetryRequest" throughout this document as if it were a distinct
   message.

   The server's extensions MUST contain "supported_versions".
   Additionally, it SHOULD contain the minimal set of extensions
   necessary for the client to generate a correct ClientHello pair.  As
   with the ServerHello, a HelloRetryRequest MUST NOT contain any
   extensions that were not first offered by the client in its
   ClientHello, with the exception of optionally the "cookie" (see
   Section 4.2.2) extension.

   Upon receipt of a HelloRetryRequest, the client MUST check the
   legacy_version, legacy_session_id_echo, cipher_suite, and
   legacy_compression_method as specified in Section 4.1.3 and then
   process the extensions, starting with determining the version using
   "supported_versions".  Clients MUST abort the handshake with an
   "illegal_parameter" alert if the HelloRetryRequest would not result
   in any change in the ClientHello.  If a client receives a second
   HelloRetryRequest in the same connection (i.e., where the ClientHello
   was itself in response to a HelloRetryRequest), it MUST abort the
   handshake with an "unexpected_message" alert.

   Otherwise, the client MUST process all extensions in the
   HelloRetryRequest and send a second updated ClientHello.  The
   HelloRetryRequest extensions defined in this specification are:

   -  supported_versions (see Section 4.2.1)

   -  cookie (see Section 4.2.2)

   -  key_share (see Section 4.2.8)

   A client which receives a cipher suite that was not offered MUST
   abort the handshake.  Servers MUST ensure that they negotiate the
   same cipher suite when receiving a conformant updated ClientHello (if
   the server selects the cipher suite as the first step in the
   negotiation, then this will happen automatically).  Upon receiving
   the ServerHello, clients MUST check that the cipher suite supplied in
   the ServerHello is the same as that in the HelloRetryRequest and
   otherwise abort the handshake with an "illegal_parameter" alert.

   In addition, in its updated ClientHello, the client SHOULD NOT offer
   any pre-shared keys associated with a hash other than that of the
   selected cipher suite.  This allows the client to avoid having to
   compute partial hash transcripts for multiple hashes in the second
   ClientHello.

   The value of selected_version in the HelloRetryRequest
   "supported_versions" extension MUST be retained in the ServerHello,
   and a client MUST abort the handshake with an "illegal_parameter"
   alert if the value changes.