]> Cryptography Consulting LLC

nicholas.sullivan+ietf@gmail.com

Security TLS TLS 1.3 key schedule schedule profile XOF deck function duplex sponge cSHAKE KMAC cipher suites TLS 1.3 builds its key schedule on HKDF over the cipher suite's hash. This document defines TLS 1.3 cipher suites that build it on a deck function over a single permutation instead, the one a deployment already carries when it uses SHA-3, ML-KEM, or ML-DSA. One permutation then runs the whole schedule, and a full handshake takes about a third of the permutation calls an HKDF schedule over that permutation would. Such a cipher suite names an AEAD algorithm together with a schedule profile that defines every key-schedule function the connection uses. The profile follows from the negotiated cipher suite alone, so no new extension is defined and the TLS 1.3 state machine and wire format are unchanged. Two profiles are defined, one on the standard SHA-3 function and one on a faster reduced-round variant of it. Discussion Venues Discussion of this document takes place on the Transport Layer Security Working Group mailing list (tls@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Every TLS 1.3 cipher suite builds its key schedule on HKDF over the cipher suite's hash. This document defines cipher suites that build it on a deck function instead, running the whole schedule on one permutation, the one a deployment already carries when it uses SHA-3, ML-KEM, or ML-DSA. Instantiating HKDF with a SHA-3 hash would remove SHA-2 without changing how the schedule works. This document changes the schedule itself, not the hash. This document extends the agility TLS 1.3 already has, in which groups, KEMs, signature schemes, PSKs, and AEAD algorithms are all negotiated, to the key schedule itself. A TLS 1.3 cipher suite normally identifies an AEAD algorithm and the hash used with HKDF. The cipher suites defined here instead identify an AEAD algorithm and a complete schedule profile: A schedule profile () defines every key-schedule computation the connection uses: the transcript hash, the secret and key derivations, the Finished and PSK binder MACs, and the Encrypted Client Hello acceptance computations. The cipher suite selects the profile by itself, through the ordinary cipher_suites and cipher_suite fields, with no separately negotiated extension. Both profiles express the schedule as one deck function , defined once for both in , and select different permutations for it: TLS13-TURBOSHAKE256 () uses the 12-round TurboSHAKE256 , and TLS13-SHAKE256 () uses the 24-round SHAKE256 . Finished, PSK binder, and Encrypted Client Hello acceptance values all use one MAC ().

Design Goals A schedule profile turns the whole derivation surface of a connection into one named, testable object. Every value comes from one permutation family, every output binds the profile identity and the governing cipher suite, and every derivation has a byte-exact test vector (). Neither profile uses SHA-2, HMAC, or HKDF in any role, and the correspondence with RFC 8446 can be audited shape by shape (). A deployment that already carries a Keccak permutation for SHA-3, ML-KEM, or ML-DSA reuses it for the entire schedule. The alternative is to keep RFC 8446's HKDF schedule and give it a SHA-3 hash. That inherits RFC 8446's analysis directly, and records a variant close to it. The deck is faster than that alternative. HKDF is built on HMAC, which runs every derivation as two nested hash calls, overhead that exists only to key a hash not built for keying. A keyed sponge needs no such wrapper: it produces each value in one squeeze, with no separate extract step between stages. Over the representative handshake of , the deck costs 52 Keccak-f[1600] permutation calls against 156 for a hash-only HKDF-SHA3-256. That factor of three follows from HKDF's definition over HMAC, so no HKDF instantiation removes it.

Scope This document does not define a new version of TLS. It changes no wire structure and no state machine: the cipher suite code point is negotiated in the cipher_suites field and selected in the ServerHello as always, and the schedule profile is not independently negotiable. A cipher suite of this document governs only the AEAD and the key schedule. It does not by itself make a connection free of SHA-2: certificate-based authentication is negotiated separately and commonly relies on SHA-2. A deployment that requires a fully SHA-2-free connection must additionally restrict itself to SHA-2-free signature schemes and certificate chains, or use PSK-only authentication ().

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the following terms.

schedule profile:

The set of algorithms and encodings, selected by a TLS 1.3 cipher suite, that defines every key-schedule computation of a connection (). Written ScheduleProfile when referring to the named component of a cipher suite.

selected_cipher_suite:

The cipher suite selected in the ServerHello message, as a 16-bit integer. uint16(selected_cipher_suite) yields its two-octet RFC 8446 encoding.

recorded cipher suite:

For a resumption PSK, the cipher suite of the ticket; for an imported PSK, target_ciphersuite ().

governing cipher suite:

The cipher suite value a derived output binds, determined by the rules of . For an output computed before the server's selection is known (an early-stage output when a PSK is offered, a PSK binder, a PSK import), it is the PSK's recorded cipher suite. For every other output it is selected_cipher_suite. Stage secrets and other values internal to a schedule bind no cipher suite ().

trunk (stage trunk):

The running deck accumulator for a schedule stage (E, H, or T), which absorbs the stage's inputs, is forked for the stage's leaf outputs, and is ratcheted to produce the stage secret.

DHE:

The (EC)DHE shared secret, computed as in RFC 8446, Section 7.4.

Nk, Nn:

The AEAD key and nonce lengths of the selected cipher suite, in octets.

FLen:

The length of Finished and PSK binder verify_data: 64 octets in both profiles of this document.

uint16(n):

The two-octet big-endian encoding of n, as in the TLS presentation language.

||:

Octet-string concatenation.

x[a..b]:

Octets a through b-1 of the octet string x, indexed from zero.

frame(x):

uint16(len(x)) || x, where len(x) is the octet length of x.

Strings are length-prefixed only: they are not null-terminated or otherwise padded after x. Both profiles of this document build every derivation input from framed items, so inputs are injectively encoded. Inputs longer than 0xFFFE octets do not occur: variable-length public values are reduced by the transcript hash or explicitly bounded before framing, and the one variable-length secret input, an external PSK, is bounded by .

An empty value contributes frame("") wherever it is framed, encoding as the two octets 0x0000 with no payload octets. An absent input omits its framed items entirely. Omitting an input is not the same as framing an empty value.

Transcript Hash The transcript hash is an unkeyed 64-octet hash defined by the schedule profile of the governing cipher suite (, ). TranscriptHash is computed over the handshake transcript as in RFC 8446, Section 4.4.1: message type and length fields are included, and record-layer framing is excluded. TranscriptHash accepts any octet string. The RFC 8446 rules define only how the handshake transcript is serialized before hashing, and the same function is applied to non-transcript inputs such as exporter labels and imported PSK identities. For a HelloRetryRequest, the RFC 8446 Section 4.4.1 synthetic-message construction is retained, substituting TranscriptHash for Hash. In both profiles of this document, TranscriptHash takes no cipher suite input, so a client can compute its checkpoints before the ServerHello. Cipher suite binding happens at output derivations only. This document uses the following checkpoint values:

TH_CH0:

TranscriptHash of the partial ClientHello transcript of RFC 8446, Section 4.2.11.2: the handshake messages through the ClientHello, with the ClientHello truncated after the PreSharedKeyExtension.identities field and the binders list excluded. After a HelloRetryRequest, this partial transcript includes the first ClientHello and the HelloRetryRequest via the synthetic-message construction of , exactly as in RFC 8446.

TH_CH:

TranscriptHash(ClientHello).

TH_SH:

TranscriptHash(ClientHello up to and including ServerHello).

TH_SF:

TranscriptHash(ClientHello up to and including the server Finished message).

TH_CF:

TranscriptHash(ClientHello up to and including the client Finished message).

For a Finished MAC computed by either peer, the covered transcript is taken up to but not including the Finished message being computed, consistent with RFC 8446, Section 4.4.4.

Schedule Profiles A schedule profile is a set of algorithms and encodings selected by a TLS 1.3 cipher suite. A schedule profile specifies:

• profile_id, a fixed octet string naming the profile, bound into its derivations;
• SecretLen, the length of stage and traffic secrets;
• FLen, the length of Finished and binder verify_data;
• TranscriptHash(messages), the unkeyed transcript hash of ;
• the derivation of initial and stage secrets from PSK and key-exchange inputs (an extract operation, a stage accumulator, or an equivalent construction);
• the derivation of every handshake, application, exporter, and resumption secret;
• the Finished MAC and PSK binder computations;
• record key and IV derivation;
• traffic-secret update;
• exporter derivation;
• resumption PSK derivation;
• the Encrypted Client Hello acceptance computations; and
• the domain-separation and input-framing rules its derivations use.

