7.10 Public-key cryptography in TLS 1.3

Equipped with the mathematical background on public-key cryptography, we can now explore how it is applied in TLS 1.3.

In the previous chapter, we learned that client Bob and server Alice exchange messages during the TLS handshake phase to establish all parameters necessary for deriving the TLS secrets and, subsequently, the TLS keys.

Technically, these cryptographic parameters are transmitted in the key˙share extension of the ClientHello, ServerHello and, if needed, HelloRetryRequest messages.

7.10.1 Client key shares and server key shares

In a ClientHello message, the key˙share extension – more precisely, its extension˙data field – contains a value called KeyShareClientHello defined as follows:
struct {
    KeyShareEntry client_shares<0..2^16-1>;
} KeyShareClientHello;

The client˙shares variable is a list of key shares offered by client Bob to server Alice in the initial ClientHello message. Generally, the client˙shares list is ordered according to Bob’s preference and starts with his most preferred key share. But Bob may also send Alice an empty client˙shares list, letting her choose the group for the key share.

The basic data block size in the TLS 1.3 specification given in RFC 8446 is one byte. A vector is a one-dimensional array of data elements of the same type whose length may be fixed or variable. Notably, the length of a vector in the TLS 1.3 specification is always given as the number of bytes. This can be confusing at first since most programming languages, as well as programming literature, declare the length of an array or vector as the number of its elements.

The angle brackets ¡…¿ denote vectors of variable length. The numbers in the angle brackets specify the range of legal lengths using the ¡floor…ceiling¿ notation. When variable-length vectors are encoded, their actual length is prepended to the vector’s contents. This length indication itself consumes as many bytes as are required to hold the vector’s maximum legal length.

The elements of the client˙shares list – that is, the TLS key shares – are of type KeyShareEntry shown in Listing 7.1. Each key share is composed of two variables. The group variable contains the name of the key share’s specific group defined in the TLS specification. The key˙exchange variable contains the actual cryptographic key share for either the finite field-based Diffie-Hellman (that is, Diffie-Hellman over the group 𝔽p∗) or for the elliptic curve Diffie-Hellman key agreement protocol. We will discuss elliptic curves in detail in the next chapter. For now, it suffices to know that points of an elliptic curve form an abelian group, so we can perform the general Diffie-Hellman key exchange protocol shown in Figure 7.1.

Listing 7.1: TLS key shares

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

In a ServerHello message, the key˙share extension contains a value called KeyShareServerHello shown in Listing 7.2. Note that in contrast to client Bob’s KeyShareClientHello, server Alice’s server˙share is a single key share entry value. This is because Alice chooses one key share from the list offered by Bob.

Listing 7.2: Data in the key share extension of a ServerHello message

struct {
   KeyShareEntry server_share;
} KeyShareServerHello;

For the TLS handshake to work, server˙share must be in the same group as one of the key shares offered by client Bob. Server Alice is not allowed to respond with a key share for any group that was not contained in Bob’s supported˙groups list he transmitted in his ClientHello message.