4.3.  Server Parameters

   The next two messages from the server, EncryptedExtensions and
   CertificateRequest, contain information from the server that
   determines the rest of the handshake.  These messages are encrypted
   with keys derived from the server_handshake_traffic_secret.

4.3.1.  Encrypted Extensions

   In all handshakes, the server MUST send the EncryptedExtensions
   message immediately after the ServerHello message.  This is the first
   message that is encrypted under keys derived from the
   server_handshake_traffic_secret.

   The EncryptedExtensions message contains extensions that can be
   protected, i.e., any which are not needed to establish the
   cryptographic context but which are not associated with individual
   certificates.  The client MUST check EncryptedExtensions for the
   presence of any forbidden extensions and if any are found MUST abort
   the handshake with an "illegal_parameter" alert.

   Structure of this message:

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

   extensions:  A list of extensions.  For more information, see the
      table in Section 4.2.

4.3.2.  Certificate Request

   A server which is authenticating with a certificate MAY optionally
   request a certificate from the client.  This message, if sent, MUST
   follow EncryptedExtensions.

   Structure of this message:

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

   certificate_request_context:  An opaque string which identifies the
      certificate request and which will be echoed in the client's
      Certificate message.  The certificate_request_context MUST be
      unique within the scope of this connection (thus preventing replay
      of client CertificateVerify messages).  This field SHALL be zero
      length unless used for the post-handshake authentication exchanges
      described in Section 4.6.2.  When requesting post-handshake
      authentication, the server SHOULD make the context unpredictable
      to the client (e.g., by randomly generating it) in order to
      prevent an attacker who has temporary access to the client's
      private key from pre-computing valid CertificateVerify messages.

   extensions:  A set of extensions describing the parameters of the
      certificate being requested.  The "signature_algorithms" extension
      MUST be specified, and other extensions may optionally be included
      if defined for this message.  Clients MUST ignore unrecognized
      extensions.

   In prior versions of TLS, the CertificateRequest message carried a
   list of signature algorithms and certificate authorities which the
   server would accept.  In TLS 1.3, the former is expressed by sending
   the "signature_algorithms" and optionally "signature_algorithms_cert"
   extensions.  The latter is expressed by sending the
   "certificate_authorities" extension (see Section 4.2.4).

   Servers which are authenticating with a PSK MUST NOT send the
   CertificateRequest message in the main handshake, though they MAY
   send it in post-handshake authentication (see Section 4.6.2) provided
   that the client has sent the "post_handshake_auth" extension (see
   Section 4.2.6).

4.4.  Authentication Messages

   As discussed in Section 2, TLS generally uses a common set of
   messages for authentication, key confirmation, and handshake
   integrity: Certificate, CertificateVerify, and Finished.  (The PSK
   binders also perform key confirmation, in a similar fashion.)  These
   three messages are always sent as the last messages in their
   handshake flight.  The Certificate and CertificateVerify messages are
   only sent under certain circumstances, as defined below.  The
   Finished message 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 uniformly take
   the following inputs:

   -  The certificate and signing key to be used.

   -  A Handshake Context consisting of the set of messages to be
      included 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 any
      supporting certificates in the chain.  Note that certificate-based
      client 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 Key
   for each scenario:

   +-----------+-------------------------+-----------------------------+
   | Mode      | Handshake Context       | Base Key                    |
   +-----------+-------------------------+-----------------------------+
   | Server    | ClientHello ... later   | server_handshake_traffic_   |
   |           | of EncryptedExtensions/ | secret                      |
   |           | CertificateRequest      |                             |
   |           |                         |                             |
   | Client    | ClientHello ... later   | client_handshake_traffic_   |
   |           | of server               | secret                      |
   |           | Finished/EndOfEarlyData |                             |
   |           |                         |                             |
   | Post-     | ClientHello ... client  | client_application_traffic_ |
   | Handshake | Finished +              | secret_N                    |
   |           | CertificateRequest      |                             |
   +-----------+-------------------------+-----------------------------+