A schedule profile is not independently negotiated. It is selected solely by the negotiated cipher suite: the ClientHello cipher_suites field offers, and the ServerHello cipher_suite field selects, as in RFC 8446, Section 4.1. Future specifications may define additional schedule profiles by registering new TLS 1.3 cipher suites whose definitions include the complete profile. Every derivation of a schedule profile MUST bind at least the following into the input of the underlying primitive: a protocol identifier (the profiles of this document use profile_id strings beginning "TLS 1.3"), the profile_id, the governing cipher suite for any output that leaves the schedule, the derivation label, the output length (a profile MAY instead fix the length of an internal stage secret as a profile constant, provided the operation that produces it is domain-separated from every variable-length operation), the transcript checkpoint or other public context where applicable, and the secret input or the stage that carries it. All variable-length items MUST be length-framed. No two distinct derivation paths may produce identical encoded inputs to the underlying primitive unless they intentionally derive the same value. Both profiles of this document bind the output length as uint16, so no output longer than 65534 octets is derivable. The one derivation whose length is caller-chosen is the exporter: an implementation MUST reject a TLS-Exporter request for more than 65534 octets rather than reduce the requested length modulo 65536, which would let two different requested lengths bind the same encoded value. Every other output length in this document is a profile constant or Nk + Nn, all far below the bound, so the exporter is the only derivation where this rejection can occur.

The Governing Profile Every output of a schedule profile binds a governing cipher suite, and through it a governing profile. The rules are:

• After the ServerHello of a full handshake, the governing cipher suite is selected_cipher_suite, and the governing profile is the schedule profile of that suite.
• A PSK binder is computed before the server selects a cipher suite. Its governing cipher suite is the PSK's recorded cipher suite, and it is computed and verified under the schedule profile associated with that PSK. As in RFC 8446, Section 4.2.11, a server MUST verify the binder of any PSK it selects, and MUST perform that verification under that PSK's recorded cipher suite.
• Early-stage outputs derived before the ServerHello (early traffic keys, the early exporter secret) are governed by the offered PSK's recorded cipher suite.
• After a HelloRetryRequest, an updated binder remains governed by the PSK's recorded cipher suite. A client SHOULD omit from its updated ClientHello any PSK whose recorded cipher suite is incompatible with the cipher suite implied by the HelloRetryRequest, and MUST recompute binders as required by RFC 8446, Section 4.2.11.2.
• A server MUST NOT select a PSK unless the schedule profile of the cipher suite it selects is compatible with the schedule profile associated with the PSK. Two schedule profiles are compatible only if they have the same profile_id and identical profile parameters. This document defines no broader compatibility. Because each profile of this document additionally binds the recorded cipher suite into the binder, a server MUST NOT select a PSK whose recorded cipher suite differs from the cipher suite it selects. This is stricter than RFC 8446, Section 4.2.11, which requires only that the selected cipher suite share the PSK's Hash. Because a schedule profile is not independently negotiated, compatibility requires the full cipher suite, not merely its transcript hash, to match.
• For 0-RTT, the server MUST require the selected cipher suite to equal the PSK's recorded cipher suite (), unless a future specification defines a narrower compatibility rule.

A PSK that is offered but not selected leaves no trace in the schedule. If the server does not select the client's PSK, both peers compute the connection's schedule as a handshake without a PSK: the client discards any PSK-keyed schedule state it built for the binder or for early data, along with its outputs, and begins the schedule again with the empty PSK, applying the destruction rules of its profile. Implementations MUST associate every PSK and session ticket with the cipher suite, and therefore the schedule profile, under which it was established.

Keyed Derivations Every derivation in this document that is keyed by a retained octet-string secret, rather than by a live stage of a profile's schedule, is a deck session rooted at that secret (), specified once for both profiles in since the deck is identical up to its permutation. MAC computes Finished, PSK binders, and Encrypted Client Hello acceptance confirmations. defines it once as a byte layout over the profile's permutation, and each profile fixes that permutation (, ). Stage schedules themselves remain profile-specific (, ). This section covers everything derived from the octet-string secrets those schedules produce.

Expanding a Retained Secret A value keyed by a retained octet-string secret is produced by a deck session () rooted at that secret. The deck is initialized, the secret is absorbed, the session is forked under a label and the governing cipher suite of the output, any context is absorbed, and the deck is squeezed to the output length. Written with the deck operations of : suite is the governing cipher suite of the output (), bound by the Fork; label is an ASCII label; context is an octet string; and L is the output length in octets. Because every item is length-framed by the deck (), distinct expansions map to distinct deck inputs. When context is empty its Absorb is omitted rather than framed as an empty value. The frame of the following "out" tag delimits the absence, so an omitted context and an empty one never yield the same input. No two expansions in this document share the same label unless they intentionally derive the same value, and L never exceeds 65534 octets (). This expansion is the analogue of RFC 8446's HKDF-Expand-Label and carries the same RFC 8446 labels. It is a use of the deck, not a separate construction.

MAC MAC(key, suite, label, message, L) computes every tag in this document: the PSK binder, both Finished values, and the ECH acceptance confirmation. Both profiles use it. This section defines it once over the profile's permutation, and each profile fixes that permutation (, ). MAC builds the octet string mac_input from a key, a positional tuple X, and a fixed customization string S, then applies the profile's permutation to mac_input as a sponge, with a 136-octet rate, a 512-bit capacity, and domain-separation byte 0x04 appended in the manner of TurboSHAKE , squeezing 8 * L bits: The four length encoders are byte-oriented. For a non-negative integer n, let b be the number of octets in its minimal big-endian form, taking b to be 1 when n is 0. left_encode(n) is the single octet b followed by n as b octets. right_encode(n) is n as b octets followed by the single octet b. For an octet string s of len(s) octets, encode_string(s) is left_encode(8 * len(s)) followed by s. bytepad(s, w) is left_encode(w) followed by s, then zero octets until the length is a multiple of w. The input X is positional. Unlike the deck's Absorb and Fork inputs, which pair each value with a frame(tag), the MAC fields carry no per-item tags. Their fixed order and length-framing parse them unambiguously, and S is the same in every invocation of either profile. The two profiles fix the permutation. On the Keccak-p[1600,12] of TLS13-TURBOSHAKE256 the sponge is TurboSHAKE256(mac_input, 0x04, L), which this document names TurboKMAC256. On the Keccak-f[1600] of TLS13-SHAKE256 it is the sponge cSHAKE256 and KMAC256 are built on, and the result is byte-for-byte NIST KMAC256 . This layout and the 0x04 domain byte are the ones cSHAKE and KMAC use, so those equalities hold by construction. MAC is defined by the layout above, not by reference to KMAC. Because right_encode(8 * L) binds the output length into mac_input before the permutation runs, neither profile is KMACXOF256, and outputs of different lengths are unrelated. MAC is the analogue of RFC 8446's HMAC-based Finished and binder MACs and carries the same RFC 8446 labels. No two invocations share a label unless they derive the same value, and L never exceeds 65534 octets ().

Record Keys Record keys are derived from a traffic secret in one call, so a retained traffic secret suffices to re-derive its keys, as in RFC 8446. The governing cipher suite is that of the traffic secret: for early-data keys, derived before the ServerHello, it is the offered PSK's recorded cipher suite, whose Nk and Nn apply. The split is unambiguous: Nk and Nn are fixed by the suite, which is bound into the derivation together with the output length. The traffic secret is already specific to one direction and one stage, so no direction or epoch input is needed. The per-record nonce construction, record format, and AEAD additional data are unchanged from RFC 8446.

Key Update A key update derives the next traffic-secret generation from the current one: with record keys re-derived from the new secret as above. Each generation is an erasure boundary: an implementation MUST destroy the previous secret, its keys, and any schedule state derived from them after the new generation is installed, and MUST NOT derive generation N+1 from anything other than generation N (in particular, not from a retained stage accumulator or a counter).

