Client                                               Server

     ClientHello
       + ClientKeyShare        -------->
                                                     ServerHello
                                                  ServerKeyShare
                                           {EncryptedExtensions}
                                          {ServerConfiguration*}
                                                   {Certificate}
                                             {CertificateVerify}
                               <--------              {Finished}
     {Finished}                -------->
     [Application Data]        <------->      [Application Data]

            *  Indicates optional or situation-dependent
               messages that are not always sent.

            {} Indicates messages protected using keys
               derived from the ephemeral secret.

            [] Indicates messages protected using keys
               derived from the master secret.

Figure 1: Message flow for full TLS Handshake

Note: Although these diagrams indicate a message called “Certificate”, this message MAY either contain a bare public key or an X.509 certificate (this is intended to support the out-of-band use case indicated above). Implementations MUST support bare public keys and MAY support X.509 certificates.

3.1.2. Basic 1-RTT Handshake

3.1.2.1. Client’s First Flight

3.1.2.1.1. Sending

In order to initiate the TLS handshake, the client sends a “ClientHello” message [S. 6.3.1.1].

       struct {
           ProtocolVersion client_version = { 3, 4 };    /* TLS v1.3 */
           Random random;
           uint8 session_id_len_RESERVED;                /* Must be zero */
           CipherSuite cipher_suites<2..2^16-2>;
           uint8 compression_methods_len_RESERVED;       /* Must be zero */
           Extension extensions<0..2^16-1>;
       } ClientHello;

The fields listed here have the following meanings:

client_version

The version of the TLS protocol by which the client wishes to communicate during this session.

random

A 32-byte random nonce.

cipher_suites

This is a list of the cryptographic options supported by the client, with the client’s first preference first.

extensions contains a set of extension fields. The client MUST include the following extensions:

SignatureAlgorithms [S. 6.3.2.1]

A list of signature/hash algorithm pairs the client supports.

NamedGroup [S. 6.3.2.2]

A list of ECDHE groups that the client supports

ClientKeyShare [S. 6.3.2.3]

Zero or more ECDHE shares drawn from the groups in NamedGroup. This SHOULD contain either a P-256 key or an X25519 key.

The client MUST also include a ServerCertTypeExtension containing type “Raw Public Key” [RFC7250], indicating its willingness to accept a raw public key rather than an X.509 certificate in the server’s Certificate message.

3.1.2.1.2. Receiving