4.4.1.  The Transcript Hash

   Many of the cryptographic computations in TLS make use of a
   transcript hash.  This value is computed by hashing the concatenation
   of each included handshake message, including the handshake message
   header carrying the handshake message type and length fields, but not
   including record layer headers.  I.e.,

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

   As an exception to this general rule, when the server responds to a
   ClientHello with a HelloRetryRequest, the value of ClientHello1 is
   replaced with a special synthetic handshake message of handshake type
   "message_hash" containing Hash(ClientHello1).  I.e.,

  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)

   The reason for this construction is to allow the server to do a
   stateless HelloRetryRequest by storing just the hash of ClientHello1
   in the cookie, rather than requiring it to export the entire
   intermediate hash state (see Section 4.2.2).

   For concreteness, the transcript hash is always taken from the
   following sequence of handshake messages, starting at the first
   ClientHello and including only those messages that were sent:
   ClientHello, HelloRetryRequest, ClientHello, ServerHello,
   EncryptedExtensions, server CertificateRequest, server Certificate,
   server CertificateVerify, server Finished, EndOfEarlyData, client
   Certificate, client CertificateVerify, client Finished.

   In general, implementations can implement the transcript by keeping a
   running transcript hash value based on the negotiated hash.  Note,
   however, that subsequent post-handshake authentications do not
   include each other, just the messages through the end of the main
   handshake.

4.4.2.  Certificate

   This message conveys the endpoint's certificate chain to the peer.

   The server MUST send a Certificate message whenever the agreed-upon
   key exchange method uses certificates for authentication (this
   includes all key exchange methods defined in this document
   except PSK).

   The client MUST send a Certificate message if and only if the server
   has requested client authentication via a CertificateRequest message
   (Section 4.3.2).  If the server requests client authentication but no
   suitable certificate is available, the client MUST send a Certificate
   message containing no certificates (i.e., with the "certificate_list"
   field having length 0).  A Finished message MUST be sent regardless
   of whether the Certificate message is empty.

   Structure of this message:

      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;

   certificate_request_context:  If this message is in response to a
      CertificateRequest, the value of certificate_request_context in
      that message.  Otherwise (in the case of server authentication),
      this field SHALL be zero length.

   certificate_list:  A sequence (chain) of CertificateEntry structures,
      each containing a single certificate and set of extensions.

   extensions:  A set of extension values for the CertificateEntry.  The
      "Extension" format is defined in Section 4.2.  Valid extensions
      for server certificates at present include the OCSP Status
      extension [RFC6066] and the SignedCertificateTimestamp extension
      [RFC6962]; future extensions may be defined for this message as
      well.  Extensions in the Certificate message from the server MUST
      correspond to ones from the ClientHello message.  Extensions in
      the Certificate message from the client MUST correspond to
      extensions in the CertificateRequest message from the server.  If
      an extension applies to the entire chain, it SHOULD be included in
      the first CertificateEntry.

   If the corresponding certificate type extension
   ("server_certificate_type" or "client_certificate_type") was not
   negotiated in EncryptedExtensions, or the X.509 certificate type was
   negotiated, then each CertificateEntry contains a DER-encoded X.509
   certificate.  The sender's certificate MUST come in the first
   CertificateEntry in the list.  Each following certificate SHOULD
   directly certify the one immediately preceding it.  Because
   certificate validation requires that trust anchors be distributed
   independently, a certificate that specifies a trust anchor MAY be
   omitted from the chain, provided that supported peers are known to
   possess any omitted certificates.

   Note: Prior to TLS 1.3, "certificate_list" ordering required each
   certificate to certify the one immediately preceding it; however,
   some implementations allowed some flexibility.  Servers sometimes
   send both a current and deprecated intermediate for transitional
   purposes, and others are simply configured incorrectly, but these
   cases can nonetheless be validated properly.  For maximum
   compatibility, all implementations SHOULD be prepared to handle
   potentially extraneous certificates and arbitrary orderings from any
   TLS version, with the exception of the end-entity certificate which
   MUST be first.

   If the RawPublicKey certificate type was negotiated, then the
   certificate_list MUST contain no more than one CertificateEntry,
   which contains an ASN1_subjectPublicKeyInfo value as defined in
   [RFC7250], Section 3.

   The OpenPGP certificate type [RFC6091] MUST NOT be used with TLS 1.3.

   The server's certificate_list MUST always be non-empty.  A client
   will send an empty certificate_list if it does not have an
   appropriate certificate to send in response to the server's
   authentication request.