Finished and PSK Binder MACs Finished and PSK binder verify_data are computed under a dedicated MAC key, expanded from a stage or traffic secret (), rather than by MACing that secret directly. This matches RFC 8446, Section 4.4.4, field for field: finished_key and binder_key take the roles of RFC 8446's identically named intermediates, and MAC takes the role of RFC 8446's HMAC. For a Finished message, base_key is the sender's handshake traffic secret, selected as in RFC 8446, Section 4.4; suite is selected_cipher_suite; label is "finished"; and th covers the transcript up to but not including the Finished message being computed. For a PSK binder, the dedicated key is derived in two steps, as RFC 8446, Section 7.1 derives binder_key and then finished_key from it: early_secret is the early-stage secret of the schedule keyed by that PSK; ext_or_res_label is "ext binder" for an external PSK and "res binder" for a resumption PSK, and label takes the same value in the MAC call; suite is the PSK's recorded cipher suite. Both finished_key and binder_key are 64 octets, the length of every stage and traffic secret in both profiles (SecretLen, , ), matching RFC 8446's use of Hash.length for the same intermediates. Binder verification follows . counts every finished_key and binder_key derivation of a representative full handshake against the corresponding RFC 8446 HKDF-Expand-Label calls. finished_key and binder_key are dedicated MAC keys: neither is ever used to derive record keys, an exporter, or any other output. No joint-security argument about reusing one secret across the deck and the MAC is therefore needed, and the MAC's security as a keyed function rests on the same sponge assumptions as the deck itself (, ). The structure is otherwise identical to RFC 8446's, field for field: finished_key and binder_key exist for the same reason in both, and the only substitution is the MAC for HMAC as the keyed function that consumes them (). The RFC 8446 key-schedule analysis of these intermediates therefore transfers directly, in both profiles of this document. Binders are computed before the ServerHello. This is possible in both profiles because stage secrets bind no cipher suite: the client ratchets a clone of the early trunk to obtain early_secret at ClientHello time, in either profile ().

Exporters Exporters are keyed by the retained exporter master secret: The early exporter is the same construction keyed by e_exp_master, with the offered PSK's recorded cipher suite as its governing suite. Hashing the label and the context bounds them and keeps the composite context injective. An implementation MUST reject a TLS-Exporter request for more than 65534 octets ().

Resumption PSK The resumption PSK for a NewSessionTicket is:

ECH Acceptance Confirmations For the cipher suites of this document, the ECH acceptance signals of are: replacing the HKDF-Extract and HKDF-Expand-Label computations of , with ech_conf_messages and hrr_ech_conf_messages the handshake message ranges that document identifies for each confirmation, per RFC 8446, Section 4.4.1. TranscriptHash(ech_conf_messages) is RFC 9849's transcript_ech_conf, i.e. the same single transcript-hash operation, applied once. The selected cipher suite is known to both peers when each confirmation is computed and checked. Keying the confirmation on ClientHelloInner.random alone matches , whose confirmation key is HKDF-Extract(0, ClientHelloInner.random), with no handshake secret mixed in. This document computes a single MAC under that same key in place of RFC 9849's extract-then-expand, so the acceptance signal keeps its RFC 9849 properties. Only a server that decrypted the inner ClientHello, and so learned ClientHelloInner.random, can compute the confirmation, and no network attacker can forge it. Because the confirmation transcript covers the ServerHello, it binds its handshake and does not transplant to another.

PSK Import Derivation An external PSK is imported per target cipher suite (). The import derivation, for every profile of this document, is: with target_ciphersuite as the governing suite, following the shape of the RFC 9258 derivation, with the entire serialized ImportedIdentityV2 reduced by the transcript hash as the context. ipsk is an explicit octet string by design: it crosses a system boundary into the PSK store. epsk is absorbed as the secret of a deck expansion () in both profiles, so a low-entropy or attacker-influenced epsk never keys either profile's underlying permutation directly.

Cipher Suites and Code Points This document defines five cipher suites. As in TLS 1.3, the code point is negotiated in the cipher_suites field of the ClientHello and selected in the ServerHello. The suffix of each name denotes the complete schedule profile of the suite, not merely a transcript hash or MAC. Cipher Suites and Their Schedule Profiles

Cipher Suite	AEAD	ScheduleProfile
TLS_AES_128_GCM_TURBOSHAKE256	AES-128-GCM	TLS13-TURBOSHAKE256
TLS_AES_256_GCM_TURBOSHAKE256	AES-256-GCM	TLS13-TURBOSHAKE256
TLS_CHACHA20_POLY1305_TURBOSHAKE256	ChaCha20-Poly1305	TLS13-TURBOSHAKE256
TLS_AES_128_GCM_SHAKE256	AES-128-GCM	TLS13-SHAKE256
TLS_AES_256_GCM_SHAKE256	AES-256-GCM	TLS13-SHAKE256

The suites of a profile differ only in the AEAD algorithm and its key and nonce lengths. The AEAD algorithms, their Nk and Nn, and the per-record nonce construction are those of RFC 8446 and its cipher suites. Code points are to be assigned by IANA (). An implementation MUST NOT combine an AEAD algorithm and a schedule profile that are not registered together as a cipher suite: each cipher suite is a single negotiated value that determines both.

The Deck Schedule Both schedule profiles of this document express the key schedule as a deck function. The key schedule is a derivation tree, and a sponge-based primitive can express a tree natively: absorb inputs into a running accumulator, fork where the tree branches, and squeeze outputs at the leaves. The schedule's normative interface is a deck function : a keyed function with extendable input and incremental output, the abstraction under which forked-state designs carry security contracts . This section defines the deck operations once, for both profiles. and each give a short instantiation naming the profile's XOF, permutation, and domain-separation constants. This document uses the following terms.

deck function:

A keyed cryptographic function taking a sequence of input strings and producing output of arbitrary length, supporting extendable input and incremental output .

stage:

One of the three phases of the schedule: early (keyed by the PSK), handshake (adds the key-exchange secrets), and application. Stages are separated by ratchets, and each key-update generation adds a further ratchet.

fork:

Deriving a leaf value from a stage by extending the stage's input sequence with a label and the governing cipher suite and squeezing. In a stateful implementation, a fork is a clone of the stage accumulator. Forks are only permitted from an accumulator that has not produced output.

ratchet:

Crossing a stage boundary by squeezing an explicit stage secret directly from the trunk (the Ratchet operation of ) and reinitializing the next stage from it, after which every accumulator of the completed stage is destroyed (). The squeeze-and-reinitialize pattern follows the RATCHET operation of and the Ratchet call of Cyclist .

The presentation is stateful, but the construction is not. Every derived value equals one invocation of a profile's deck function over the framed derivation path from its stage's initialization to that value, with no extract-then-expand structure, and an implementation that recomputes each value from its path is as conformant as one that maintains cloned accumulators. The three stages of are protocol phases separated by ratchets, not KDF steps: shared trunks absorb each input once, the handshake holds only two intermediate secrets, and the one-way truncations fall at the stage boundaries where TLS must erase prior state. The keyed-duplex construction underlying both profiles has concrete security bounds , and the TLS 1.3 key schedule has a proof framework based on derivation graphs with explicit intermediate values . composes those lines of work into a handshake-level security argument for the TLS13-TURBOSHAKE256 profile.

The Deck Schedule Interface The schedule is expressed through operations that build input sequences for the deck function DF(S, L), which maps a completed sequence S and an output length L to L octets of output. Each profile's instantiation of DF is given in and . Every operation that absorbs data contributes frame(tag) || frame(value) to the sequence, so distinct input sequences yield distinct absorbed strings.

Operations Each operation's effect on a sequence is:

Init():

Begin a session by framing the governing profile's profile_id (, ).

Absorb(S, tag, value):

Add one tagged input to S, returning S.

Fork(S, label, suite):

Branch a new sequence for a single output. The copy diverges from S under the framed label, and suite, the governing cipher suite of the output being derived, is bound under the fixed tag "suite". S is unmodified. An implementation MUST NOT apply Fork to a sequence that has produced output.

Squeeze(S, tag, L):

Terminate S and produce L octets. An implementation MUST NOT absorb further input into a squeezed S and MUST NOT fork it. Binding L into the sequence before output ensures that outputs of different lengths are unrelated rather than prefixes of one another. L never exceeds 65534 octets for any derivation in this document.

Ratchet(S, label):

Cross a stage boundary: squeeze the 64-octet stage secret directly from the stage trunk under the stage label, terminating the trunk. A ratchet output binds no cipher suite: stage secrets never leave the schedule, and every output that does binds its governing suite at its own Fork or expansion (, ). The ratchet labels "early secret" and "main secret" are reserved: they appear as no absorb tag, fork label, or squeeze tag elsewhere in either profile.

Leaf derivations keyed by a live stage use Fork and Squeeze. Derivations keyed by a retained octet-string secret use a deck expansion (), built from the same Init, Absorb, Fork, and Squeeze operations over each profile's DF.

