2. Cryptographic Dependencies of a TLS 1.3 Handshake

This chapter establishes what a TLS 1.3 connection actually requires of a cryptographic library. The purpose is not to restate the protocol, which is specified in RFC 8446, but to identify every point at which an algorithm implementation is consumed, because each such point is a place where a provider-supplied algorithm must be able to appear.

2.1 Four independent decisions

A TLS 1.3 connection is parameterised by four cryptographic choices. They are negotiated separately, they appear in different handshake messages, and — this is the observation the rest of the paper depends on — they are supplied to OpenSSL through different mechanisms.

A crucial structural fact follows from the first two rows: in TLS 1.3 the cipher suite identifier binds the AEAD algorithm and the hash together. TLS_AES_128_GCM_SHA256 is one code point naming two algorithms. This is a deliberate simplification relative to TLS 1.2, where the suite additionally encoded the key exchange and authentication methods; in 1.3 those moved into extensions, which is precisely why groups and signature algorithms are independently negotiable and cipher suites are not.

2.2 The handshake, as a sequence of algorithm uses

Stated as a list of demands on the library rather than as a message flow, a TLS 1.3 handshake proceeds roughly as follows. The client offers cipher suites, supported groups and signature algorithms, and speculatively generates a key share for one or more groups. Generating that share is the first algorithm use: a key pair in the offered group must exist before the first flight is sent.

The server selects a suite, a group and — if it must authenticate — a signature algorithm. It generates its own key share, completes the key agreement, and from that point the key schedule begins. Every secret in TLS 1.3 is derived by HKDF using the hash bound to the selected suite, and the transcript hash over all handshake messages so far participates in those derivations. The server signs the transcript with its long-term key, and both sides compute Finished values using a MAC keyed from the schedule.

The ordering matters for a provider design in a way that is easy to miss:

1. The group is used before the suite is known. The client generates a key share when it constructs its first flight, before the server has chosen anything. A provider-supplied group must therefore be available at the point the client is composing ClientHello, and must be advertised in supported_groups for the server to be able to choose it.
2. The hash is used from the moment the suite is selected, and never changes. The transcript hash covers messages that were exchanged before the suite was chosen; implementations buffer the early transcript and hash it once the algorithm is known. A provider-supplied hash is therefore consumed retrospectively over data already sent.
3. The AEAD is used last of the three, once handshake traffic keys exist, and then continuously for the life of the connection.

The consequence for this paper is that the three algorithm classes in its title are not symmetric. The group must be advertised; the hash must be selectable at the moment a suite is chosen and then drives everything derived; the AEAD is comparatively self-contained.

2.3 The key schedule and why the hash is special

TLS 1.3 derives all keying material through HKDF, structured as a schedule of Extract and Expand steps. The hash function selected by the cipher suite determines the HMAC used inside HKDF and therefore the length of every secret in the schedule: a suite naming SHA-256 produces 32-byte secrets throughout, one naming SHA-384 produces 48-byte secrets.

This has a design consequence that is more restrictive than it first appears. Introducing a new hash function into TLS is not merely adding an implementation; it changes the width of the key schedule. Every buffer, every derived secret, every Finished value and every exporter output takes its length from that hash. An implementation that assumed 32 or 48 bytes — in the TLS stack, in an application's exporter usage, or in a session-resumption cache — is affected by the change in a way it is not affected by a change of record cipher.

A new AEAD, by contrast, is comparatively contained. It has a key length, an IV length and a tag length; provided the record layer can learn those three values, the rest of the protocol is indifferent to which algorithm produced the ciphertext.

2.4 What the record layer needs from an AEAD

TLS 1.3 record protection uses an AEAD interface with a per-record nonce constructed from a static IV and a sequence number. The record layer requires the following from whatever algorithm it is handed:

Key length

How many bytes of key material the schedule must produce.

IV length

The width of the static IV, into which the sequence number is folded.

Tag length

The expansion between plaintext and ciphertext, needed for record sizing and for the maximum-fragment computation.

AAD handling

The record header is supplied as associated data.

Deterministic nonce construction

TLS constructs the nonce itself; the algorithm must accept an externally supplied nonce rather than generating one.

The last point excludes some AEAD constructions from direct use. An algorithm that insists on generating its own nonce, or that uses a nonce width incompatible with the 64-bit sequence number folded into the static IV, cannot be dropped into the TLS 1.3 record layer without adaptation. This is a constraint on algorithm choice, not on the provider mechanism, but it must be checked before a design commits to a particular cipher.

2.5 What key exchange needs from a group

The key_share extension carries an opaque octet string whose interpretation is defined per group. For an elliptic-curve group this is a point encoding; for a finite-field group, an integer. The TLS stack requires of a group:

• a code point, so it can be named in supported_groups;
• a wire encoding for a public share, with a known or derivable length;
• key generation, producing a private value and its public share;
• key derivation, combining a local private value with a peer share to produce a shared secret of known length;
• validation of a received peer share, since a malformed or malicious share must be rejected rather than processed.

The last item deserves emphasis because it is where key-exchange implementations have historically failed. A group implementation that does not validate peer input — that accepts a point not on the curve, or a small-order point — introduces a vulnerability that no amount of correctness in the rest of the stack will compensate for. Chapter 17 returns to this.

2.6 What authentication needs from a signature algorithm

The server signs a defined context string concatenated with the transcript hash, using an algorithm named by a code point in signature_algorithms. The requirements are a code point, an association with a key type and OID so that certificates can be matched to it, a signing operation, a verification operation, and a statement of the security level so that policy can rank it.

2.7 Summary of the demand surface

Collecting the above, a provider that wishes to participate fully in a TLS 1.3 connection must be able to present, through whatever mechanism OpenSSL offers:

The next chapter describes the mechanism through which a provider exposes anything at all; Chapter 4 then maps this demand surface onto it.