4.4.2.1.  OCSP Status and SCT Extensions

   [RFC6066] and [RFC6961] provide extensions to negotiate the server
   sending OCSP responses to the client.  In TLS 1.2 and below, the
   server replies with an empty extension to indicate negotiation of
   this extension and the OCSP information is carried in a
   CertificateStatus message.  In TLS 1.3, the server's OCSP information
   is carried in an extension in the CertificateEntry containing the
   associated certificate.  Specifically, the body of the
   "status_request" extension from the server MUST be a
   CertificateStatus structure as defined in [RFC6066], which is
   interpreted as defined in [RFC6960].

   Note: The status_request_v2 extension [RFC6961] is deprecated.
   TLS 1.3 servers MUST NOT act upon its presence or information in it
   when processing ClientHello messages; in particular, they MUST NOT
   send the status_request_v2 extension in the EncryptedExtensions,
   CertificateRequest, or Certificate messages.  TLS 1.3 servers MUST be
   able to process ClientHello messages that include it, as it MAY be
   sent by clients that wish to use it in earlier protocol versions.

   A server MAY request that a client present an OCSP response with its
   certificate by sending an empty "status_request" extension in its
   CertificateRequest message.  If the client opts to send an OCSP
   response, the body of its "status_request" extension MUST be a
   CertificateStatus structure as defined in [RFC6066].

   Similarly, [RFC6962] provides a mechanism for a server to send a
   Signed Certificate Timestamp (SCT) as an extension in the ServerHello
   in TLS 1.2 and below.  In TLS 1.3, the server's SCT information is
   carried in an extension in the CertificateEntry.

4.4.2.2.  Server Certificate Selection

   The following rules apply to the certificates sent by the server:

   -  The certificate type MUST be X.509v3 [RFC5280], unless explicitly
      negotiated otherwise (e.g., [RFC7250]).

   -  The server's end-entity certificate's public key (and associated
      restrictions) MUST be compatible with the selected authentication
      algorithm from the client's "signature_algorithms" extension
      (currently RSA, ECDSA, or EdDSA).

   -  The certificate MUST allow the key to be used for signing (i.e.,
      the digitalSignature bit MUST be set if the Key Usage extension is
      present) with a signature scheme indicated in the client's
      "signature_algorithms"/"signature_algorithms_cert" extensions (see
      Section 4.2.3).

   -  The "server_name" [RFC6066] and "certificate_authorities"
      extensions are used to guide certificate selection.  As servers
      MAY require the presence of the "server_name" extension, clients
      SHOULD send this extension, when applicable.

   All certificates provided by the server MUST be signed by a signature
   algorithm advertised by the client if it is able to provide such a
   chain (see Section 4.2.3).  Certificates that are self-signed or
   certificates that are expected to be trust anchors are not validated
   as part of the chain and therefore MAY be signed with any algorithm.

   If the server cannot produce a certificate chain that is signed only
   via the indicated supported algorithms, then it SHOULD continue the
   handshake by sending the client a certificate chain of its choice
   that may include algorithms that are not known to be supported by the
   client.  This fallback chain SHOULD NOT use the deprecated SHA-1 hash
   algorithm in general, but MAY do so if the client's advertisement
   permits it, and MUST NOT do so otherwise.

   If the client cannot construct an acceptable chain using the provided
   certificates and decides to abort the handshake, then it MUST abort
   the handshake with an appropriate certificate-related alert (by
   default, "unsupported_certificate"; see Section 6.2 for more
   information).

   If the server has multiple certificates, it chooses one of them based
   on the above-mentioned criteria (in addition to other criteria, such
   as transport-layer endpoint, local configuration, and preferences).