One-Shot Equivalence Because Fork applies only before output and Squeeze, and therefore Ratchet, terminates a sequence, every derived value is exactly one deck-function invocation over the framed path from Init to its final squeeze. Derived values are therefore byte-exact and testable without reference to any internal state. An implementation MAY realize forks by cloning a running accumulator or by recomputing each leaf from its path. Both strategies MUST produce identical octets.

Derivation Shapes Every RFC 8446 derivation replaced by this document is an instance of one of six shapes. This table is the specification frame for and makes the RFC 8446 correspondence auditable. Derivation Shapes and Their Realizations

Shape	RFC 8446 sites	Realization
Root absorb	early_secret; PSK import	Init + Absorb secret
Accumulate	handshake_secret (per component)	Absorb secret
Ratchet	early_secret; main_secret; key update	Ratchet or expand
Branch	traffic/master secrets; resumption	Fork + Squeeze
Expand-to-use	record keys; exporters	Expand from a secret
Keyed check	Finished; PSK binders	MAC

Shapes 1 through 3 act on the trunk of a stage. Shapes 4 through 6 are forks or self-contained keyed calls. The early_secret of RFC 8446 becomes this document's first ratchet, and the handshake_secret extract becomes an accumulation into the handshake stage. Both stage boundaries remain explicit octet-string secrets (). Record keys are derived from their traffic secret by a separate call, as in RFC 8446, so a retained traffic secret suffices to re-derive its keys. Deriving them by squeezing alongside the secret would save a few invocations but break that re-derivability, so the schedule keeps the separate call.

Key Schedule The schedule has three stages separated by two ratchets, and each key-update generation adds a further ratchet. Stage trunks and stage secrets bind no cipher suite value, matching the RFC 8446 extracts they replace: a client offering several cipher suites of this document computes one schedule, and only leaf derivations differ, in their framed suffix alone. The governing cipher suite is bound at each leaf derivation, by Fork or expansion. In the listing below, suite denotes the governing cipher suite of the leaf being derived: the offered PSK's recorded cipher suite in the early stage, and selected_cipher_suite thereafter. This listing is identical for both profiles. Only each profile's DF and MAC instantiations differ (, ). When the negotiated group is a hybrid or other multi-component key exchange, DHE is not one secret. Each component shared secret is absorbed by its own Absorb(H, "dh", component), in the order that group defines them, and the components are never concatenated first. Both peers MUST absorb in that order, so they build the same handshake-stage input sequence.

Absent and Empty Inputs A handshake without a PSK still executes Absorb(E, "psk", ""). That contributes frame("psk") followed by frame(""), that is, 0x0003 || "psk" || 0x0000. This is unambiguous because a PSK of this document is never zero-length (an imported or resumption PSK is 64 octets). In that case the early stage carries no leaves and early_secret is a single deterministic, public constant of the profile, as RFC 8446's early secret is the extract of two known constants. The stage exists for uniformity across handshake modes, and the schedule's security does not rest on its secrecy when no PSK is present. A PSK-only handshake omits Absorb(H, "dh", ...) entirely: the tag "dh" does not appear in the sequence.

Suite Binding and Stage Secrets A server never selects a PSK whose recorded cipher suite differs from the cipher suite it selects (), so early_secret never feeds the handshake stage under a suite the transcript does not confirm. early_secret and main_secret are the schedule's explicit stage secrets, and like the RFC 8446 extracts they replace they are interoperable octet strings: an implementation that computes them by cloned accumulators and one that computes them as one-shot invocations over the framed path MUST produce identical octets. An implementation MUST destroy each stage secret once the next stage has absorbed it (). Note that main_secret binds TH_SH through its trunk, where the corresponding RFC 8446 extract binds no transcript. This is a strict superset binding, computed identically by both peers, and is intentional.

The TLS13-TURBOSHAKE256 Profile The TLS13-TURBOSHAKE256 schedule profile instantiates the deck schedule of with TurboSHAKE256 , built on the 12-round Keccak-p[1600,12] permutation of . The profile parameters are:

profile_id:

The fixed ASCII string "TLS 1.3 DeckSchedule v1" (23 octets), absorbed first into every derivation as frame(profile_id) ().

SecretLen:

64 octets, the length of every stage and traffic secret.

FLen:

64 octets.

Instantiation The deck function is: where seq(S) is the concatenation of every framed item of S in order. TurboSHAKE256's output length is in octets per , so L is passed unchanged, unlike the SHAKE256 profile, whose bit-oriented length needs an 8 * L conversion (). The transcript hash of is instantiated with the same function: TranscriptHash(x) = TurboSHAKE256("tls13 hash" || x, 0x1F, 64). The domain-separation byte for the deck and the transcript hash is fixed to 0x1F, the RFC 9861 default, so an API without the D parameter implements both unchanged. The MAC () requires D = 0x04, so the TurboSHAKE interface this profile uses MUST expose the domain byte. TurboSHAKE256 uses the Keccak-p[1600,12] permutation as a sponge: input is absorbed into a 1600-bit state in rate-sized blocks of 136 octets, with the permutation applied after each block, and output is read from the same state. The capacity is the 512-bit portion of the state that input and output never touch. It is what the erasure argument of relies on, and the 64-octet secret, transcript-hash, and MAC lengths used throughout this document are set to match it. The stateful view of this construction is analyzed as a duplex , under the keyed-sponge and keyed-duplex results .

Required API Surface The required API surface is incremental absorption, cloning of an unfinalized state, and one-shot squeeze with the output length known up front. Cloning before any output is incremental input to two separate invocations, which Section 2.1 of permits; no absorb-after-squeeze occurs anywhere in this document, so no access below the TurboSHAKE interface is required. The clone discipline is the same one TLS stacks already apply to SHA-2 transcript-hash checkpoints.

MAC This profile's MAC is the construction of over this profile's Keccak-p[1600,12] permutation.

The TLS13-SHAKE256 Profile The TLS13-SHAKE256 schedule profile instantiates the deck schedule of with plain SHAKE256 , built on the 24-round Keccak-f[1600] permutation, in place of TurboSHAKE256's Keccak-p[1600,12]. This profile mirrors the TLS13-TURBOSHAKE256 profile's framing exactly: domain separation comes from the same framed-prefix mechanism the TurboSHAKE profile uses, an absorbed frame(profile_id) at Init (), not from cSHAKE's function-name and customization-string inputs. The two profiles' decks therefore differ only in the underlying permutation, so expansion () and the MAC construction () are shared by both profiles, each differing only in which permutation it invokes (, ). The profile parameters are:

profile_id:

The fixed ASCII string "TLS 1.3 SHAKESchedule v1" (24 octets), absorbed first into every derivation as frame(profile_id) (), as in the TLS13-TURBOSHAKE256 profile.

SecretLen:

64 octets, the length of every stage and traffic secret.

FLen:

64 octets.

Instantiation The deck function is: where seq(S) is the concatenation of every framed item of S in order, SHAKE256(X, L) is the function of with X the main input and L the output length in bits, and 8 * L converts this document's octet-oriented L to the bit-oriented L argument of SHAKE256. SHAKE256 takes no function-name or customization-string input. Domain separation for this profile comes entirely from seq(S) itself beginning with frame(profile_id) (), the same mechanism the TLS13-TURBOSHAKE256 profile uses in place of a fixed domain-separation byte. The transcript hash of is instantiated with the same function: TranscriptHash(x) = SHAKE256("tls13 hash" || x, 512). SHAKE256 uses the Keccak-f[1600] permutation as a sponge with a 136-octet rate and a 512-bit capacity, the same rate and capacity as TurboSHAKE256. Input is absorbed in rate-sized blocks with the permutation applied after each block, and output is read from the same state. The capacity is what the erasure argument of relies on, and the 64-octet secret, transcript-hash, and MAC lengths used throughout this document match it in both profiles.

Required API Surface The required API surface is incremental absorption, cloning of an unfinalized state, and one-shot squeeze with the output length known up front, as in . No absorb-after-squeeze occurs anywhere in this document, so no access below the SHAKE256 interface is required.

MAC This profile's MAC is the construction of over this profile's Keccak-f[1600] permutation.

