15. Key Schedule Integration

Constraint C3 stated that a change of handshake hash changes the width of the entire key schedule. This chapter develops that claim, because it is the most invasive consequence of the design and the one most likely to be discovered late.

15.1 The schedule

TLS 1.3 derives every secret through HKDF, structured as a sequence of Extract and Expand operations. Schematically, an early secret is extracted from the pre-shared key or zero; a handshake secret is extracted from the shared secret produced by key exchange; and a master secret follows. From each, traffic secrets are expanded, and from those, keys and IVs.

Two properties of this structure govern the design:

Every step uses the suite's hash. HKDF is HMAC-based, and the HMAC uses the negotiated hash. There is no point in the schedule where a different algorithm appears.
Secret widths equal the hash output length. The extract step produces a pseudorandom key of the hash's output size, and every derived secret inherits it.

Consequently the schedule's arithmetic is parameterised by one number, and that number comes from the provider's size parameter (§9.3).

15.2 What changes when the hash changes

Quantity	With a 32-byte hash	With a 48-byte hash	Source of the value
Early / handshake / master secret	32 bytes	48 bytes	Hash output length
Traffic secrets	32 bytes	48 bytes	Hash output length
Finished key and value	32 bytes	48 bytes	Hash output length
Transcript hash	32 bytes	48 bytes	Hash output length
Record key	AEAD key length — unchanged by the hash		Cipher `keylen`
Record IV	AEAD IV length — unchanged by the hash		Cipher `ivlen`

The last two rows are the useful observation: the record keys are expanded to the cipher's required lengths and do not inherit the hash width. The AEAD and the hash are therefore loosely coupled — a suite may pair any hash with any AEAD, provided both report their parameters correctly. This is why §8 and §9 could be specified independently.

15.3 Where a wrong length manifests

A hash component that misreports its output length does not fail at the point of the error. It fails downstream, and the distance between cause and symptom is the reason this chapter exists.

Understated length: Secrets are truncated. The handshake may proceed to the Finished exchange and fail there, because the two endpoints derived different values. The symptom is a MAC failure; the cause is a parameter.
Overstated length: The consumer allocates and expects more bytes than the algorithm produces. Depending on the consumer this is a buffer of uninitialised or zero bytes entering the schedule — which may still be deterministic on both sides and therefore may still succeed, producing a connection whose keys have less entropy than they appear to. This is the worse of the two failures, because it does not announce itself.
Correct length, wrong block size: HMAC's padding is wrong, so every HKDF step is wrong, and the failure is total and immediate.

Security-relevant. The overstated-length case can produce a working connection with weakened keys. A test suite that checks only that handshakes succeed will pass. The test that catches it is a known-answer test over the key schedule itself — derive from fixed inputs and compare against values computed independently — which Chapter 19 accordingly requires.

15.4 The transcript

The transcript hash covers all handshake messages in order, and it is consumed at several points without being finalised (§9.2). The design obligations are therefore concentrated in duplication rather than in the hashing itself.

A subtle requirement follows from §2.2: because the hash is not known until the suite is selected, the early messages are buffered and hashed retrospectively. Any divergence between the bytes as sent and the bytes as buffered produces a transcript mismatch, detected at Finished. When a custom hash is in use, this ordinary failure mode is easily misattributed to the new algorithm; distinguishing them requires comparing the transcript input on both endpoints, not the digest output.

15.5 Exporters and resumption

Two features extend the schedule's reach beyond the connection and are easily overlooked.

Exporters allow an application to derive keying material from the connection, and the exported length is requested by the application while the underlying derivation uses the suite's hash. An application that assumed a particular hash — for instance in a protocol that binds channel identity to an exporter of fixed size — interacts with a changed hash in ways the TLS layer cannot detect.

Resumption stores a secret whose width is the hash's output length, and a resumption attempt must use a suite with the same hash as the original connection. A deployment introducing a custom hash must ensure its session cache records which hash produced each entry, or resumption will fail in ways that look intermittent — succeeding when the same suite happens to be selected again and failing otherwise.

15.6 Summary and design rule

The key schedule is parameterised by exactly one provider-supplied value, and that value must be correct. The design rule that follows is narrow and worth stating as such:

Rule. A hash component intended as a TLS handshake hash must be validated by comparing key-schedule outputs against independently computed values, not merely by comparing digests. Digest correctness does not imply schedule correctness, because the schedule depends on the reported length and block size in addition to the computation.