4.4.2.3.  Client Certificate Selection

   The following rules apply to certificates sent by the client:

   -  The certificate type MUST be X.509v3 [RFC5280], unless explicitly
      negotiated otherwise (e.g., [RFC7250]).

   -  If the "certificate_authorities" extension in the
      CertificateRequest message was present, at least one of the
      certificates in the certificate chain SHOULD be issued by one of
      the listed CAs.

   -  The certificates MUST be signed using an acceptable signature
      algorithm, as described in Section 4.3.2.  Note that this relaxes
      the constraints on certificate-signing algorithms found in prior
      versions of TLS.

   -  If the CertificateRequest message contained a non-empty
      "oid_filters" extension, the end-entity certificate MUST match the
      extension OIDs that are recognized by the client, as described in
      Section 4.2.5.

4.4.2.4.  Receiving a Certificate Message

   In general, detailed certificate validation procedures are out of
   scope for TLS (see [RFC5280]).  This section provides TLS-specific
   requirements.

   If the server supplies an empty Certificate message, the client MUST
   abort the handshake with a "decode_error" alert.

   If the client does not send any certificates (i.e., it sends an empty
   Certificate message), the server MAY at its discretion either
   continue the handshake without client authentication or abort the
   handshake with a "certificate_required" alert.  Also, if some aspect
   of the certificate chain was unacceptable (e.g., it was not signed by
   a known, trusted CA), the server MAY at its discretion either
   continue the handshake (considering the client unauthenticated) or
   abort the handshake.

   Any endpoint receiving any certificate which it would need to
   validate using any signature algorithm using an MD5 hash MUST abort
   the handshake with a "bad_certificate" alert.  SHA-1 is deprecated,
   and it is RECOMMENDED that any endpoint receiving any certificate
   which it would need to validate using any signature algorithm using a
   SHA-1 hash abort the handshake with a "bad_certificate" alert.  For
   clarity, this means that endpoints can accept these algorithms for
   certificates that are self-signed or are trust anchors.

   All endpoints are RECOMMENDED to transition to SHA-256 or better as
   soon as possible to maintain interoperability with implementations
   currently in the process of phasing out SHA-1 support.

   Note that a certificate containing a key for one signature algorithm
   MAY be signed using a different signature algorithm (for instance, an
   RSA key signed with an ECDSA key).