PSK Importer TLS 1.3 permits external PSKs , and imports an external PSK into a target KDF, producing a PSK bound to its target. An external PSK used with a cipher suite of this document is imported per target cipher suite into an ipsk. ImportedIdentityV2 below is this document's own variant of the ImportedIdentity struct of RFC 9258, Section 4, binding target_ciphersuite where that structure binds target_kdf: ; opaque context<0..2^16-1>; uint16 target_protocol; /* 0x0304 for TLS 1.3 */ uint16 target_ciphersuite; /* a cipher suite of this document */ } ImportedIdentityV2; ]]> The client offers the full ImportedIdentityV2 serialization as the PskIdentity.identity, and a server that recognizes the structure recomputes ipsk and MUST verify target_ciphersuite equals the cipher suite it selects (). A server that does not recognize the structure treats the entry as an unknown PSK identity, per ordinary RFC 8446 handling. The import derivation is the generic derivation of , keyed by epsk under target_ciphersuite. Binding target_ciphersuite rather than RFC 9258's target_kdf diversifies the imported PSK per cipher suite. That is one step finer than RFC 9258's per-KDF granularity, and it matches the per-suite binding this document uses everywhere else. It reuses the TLS Cipher Suites registry and registers no TLS KDF Identifier. The five code points of are the only values target_ciphersuite takes. An endpoint MUST NOT use the raw external PSK epsk directly as a TLS PSK for a cipher suite of this document, and MUST NOT import an epsk longer than 0xFFFE octets, so every framed value fits a single frame. A client that imports one external PSK for use with more than one cipher suite of this document MUST produce a separate ImportedIdentityV2, and hence a separate ipsk, per target_ciphersuite.

Zero-RTT and Early Data Early data remains PSK-only and remains replayable under the RFC 8446 anti-replay model. This document changes neither. A client MAY send early data only if the first offered PSK's recorded cipher suite is among the cipher suites it offers and the remembered ALPN and early-data policy match the ticket. A server MUST reject early data unless the selected cipher suite equals the offered PSK's recorded cipher suite, the selected ALPN equals the ticket's, and all RFC 8446 anti-replay checks pass. The suite-equality check, not the binder, prevents redirecting early data to a different AEAD.

Alerts This section lists the alerts an implementation of this document sends, in addition to those already defined by RFC 8446:

• illegal_parameter: a raw external PSK offered for a cipher suite of this document without import (); or an ImportedIdentityV2 whose target_ciphersuite does not equal the selected cipher suite.
• decrypt_error: a Finished or PSK binder MAC that fails verification, as in RFC 8446.
• handshake_failure: no cipher suite of this document is mutually supported when one is required.

Companion Mechanisms Several deployed mechanisms invoke HKDF-Expand-Label directly. This document defines the Encrypted Client Hello confirmation for its cipher suites (), because ECH is pervasive in the deployments most likely to exercise these schedules. The remaining mechanisms are out of scope until a companion document defines their analogues.

Out of Scope

• DTLS 1.3 derives a record sequence-number encryption key (Section 4.2.3) and separates its schedule with the "dtls13" label prefix (Section 5.9). DTLS-OK is N in .
• QUIC derives its Initial secrets and its "quic key", "quic iv", "quic hp", and "quic ku" values with HKDF-Expand-Label.
• Exported Authenticators derive their own Finished keys with HKDF-Expand-Label.

An endpoint negotiating a cipher suite of this document MUST NOT use these mechanisms with that connection unless a specification defines their derivations for its schedule profile.

IANA Considerations IANA is requested to register five code points in the TLS Cipher Suites registry per the procedures of . Requested TLS Cipher Suites Registrations

Value	Description	DTLS-OK	Recommended
TBD	TLS_AES_128_GCM_TURBOSHAKE256	N	N
TBD	TLS_AES_256_GCM_TURBOSHAKE256	N	N
TBD	TLS_CHACHA20_POLY1305_TURBOSHAKE256	N	N
TBD	TLS_AES_128_GCM_SHAKE256	N	N
TBD	TLS_AES_256_GCM_SHAKE256	N	N

The reference for each entry is this document. DTLS-OK is N (). Recommended is N pending working group consensus. The ScheduleProfile column of is explanatory in this document. It is not independently negotiated, and no registry of schedule profiles is created. Future documents that define new TLS 1.3 alternative key-schedule profiles are expected to register new TLS cipher-suite code points whose definitions include the complete schedule profile. OPEN ISSUE: Because every derived output binds the governing cipher suite value, no final test vector can exist before code points are assigned. Early code point allocation under RFC 7120 should be considered once the document is adopted. Until then, the test vectors of use declared placeholder values.

Security Considerations This section follows RFC 3552. It states what the schedules protect, the assumptions they rest on, the properties common to every schedule profile of this document, and the analysis specific to each profile.

Schedule-Profile Separation Every derivation of both profiles binds the profile_id and, for every output that leaves the schedule, the governing cipher suite (). Labels, output lengths, profile identifiers, cipher suite values, and context fields are length-framed and bound into each output. No output of one profile can then collide with an output of another, or of any future profile with a distinct profile_id, even when they share a permutation: the profile_id separates them at the input encoding. Nor can any output be transplanted between cipher suites, even between two suites of the same profile: the suite binding separates them. Within each profile, distinct derivation paths produce distinct primitive inputs. gives the byte-level argument for TLS13-TURBOSHAKE256. The same framing, with this profile's own profile_id and lengths, gives it for TLS13-SHAKE256.

PSK Profile Binding A PSK is associated with the schedule profile under which it was established, and its binder is computed and verified under that profile and the PSK's recorded cipher suite (). This matters because the binder is computed before the server selects a cipher suite: without the recorded-suite rule, a PSK established under one profile could key the early stage of another, and the binder would not detect it. The server-side selection rules ensure that no secret derived from a PSK ever feeds a schedule other than the one the PSK is bound to. For 0-RTT the rule is strictest, requiring the selected cipher suite to equal the PSK's recorded cipher suite: early-data keys are derived and used before the server's selection can be confirmed by the transcript, so suite equality, not the binder, prevents redirecting early data to a different AEAD or profile.

Downgrade Resistance The governing cipher suite is bound into every derived output, and the selected cipher suite appears in the ServerHello and therefore in TH_SH. In both profiles, intermediate secrets are suite-independent, but no output leaves the schedule without a suite binding, and the server never selects a PSK whose recorded suite differs from its selected suite (), so no output is keyed under a suite the transcript does not confirm. Downgrade among the suites of this document is prevented by the transcript and the per-output suite binding, and, for early data, by the suite-equality check. A client that requires an alternative schedule profile MUST offer only cipher suites of this document. The two profiles of this document share the same schedule structure and the same composed security argument (), differing only in the underlying permutation. Cipher-suite negotiation integrity guarantees that the selection is authentic. A deployment that offers suites of both profiles accepts whichever the peer selects.

PSK Entropy As in RFC 8446, binder unforgeability against an attacker who can guess an external PSK requires the PSK to have adequate entropy, since such an attacker can recompute the binder offline. External PSKs SHOULD have at least 64 octets of entropy.

Authentication Is Out of Scope A cipher suite of this document governs only the AEAD and the key schedule. A fully SHA-2-free connection also requires SHA-2-free authentication: certificate-based authentication is negotiated separately, through the signature_algorithms and signature_algorithms_cert extensions, and commonly relies on SHA-2. A deployment that must avoid SHA-2 entirely MUST restrict those extensions accordingly, or use PSK-only authentication.