Upon receiving the client’s ClientHello, the server selects a ciphersuite and ECDHE group out of the lists provided by the client in the cipher_suites list and the NamedGroup extension. If the client supplied an appropriate ClientKeyShare for that group, then the server responds with a ServerHello (see {{server-first-flight). Otherwise, it replies with a HelloRetryRequest (Section 3.1.3), indicating that the client needs to re-send the ClientHello with an appropriate key share; because all TCPINC implementations are required to support P-256, this should not happen unless P-256 is deprecated by a subsequent specification.

3.1.2.2. Server’s First Flight

3.1.2.2.1. Sending

The server respond’s to the client’s first flight with a sequence of messages:

ServerHello [6.3.1.2]

Contains a nonce and the cipher suite that the server has selected out of the client’s list. The server MUST support the extensions listed in Section 3.1.2.1.1 and MUST also ignore any extensions it does not recognize; this implies that the server can implement solely the extensions listed in Section 3.1.2.1.1.

ServerKeyShare [6.3.3]

Contains the server’s ECDHE share for one of the groups offered in the client’s ClientKeyShare message. All messages after ServerKeyShare are encrypted using keys derived from the ClientKeyShare and ServerKeyShare.

EncryptedExtensions [6.3.4]

Responses to the extensions offered by the client. In this case, the only relevant extension is the ServerCertTypeExtension.

Certificate [6.3.5]

The server’s certificate. If the client offered a “Raw Public Key” type in ServerCertTypeExtension this message SHALL contain a SubjectPublicKeyInfo value for the server’s key as specified in [RFC7250]. Otherwise, it SHALL contain one or more X.509 Certificates, as specified in [I-D.ietf-tls-tls13], Section 6.3.5. In either case, this message MUST contain a key which is consistent with the client’s SignatureAlgorithms and NamedGroup extensions.

ServerConfiguration [6.3.7]

A server configuration value for use in 0-RTT (see Section 3.1.4).

CertificateVerify [6.3.8]

A signature over the handshake transcript using the key provided in the certificate message.

Finished [6.3.9]

A MAC over the entire handshake transcript up to this point.

Once the server has sent the Finished message, it can immediately generate the application traffic keys and start sending application traffic to the client.

3.1.2.3. Receiving

Upon receiving the server’s first flight, the client proceeds as follows:

• Read the ServerHello message to determine the cryptographic parameters.
• Read the ServerKeyShare message and use that in combination with the ClientKeyShare to compute the keys which are used to encrypt the rest of the handshake.
• Read the EncryptedExtensions message. As noted above, the main extension which needs to be processed is ServerCertTypeExtension, which indicates the format of the server’s certificate message.
• Read the server’s certificate message and store the server’s public key. Unless the implementation is specifically configured otherwise, it SHOULD NOT attempt to validate the certificate, even if it is of type X.509 but merely extract the key.
• Read the server’s CertificateVerify message and verify the server’s signature over the handshake transcript. If the signature does not verify, the client terminates the handshake with an alert (Section 6.1.2).
• Read the server’s Finished message and verify the finished MAC based on the DH shared secret. If the MAC does not verify, the client terminates the handshake with an alert.

3.1.2.4. Client’s Second Flight

Finally, the client sends a Finished message which contains a MAC over the handshake transcript (except for the server’s Finished). [[TODO: In the upcoming draft of TLS 1.3, the client’s Finished will likely include the server’s Finished.]] Once the client has transmitted the Finished, it can begin sending encrypted traffic to the server.

The server reads the client’s Finished message and verifies the MAC. If the MAC does not verify, the client terminates the handshake with an alert.

3.1.3. Hello Retry Request [6.3.1.3]

Because there are a small number of recommended groups, the ClientKeyShare will generally contain a key share for a group that the server supports. However, it is possible that the client will not send such a key share, but there may be another group that the client and server jointly support. In that case, the server MUST send a HelloRetryRequest indicating the desired group:

      struct {
          ProtocolVersion server_version;
          CipherSuite cipher_suite;
          NamedGroup selected_group;
          Extension extensions<0..2^16-1>;
      } HelloRetryRequest;

In response to the HelloRetryRequest the client re-sends its ClientHello but with the addition of the group indicated in “selected_group”.

3.1.4. Zero-RTT Exchange

TLS 1.3 allows the server to send its first application data message to the client immediately upon receiving the client’s first handshake message (which the client can send upon receiving the server’s SYN/ACK). However, in the basic handshake, the client is required to wait for the server’s first flight before it can send to the server. TLS 1.3 also includes a “Zero-RTT” feature which allows the client to send data on its first flight to the server.

In order to enable this feature, in an initial handshake the server sends a ServerConfiguration message which contains the server’s semi-static (EC)DH key which can be used for a future handshake:

      struct {
          opaque configuration_id<1..2^16-1>;
          uint32 expiration_date;
          NamedGroup group;
          opaque server_key<1..2^16-1>;
          EarlyDataType early_data_type;
          ConfigurationExtension extensions<0..2^16-1>;
      } ServerConfiguration;

The group and server_key fields contain the server’s (EC)DH key and the early_data_type field is used to indicate what data can be sent in zero-RTT. Because client authentication is forbidden in TCPINC-uses of TLS 1.3 (see Section 3.3), the only valid value here is “early_data”, indicating that the client can send data in 0-RTT.

When a ServerConfiguration is available, the client can send an EarlyDataIndication extension in its ClientHello and then start sending data immediately, as shown below.

       Client                                               Server

       ClientHello
         + ClientKeyShare
         + EarlyDataIndication
       (EncryptedExtensions)
       (Application Data)        -------->
                                                       ServerHello
                                             + EarlyDataIndication
                                                    ServerKeyShare
                                             {EncryptedExtensions}
                                            {ServerConfiguration*}
                                                     {Certificate}
                                               {CertificateVerify}
                                 <--------              {Finished}
       {Finished}                -------->

       [Application Data]        <------->      [Application Data]

            () Indicates messages protected using keys
               derived from the static secret.

       struct {
           ContentType opaque_type = application_data(23); /* see fragment.type */
           ProtocolVersion record_version = { 3, 1 };    /* TLS v1.x */
           uint16 length;
           aead-ciphered struct {
              opaque content[TLSPlaintext.length];
              ContentType type;
              uint8 zeros[length_of_padding];
           } fragment;
       } TLSCiphertext;

    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 

    TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384