4.4.3.  Certificate Verify

   This message is used to provide explicit proof that an endpoint
   possesses the private key corresponding to its certificate.  The
   CertificateVerify message also provides integrity for the handshake
   up to this point.  Servers MUST send this message when authenticating
   via a certificate.  Clients MUST send this message whenever
   authenticating via a certificate (i.e., when the Certificate message
   is non-empty).  When sent, this message MUST appear immediately after
   the Certificate message and immediately prior to the Finished
   message.

   Structure of this message:

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

   The algorithm field specifies the signature algorithm used (see
   Section 4.2.3 for the definition of this type).  The signature is a
   digital signature using that algorithm.  The content that is covered
   under the signature is the hash output as described in Section 4.4.1,
   namely:

      Transcript-Hash(Handshake Context, Certificate)

   The digital signature is then computed over the concatenation of:

   -  A string that consists of octet 32 (0x20) repeated 64 times

   -  The context string

   -  A single 0 byte which serves as the separator

   -  The content to be signed

   This structure is intended to prevent an attack on previous versions
   of TLS in which the ServerKeyExchange format meant that attackers
   could obtain a signature of a message with a chosen 32-byte prefix
   (ClientHello.random).  The initial 64-byte pad clears that prefix
   along with the server-controlled ServerHello.random.

   The context string for a server signature is
   "TLS 1.3, server CertificateVerify".  The context string for a
   client signature is "TLS 1.3, client CertificateVerify".  It is
   used to provide separation between signatures made in different
   contexts, helping against potential cross-protocol attacks.

   For example, if the transcript hash was 32 bytes of 01 (this length
   would make sense for SHA-256), the content covered by the digital
   signature for a server CertificateVerify would be:

      2020202020202020202020202020202020202020202020202020202020202020
      2020202020202020202020202020202020202020202020202020202020202020
      544c5320312e332c207365727665722043657274696669636174655665726966
      79
      00
      0101010101010101010101010101010101010101010101010101010101010101

   On the sender side, the process for computing the signature field of
   the CertificateVerify message takes as input:

   -  The content covered by the digital signature

   -  The private signing key corresponding to the certificate sent in
      the previous message

   If the CertificateVerify message is sent by a server, the signature
   algorithm MUST be one offered in the client's "signature_algorithms"
   extension unless no valid certificate chain can be produced without
   unsupported algorithms (see Section 4.2.3).

   If sent by a client, the signature algorithm used in the signature
   MUST be one of those present in the supported_signature_algorithms
   field of the "signature_algorithms" extension in the
   CertificateRequest message.

   In addition, the signature algorithm MUST be compatible with the key
   in the sender's end-entity certificate.  RSA signatures MUST use an
   RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5
   algorithms appear in "signature_algorithms".  The SHA-1 algorithm
   MUST NOT be used in any signatures of CertificateVerify messages.

   All SHA-1 signature algorithms in this specification are defined
   solely for use in legacy certificates and are not valid for
   CertificateVerify signatures.

   The receiver of a CertificateVerify message MUST verify the signature
   field.  The verification process takes as input:

   -  The content covered by the digital signature

   -  The public key contained in the end-entity certificate found in
      the associated Certificate message

   -  The digital signature received in the signature field of the
      CertificateVerify message

   If the verification fails, the receiver MUST terminate the handshake
   with a "decrypt_error" alert.

4.4.4.  Finished

   The Finished message is the final message in the Authentication
   Block.  It is essential for providing authentication of the handshake
   and of the computed keys.

   Recipients of Finished messages MUST verify that the contents are
   correct and if incorrect MUST terminate the connection with a
   "decrypt_error" alert.

   Once a side has sent its Finished message and has received and
   validated the Finished message from its peer, it may begin to send
   and receive Application Data over the connection.  There are two
   settings in which it is permitted to send data prior to receiving the
   peer's Finished:

   1.  Clients sending 0-RTT data as described in Section 4.2.10.

   2.  Servers MAY send data after sending their first flight, but
       because the handshake is not yet complete, they have no assurance
       of either the peer's identity or its liveness (i.e., the
       ClientHello might have been replayed).

   The key used to compute the Finished message is computed from the
   Base Key defined in Section 4.4 using HKDF (see Section 7.1).
   Specifically:

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

   Structure of this message:

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

   The verify_data value is computed as follows:

      verify_data =
          HMAC(finished_key,
               Transcript-Hash(Handshake Context,
                               Certificate*, CertificateVerify*))

      * Only included if present.

   HMAC [RFC2104] uses the Hash algorithm for the handshake.  As noted
   above, the HMAC input can generally be implemented by a running hash,
   i.e., just the handshake hash at this point.

   In previous versions of TLS, the verify_data was always 12 octets
   long.  In TLS 1.3, it is the size of the HMAC output for the Hash
   used for the handshake.

   Note: Alerts and any other non-handshake record types are not
   handshake messages and are not included in the hash computations.

   Any records following a Finished message MUST be encrypted under the
   appropriate application traffic key as described in Section 7.2.  In
   particular, this includes any alerts sent by the server in response
   to client Certificate and CertificateVerify messages.

4.5.  End of Early Data

      struct {} EndOfEarlyData;

   If the server sent an "early_data" extension in EncryptedExtensions,
   the client MUST send an EndOfEarlyData message after receiving the
   server Finished.  If the server does not send an "early_data"
   extension in EncryptedExtensions, then the client MUST NOT send an
   EndOfEarlyData message.  This message indicates that all 0-RTT
   application_data messages, if any, have been transmitted and that the

   following records are protected under handshake traffic keys.
   Servers MUST NOT send this message, and clients receiving it MUST
   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
   the appropriate application traffic key.