Retained RFC 8446 Properties 0-RTT replay properties and forward secrecy via key erasure (realized by each profile's destruction rules) are unchanged from RFC 8446. In both profiles, hybrid key-exchange components remain separated: each component secret is absorbed separately, and secrets are not concatenated before derivation ().

TLS13-TURBOSHAKE256 Considerations The considerations of this subsection apply only to the TLS13-TURBOSHAKE256 profile.

Cryptographic Analysis The keyed sponge and keyed duplex have concrete security bounds , surveyed in ; deck-function session modes are analyzed in ; and the TLS 1.3 key schedule is proven in a multi-stage derivation framework . This subsection develops the security argument for the schedule of this document by composing those results.

Threat Model and Goals The adversary model and key-schedule goals are those of : an active network adversary that controls message delivery, may learn selected stage secrets under compromise predicates, and seeks to distinguish unseen traffic keys, forge Finished or binder values, break forward secrecy across ratchet boundaries, or downgrade the negotiated cipher suite. Authentication of peer identity remains outside the cipher suite, as in RFC 8446. The schedule must provide indistinguishability of record keys and exporter outputs under the chosen AEAD, integrity of the handshake transcript through Finished and binder verification, forward secrecy from handshake compromise to application traffic once (EC)DHE is used, and the RFC 8446 0-RTT replay model when early data is accepted.

Primitive Assumptions The deck function DF is modeled as a sponge over a random permutation . TranscriptHash is an unkeyed XOF on inputs prefixed with "tls13 hash" (). Every keyed derivation is a single call DF(S, L) where seq(S) is an injectively framed byte string (). fixes the XOF, domain-separation parameter, and output lengths for the cipher suites defined here. Under injective framing, distinct derivations map to distinct sponge inputs, and the keyed-duplex analyses bound the adversary's advantage in distinguishing outputs or forging MAC values as a function of permutation queries and output length. TurboKMAC256 is introduced by this document and is not covered by NIST's KMAC security analysis, which is scoped to the Keccak-f[1600]-based cSHAKE256 of KMAC256. Its security is treated here as inheriting from the generic keyed-sponge and keyed-duplex bounds of and , which are stated over an idealized permutation of any round count, not as a NIST-validated instance of KMAC256.

Security Strength and Round Margin TLS13-TURBOSHAKE256 targets 256-bit security, the level its 512-bit capacity supports. Its guarantees at that level all rest on the 12-round Keccak-p[1600,12] permutation of TurboSHAKE256: collision resistance of the transcript hash, indistinguishability of the stage and traffic secrets, and unforgeability of the Finished and binder values. claims that permutation's security at 256 bits. The reduced round count is the only structural difference from a full-permutation instantiation. Capacity, framing, and the derivation graph match the TLS13-SHAKE256 profile, which reaches the same target over the full 24-round Keccak-f[1600] permutation. A deployment that prefers that larger round margin can negotiate TLS13-SHAKE256, the conservative choice ().

Derivation Graph Each derived octet string is one leaf of a derivation tree (). Stage trunks E, H, and T absorb the inputs that RFC 8446 mixes through chained HKDF-Extract and Derive-Secret calls. Ratchets emit the only stage-boundary secrets, early_secret and main_secret (). finished_key and binder_key are the schedule's other intermediate secrets. Each is a deck expansion of a retained secret (), a fresh deck rooted at that secret rather than a fork of a live stage trunk, and each keys exactly one MAC invocation and no other output (). Every remaining leaf equals an expansion, a MAC invocation, or Squeeze(Fork(...)), and each stage secret equals Ratchet(...), hence one deck-function or MAC invocation each (, , ). The comparison of maps every HKDF-Expand-Label site to a unique framed path, and no RFC 8446 secret is derived without a matching leaf here. The mapping is one-to-one on derived values with one intentional divergence: main_secret binds TH_SH through its trunk where the RFC 8446 extract binds no transcript. That extra binding front-loads transcript agreement that RFC 8446 enforces only at Finished. It removes no binding RFC 8446 requires, but it makes this tree a strict superset of the proven RFC 8446 derivation graph rather than an exact image of it. Under the random-permutation model, each leaf is idealized as an independent random-oracle call on its framed path, the standard idealization step for keyed-sponge proofs . It applies at two levels. A traffic or master secret is forked from a live stage trunk whose absorbed secrets have, by fork time, mixed across the full state, so the full-state keyed-duplex bound of governs it. A retained-secret expansion of is instead a fresh deck rooted at a single secret absorbed through the rate, an outer-keyed sponge governed by the keyed-sponge bound of . Because that secret is itself an idealized-uniform ratchet or fork output, the two levels compose by the standard hybrid over the derivation tree. This idealization connects the schedule to the multi-stage framework. is defined over discrete extract-and-expand invocations, so it does not by itself cover a single running sponge state. The keyed-sponge idealization, not directly, carries this document's continuous deck into that framework's scope.

Multi-Stage Security models TLS 1.3 as a multi-stage authenticated key exchange whose stages align with Early, Handshake, and Application secrets. Extract transitions pass an intermediate secret into the next stage while erasing the prior stage's expandable state. Here, early_secret and main_secret are explicit ratchet outputs, and the destruction rules of enforce the same erasure: once H absorbs early_secret, the early stage MUST NOT remain usable, and likewise for main_secret into T. Given (EC)DHE, early_secret and main_secret depend on secrets the adversary does not know at the ratchet. The 512-bit capacity withheld at each squeeze prevents recovering pre-ratchet sponge states from ratchet outputs alone (). This matches the extract semantics on which relies: stage t+1 keys are unpredictable from stage t traffic keys even if stage t was compromised before the ratchet, provided the fresh key-exchange contribution was not learned. Traffic and master secrets within a stage are forks from a common trunk that already binds TH_SH or TH_SF. Fork labels, suite bindings, and transcript absorbs are framed separately (), so fork security reduces to the multi-user keyed-duplex bounds of on a single stage trunk. Finished and binder MACs are MAC invocations (, ), a construction independent of expansion, yielding the same PRF-on-transcript role as HMAC in the analysis. Composing the stage arguments in order E, H, T, under the keyed-sponge idealization above, gives an argument, in the random-permutation model, for the same class of multi-stage key-schedule goals as for connections that use this schedule in place of HKDF, modulo the keyed-sponge and keyed-duplex advantage terms of and : record keys, exporter keys, resumption PSKs, and key-update secrets are argued to inherit the same indistinguishability and integrity guarantees, conditional on the AEAD and authentication assumptions of RFC 8446. This document does not claim a formal reproduction of the theorem, whose statement is proved over discrete extract-and-expand nodes. The subsections below restate protocol-specific assumptions, downgrade controls, and implementation obligations that the model treats as explicit rules rather than derived properties.

Erasure Boundaries and One-Wayness

The Invertibility Hazard A sponge accumulator is built on a permutation (), and permutations are invertible: an accumulator derived from another by absorption alone carries its full past with it. Given a state equal to the permutation of a prior state XORed with a publicly known block (a label, a transcript hash, a stage marker), anyone holding the later state recovers the earlier one. This holds for any sponge-based realization of the deck function, not only the instantiation of this document. A design that carried a raw accumulator across a stage boundary would therefore let a post-handshake state compromise re-derive handshake traffic secrets. One-wayness comes only from truncation at squeeze time: a squeeze withholds the capacity, 512 bits in the instantiation of , so no squeezed output, of any length, permits reconstruction of the state that produced it. Accordingly, an explicit ratchet sits at every boundary where TLS requires erasure or compromise isolation: the early-to-handshake transition (early_secret), the handshake-to-application transition (main_secret), and every key-update generation.

State-Handling Rules An implementation MUST destroy every accumulator of a stage when the stage's ratchet is crossed, MUST NOT retain a forked accumulator as a successor across a ratchet, and MUST NOT serialize, export, or compare accumulators. Squeezed octet-string secrets are subject to the same discipline as their RFC 8446 counterparts: an implementation MUST destroy handshake-stage traffic secrets and record keys when their RFC 8446 analogues would be destroyed, and MUST destroy each stage secret once the next stage has absorbed it. Every cloned accumulator is a 200-octet copy of secret capacity. Clones exist from fork to squeeze. An implementation SHOULD keep that window short and MUST zeroize each clone when it is destroyed, exactly as it zeroizes key material. Within a stage, retaining accumulators is equivalent to retaining the stage's secrets: compromise of a live accumulator yields that stage's underived leaves, as compromise of a stage secret does in RFC 8446, and no more.

Domain Separation Every sequence begins with frame(profile_id) for the fixed profile_id "TLS 1.3 DeckSchedule v1", separating these derivations from any other use of the instantiation's XOF. The invariant the analysis relies on is that distinct derivation paths yield distinct byte strings as deck-function inputs. The framing rules give this jointly: every absorbed item carries a framed tag, every fork absorbs a framed label and the governing cipher suite, output length is bound before squeezing, the ratchet labels are reserved for ratchets, and no label is shared between MAC-type and expand-type uses. Absent inputs are distinguished from empty inputs by the framed tag stream (). Unkeyed transcript hashing is separated at the byte level: a TranscriptHash input begins with the octets of "tls13 hash" (0x74 0x6c ...), whereas every keyed sequence begins with uint16(len(profile_id)) = 0x00 0x17. These leading octets cannot coincide. The MAC () uses domain byte 0x04 where a deck derivation uses the instantiation XOF's native byte, so a MAC output and a deck output over one permutation cannot coincide, and their input encodings differ.

Related Constructions Running-state protocol constructions with fork and ratchet operations have precedent: BLINKER builds a two-party record protocol from a single sponge state with domain-separated forks; STROBE defines KEY, PRF, and RATCHET operations over a duplex, with RATCHET zeroizing rate bytes against rollback; Cyclist makes the ratchet a first-class call; and Disco composes STROBE with the Noise handshake, the closest existing analogue of a handshake key schedule over a forked state. Disco's formal analysis is thin relative to the Noise literature. This document treats it as precedent, not assurance.

TLS13-SHAKE256 Considerations The TLS13-SHAKE256 profile is structurally identical to the TLS13-TURBOSHAKE256 profile (), so the Cryptographic Analysis, Erasure Boundaries, and Related Constructions arguments of apply to it directly, with SHAKE256's Keccak-f[1600] permutation in place of TurboSHAKE256's Keccak-p[1600,12] and this profile's own profile_id and lengths in place of the TLS13-TURBOSHAKE256 profile's (). It does not use raw keyed SHAKE256 for any keyed operation: expansion is a deck-native absorb-then-squeeze session over a framed protocol identifier (), and MAC is the construction of , whose key block, function name, and customization string provide the keyed-mode domain separation that bare SHAKE256 lacks (). KMACXOF256 is not used. Every MAC invocation binds its output length, so outputs of different lengths are unrelated.

Test Vectors Each schedule profile requires independent test vectors covering every derivation it defines. provides vectors for both profiles. Final vectors for both profiles require assigned code points ().

Out of Scope QUIC, DTLS 1.3, and Exported Authenticators remain out of scope for both profiles (): an endpoint negotiating a cipher suite of this document MUST NOT use those mechanisms with that connection unless a specification defines their derivations for its schedule profile.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301. This document describes an interface for importing external Pre-Shared Keys (PSKs) into TLS 1.3. This document describes a mechanism in Transport Layer Security (TLS) for encrypting a message under a server public key. This document defines four eXtendable-Output Functions (XOFs), hash functions with output of arbitrary length, named TurboSHAKE128, TurboSHAKE256, KT128, and KT256. All four functions provide efficient and secure hashing primitives, and the last two are able to exploit the parallelism of the implementation in a scalable way. This document is a product of the Crypto Forum Research Group. It builds up on the definitions of the permutations and of the sponge construction in NIST FIPS 202 and is meant to serve as a stable reference and an implementation guide. National Institute of Standards and Technology Informative References National Institute of Standards and Technology This document describes how Transport Layer Security (TLS) is used to secure QUIC. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. This document describes a mechanism that builds on Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) and enables peers to provide proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out of band to the other peer, and verified by the receiving peer. National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology

Comparison with RFC 8446 This appendix is non-normative. It compares the RFC 8446 schedule with the deck schedule of . Both profiles of this document share this schedule and differ only in the underlying permutation, so the comparison applies equally to TLS13-TURBOSHAKE256 and TLS13-SHAKE256. The figure labels the deck side generically for that reason. With finished_key and binder_key as dedicated MAC keys (), the two schedules are close structurally, not only in the values they produce: both carry the same named intermediates, binder_key and finished_key, into the same MAC step, and both produce the same six traffic and master secrets from the same three trunk inputs. The figure shows the two schedules side by side for a full handshake, lining up node for node where they agree. The table maps each RFC 8446 construction to its replacement.

The Two Schedules Side by Side binder_key | +--> binder_key | +--> c e traffic | +--> c e traffic | +--> e exp master | +--> e exp master v v ratchet "early secret" Derive-Secret "derived" +--------------+ | | early_secret | RATCHET 1 | DHE +--+-----------+ | | | re-init; absorb early_secret, v v | DHE, TH_SH once +--------------+ v | Handshake | +--------------+ | Secret | | H stage | +--+------+----+ +--+------+----+ | | | | | +--> c hs traffic | +--> c hs traffic | +--> s hs traffic | +--> s hs traffic v | Derive-Secret "derived" v ratchet "main secret" | +--------------+ | 0 | main_secret | RATCHET 2 | | +--+-----------+ v v | re-init; absorb main_secret, +--------------+ | TH_SF once | Main Secret | v +--+-----------+ +--------------+ | | T stage | +--> c ap traffic +--+-----------+ +--> s ap traffic | +--> exp master +--> c ap traffic +--> res master (TH_CF) +--> s ap traffic | +--> exp master v +--> res master (TH_CF) per traffic secret: | "key" + "iv" v Expand-Labels per traffic secret: one call, split per base_key or per base_key or binder_key: binder_key: finished_key = finished_key = Expand-Label "finished" expand(...,"finished",...,SecretLen) ]]>

expand(...) in the figure denotes a deck expansion (). It is figure-only shorthand and is not a function name this document defines. Both schedules fork binder_key from the same Early Secret analogue, and both derive finished_key from binder_key or from a traffic secret by the same "finished" label, feeding the same MAC step (HMAC on the left, MAC on the right, ). The schedules diverge in topology, not in which named secrets exist: RFC 8446 threads every stage transition through a discrete HKDF-Extract, salted by a Derive-Secret("derived") call, where the deck schedule absorbs each stage's inputs into one running state and crosses the boundary with a single ratchet. The Finished and binder MACs, record keys, exporters, resumption PSK, key updates, and PSK import each replace their RFC 8446 counterparts one for one, and gives the per-shape rules.

Invocation Count The figure of shows structural closeness. This table quantifies it. Both profiles of this document share the deck schedule and therefore the same invocation count, differing only in the underlying permutation, so the count is given once for both. The handshake counted is one full 1-RTT handshake that offers and selects a PSK, uses (EC)DHE, accepts 0-RTT early data, issues one NewSessionTicket, and performs one KeyUpdate in each direction, the maximal common case both RFC 8446, Section 7.1 and cover completely. A deck invocation is one expand, MAC, or Ratchet call, matching the One-Shot Equivalence of . An RFC 8446 invocation is one HKDF-Extract, HKDF-Expand-Label, or HMAC call. Fork and Absorb build an input sequence rather than invoking the primitive and are not separately counted, matching how already accounts for deck operations. Invocation Count for One Full Handshake

Derived value	Deck (this document)	RFC 8446
Early Secret / early_secret	1 (Ratchet)	1 (HKDF-Extract)
binder_key	1 (expand)	1 (Derive-Secret)
finished_key (binder)	1 (expand)	1 (Expand-Label)
PSK binder verify_data	1 (MAC)	1 (HMAC)
client_early_traffic_secret	1 (Fork+Squeeze)	1 (Derive-Secret)
early_exporter_master_secret	1 (Fork+Squeeze)	1 (Derive-Secret)
early traffic key + iv	1 (expand)	2 (Expand-Label)
"derived" salt (to Handshake Secret)	0	1 (Derive-Secret)
Handshake Secret / main_secret	1 (Ratchet)	1 (HKDF-Extract)
client_handshake_traffic_secret	1 (Fork+Squeeze)	1 (Derive-Secret)
server_handshake_traffic_secret	1 (Fork+Squeeze)	1 (Derive-Secret)
client hs traffic key + iv	1 (expand)	2 (Expand-Label)
server hs traffic key + iv	1 (expand)	2 (Expand-Label)
finished_key (server Finished)	1 (expand)	1 (Expand-Label)
server Finished verify_data	1 (MAC)	1 (HMAC)
finished_key (client Finished)	1 (expand)	1 (Expand-Label)
client Finished verify_data	1 (MAC)	1 (HMAC)
"derived" salt (to Master Secret)	0	1 (Derive-Secret)
Master Secret (2nd ratchet)	1 (Ratchet)	1 (HKDF-Extract)
client_application_traffic_secret_0	1 (Fork+Squeeze)	1 (Derive-Secret)
server_application_traffic_secret_0	1 (Fork+Squeeze)	1 (Derive-Secret)
exporter_master_secret	1 (Fork+Squeeze)	1 (Derive-Secret)
resumption_master_secret	1 (Fork+Squeeze)	1 (Derive-Secret)
client ap traffic key + iv (gen 0)	1 (expand)	2 (Expand-Label)
server ap traffic key + iv (gen 0)	1 (expand)	2 (Expand-Label)
client_application_traffic_secret_1	1 (expand)	1 (Expand-Label)
client ap traffic key + iv (gen 1)	1 (expand)	2 (Expand-Label)
server_application_traffic_secret_1	1 (expand)	1 (Expand-Label)
server ap traffic key + iv (gen 1)	1 (expand)	2 (Expand-Label)
resumption PSK (NewSessionTicket)	1 (expand)	1 (Expand-Label)
TLS-Exporter output (one request)	1 (expand)	2 (Derive-Secret + Expand-Label)
Total	29	39