4.6.1.  New Session Ticket Message

   At any time after the server has received the client Finished
   message, it MAY send a NewSessionTicket message.  This message
   creates a unique association between the ticket value and a secret
   PSK derived from the resumption master secret (see Section 7).

   The client MAY use this PSK for future handshakes by including the
   ticket value in the "pre_shared_key" extension in its ClientHello
   (Section 4.2.11).  Servers MAY send multiple tickets on a single
   connection, either immediately after each other or after specific
   events (see Appendix C.4).  For instance, the server might send a new
   ticket after post-handshake authentication in order to encapsulate
   the additional client authentication state.  Multiple tickets are
   useful for clients for a variety of purposes, including:

   -  Opening multiple parallel HTTP connections.

   -  Performing connection racing across interfaces and address
      families via (for example) Happy Eyeballs [RFC8305] or related
      techniques.

   Any ticket MUST only be resumed with a cipher suite that has the same
   KDF hash algorithm as that used to establish the original connection.

   Clients MUST only resume if the new SNI value is valid for the server
   certificate presented in the original session and SHOULD only resume
   if the SNI value matches the one used in the original session.  The
   latter is a performance optimization: normally, there is no reason to
   expect that different servers covered by a single certificate would
   be able to accept each other's tickets; hence, attempting resumption
   in that case would waste a single-use ticket.  If such an indication
   is provided (externally or by any other means), clients MAY resume
   with a different SNI value.

   On resumption, if reporting an SNI value to the calling application,
   implementations MUST use the value sent in the resumption ClientHello
   rather than the value sent in the previous session.  Note that if a
   server implementation declines all PSK identities with different SNI
   values, these two values are always the same.

   Note: Although the resumption master secret depends on the client's
   second flight, a server which does not request client authentication
   MAY compute the remainder of the transcript independently and then
   send a NewSessionTicket immediately upon sending its Finished rather
   than waiting for the client Finished.  This might be appropriate in
   cases where the client is expected to open multiple TLS connections
   in parallel and would benefit from the reduced overhead of a
   resumption handshake, for example.

      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;

   ticket_lifetime:  Indicates the lifetime in seconds as a 32-bit
      unsigned integer in network byte order from the time of ticket
      issuance.  Servers MUST NOT use any value greater than
      604800 seconds (7 days).  The value of zero indicates that the
      ticket should be discarded immediately.  Clients MUST NOT cache
      tickets for longer than 7 days, regardless of the ticket_lifetime,
      and MAY delete tickets earlier based on local policy.  A server
      MAY treat a ticket as valid for a shorter period of time than what
      is stated in the ticket_lifetime.

   ticket_age_add:  A securely generated, random 32-bit value that is
      used to obscure the age of the ticket that the client includes in
      the "pre_shared_key" extension.  The client-side ticket age is
      added to this value modulo 2^32 to obtain the value that is
      transmitted by the client.  The server MUST generate a fresh value
      for each ticket it sends.

   ticket_nonce:  A per-ticket value that is unique across all tickets
      issued on this connection.

   ticket:  The value of the ticket to be used as the PSK identity.  The
      ticket itself is an opaque label.  It MAY be either a database
      lookup key or a self-encrypted and self-authenticated value.

   extensions:  A set of extension values for the ticket.  The
      "Extension" format is defined in Section 4.2.  Clients MUST ignore
      unrecognized extensions.

   The sole extension currently defined for NewSessionTicket is
   "early_data", indicating that the ticket may be used to send 0-RTT
   data (Section 4.2.10).  It contains the following value:

   max_early_data_size:  The maximum amount of 0-RTT data that the
      client is allowed to send when using this ticket, in bytes.  Only
      Application Data payload (i.e., plaintext but not padding or the
      inner content type byte) is counted.  A server receiving more than
      max_early_data_size bytes of 0-RTT data SHOULD terminate the
      connection with an "unexpected_message" alert.  Note that servers
      that reject early data due to lack of cryptographic material will
      be unable to differentiate padding from content, so clients
      SHOULD NOT depend on being able to send large quantities of
      padding in early data records.

   The PSK associated with the ticket is computed as:

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

   Because the ticket_nonce value is distinct for each NewSessionTicket
   message, a different PSK will be derived for each ticket.

   Note that in principle it is possible to continue issuing new tickets
   which indefinitely extend the lifetime of the keying material
   originally derived from an initial non-PSK handshake (which was most
   likely tied to the peer's certificate).  It is RECOMMENDED that
   implementations place limits on the total lifetime of such keying
   material; these limits should take into account the lifetime of the
   peer's certificate, the likelihood of intervening revocation, and the
   time since the peer's online CertificateVerify signature.

4.6.2.  Post-Handshake Authentication

   When the client has sent the "post_handshake_auth" extension (see
   Section 4.2.6), a server MAY request client authentication at any
   time after the handshake has completed by sending a
   CertificateRequest message.  The client MUST respond with the
   appropriate Authentication messages (see Section 4.4).  If the client
   chooses to authenticate, it MUST send Certificate, CertificateVerify,

   and Finished.  If it declines, it MUST send a Certificate message
   containing no certificates followed by Finished.  All of the client's
   messages for a given response MUST appear consecutively on the wire
   with no intervening messages of other types.

   A client that receives a CertificateRequest message without having
   sent the "post_handshake_auth" extension MUST send an
   "unexpected_message" fatal alert.

   Note: Because client authentication could involve prompting the user,
   servers MUST be prepared for some delay, including receiving an
   arbitrary number of other messages between sending the
   CertificateRequest and receiving a response.  In addition, clients
   which receive multiple CertificateRequests in close succession MAY
   respond to them in a different order than they were received (the
   certificate_request_context value allows the server to disambiguate
   the responses).

4.6.3.  Key and Initialization Vector Update

   The KeyUpdate handshake message is used to indicate that the sender
   is updating its sending cryptographic keys.  This message can be sent
   by either peer after it has sent a Finished message.  Implementations
   that receive a KeyUpdate message prior to receiving a Finished
   message MUST terminate the connection with an "unexpected_message"
   alert.  After sending a KeyUpdate message, the sender SHALL send all
   its traffic using the next generation of keys, computed as described
   in Section 7.2.  Upon receiving a KeyUpdate, the receiver MUST update
   its receiving keys.

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

      struct {
          KeyUpdateRequest request_update;
      } KeyUpdate;

   request_update:  Indicates whether the recipient of the KeyUpdate
      should respond with its own KeyUpdate.  If an implementation
      receives any other value, it MUST terminate the connection with an
      "illegal_parameter" alert.

   If the request_update field is set to "update_requested", then the
   receiver MUST send a KeyUpdate of its own with request_update set to
   "update_not_requested" prior to sending its next Application Data
   record.  This mechanism allows either side to force an update to the
   entire connection, but causes an implementation which receives

   multiple KeyUpdates while it is silent to respond with a single
   update.  Note that implementations may receive an arbitrary number of
   messages between sending a KeyUpdate with request_update set to
   "update_requested" and receiving the peer's KeyUpdate, because those
   messages may already be in flight.  However, because send and receive
   keys are derived from independent traffic secrets, retaining the
   receive traffic secret does not threaten the forward secrecy of data
   sent before the sender changed keys.

   If implementations independently send their own KeyUpdates with
   request_update set to "update_requested" and they cross in flight,
   then each side will also send a response, with the result that each
   side increments by two generations.

   Both sender and receiver MUST encrypt their KeyUpdate messages with
   the old keys.  Additionally, both sides MUST enforce that a KeyUpdate
   with the old key is received before accepting any messages encrypted
   with the new key.  Failure to do so may allow message truncation
   attacks.