Of the deck total, 3 invocations are MAC (the PSK binder and both Finished values) and 26 are expand, Ratchet, or Fork+Squeeze. Of the RFC 8446 total, 3 invocations are HMAC and 36 are HKDF-Extract or HKDF-Expand-Label. This operation count understates the difference, because it counts operations rather than the permutation calls that are the cost unit the two schedules share. Each HKDF or HMAC operation is two nested hash calls, so over the same 24-round Keccak-f[1600] permutation a hash-only HKDF-SHA3-256 instantiation of the RFC 8446 schedule costs 156 permutation calls for this handshake against the deck's 52, a factor of three. HMAC's nested hashing is the overhead a keyed sponge does not carry. The deck is lower at the operation level too, in every row where RFC 8446 needs two Expand-Label calls, one for "key" and one for "iv", against this document's single expansion that outputs Nk + Nn octets and splits the result (), and in the two rows where RFC 8446's chained-extract structure needs an explicit Derive-Secret("derived") call to salt the next HKDF-Extract, which this document's ratchet does not need. The composed security argument of does not rest on either count.

Implementation Considerations This appendix is non-normative. The profile of requires incremental XOF absorption, cloning of an unfinalized state, and one-shot squeeze. Output lengths are always known up front. See for the concrete API surface and permutation parameters of that profile. gives the analogous parameters for the TLS13-SHAKE256 profile. Stage trunks and stage secrets bind no cipher suite value, so a client offering several cipher suites of this document maintains one schedule regardless of how many suites it offers. Only leaf derivations differ, and only in their framed suffix. An implementation choosing the one-shot recomputation strategy for leaves retains raw key-exchange inputs longer than the stateful strategy. The stateful strategy is the appropriate choice wherever the erasure semantics of matter. Accumulator clones follow the lifetime and zeroization rules of . Both ratchets consume a transcript checkpoint that the corresponding RFC 8446 extracts do not: the handshake stage absorbs TH_SH and the application stage absorbs TH_SF at initialization. A stack that mirrors RFC 8446's derivation order and computes its master secret before the server Finished exists must defer the second ratchet until that checkpoint is available. In the one stack ported so far this was code motion within existing functions, with no change to message flow. The destruction rules of bound what an implementation deliberately retains. In garbage-collected runtimes, zeroization is inherently best effort: the runtime may have copied or moved key material, and erasing every copy is not achievable from the language. Such implementations satisfy the destruction rules by ceasing use, dropping references, and zeroizing the buffers they control, as they already do for RFC 8446 key material. A cipher suite is a single negotiated value that determines both the AEAD algorithm and the schedule profile. There is no mechanism for combining them independently (). PSKs and session tickets carry their originating cipher suite, and therefore their schedule profile, with them (). A client that offers PSKs associated with different schedule profiles computes each binder under its own PSK's profile, which requires maintaining transcript-hash state per governing profile for the partial ClientHello transcript.

Test Vectors This appendix is non-normative. Complete machine-readable test vectors for both profiles are published as artifacts in this document's repository, alongside the reference implementation that generated them and the independent implementations that reproduced them. Every derived output binds the governing cipher suite, so no final vector can exist before code points are assigned (): the sets use declared private-use placeholder values (0xFF01 to 0xFF03 for the TLS13-TURBOSHAKE256 suites, 0xFF04 and 0xFF05 for the TLS13-SHAKE256 suites). The vectors track this document's expansion and MAC operations (, ) and are regenerated whenever that encoding or the code points change. Each set is generated by one implementation and reproduced by an independent implementation constructed from this document alone.

TLS13-TURBOSHAKE256 Vectors The published set contains 44 vectors: transcript-hash pins, the no-PSK early_secret, a full schedule trace with a PSK and a key-exchange secret (resumption and external binders, early leaves, both stage secrets, and all six traffic and master secrets), record key blocks for both key lengths under all three suites, the Finished MAC, two key-update generations, resumption PSKs with present and empty nonces, exporters including the early exporter, both ECH confirmations, a PSK-only trace pinning the omitted "dh" absorb, suite-binding cross-checks, the HelloRetryRequest synthetic transcript, and the PSK-importer ipsk in three variants, including an epsk at the 0xFFFE frame limit.

TLS13-SHAKE256 Vectors This profile's vector set tracks the deck schedule of instantiated with SHAKE256 (), mirroring the coverage of : transcript-hash pins, the no-PSK early_secret, a full schedule trace with a PSK and a key-exchange secret, record key blocks for both key lengths, two key-update generations, resumption PSKs, exporters, both ECH confirmations, suite-binding cross-checks, the HelloRetryRequest synthetic transcript, and the PSK-importer ipsk. The published set contains 40 vectors, generated from this profile and reproduced by an independent implementation built from this document alone. Within this profile's two suites and single PSK-importer ipsk, it omits the third-suite cross-checks and the extra import variants of . A message-level full-handshake trace in the style of RFC 8448 has not yet been extracted, though a reference implementation now wires this profile into a TLS stack.

A Fully FIPS-Component Key Schedule (Informative) This appendix is non-normative. It records an extract-and-expand schedule assembled entirely from FIPS-approved components, for deployers and future work that need that property before or instead of the deck schedule of . This document does not define this schedule as a profile: it has no code point, no cipher suite, and no IANA registration, and and are unaffected by it. The TLS13-SHAKE256 profile's deck schedule of is built from FIPS 202 and SP 800-185 functions used in isolation, SHAKE256 for the deck and KMAC256 for the MAC, but as a keyed-duplex key-derivation function the deck is not itself an approved key-derivation function under any current NIST Special Publication, and no CAVP or CMVP testing covers it. A deployment that requires FIPS-approved primitives throughout therefore cannot use the deck. This appendix records an approved-component alternative for it, subject to the validation caveats below. TLS13-TURBOSHAKE256, whose TurboSHAKE256 and TurboKMAC256 are not approved functions, is not available to such a deployment either. The schedule is the RFC 8446, Section 7.1 extract-and-expand structure with its PRF replaced by KMAC256 throughout, and its Extract step drawn from NIST SP 800-56C rather than from HKDF-Extract.

Extract:

An SP 800-56C two-step randomness-extraction step, PRK = KMAC256(K = salt, X = IKM, L = 512, S = ""), applied at each of the three stage transitions of RFC 8446, Section 7.1: Early = Extract(0, PSK), Handshake = Extract(derived, (EC)DHE), and Master = Extract(derived, 0), where derived is the RFC 8446 Derive-Secret("", "derived", "") intermediate at each transition and 0 denotes an all-zero string of the same length as the adjacent secret.

Expand:

An SP 800-108 KBKDF counter-mode expansion with KMAC256 as the PRF, used for every Derive-Secret and HKDF-Expand-Label site of RFC 8446, Section 7.1: record keys, traffic secrets, exporter and resumption secrets, and the Finished and PSK binder keys.

TranscriptHash:

An approved SHA-3-family function: SHA3-256, SHA3-384, or, for a variable-length instantiation with an explicit output length, SHAKE256 or cSHAKE256 .

This schedule is structurally RFC 8446, Section 7.1 with its PRF replaced by another approved PRF. Most of the CMVP approved-CVL decomposition of the TLS 1.3 KDF therefore transfers directly: for the initial all-zero input and for Expand, for which SP 800-108 recognizes KMAC as a PRF. The RFC 8446 key-schedule security analysis is likewise modular over the underlying PRF and re-instantiates with KMAC256. The one component that does not transfer for free is the Extract step: SP 800-56C's approved randomness-extraction functions are HMAC- and AES-CMAC-based, so whether KMAC256 is approved there, rather than HMAC, is a point a validation would have to establish, and this document does not assert it. This document does not claim that a schedule built this way is fully FIPS-validated or fully FIPS-validatable today. It is assembled entirely from FIPS-approved components, and whether a CMVP validation of the composite reuses existing CAVP test vectors for SP 800-56C and SP 800-108 or requires its own named CVL entry is a determination for a validation laboratory and CMVP, not one this document makes. This appendix records the approvable variant for deployers and future work. It is not a profile this document defines.