]> XOF-based key schedules for TLS 1.3 Cryptography Consulting LLC
nicholas.sullivan+ietf@gmail.com
Tampere University, Finland
markku-juhani.saarinen@tuni.fi
STMicroelectronics, Belgium
gilles.vanassche@st.com
Security TLS TLS 1.3 key schedule KDF XOF dec engine duplex sponge cSHAKE cipher suites TLS 1.3 runs its entire key schedule on HKDF over SHA-2. This document defines an extension that replaces that schedule with one built on an extendable-output function (XOF): the negotiated KDF governs every derivation, the Finished and binder MACs, and the transcript hash, so no SHA-2 remains in the key schedule. The cipher suites, AEAD algorithms, state machine, and record layer are unchanged, and a connection without the extension uses HKDF as today. Two KDFs are defined, SHAKE256 and the reduced-round TurboSHAKE256. This document updates RFC 9147, RFC 9258, RFC 9261, and RFC 9849. 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 In TLS 1.3 , every cipher suite runs its key schedule on HKDF over the suite's hash. This document defines an extension that negotiates an XOF-based KDF for the connection. Its key schedule runs on a single Keccak permutation and replaces HKDF across every derivation, the Finished and binder MACs, and the transcript hash. The permutation is the one a deployment already carries when it uses SHA-3, ML-KEM, or ML-DSA. When no KDF is negotiated, the cipher suite's hash names HKDF and TLS 1.3's own schedule runs, exactly as today. 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. TLS 1.3 already negotiates groups, KEMs, signature schemes, PSKs, and AEAD algorithms. This document extends that agility to the key schedule itself. A TLS 1.3 cipher suite identifies an AEAD algorithm and the hash used with HKDF. This document leaves the suite alone and negotiates the KDF beside it:
Cipher Suite and KDF
A KDF () 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. It is negotiated in the schedule_profile extension of , independently of the cipher suite. A connection that negotiates no KDF is a TLS 1.3 connection: absence is the default, and TLS 1.3's own schedule needs no identifier of its own. Each KDF defined here is a profile of the same construction: an XOF viewed under the interface of a doubly extendable cryptographic (dec) engine, where it absorbs the schedule's inputs as length-framed strings and squeezes each derived value from the accumulated sequence. It is defined once for both profiles in , and each selects a different permutation for it: TLS13_TURBOSHAKE256 () uses the 12-round TurboSHAKE256 , and TLS13_SHAKE256 () uses the 24-round SHAKE256 . Finished and PSK binder values, including an Exported Authenticator's Finished, use one MAC (). The Encrypted Client Hello acceptance value is produced by the dec engine's output operation, Derive ().
Design Goals A KDF turns the whole derivation surface of a connection into one named, testable object. Every value comes from one permutation, every query is injectively framed (), DeriveN outputs occupy disjoint slices, and gives byte-exact values for both profiles. Neither KDF uses SHA-2, HMAC, or HKDF in any role, and the correspondence with TLS 1.3 can be audited shape by shape (). The alternative is to keep TLS 1.3's HKDF schedule and give it a SHA-3 hash. The dec engine costs fewer permutation calls than that alternative. HKDF is built on HMAC, and every HMAC call nests two hash calls, overhead that exists only to key a hash not built for keying. A keyed sponge needs no such wrapper: it produces each Derive output in one squeeze, with no separate extract step between stages. Over the representative handshake of , the dec engine costs 23 Keccak permutation calls against 120 for a hash-only HKDF-SHA3-256 over the same permutation (). HMAC accounts for four permutation calls in every HKDF operation, two for each of its nested hashes, where a Derive here costs one or two and a DeriveN at most three ().
Scope This document does not define a new version of TLS, and defines no cipher suites. It adds one extension. The state machine, record layer, all other wire structures, cipher suites, AEAD algorithms, and per-record nonce construction remain those of TLS 1.3, or of DTLS 1.3 on a DTLS 1.3 connection (). A KDF governs only the key schedule and the transcript hash (). Negotiating one 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 TLS or DTLS connection must additionally restrict itself to SHA-2-free signature schemes and certificate chains, or use PSK-only authentication. Note also that the cipher suite continues to name a hash, which under a KDF of this document governs nothing in the key schedule ().
Dec Engine A key schedule is a derivation tree. A dec engine () expresses that tree directly: absorb a stage's inputs into a running accumulator, derive each leaf from a clone, and ratchet the accumulator into the next stage. One XOF does the work HKDF splits between Extract, at the stage boundaries, and Expand-Label, at the leaves. The construction takes no key: a secret is an ordinary framed input. The operations named here, Init, Absorb, Derive, DeriveN, and Ratchet, are defined normatively in .
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.
KDF:
The key-derivation function of a connection, named by a TLS KDF Identifier and negotiated in the schedule_profile extension (). It defines every key-schedule computation of the connection () and determines the key schedule: a TLS13_TURBOSHAKE256 or TLS13_SHAKE256 identifier implies this document's dec engine-based key schedule (), and absence of the extension implies TLS 1.3's HKDF schedule over the cipher suite's hash.
selected_cipher_suite:
The cipher suite selected in the ServerHello message.
associated cipher suite:
The cipher suite associated with a PSK ().
dec engine:
A doubly-extendable cryptographic (dec) stateful object, whose input is a sequence of strings, and whose output is a hash of that input.
dec accumulator:
The state of a dec engine, which materializes the sequence of strings it received so far.
trunk (stage trunk):
The running dec accumulator for a schedule stage (E, H, or T), which absorbs the stage's inputs, is cloned for each of the stage's leaf outputs or DeriveN output tuples, and yields an internal squeezed residue that seeds the next stage's trunk at the stage boundary.
shared_secret:
The asymmetric shared secret, computed as in .
Nk, Nn:
The AEAD key and nonce lengths of the selected cipher suite, in octets.
FLen:
The length of the verify_data of a Finished message, including an Exported Authenticator's, and of a PSK binder: 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.
A uint16 encodes 65535, so frame(x) carries any x of 0xFFFF octets or fewer, and longer inputs 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 negotiated KDF (, ). TranscriptHash is computed over the handshake transcript as in : message type and length fields are included, and record-layer framing is excluded. TranscriptHash accepts any octet string. The TLS 1.3 rules define only how the handshake transcript is serialized before hashing, and the same function is applied to non-transcript inputs such as exporter contexts and imported PSK identities. For a HelloRetryRequest, the synthetic-message construction in 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. The selected suite enters the transcript at the ServerHello, separating later outputs as in TLS 1.3. The schedule_profile extension enters the transcript at the ClientHello, so TH_CH0, TH_CH, and TH_SH bind the offered KDFs. This document uses the following checkpoint values:
TH_CH0:
TranscriptHash of the partial ClientHello transcript in : 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 TLS 1.3.
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 .
Key-Derivation Functions A KDF is a set of algorithms and encodings negotiated in the schedule_profile extension (), independently of the cipher suite. A KDF specifies:
  • the XOF over which its dec engine-based key schedule and MAC are instantiated ().
  • 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.
  • the domain-separation and input-framing rules its derivations use.
The suite continues to select the AEAD, as in . Future specifications may define additional KDFs by registering a TLS KDF Identifier () whose definition covers every computation listed above. Every derivation of a KDF MUST bind at least the following into the input of the underlying primitive: a protocol identifier (the KDFs of this document frame schedule_label, ), each output label and length (a KDF MAY instead fix the length of an internal stage secret as a 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. A multi-output operation also MUST bind the output count and ordered partition. Distinct canonical input sequences have distinct encodings. Outputs of one DeriveN share a query and occupy disjoint slices (). Both profiles of this document bind each output length as uint16. DeriveN also bounds their sum to 65535 octets (), so no invocation produces more than 65535 octets. The exporter is the one derivation whose length is caller-chosen, and says which requests it rejects. Every other output length in this document is fixed: a profile constant, Nk, Nk + Nn, or the 8 octets of an ECH confirmation, and each fixed DeriveN total is a sum of these. All are far below the bound.
KDF Selection and PSK Compatibility The negotiated KDF governs the whole key schedule of a connection, the role SHA-256 or SHA-384 plays in . Its XOF runs every derivation of the schedule (). A PSK binder is computed before the server selects a cipher suite, and verified under the KDF the PSK is bound to. As in , a server MUST verify the binder of any PSK it selects. The binder is keyed by a secret derived under that KDF (), so a binder computed under one KDF verifies under another only by chance. A server MUST NOT select a PSK unless the KDF of the connection it forms is compatible with the KDF associated with the PSK. Two KDFs are compatible only if they are the same TLS KDF Identifier. This document defines no broader compatibility. This rule is the analogue of , which requires a resumption to share the PSK's hash: under this document the KDF is the hash (). A client MUST abort the handshake with an illegal_parameter alert if the server selects a PSK whose KDF is incompatible with the selected KDF, as that section requires of the hash. Otherwise a 1-RTT resumption follows TLS 1.3. The selected cipher suite need not equal the PSK's associated cipher suite. A resumption MAY change the AEAD as long as the KDFs are compatible. The selected suite appears in the ServerHello and therefore in the transcript, which separates every handshake and application output as in TLS 1.3 (). After a HelloRetryRequest, an updated binder remains under the PSK's KDF. A client SHOULD omit from its updated ClientHello any PSK whose KDF is incompatible with the KDF implied by the HelloRetryRequest, and MUST recompute binders as required by . For 0-RTT, the server MUST require the selected cipher suite to equal the PSK's associated cipher suite (). This is TLS 1.3's own 0-RTT rule. A PSK that is offered but not selected contributes no secret to the schedule, though its identity and binder remain in the ClientHello and so in the transcript. 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 KDF. Implementations MUST associate every PSK and session ticket with its KDF to select a compatible PSK and compute its binder. For an imported PSK, this is its target_kdf (). Implementations MUST also retain the PSK's associated early-data parameters (cipher suite, ALPN, and early-data permission). As in , these are provisioned along with the key for external PSKs, including imported PSKs, and negotiated when the PSK was established for resumption PSKs and session tickets. An imported PSK without provisioned early-data parameters is not eligible for early data.
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 dec engine rooted at that secret (), specified once for both profiles in since the dec engine is identical up to the underlying cryptographic permutation. MAC, which computes the Finished and PSK binder tags, is one such derivation (). The stage schedule is also the same for both profiles (), and only DF differs (, ).
Deriving from a Retained Secret A value keyed by a retained octet-string secret uses Derive or DeriveN () whose dec engine is seeded with that secret rather than run as a live stage trunk. The seed is the secret itself: Init(secret), the same way a ratchet seeds the next stage with its residue. Derive then adds the context under the "ctx_" tag if any, the label, and the output length under the "out_" tag: label is a 3-octet label registered in the TLS XOF Key Schedule Labels registry (), whose initial contents are the labels of , context is an octet string, and L is the output length in octets. Every item is length-framed by the dec engine (). DeriveN binds the ordered labels and lengths before one squeeze and partitions that output into disjoint slices. An empty context is omitted rather than framed as an empty value, and omission is its canonical encoding. It differs from an explicitly framed empty value, because after an omitted context the next item is the label or "outs", not frame("ctx_"). L never exceeds 65535 octets (). Such a Derive is the analogue of TLS 1.3's HKDF-Expand-Label, and gives the label each of its labels replaces in TLS 1.3 or DTLS 1.3. The following retained-secret derivations are instances of this shape, each fixing the base secret, label, context, and output length. The exporter () uses two such derivations, with the raw exporter label as the first context and the context hash as the second. The ECH acceptance confirmations () take a transcript hash as context, and MAC () takes the message it authenticates. Every derivation of this shape carries its context under the "ctx_" tag, including one whose context is itself a transcript hash.
  1. Early key_block () uses c_e_traffic as its base secret, label "key", no context, and length Nk + Nn in a single-output Derive.
  2. The DeriveN that derives finished_key and key_block () uses the sender's handshake traffic secret as its base secret and no context. Its outputs are finished_key with label "fin" and length SecretLen, then key_block with label "key" and length Nk + Nn.
  3. The DeriveN that derives the next traffic secret and key_block () uses the sender's current application traffic secret as its base secret and no context. Its outputs are the next traffic secret with label "upd" and length SecretLen, then key_block with label "key" and length Nk + Nn.
  4. resumption_psk uses resumption_secret as its base secret, label "rsp", context ticket_nonce, and length SecretLen in a single-output Derive.
  5. ipsk () uses epsk as its base secret, label "ipk", context TranscriptHash(ImportedIdentity), and length SecretLen in a single-output Derive. The context is the transcript-hash reduction defined in .
The DeriveN calls for record keys apply separately to each direction. "key" names the whole key_block, which contains write_key followed by write_iv.
MAC MAC(key, message, L) computes every tag in this document: the PSK binder, both Finished values, and the Finished of an Exported Authenticator (). It is a Derive over a dec engine seeded with the key (), with the label "mac" and the message as its context: Every MAC of this document takes a 64-octet key and a 64-octet transcript hash as its message, so its input to DF () is these 167 octets, with the key and the message each starting on an 8-octet boundary (). The listing is the TLS 1.3 layout. A DTLS 1.3 connection substitutes "dtls13" for "tls13 ", with the same lengths and offsets (): No other derivation of this document uses the label "mac", so a MAC input is never the input of another derivation (). The output length is bound by the "out_" item as in every Derive, so tags of different lengths are computed over different inputs. MAC is the analogue of TLS 1.3's HMAC-based Finished and binder MACs, and like them it is keyed by a dedicated key that keys nothing else (, ). The client and server Finished values are computed the same way, each over a different key and a different message. L never exceeds 65535 octets (). MAC uses the profile's DF and nothing else, so it needs no primitive beyond the SHAKE256 or TurboSHAKE256 that computes every other derivation and the transcript hash.
Record Keys Record keys are the "key" output of . A retained traffic secret suffices to re-derive its keys, as in TLS 1.3. For early-data keys, derived before the ServerHello, Nk and Nn are those of the offered PSK's associated cipher suite. For every other traffic secret they are those of selected_cipher_suite. Early record keys use the single-output encoding: Each handshake traffic secret uses a fixed DeriveN call that also produces that sender's Finished key: Every application traffic-secret generation uses a fixed DeriveN call that also produces the next generation's secret: The application record DeriveN runs even when no KeyUpdate is planned, so the next traffic secret exists from the start of its predecessor's epoch. The next generation's record keys are derived only when its epoch starts. SecretLen is 64, so the secret and key_block start on 64-bit boundaries, and the IV does too when Nk is a multiple of 8. Each descriptor's length is bound into the input. The split is unambiguous: Nk and Nn are fixed by the suite, and their sum is bound into the derivation as the key_block output length, so Nk + Nn also changes the finished_key or next traffic secret derived alongside it. 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 TLS 1.3, or from DTLS 1.3 on a DTLS 1.3 connection.
Key Update A key update installs app_traffic_secret_{N+1}, the "upd" output already produced with generation N's record keys (). It then runs the application record DeriveN again, under the installed secret: The new next_secret is app_traffic_secret_{N+2} and is retained until the next update. An implementation MUST NOT derive generation N+1 from anything other than generation N, in particular not from a retained stage accumulator or a counter: that rule determines the derived value and so is an interoperability requirement. Each generation is also an erasure boundary. In TLS, the previous secret, its keys, and any schedule state derived from them are destroyed once the new generation is installed, except for the successor secret deliberately carried across the boundary (). In DTLS, a receiver MUST retain the previous epoch's record key, IV, and sn_key (), or their traffic secret, until it successfully decrypts a record from the new epoch ().
Finished and PSK Binder MACs Finished and PSK binder verify_data are computed under a dedicated MAC key, derived from a stage or traffic secret (), rather than by MACing that secret directly. This matches : finished_key and binder_key take the roles of TLS 1.3's identically named intermediates, and MAC takes the role of TLS 1.3's HMAC. A handshake finished_key is the "fin" output of the DeriveN that derives that sender's handshake record keys (). For post-handshake authentication, base_key is the sender's current application traffic secret from the authentication-input table of . The label is "fin", and th covers the Handshake Context and authentication messages that the same table gives for that Finished, up to but not including the Finished being computed. For a PSK binder, the dedicated key is derived in two steps, as TLS 1.3 derives binder_key in Section 7.1 and then finished_key from it in Section 4.3.11.2, via Section 4.5.3: E is the live early trunk of the schedule keyed by that PSK, before its ratchet (). binder_key comes from a DeriveN on E that also derives early_residue, so the early trunk is the analogue of TLS 1.3's Early Secret from which derives binder_key. binder_label is "ebk" for a non-imported external PSK, replacing "ext binder", "ibk" for an imported PSK, replacing "imp binder" from , and "rbk" for a resumption PSK, replacing "res binder". The handshake dec engine is seeded from this DeriveN (), so the early residue depends on the binder label, so equal non-imported external, imported, and resumption PSK bytes lead to different handshake-stage inputs. Without a PSK there is no binder DeriveN. finished_key is derived under "fin" for both a Finished and a binder, and the two are already separated one step up by their base secret, a traffic secret against binder_key. Both finished_key and binder_key are 64 octets, the length of every stage and traffic secret in both profiles (SecretLen, , ), matching TLS 1.3'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 TLS 1.3 HKDF-Expand-Label calls. Each finished_key is a dedicated MAC key, and a handshake Finished MAC key shares its base secret, the sender's handshake traffic secret, with that sender's record keys (). Binders are computed before the ServerHello. This is possible in both profiles because the early trunk binds no cipher suite: the client clones the early trunk to obtain binder_key at ClientHello time, in either profile ().
Exporters Exporters use two retained-secret derivations, following the shape of : The early exporter is the same construction keyed by early_exporter_secret. The raw label is the first Derive's context and is framed under "ctx_" (). An implementation MUST reject a TLS-Exporter request whose label exceeds the 65535-octet frame limit, rather than reduce its length modulo 65536. The intermediate lets an implementation that knows all its exporter labels derive their label secrets and then erase exporter_secret, as recommends. Framing the raw label separates inputs to the first Derive without relying on TranscriptHash collision resistance for that separation. The second Derive takes the context hash because the context has unbounded length. An implementation MUST reject a TLS-Exporter request for zero octets or for more than 65535 octets of output. Reducing a longer request modulo 65536 would let two different requested lengths bind the same encoded value.
ECH Acceptance Confirmations This document updates for a connection that negotiates a KDF of this document. A connection that negotiates no KDF uses unchanged. For the KDFs of this document, the ECH acceptance signals of are: replacing the HKDF-Extract and HKDF-Expand-Label computations of and its labels "ech accept confirmation" and "hrr ech accept confirmation", with ech_conf_messages and hrr_ech_conf_messages the handshake message ranges that document identifies for each confirmation, per . TranscriptHash(ech_conf_messages) is the transcript_ech_conf of , the same single transcript-hash operation, applied once. 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 seeds a dec engine with ClientHelloInner.random itself and takes one Derive, in place of the extract-then-expand of . Computing the confirmation requires ClientHelloInner.random, which only the client and a server that holds ClientHelloInner know. Each confirmation's transcript covers the message that carries it, the ServerHello or the HelloRetryRequest.
ECH and KDF Selection The server applies the rules of to ClientHelloInner if it accepts ECH and to ClientHelloOuter if it rejects it. The two may offer different KDFs. The client learns which from the server's first message, as in . It computes the confirmation under the KDF that message selects, or as in if it selects none, and a confirmation it cannot compute counts as a rejection. It then applies the rules of to the same ClientHello. The KDF of the HPKE suite that encrypts ClientHelloInner plays no part in this selection.
PSK Import Derivation An external PSK is imported per target KDF (). For every KDF of this document, ipsk is the "ipk" derivation of , keyed by epsk with TranscriptHash(ImportedIdentity) as context, with target_kdf as the KDF. This follows the shape of the derivation in , with the entire serialized ImportedIdentity 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 dec engine-based derivation () in both profiles, so a low-entropy or attacker-influenced epsk never keys either profile's underlying permutation directly.
Negotiating a KDF This document defines no cipher suites. A connection uses the cipher suites of TLS 1.3, and negotiates its KDF separately, in a new extension. Coupling the two would make the offered set the product of the AEAD choices and the schedule choices, and would oblige a client that wants one schedule with two AEADs to carry a code point for each combination. The schedule and the AEAD are independent choices, and this document negotiates them independently. The value negotiated is a TLS KDF Identifier, the registry already created for naming a key schedule independently of a cipher suite. A KDF of this document registers there (). ; /* TLS KDF Identifiers */ } ScheduleProfileList; ]]> The extension_data of a schedule_profile extension () is a ScheduleProfileList in a ClientHello, in preference order, and a single uint16 in a ServerHello or a HelloRetryRequest. Absence is the default, and the default is TLS 1.3: a connection whose ClientHello omits the extension, or whose server does not echo it, runs the key schedule in , HKDF over the negotiated cipher suite's hash. That is HKDF_SHA256 or HKDF_SHA384 as the suite's hash determines, so TLS 1.3's own schedule needs no value of its own here and an endpoint of this document interoperates with TLS 1.3 unchanged. A client that requires an alternative schedule MUST abort with a handshake_failure alert if the server's first message, a HelloRetryRequest or ServerHello, omits the extension (). After an ECH rejection, the requirement does not extend to the ClientHelloOuter handshake, which only authenticates the public name for ECH retry and carries no application data (). The offered list does not signal whether the client requires an alternative schedule or permits fallback. Because absence is the sole signal for the TLS 1.3 schedule, a ScheduleProfileList MUST NOT include HKDF_SHA256 or HKDF_SHA384, the other values of the TLS KDF Identifiers registry (). A server that receives either MUST treat it as if that KDF were not offered, and MUST NOT select it. The KDFs of this document are TLS13_TURBOSHAKE256 () and TLS13_SHAKE256 (). A server MUST NOT select a KDF the client did not offer. A client that sent schedule_profile MUST abort the handshake with an illegal_parameter alert if the ServerHello or HelloRetryRequest selects a KDF it did not offer, as requires for the cipher suite. A client that did not send it treats the extension in either message as unsolicited and aborts with an unsupported_extension alert (). A server that selects a KDF of this document MUST send the extension in its ServerHello, so the selection is covered by the transcript (). A server that sends a HelloRetryRequest and selects a KDF of this document MUST carry the selected KDF as a schedule_profile extension in the HelloRetryRequest. That selection pins the KDF for the rest of the handshake and is the KDF implied by the HelloRetryRequest (). The client computes its second ClientHello and every later checkpoint under that KDF, and the HelloRetryRequest is covered by the transcript. A HelloRetryRequest without the extension selects the TLS 1.3 schedule for the rest of the handshake, and the server MUST NOT then send the extension in its ServerHello. A client that sent schedule_profile MUST abort the handshake with an illegal_parameter alert if the ServerHello's schedule_profile, present or absent, differs from the HelloRetryRequest's, as requires for the cipher suite. With ECH, these rules apply to the ClientHello that identifies.
What the KDF Governs A KDF defines every key-schedule computation of the connection, including the transcript hash (). When a KDF of this document is negotiated, the hash named by the cipher suite governs nothing in the key schedule: the transcript hash is the KDF's, and the derivations and MACs are the KDF's. The transcript hash a CertificateVerify signs () is also the KDF's TranscriptHash. The cipher suite's name still carries that hash. A connection on TLS_AES_128_GCM_SHA256 with TLS13_TURBOSHAKE256 selected takes AES-128-GCM, its Nk and Nn, and its per-record nonce construction from the suite, and takes SHA-256 from nowhere: no part of the key schedule uses it. A connection that negotiates no KDF is unaffected: the suite's hash governs its schedule exactly as TLS 1.3 specifies.
The Dec Engine-Based Key Schedule Both KDFs of this document express the key schedule as a dec engine (). The schedule's normative interface is defined here, in terms of the profile's XOF and nothing else: Init and Absorb build a framed input sequence, Derive reads one to produce a keyed output, DeriveN reads one to produce an ordered tuple, and Ratchet crosses a stage boundary. Each Derive or DeriveN is one XOF call over its input sequence. and each give a short instantiation naming the profile's XOF, permutation, and domain-separation constants. This document uses the following terms.
schedule_label:
The fixed 6-octet ASCII string "tls13 " (with a trailing space), framed at Init () into every derivation of both profiles, or "dtls13" on a DTLS 1.3 connection (). It marks the dec engine-based key schedule and is identical for both profiles, which are separated by their XOF, not by this label. It is byte-identical to the label prefix of HKDF-Expand-Label, "tls13 " in and "dtls13" in . Its byte-level separation from other uses of the same XOF, including the transcript hash, is covered in .
dec engine:
A doubly-extendable cryptographic (dec) stateful object, whose input is a sequence of strings, and whose output is a hash of that input. In the scope of this document, it is implemented as an extendable-output function evaluated over a sequence of framed input strings, with the output length bound into the sequence before any output is produced (). The construction beneath it is an XOF and takes no key parameter, its secrets being ordinary framed inputs.
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 (). A key update is a derivation of the retained traffic secret (), not a ratchet.
ratchet:
Replacing a stage's dec accumulator with a fresh one, seeded by a residue squeezed from it under "drv", then destroying the old dec accumulator (). gives the call that produces each residue.
The presentation is stateful, but the construction is not. Each Derive or DeriveN equals one invocation of a profile's XOF over its framed input sequence. The three stages of are protocol phases separated by stage boundaries, not KDF steps: shared trunks absorb each input once, the two squeezed residues connect the stages, and the one-way truncations fall at the stage boundaries where TLS must erase prior state. Their one-wayness is conditional ().
The Dec Engine Interface A dec engine accumulates a running sequence of framed inputs. The profile's DF(S, L) is the XOF over that sequence (, ). It returns L octets, and L is from 1 to 65535, since TurboSHAKE256 is defined only for a positive output length (). The schedule runs one dec engine per stage, driven by five operations.
Operations Each descriptor is framed in the listed order. Each o_i is the next L_i octets of the squeezed string. The output tuple and descriptor list use the notation of , with the optional context last. Init starts a dec engine with framing schedule_label. Every dec engine is Init'd, so every keyed sequence opens with frame(schedule_label), the label prefix of TLS 1.3 or DTLS 1.3 (). A ratchet residue or a retained secret is passed to Init as the seed and framed under the tag "seed" (, ). Absorb feeds one tagged input into the running dec engine. That is the same role HKDF-Extract's mixing step plays in TLS 1.3. "outs" is a fixed DeriveN terminal marker alongside "out_". Derive is the single-output operation. It clones the running dec accumulator, absorbs that leaf's context, then adds the leaf label. The dec accumulator being derived from fixes ctag: a live stage trunk takes "th__", whose context is a transcript checkpoint, and a dec engine seeded from a retained secret takes "ctx_", whose context is that derivation's expansion context. A Derive with no context frames neither. The context precedes the label here, the reverse of TLS 1.3's HkdfLabel order. The framing is injective either way, and placing the context first lets sibling leaves that share it branch after one absorption. The clone leaves the dec engine unchanged, so one dec accumulator yields all of a stage's leaves. Derive fills exactly HKDF-Expand-Label's role. At a stage leaf it stands in for TLS 1.3's Derive-Secret(secret, label, Messages), with the dec accumulator in place of the secret. A value keyed by a retained secret is a Derive or DeriveN over a dec engine seeded with that secret (). A Derive that omits L, including the Ratchet residue, outputs SecretLen octets. A Derive that fixes its own length passes L explicitly (the early key_block, sn_key, exporters, the ECH confirmation, MAC). When the context is omitted, L is the third argument. DeriveN also clones the dec accumulator without consuming it, and uses the same context rules. Every DeriveN label MUST be registered, and labels within a descriptor list MUST be distinct. DeriveN MUST reject k outside 2..65535, any L_i outside 1..65535, or a sum above 65535. Lengths and their sum are checked before conversion to uint16, without wraparound. The count, labels, order, and each length are absorbed before squeezing. The total is determined by the length list. Binding only that total would not bind the partition. DeriveN is restricted to the fixed derivations of this document. A caller MUST NOT omit, reorder, append, or resize descriptors according to which outputs it currently needs. Each derivation fixes the context and parent dec accumulator as well as the descriptors. Other protocols use Derive under . Ratchet crosses a stage boundary. Its residue is a Derive under the label "drv", which is this schedule's analogue of TLS 1.3's Derive-Secret(., "derived", "") between stages. The next dec engine is Init'd like any other, framing schedule_label, then seeded with that residue, so "drv" names the residue, not the new dec accumulator. The residue is internal and never leaves the schedule. Any stage input, such as the asymmetric shared secret, is a later Absorb into the new dec engine, not part of the ratchet. says which boundaries use Ratchet. The old dec engine is retired: nothing absorbs into it or derives from it afterward. This is not the in-place Ratchet() of Cyclist or STROBE (, ), which returns nothing. A Derive is one DF call over its framed path, and a ratchet residue is one such Derive. It is therefore byte-exact and testable alone.
Labels and Alignment schedule_label is 6 octets and every tag is 4 octets, so frame(schedule_label) fills 8 octets and every framed tag, together with the two-octet length of the value it names, fills 8 more. A value framed under a tag therefore starts on an 8-octet boundary whenever every value before it in the dec engine's input is a multiple of 8 octets long, which lets an implementation that absorbs 64-bit lanes take key material without realigning it. With the 64-octet secrets and transcript hashes of this document, that holds for the PSK and every seed, at offset 16, for the first asymmetric shared secret component, at offset 88, for every transcript checkpoint and MAC message that follows only such values, and for the context of the ECH confirmations, at offset 56. It does not hold after a value whose length is not a multiple of 8. A P-521 shared secret is 66 octets, so the transcript checkpoint after it starts at offset 162, and an external PSK has arbitrary length, so the context of its import derivation may be unaligned. In the exporter (), the raw label in the first Derive and the context hash in the second each start at offset 88: 8 octets for frame(schedule_label), 72 for the tagged seed, and 8 for frame("ctx_") and the context's length. Every derivation label is 3 octets, and every one is registered in the TLS XOF Key Schedule Labels registry (), which keeps labels distinct. The tags and schedule_label are fixed by this document and are not registered. In single-output Derive a label is the last item before the output length, so its length does not bear on alignment. A short label keeps the tail of a Derive at 15 octets. In DeriveN each label precedes its own output-length field. The "outs" marker and framed count occupy 10 octets, followed by k 15-octet descriptors, for a tail of 10 + 15*k octets. Labels and tags are absorbed as they are. Apart from handshake transcript hashes, the only inputs reduced by TranscriptHash before framing are the exporter context and the ImportedIdentity, whose lengths are not bounded by this document (, ). Tags shorter than four letters are padded with underscores. The tags are: Tags
Tag Names Replaces
"psk_" the PSK, in the early stage "psk"
"shs_" each asymmetric shared secret component "dh"
"seed" Init seed: residue or retained secret (untagged)
"th__" Transcript checkpoint at a stage leaf "th"
"ctx_" Retained-secret derivation context "context"
"out_" each output length "out"
"outs" DeriveN terminal marker and output count none
The TLS XOF Key Schedule Labels registry () is the canonical list of labels, and this table explains the labels of this document. Each replaces the label that TLS 1.3 gives the derivation it names, or, for "ibk", the label of , for "eca" and "hca", the label of , and for "snk", the label of . "mac" has no TLS 1.3 counterpart: Labels
Label Derives Replaces
"cet" c_e_traffic "c e traffic"
"ees" early_exporter_secret "e exp master"
"ebk" binder_key, non-imported external PSK "ext binder"
"ibk" binder_key, imported PSK "imp binder" ()
"rbk" binder_key, resumption PSK "res binder"
"drv" a ratchet residue "derived"
"cht" c_hs_traffic "c hs traffic"
"sht" s_hs_traffic "s hs traffic"
"cat" c_ap_traffic "c ap traffic"
"sat" s_ap_traffic "s ap traffic"
"exs" exporter_secret "exp master"
"rss" resumption_secret "res master"
"fin" finished_key "finished"
"mac" every MAC tag (HMAC)
"key" key_block "key" and "iv"
"upd" the next traffic secret "traffic upd"
"rsp" resumption_psk "resumption"
"ipk" ipsk "derived psk"
"exl" an exporter label secret Derive-Secret(Secret, label, "")
"exp" an exporter output "exporter"
"eca" accept_confirmation "ech accept confirmation"
"hca" hrr_accept_confirmation "hrr ech accept confirmation"
"snk" sn_key, DTLS 1.3 "sn"
Labels are distinct from one another, and every label differs from every tag in length. The DeriveN that derives c_e_traffic and early_exporter_secret has this layout. With SecretLen equal to 64:
Derivation Shapes Every derivation this document replaces is an instance of one of six shapes.
  1. Root absorb: the Early Secret extract, as Init + Absorb.
  2. Accumulate: the Handshake Secret extract IKM, per component, as Absorb.
  3. Ratchet: Derive-Secret(., "derived", "") at a boundary, as Ratchet, or with a PSK as the "drv" output derived alongside binder_key.
  4. Dec derive: traffic and exporter secrets, PSK binder keys, as Derive or DeriveN.
  5. Secret derive: record keys, exporter label secrets and outputs, key update, resumption, PSK import (), the DTLS 1.3 sequence-number key, and the ECH acceptance confirmations, as Derive or DeriveN.
  6. Keyed check: Finished and PSK binders, including an Exported Authenticator's Finished, as MAC.
Shapes 1 through 3 act on the trunk of a stage. Shapes 4 and 5 are the output operations, Derive and DeriveN, over a live trunk or over a seeded dec engine rooted at a retained secret (). Shape 6 is shape 5 under the label "mac", with the message as context (). Record keys are derived from their traffic secret by a separate call, as in TLS 1.3, so a retained traffic secret suffices to re-derive its keys. Deriving them within the call that produces the traffic 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 stage boundaries. A key-update generation is a derivation of the retained traffic secret (), not a further ratchet. Stage trunks and stage secrets bind no cipher suite value, matching the TLS 1.3 extracts they replace. No leaf derivation binds one directly either. A client offering several cipher suites under one KDF computes one schedule. Only record-key derivations depend directly on the suite, through Nk and Nn (). Every derivation frames schedule_label at Init (). The negotiated KDF is bound by the XOF, not by this label. This listing is identical for both profiles. Only each profile's DF instantiation differs (, ). With a PSK, early_residue is the "drv" output of the DeriveN on E that also derives binder_key, and both peers MUST seed the handshake dec engine with it rather than with a residue of Ratchet(E), which would differ. Without a PSK, both early DeriveN calls are omitted and H = Ratchet(E). The handshake boundary always uses Ratchet(H). The DeriveN that derives c_e_traffic and early_exporter_secret is used for 0-RTT. At the early-to-handshake boundary, E and early_residue are destroyed after H is initialized. The handshake boundary destroys H and its residue after T is initialized. A PSK-only handshake omits the Absorb into H. binder_label is selected as specified in . early_residue is retained until the early boundary. The early traffic and exporter DeriveN uses TH_CH even if only one of its outputs is needed. When the negotiated group is a hybrid or other multi-component key exchange, shared_secret denotes the ordered list of component shared secrets whose concatenation the group specification defines as its shared secret (for example, ). Both peers MUST use exactly those components in that concatenation order, absorbing each with its own Absorb(H, "shs_", component), without first concatenating them.
Absent and Empty Inputs A handshake without a PSK still executes Absorb(E, "psk_", ""). That call contributes the following bytes: This is unambiguous because a PSK of this document is never zero-length: an imported or resumption PSK is 64 octets (), and an endpoint MUST NOT use an empty raw external PSK. Without a PSK, the early stage carries no leaves and its dec accumulator holds only known constants, as TLS 1.3'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, "shs_", ...) entirely: the tag "shs_" does not appear in the sequence.
Stage Secrets The three stage dec accumulators E, H, and T are this schedule's analogue of TLS 1.3's Early, Handshake, and Main Secret. They are states, not values. A leaf clones the running dec engine rather than reading an extracted octet string, so no named early or main secret is materialized. Each stage boundary seeds the next dec engine with a residue under "drv" (), and that dec engine frames schedule_label at Init. That residue is the analogue of TLS 1.3's unnamed "derived" salt. It never leaves the schedule. It seeds the next dec engine once and is then discarded (). The values that do leave, the traffic and exporter secrets, occupy disjoint slices within a DeriveN output tuple. The DeriveN calls that derive early, handshake, and application traffic and exporter secrets each bind their ordered labels, lengths, and transcript checkpoint (). Early data is separated in addition by the 0-RTT equality check (). Every stage binds its transcript at the leaves, so the dec engines themselves bind none. The derivation graph maps onto the TLS 1.3 graph ().
The TLS13_TURBOSHAKE256 Profile The TLS13_TURBOSHAKE256 profile instantiates the dec engine-based key schedule of with TurboSHAKE256 , built on the 12-round Keccak-p[1600,12] permutation of . The profile parameters are:
SecretLen:
64 octets, the length of every stage and traffic secret.
FLen:
64 octets.
Instantiation The dec engine is implemented using TurboSHAKE256 as XOF: 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 is fixed to 0x1F, the default of , for every use of TurboSHAKE256 in this profile, so an API without the D parameter implements the profile unchanged. 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 Finished and binder MAC lengths are set to match it.
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.
The TLS13_SHAKE256 Profile The TLS13_SHAKE256 profile instantiates the dec engine-based key 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(schedule_label) at Init (), not from cSHAKE's function-name and customization-string inputs. The two profiles' dec engines therefore differ only in the underlying permutation, so derivation () and the MAC construction () are shared by both profiles. The profile parameters, SecretLen and FLen, are 64 octets as in .
Instantiation The dec engine is implemented using SHAKE256 as XOF: 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. This profile's domain separation comes from seq(S) beginning with frame(schedule_label), as describes (). 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 the same 136-octet rate and 512-bit capacity as TurboSHAKE256 (). The capacity is what the erasure argument of relies on, and the 64-octet secret, transcript-hash, and Finished and binder MAC lengths match it in both profiles.
Required API Surface The required API surface is that of : no absorb-after-squeeze occurs, so no access below the SHAKE256 interface is required.
PSK Importer TLS 1.3 permits external PSKs , and imports an external PSK into a target KDF, producing a PSK bound to its target. This document updates the importer computation in for the KDFs defined here. It replaces HKDF-Extract and HKDF-Expand-Label using the EPSK-associated hash, or its SHA-256 default, with the target KDF's "ipk" derivation and TranscriptHash (). uses the target KDF only for output length and identity separation. This document also uses it to select the importer computation, avoiding a SHA-2 dependency. A provisioning importer taught only the new TLS KDF Identifier and output length still applies the EPSK-associated-hash rule of . It produces a different ipsk for the same ImportedIdentity than the importer specified here. A peer using this document's computation discovers the mismatch at binder verification. A KDF of this document is a TLS KDF Identifier (), so an external PSK imported for use with one is imported under the unchanged ImportedIdentity of , with target_kdf naming the KDF. No variant structure is needed, and none is defined. For a DTLS 1.3 target, the "ipk" derivation frames "dtls13" as its schedule label, since uses the label prefix of the target protocol. binds an imported PSK to a KDF and not to a cipher suite, deliberately, so that a PSK cannot be reused across key schedules. Negotiating the schedule in its own extension makes that KDF a value the protocol negotiates, so the binding applies as intends. The import derivation is the generic derivation of , keyed by epsk under target_kdf. An endpoint MUST NOT import an epsk, or use a raw external PSK, longer than 0xFFFF octets, so every framed value fits a single frame. A client that imports one external PSK for use under more than one KDF MUST produce a separate ImportedIdentity, and hence a separate ipsk, per target_kdf, exactly as requires. Import is RECOMMENDED. As in , it is not required. A raw external PSK is associated with its KDF when it is established. One established without a KDF is associated with SHA-256, as specifies for an external PSK without a hash, and so with the TLS 1.3 schedule rather than a KDF of this document. A raw external PSK carries no binding to the KDF it is used under, and its length is whatever provisioning chose, so a length that is not a multiple of 8 leaves the items after it unaligned () and may cost one further permutation. An imported PSK is SecretLen octets and raises neither question. For imports into these KDFs, target-KDF selection also supersedes the single-associated-hash restriction in . The separate ImportedIdentity values bind each ipsk to one target KDF, preventing reuse of one imported PSK across TLS schedules. They do not isolate the underlying epsk from the different importer KDFs: importing the same epsk for both profiles feeds that secret to both permutations ().
Zero-RTT and Early Data Early data remains PSK-only and remains replayable under the TLS 1.3 anti-replay model. This document changes neither. A client MAY send early data using the first offered PSK's associated parameters () only if they permit early data and the associated cipher suite is among those it offers. A server MUST reject early data unless the offered PSK's associated parameters permit early data, the selected cipher suite equals the offered PSK's associated cipher suite, the selected ALPN equals the PSK's associated ALPN, and all TLS 1.3 anti-replay checks pass. The suite-equality check, not the binder, prevents redirecting early data to a different AEAD.
Authentication Certificate-based authentication is negotiated as in TLS 1.3, and what a CertificateVerify signs follows from the transcript hash. The content covered by the signature is Transcript-Hash(Handshake Context, Certificate) (), and under a KDF of this document that is the 64-octet TranscriptHash of . The 64 octets of 0x20, the context string, and the separator octet are unchanged, so a server signs: The signature scheme then processes that content as its own definition requires, and that processing is outside the key schedule. The ECDSA and RSASSA-PSS schemes of TLS 1.3 hash it with SHA-2, and Ed25519 uses SHA-512 internally, whatever KDF is negotiated. A certificate chain carries the same dependence through the signature schemes of its certificates, which the signature_algorithms_cert extension negotiates (). A deployment that must avoid SHA-2 entirely MUST restrict the signature_algorithms and signature_algorithms_cert extensions to signature schemes that use no SHA-2, such as Ed448 () or ML-DSA (, ), or use PSK-only authentication.
Alerts This section lists the alerts an implementation of this document sends, in addition to those already defined by TLS 1.3:
  • illegal_parameter: a ServerHello or HelloRetryRequest that selects a KDF missing from the client's schedule_profile list, a ServerHello whose schedule_profile differs from the HelloRetryRequest's when the client sent one, or a selected PSK whose KDF, for an imported PSK its target_kdf, is incompatible with the selected KDF.
  • unsupported_extension: a schedule_profile extension in a ServerHello or HelloRetryRequest when the ClientHello did not carry one, as in TLS 1.3.
  • decrypt_error: a handshake or post-handshake Finished, or a PSK binder MAC, that fails verification, as in TLS 1.3.
  • handshake_failure: the server's first message omits schedule_profile when local policy requires a KDF of this document ().
Companion Mechanisms Several deployed mechanisms invoke HKDF-Expand-Label or HMAC directly. This document defines the Encrypted Client Hello confirmation for its KDFs (), because ECH is pervasive in the deployments most likely to exercise these schedules, defines DTLS 1.3 (), and updates Exported Authenticators, which use the exporter and the cipher suite's hash (). A protocol built on TLS 1.3 that derives keys from a secret of this key schedule with HKDF-Expand-Label(Secret, Label, Context, Length) instead uses the Derive of on a connection that negotiates a KDF of this document: Derive(Init(Secret), label, Context, Length), with the context omitted when it is empty. Such a protocol MUST use the single-output form. The sequence-number key of DTLS 1.3 () is an instance of this rule. That protocol's specification assigns the label and registers it in the TLS XOF Key Schedule Labels registry (), whose registration rules keep every label 3 octets long () and distinct from every other label. Until its specification registers its labels, such a protocol has no defined derivation under this key schedule. Any other mechanism that derives keys with HKDF-Expand-Label or HMAC, including one that derives them before any KDF is negotiated, is not covered by this document and needs its own specification. Until a specification defines a mechanism's derivations for a KDF of this document, an endpoint that negotiates that KDF MUST NOT use the mechanism on that connection. QUIC has no such specification yet: its "quic key", "quic iv", "quic hp", and "quic ku" labels are not registered (), and its Initial secrets are derived before any KDF is negotiated. An endpoint MUST NOT negotiate a KDF of this document in QUIC until one exists.
DTLS 1.3 DTLS 1.3 uses the key schedule of TLS 1.3 with two changes, and a KDF of this document applies both. This document updates for a connection that negotiates a KDF of this document. A connection that negotiates no KDF uses unchanged. First, replaces the "tls13 " label prefix with "dtls13" to separate DTLS 1.3 keys from TLS 1.3 keys. schedule_label is that prefix (), so a DTLS 1.3 connection frames "dtls13" at every Init: Every DTLS 1.3 derivation therefore has a different input from the TLS 1.3 derivation over the same values. The transcript hash is unchanged: its "tls13 hash" prefix separates it from keyed sequences () and is not a label prefix, and DTLS 1.3 computes the transcript over the messages that specifies. Second, derives a key for record sequence number encryption from each traffic secret. It is a derivation of that secret, alongside the record keys of : Nk is the AEAD key length, the key_length of . For DTLS 1.3, a sender MUST remain able to send in the original epoch while handshake retransmission and acknowledgement obligations require it, including until the final flight is acknowledged ( and ), and MUST continue advancing that epoch's send record sequence number without resetting it. It can keep the epoch's record key, IV, and sn_key, or re-derive them from a retained traffic secret: key_block is deterministic, so both give the same keys. Because key_block is deterministic, re-deriving it and resetting the sequence number repeats the record key and nonce. With AES-GCM, nonce reuse across different records permits recovery of the GHASH authentication subkey and record forgery through Joux's forbidden attack , demonstrated against TLS by .
Exported Authenticators Exported Authenticators let either peer authenticate after the handshake. computes each authenticator from two exporter values and an "authenticator hash", which it defines as the hash associated with the cipher suite (Section 5.1 of ). Under a KDF of this document the cipher suite's hash governs nothing (), so this document updates for a connection that negotiates a KDF of this document. A connection that negotiates no KDF uses unchanged. The authenticator hash is the KDF's TranscriptHash (), and its output length is 64 octets. The Handshake Context and the Finished MAC Key of Section 5.1 of are values of the TLS-Exporter of , keyed by exporter_secret, with the labels registers, an empty context, and a length of 64 octets. For an authenticator sent by the server: A client uses the "EXPORTER-client" labels in the same way. The CertificateVerify of Section 5.2.2 of signs the octet 0x20 repeated 64 times, the context string "Exported Authenticator", a zero octet, and: The Finished of Section 5.2.3 of is the MAC of in place of HMAC, with FLen, which is 64: The Finished of an empty authenticator (Section 6 of ) is the same computation with no CertificateVerify, over a Certificate message that carries the certificate_request_context of the authenticator request and no CertificateEntries. That Certificate message is serialized and hashed like any other but is not sent, and it is not a zero-length string. As in , an absent authenticator request contributes no octets. Every other rule of applies unchanged, including the use of exporter_secret and not early_exporter_secret, the uniqueness of certificate_request_context, and the requirement that a server verify the client Finished before sending or processing an authenticator. The signature scheme keeps its own hash, as describes. On a DTLS 1.3 connection, exporter_secret, the exporter outputs, and the Finished MAC all use schedule_label "dtls13" (). An implementation of Exported Authenticators outside the TLS library () MUST obtain the connection's negotiated KDF identifier, or an indication that no KDF was negotiated, and whether the connection uses TLS or DTLS. The KDF selection determines the authenticator hash and MAC, their output lengths, and the exporter output lengths. The protocol determines the MAC's schedule_label. An API providing only TLS-Exporter(label, context, length) is insufficient because it does not convey that selection. Updating the TLS library alone can therefore leave an application producing incompatible authenticators.
IANA Considerations This document requests no cipher suite code points. It uses those of TLS 1.3 ().
The schedule_profile Extension IANA is requested to register one entry in the TLS ExtensionType Values registry per the procedures of . Requested TLS ExtensionType Registration
Value Extension Name TLS 1.3 DTLS-Only Recommended Reference
TBD schedule_profile CH, SH, HRR N N This document
It is permitted in the ClientHello, the ServerHello, and the HelloRetryRequest. DTLS-Only is N because schedule_profile applies to TLS 1.3 and DTLS 1.3 alike (). Recommended is N pending working group consensus.
TLS KDF Identifiers IANA is requested to register two entries in the TLS KDF Identifiers registry created by , per its Specification Required policy. KDF identifiers need no new registry: that registry already names a key schedule independently of a cipher suite, which is what this document negotiates. Requested TLS KDF Identifier Registrations
Value Description Reference
TBD TLS13_TURBOSHAKE256 This document
TBD TLS13_SHAKE256 This document
A KDF registered here defines every key-schedule computation it governs: its transcript hash, its secret and key derivations, its Finished and PSK binder MACs, and its Encrypted Client Hello acceptance computations (). A registration that leaves any of those to the cipher suite has to say so: a KDF silent on a computation is under-specified, not inheriting.
TLS XOF Key Schedule Labels IANA is requested to create a registry named "TLS XOF Key Schedule Labels" in the "Transport Layer Security (TLS) Parameters" registry group. Each entry names one output of Derive or one descriptor of DeriveN (). A DeriveN call has no registered label of its own. Its outputs each carry their registered label. A label is exactly 3 octets of ASCII (), and no two entries have the same label. The 4-octet tags and schedule_label of this document are not labels and are not registered. In particular, "outs" is a fixed terminal marker, not a registry entry. The registration policy is Specification Required (). The designated expert approves a request only if the label is exactly 3 ASCII octets, no entry already has it, and the specification states the secret the label derives from, the encoding of its context, the output length, and what the output is used for, and rejects any other request. A registration specifies one output. The initial "key" registration specifies key_block for both Derive and DeriveN. A registered label is never reused or redefined. Each registration names its change controller, a person or organization. The change controller of the initial entries is the IETF. Each entry has a Label, a Use, a Change Controller, and a Reference. The initial contents are the labels of , all with the IETF as change controller: Initial Contents of the TLS XOF Key Schedule Labels Registry
Label Use Reference
"cet" c_e_traffic This document
"ees" early_exporter_secret This document
"ebk" binder_key, non-imported external PSK This document
"ibk" binder_key, imported PSK This document
"rbk" binder_key, resumption PSK This document
"drv" a ratchet residue This document
"cht" c_hs_traffic This document
"sht" s_hs_traffic This document
"cat" c_ap_traffic This document
"sat" s_ap_traffic This document
"exs" exporter_secret This document
"rss" resumption_secret This document
"fin" finished_key This document
"mac" every MAC tag This document
"key" key_block This document
"upd" the next traffic secret This document
"rsp" resumption_psk This document
"ipk" ipsk This document
"exl" an exporter label secret This document
"exp" an exporter output This document
"eca" accept_confirmation This document
"hca" hrr_accept_confirmation This document
"snk" sn_key, DTLS 1.3 This document
Update to RFC 9258 anticipates this document: "Future specifications that change the way the KDF is negotiated will need to update this specification to make clear how target KDFs are determined for the import process." This document changes how the KDF is negotiated, and determines target KDFs as follows. The target_kdf of an ImportedIdentity is the TLS KDF Identifier the importing client will negotiate in the schedule_profile extension (). For a connection that negotiates no KDF, the target_kdf is HKDF_SHA256 or HKDF_SHA384 as the target cipher suite's hash determines, exactly as before this document. For the KDFs defined here, also replaces the importer computation and EPSK-associated-hash rule of . The schedule_profile extension carries the negotiated TLS KDF Identifier value on the wire, and the transcript hash covers it (), so no final message-level trace for a KDF of this document can exist before its value is assigned. Schedule-level vectors do not wait on that assignment, since no derivation of absorbs a code point: a transcript checkpoint enters as an argument, and one stated as a literal value pins the output with no code point anywhere in the input. The exceptions are ipsk (), whose context is TranscriptHash of an ImportedIdentity that carries target_kdf, and values derived from ipsk, including the imported-PSK binder. carries no message-level trace yet.
Security Considerations
KDF Separation TLS13_TURBOSHAKE256 and TLS13_SHAKE256 frame the same schedule_label, so their inputs can coincide. They run different permutations, the 12-round Keccak-p[1600,12] and the 24-round Keccak-f[1600], though the first is the last 12 rounds of the second (, Sections 3.3 and 3.4). Most secret inputs are bound to a single KDF (). For those secrets, coincident framed inputs do not by themselves expose either secret if both XOFs jointly behave as independent random oracles and each secret is unpredictable to the adversary (). An external PSK used under both profiles is the exception. For an imported PSK, requires a separate ipsk per target_kdf, but the epsk beneath them is one secret, absorbed under both permutations. Raw external PSK reuse also shares a secret between profiles. A deployment that negotiates TLS13_SHAKE256 for its larger round margin () does not gain that separation for such a PSK. A deployment that provisions a separate external PSK per KDF, rather than using one under both, has no secret in common between them.
Downgrade Resistance The selected cipher suite appears in the ServerHello and therefore in the transcript from TH_SH onward, which every handshake and application output binds (). A peer that assumed a different suite would hold a different transcript, and its Finished MAC would fail. Stripping the extension in flight makes the ClientHello transcripts differ and the Finished MACs fail. A server can decline the extension by omitting it from its first message (). The client decides whether to accept that capability mismatch. A deployment that offers both KDFs accepts whichever the server echoes.
PSK Entropy An attacker who can guess an external PSK can recompute its binder offline. External PSKs SHOULD be drawn with at least 256 bits of min-entropy, the target security level of both profiles.
Authentication A fully SHA-2-free connection also needs SHA-2-free authentication, which specifies. The exporter labels that Exported Authenticators use are registered, not reserved, so an application with access to the exporter can obtain the Finished MAC Key ().
Hybrid Key Exchange One uncompromised component keeps the derivation unpredictable even if another is adversarial. Each component is absorbed as its own framed input (, ), and under the flat sponge claim () an output is unpredictable if any input before it is. Every leaf that depends on the shared secret binds a transcript checkpoint (TH_SH, TH_SF, or TH_CF) covering all key shares and any KEM ciphertexts, the binding that , Section 3.2, adds to a dual PRF of the component secrets. The uncompromised component's secrecy rests on its own key-exchange assumption, and the chaining analysis remains open ().
Cryptographic Analysis The per-derivation bound ultimately comes from the security claim on Keccak (, Section 1.5) and on TurboSHAKE (, Section 2), as discussed in . Protocol security also depends on erasure and authentication, with proof obligations still open ().
Threat Model and Goals The adversary is that of : an active network adversary that controls message delivery, can supply dishonest PSKs and key shares, and can obtain output keys. analyzes the secrecy of the key schedule's output keys, not authentication. Authentication of peer identity remains outside the cipher suite, as in TLS 1.3. 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 compromise of a handshake traffic secret to application traffic once the asymmetric shared secret is used, and the TLS 1.3 0-RTT replay model when early data is accepted.
Primitive Assumptions DF is the profile's XOF over a framed byte string. The XOF is claimed secure under a flat sponge claim with the claimed capacity equal to the capacity of the underlying sponge function (, Section 1.5, and , Section 2), that is, c=512 in the scope of this document. Informally, it means that SHAKE256 and TurboSHAKE256 are claimed to offer the same security strength as a random oracle (RO) in all cases where the RO offers a strength below 256 bits and a strength of 256 bits otherwise. Security strength is meant in the sense of , which covers decision games such as PRF distinguishing as well as search games. As for any concrete hash function or XOF, the claim excludes weaknesses due to the mere fact that the function can be described compactly and can be efficiently executed, e.g., the so-called random oracle implementation impossibility , as well as properties that cannot be modeled as a single-stage game . The claim is supported by the results of third-party cryptanalysis, of which a list of publications is available at . These results target reduced-round versions of Keccak, and at the time of this writing, no such result contradicts the above claim at the nominal number of rounds of (Turbo)SHAKE256. The claim is further supported by the proof of indifferentiability of the sponge construction that SHAKE256 and TurboSHAKE256 use. Informally, this proof ensures the absence of generic attacks on a sponge function (i.e., attacks that work irrespective of the underlying permutation) below a complexity of 2^(c/2) , except for attacks whose complexity is already below 2^(c/2) on a RO. In the sequel, we assume that the profile's XOF, and therefore the dec engine, is as secure as claimed and discussed above, and therefore reason on the usage of the XOF as that of a RO.
Primitive Usage Every Derive or DeriveN is a single call DF(S, L) where seq(S) is injectively framed (), so calls with different inputs query the oracle at different points, and the outputs of one DeriveN are disjoint slices of one answer. In the random-oracle game, an adversary that never queries a string carrying the secret cannot distinguish those outputs from independent uniform strings. For a secret with h bits of min-entropy conditioned on the adversary's view, the chance of such a query is at most q / 2^h in q queries. For an external PSK with 256 bits of min-entropy (), that is q / 2^256. These are bounds in that game, subject to the flat sponge claim (), not bounds for the complete protocol. If the DeriveN answer is uniform, revealing some slices leaves the others uniform and independent, provided the adversary has not queried the secret-bearing input and has learned neither the full output tuple, nor a secret the tuple was derived from, nor another name for a target slice. Finished and binder verification require MAC to be unforgeable under a chosen-message attack. Each MAC key is a 64-octet finished_key used for MAC and nothing else (). The same key may be used over several messages, as for a binder recomputed after a HelloRetryRequest or for post-handshake Finished messages within one traffic generation. For Exported Authenticators, the MAC key is the 64-octet Finished MAC Key, also used for MAC and nothing else. The same key can serve successive Exported Authenticators on one connection (). MAC is a Derive (), so the preceding random-oracle argument applies. In that game, a uniform secret unknown to the adversary keys a pseudorandom function of the rest of the framed input. With an L-octet output, each verification attempt adds at most 2^(-8L) to the forgery probability, in addition to the probability of querying the secret. The uniformity of finished_key to an adversary depends on that of the secrets beneath it. A finished_key derived from a guessable external PSK is not uniform to the adversary (). If the ECH confirmation Derive output () is pseudorandom, a network attacker without ClientHelloInner.random guesses the 8 octets with probability at most 2^-64 per attempt, plus its advantage in distinguishing the output from random.
Derivation Graph The stage trunks E, H, and T and the ratchet residues map to TLS 1.3's Early/Handshake/Main Secrets and its unnamed "derived" salt as sets out. DeriveN also combines sibling sites into one query. The map is onto rather than one to one: this document derives key_block once and slices the record key and IV from it, where TLS 1.3 derives each at its own site. It is structural and does not carry the TLS 1.3 proof.
What Is Not Yet Established This schedule does not yet have an analysis equivalent to . is proved over discrete extract-and-expand nodes, not over an accumulator carried across each stage and cloned at its leaves. The cross-stage chaining needs analysis, in particular absorbing the asymmetric shared secret into a dec engine seeded with the early residue, the step TLS 1.3 performs as an HKDF-Extract salted with the early secret's "derived" value. The flat sponge claim does not cover the key exchange itself. Under active substitution of key shares, a Diffie-Hellman group needs an oracle form of the computational Diffie-Hellman assumption, and a KEM an active-attack assumption such as IND-CCA ( covers hybrid groups). The reasoning in Section 6.4 of can be followed to cover derivations keyed by an independent PSK the adversary cannot predict, directly or through residues chained from it, but not the absorption of the shared secret or what depends on it alone. Whether the ECH confirmation replacement () keeps every property analyzes is not established here.
Erasure Boundaries A sponge function is built on a permutation, and permutations are invertible. If the intervening absorbed blocks are known, anyone holding a later state can recover the earlier one. Carrying a raw accumulator across a stage boundary would therefore let a post-handshake state compromise re-derive handshake traffic secrets when those intervening blocks are known. A Ratchet breaks the chain because its squeeze returns a function of the state, not the state itself. In the random-oracle game (), recovering it requires a query on the secret-bearing input. A boundary mixing an asymmetric shared_secret relies instead on the exchange's computational hardness and the open chaining analysis (), not on information-theoretic entropy given the public key shares. The early-to-handshake boundary carries only the PSK, so its one-wayness depends on the PSK's min-entropy (): a low-entropy external PSK earns no forward secrecy there from that boundary alone. A PSK-only handshake absorbs no asymmetric shared secret at all (), so every boundary has the same PSK-entropy limitation. The one-wayness argument is conditional on erasing the old trunk. The squeeze does not erase it. A ratchet's forward secrecy is only as good as the erasure behind it, and erasure is local: no peer observes it, and no interoperability test detects its absence. The erasure rules below are therefore expectations, not interoperability requirements, and an implementation SHOULD follow them as its platform allows. An accumulator of a stage should not outlive that stage's ratchet, should not be retained as a successor across a ratchet, and should not be serialized, exported, or compared. Handshake-stage traffic secrets and record keys should be destroyed when their TLS 1.3 analogues would be, and each stage secret once the next stage has absorbed it. For DTLS, destruction of epoch material is subject to the retention requirements in . Every cloned accumulator is a 200-octet copy of secret state, and a clone exists for the span of a Derive or DeriveN. Keeping that window short, and zeroizing each clone when it is dropped, limits what a compromise recovers. A buffer holding the complete output tuple of a DeriveN that derives record keys exposes both its record material and its finished_key or successor secret. Redundant buffers holding DeriveN output tuples should be erased after their slices have been distributed. Unused successor secrets should be erased when the connection closes, subject to the DTLS retention rules above. Compromise of a live accumulator yields that stage's underived leaves, as compromise of a stage secret does in TLS 1.3. With the preceding state and other absorbed blocks known, invertibility can also expose an absorbed asymmetric shared secret. On platforms that cannot guarantee erasure these erasure rules are best effort ().
Domain Separation Distinct derivation paths yield distinct byte strings as dec engine inputs. A framed sequence decodes to exactly one list of items: frame(x) is uint16(len(x)) || x with no padding (). Every dec engine opens with frame(schedule_label), then its rooting item (, ): the PSK for the early stage, the early residue for the handshake stage, the handshake residue for the application stage, and the retained secret for a derivation (). The PSK is framed under the tag "psk_" and every residue or retained secret under "seed", so the early trunk differs from every other dec accumulator in its first tag. Dec accumulators that open with the same tag are told apart by their seed value, not their structure. A path over a live stage trunk and a path over a dec engine seeded with a retained secret draw from disjoint label vocabularies (, ). Within either, every item before the terminal label or the "outs" marker is a framed tag drawn from this document's fixed vocabulary followed by its framed value, in an order the schedule fixes, so two paths of the same kind and the same length that agree tag for tag can differ only in a value. Two paths that differ at all therefore differ at some item, so their framed sequences differ. The "outs" marker cannot be a prefix tag or a three-octet Derive label, so it separates DeriveN from both a Derive and an unfinished prefix. Its framed descriptor count fixes how many labels and lengths follow, and those ordered lengths fix the DeriveN output partition. Unkeyed transcript hashing is separated at the byte level: The first octet separates a keyed sequence from the transcript hash.
Per-Profile Considerations
TLS13_TURBOSHAKE256 TLS13_TURBOSHAKE256 targets 256-bit security, which , Table 4 claims for TurboSHAKE256 and its 512-bit capacity (, Section 2.2) supports.
TLS13_SHAKE256 TLS13_SHAKE256 uses SHAKE256's Keccak-f[1600] in place of TurboSHAKE256's Keccak-p[1600,12] (). Its full 24-round permutation supports the same 256-bit target with a larger round margin ().
References Normative References The Transport Layer Security (TLS) Protocol Version 1.3 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 obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. IANA Registry Updates for TLS and DTLS This document updates the changes to the TLS and DTLS IANA registries made in RFC 8447. It adds a new value, "D" for discouraged, to the "Recommended" column of the selected TLS registries and adds a "Comment" column to all active registries that do not already have a "Comment" column. Finally, it updates the registration request instructions. This document updates RFC 8447. Importing External Pre-Shared Keys (PSKs) for TLS 1.3 This document describes an interface for importing external Pre-Shared Keys (PSKs) into TLS 1.3. Exported Authenticators in TLS 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. TLS Encrypted Client Hello This document describes a mechanism in Transport Layer Security (TLS) for encrypting a message under a server public key. KangarooTwelve and TurboSHAKE 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. The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 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. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions National Institute of Standards and Technology Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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. Informative References Edwards-Curve Digital Signature Algorithm (EdDSA) This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. Using TLS to Secure QUIC This document describes how Transport Layer Security (TLS) is used to secure QUIC. Use of ML-DSA in TLS 1.3 DigiCert Google Cloudflare This memo specifies how the post-quantum signature scheme ML-DSA (FIPS 204) is used for authentication in TLS 1.3. Module-Lattice-Based Digital Signature Standard National Institute of Standards and Technology Authentication Failures in NIST version of GCM Nonce-Disrespecting Adversaries: Practical Forgery Attacks on GCM in TLS Hybrid Key Exchange in TLS 1.3 Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if a way is found to defeat the encryption for all but one of the component algorithms. It is motivated by the transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. The Keccak reference TurboSHAKE Third-Party Cryptanalysis On the Indifferentiability of the Sponge Construction Shaking up authenticated encryption On the Bit Security of Cryptographic Primitives n.d. Xoodyak, a Lightweight Cryptographic Scheme The STROBE Protocol Framework Key-Schedule Security for the TLS 1.3 Standard Indifferentiability, Impossibility Results on Reductions, and Applications to the Random Oracle Methodology Careful with Composition: Limitations of the Indifferentiability Framework Hybrid Key Encapsulation Mechanisms and Authenticated Key Exchange
Comparison with TLS 1.3 This appendix is non-normative. It compares the TLS 1.3 schedule with the dec engine-based key schedule of . Both profiles share this schedule and differ only in the underlying permutation, so the comparison applies equally to TLS13_TURBOSHAKE256 and TLS13_SHAKE256, and the figure labels the dec engine side generically.
TLS 1.3 with Imported PSKs and the Dec Engine-Based Key Schedule RFC 9846 and RFC 9258 This document, the dec engine-based key schedule HKDF-Extract(0, PSK) E = Init() Absorb(E "psk_", PSK) Early Secret E accumulator Derive-Secret(., Lbl, TH) DeriveN(E, [cet, ees], "c e traffic" TH_CH TH_CH) = c_e_traffic c_e_traffic "e exp master" TH_CH early_exporter_secret = early_exporter_secret binder_label = "imp binder" (no context) "ebk" "ibk" or "rbk" = binder_key DeriveN(E, [binder_label, "drv"]) binder_key Derive-Secret(., "derived") early_residue HKDF-Extract(derived, H = Init early_residue) asymmetric shared secret) Absorb(H "shs_", shared_secret) Handshake Secret H accumulator Derive-Secret(., Lbl, TH) DeriveN(H, [cht, sht], "c hs traffic" TH_SH TH_SH) = c_hs_traffic c_hs_traffic "s hs traffic" TH_SH s_hs_traffic = s_hs_traffic Derive-Secret(., "derived") Ratchet(H) emits residue HKDF-Extract(derived, 0) T = Init residue) Main Secret T accumulator Derive-Secret(., Lbl, TH) DeriveN(T, [cat, sat, exs], "c ap traffic" TH_SF TH_SF) = c_ap_traffic c_ap_traffic "s ap traffic" TH_SF s_ap_traffic = s_ap_traffic exporter_secret "exp master" TH_SF = exporter_secret Derive(T, "rss", TH_CF) "res master" TH_CF resumption_secret = resumption_secret "c e traffic" TH_CH | TH_CH) | = c_e_traffic +-> c_e_traffic +-> "e exp master" TH_CH +-> early_exporter_secret | = early_exporter_secret | binder_label = +-> "imp binder" (no context) | "ebk", "ibk" or "rbk" | = binder_key | DeriveN(E, | | [binder_label, "drv"]) | +-> binder_key | Derive-Secret(., "derived") +-> early_residue v v HKDF-Extract(derived, H = Init(early_residue) asymmetric shared secret) Absorb(H, "shs_", shared_secret) | | v v +-----------------+ +=================+ | Handshake Secret| | H accumulator | +-----------------+ +=================+ | Derive-Secret(., Lbl, TH) | DeriveN(H, [cht, sht], +-> "c hs traffic" TH_SH | TH_SH) | = c_hs_traffic +-> c_hs_traffic +-> "s hs traffic" TH_SH +-> s_hs_traffic | = s_hs_traffic | | Derive-Secret(., "derived") | Ratchet(H) emits residue v v HKDF-Extract(derived, 0) T = Init(residue) | | v v +-----------------+ +=================+ | Main Secret | | T accumulator | +-----------------+ +=================+ | Derive-Secret(., Lbl, TH) | DeriveN(T, [cat, sat, exs], +-> "c ap traffic" TH_SF | TH_SF) | = c_ap_traffic +-> c_ap_traffic +-> "s ap traffic" TH_SF +-> s_ap_traffic | = s_ap_traffic +-> exporter_secret +-> "exp master" TH_SF | | = exporter_secret | Derive(T, "rss", TH_CF) +-> "res master" TH_CF +-> resumption_secret | = resumption_secret | ]]>
The imported-PSK binder branch uses the label from . Both schedules derive finished_key from binder_key or from a traffic secret by the corresponding label, "finished" on the left and "fin" on the right, feeding the same MAC step: HMAC on the left, MAC on the right. The Finished and binder MACs, record keys, exporters, resumption PSK, key updates, and PSK import each replace their TLS 1.3 counterparts, and gives the per-shape rules.
Invocation Count The handshake counted is one full 1-RTT handshake that offers and selects a PSK, uses the asymmetric shared secret, and accepts 0-RTT early data: the case both and cover completely. Derivations after the handshake, for a NewSessionTicket, a KeyUpdate, or a TLS-Exporter request, are not counted. Counts are per endpoint. A dec engine invocation is one Derive, DeriveN, MAC, or Ratchet call, each of which makes one DF call (). A TLS 1.3 invocation is one HKDF-Extract, HKDF-Expand-Label, or HMAC call. Absorb builds an input sequence rather than invoking the primitive and is not separately counted, matching how already accounts for dec engine operations. Transcript-hash computations are excluded from both columns: both schedules compute the same checkpoints over the same messages. Invocation Count for One Full Handshake
Derived value This document TLS 1.3
Early Secret analogue 0 1 (HKDF-Extract)
binder_key 1 (DeriveN) 1 (Derive-Secret)
finished_key (binder) 1 (Derive) 1 (Expand-Label)
PSK binder verify_data 1 (MAC) 1 (HMAC)
client_early_traffic_secret 1 (DeriveN) 1 (Derive-Secret)
early_exporter_secret 0 (shared) 1 (Derive-Secret)
early traffic key + iv 1 (Derive) 2 (Expand-Label)
"derived" salt (to Handshake Secret) 0 (shared) 1 (Derive-Secret)
Handshake Secret (absorbed, not ratcheted) 0 1 (HKDF-Extract)
client_handshake_traffic_secret 1 (DeriveN) 1 (Derive-Secret)
server_handshake_traffic_secret 0 (shared) 1 (Derive-Secret)
client hs traffic key + iv 1 (DeriveN) 2 (Expand-Label)
server hs traffic key + iv 1 (DeriveN) 2 (Expand-Label)
finished_key (server Finished) 0 (shared) 1 (Expand-Label)
server Finished verify_data 1 (MAC) 1 (HMAC)
finished_key (client Finished) 0 (shared) 1 (Expand-Label)
client Finished verify_data 1 (MAC) 1 (HMAC)
"derived" salt (to Main Secret) 1 (Ratchet) 1 (Derive-Secret)
Main Secret analogue 0 1 (HKDF-Extract)
client_application_traffic_secret_0 1 (DeriveN) 1 (Derive-Secret)
server_application_traffic_secret_0 0 (shared) 1 (Derive-Secret)
exporter_secret 0 (shared) 1 (Derive-Secret)
resumption_secret 1 (Derive) 1 (Derive-Secret)
client ap traffic key + iv (gen 0) 1 (DeriveN) 2 (Expand-Label)
server ap traffic key + iv (gen 0) 1 (DeriveN) 2 (Expand-Label)
Total 15 30
A value marked "0 (shared)" is an output of a DeriveN counted on another row: the "derived" salt with binder_key, early_exporter_secret with client_early_traffic_secret, server_handshake_traffic_secret and server_application_traffic_secret_0 with their client counterparts, exporter_secret with client_application_traffic_secret_0, and each finished_key with its sender's handshake traffic key + iv.
Permutation Count gives the per-operation counting rule. Over the handshake of , counted by that rule and excluding the transcript hash as that table does, with a 64-octet PSK, a 32-octet shared secret, and a 64-octet transcript hash: Permutation Calls for One Full Handshake
Schedule Permutation calls
Either profile of this document 23
HKDF-SHA3-256 over the same permutation 120
Permutation-Counting Method This appendix is non-normative. For an input of n octets producing L octets, a sponge over the profile's permutation applies floor(n / 136) + 1 permutations while absorbing, since the padding rule always appends at least one octet, and ceil(L / 136) - 1 more while squeezing, since the first output block is read from the state the absorption left. For DeriveN, L is the sum of all descriptor lengths. The 192-octet output tuple of the DeriveN that derives c_ap_traffic, s_ap_traffic, and exporter_secret therefore needs one extra squeeze block. A DeriveN call absorbs its checkpoint once for all its slices. The siblings that shared a context in the single-output baseline are now slices of that one call. Summing the standalone cost floor(n / 136) + 1 + ceil(L / 136) - 1 for each of the 15 calls gives 23 permutations. Sharing absorption between calls does not change this total for the stated workload. Each HKDF-Extract, and each HKDF-Expand-Label of at most 32 octets, is one HMAC-SHA3-256, and one HMAC-SHA3-256 is four permutation calls: two for the inner hash of (K XOR ipad) || m and two for the outer hash of (K XOR opad) || digest, each filling one 136-octet block and padding into a second.
Implementation Considerations This appendix is non-normative. Both profiles need the same three capabilities of an XOF: incremental absorption, cloning of a state that has not produced output, and a squeeze of a length known before the squeeze begins. Each profile's concrete parameters are in and . Each handshake and application leaf absorbs its transcript checkpoint, TH_SH, TH_SF, or TH_CF, as its context (), the same point at which the corresponding TLS 1.3 Derive-Secret call consumes Messages. A stack ported from TLS 1.3 therefore need not compute any transcript checkpoint it does not already compute. A client that offers PSKs associated with different KDFs computes each binder under its own PSK's KDF, and therefore maintains transcript-hash state per KDF for the partial ClientHello transcript. TranscriptHash is itself defined by the KDF (, ), so the checkpoints of differ per offered KDF. A client offering more than one either buffers the handshake messages until the KDF is known or carries checkpoint state per offered KDF, discarding the state of those not selected once the KDF is pinned, at the ServerHello or at a HelloRetryRequest. This is the one place where offering more than one KDF costs an implementation more than a single schedule: the schedule binds no cipher suite (), so it is shared across every suite offered. The suite-dependent lengths are described in and . A binder finished_key uses standalone Derive under binder_key. A handshake finished_key is the "fin" output of the DeriveN over its traffic secret that also derives the record keys. Post-handshake authentication uses standalone Derive under the current application secret (). Sharing the label "fin" does not make these derivations interchangeable. An implementation that feeds a binder's MAC key from the Finished path's base secret produces a wrong binder that no Finished-path test vector detects. A DeriveN implementation knows the whole descriptor list before it squeezes. It can distribute slices directly to their consumers or use a temporary combined buffer. It should erase temporary state and retain only required outputs (). Requesting one slice does not change the DeriveN call. 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. The erasure rules of are written to be met on such platforms by ceasing use, dropping references, and zeroizing the buffers the implementation controls, as implementations already do for TLS 1.3 key material.
Test Vectors This appendix is non-normative. The vectors below are tentative. They were produced by a reference implementation and reproduced byte for byte by a second implementation written from this document alone, in another language and sharing no code with the first, but written by the same author. They are therefore not yet the independent evidence this appendix calls for, and they may change. Each profile's permutation is pinned against published vectors, TurboSHAKE256 against those of and SHAKE256 against those of . What rests on a single reading of this document is the schedule itself: the framing, the field order, and the context tags. That is the part most likely to move. The initial secrets and main-handshake checkpoints below are TranscriptHash of short ASCII strings, so the inputs are reproducible from this document and the same values serve as TranscriptHash vectors: The PSK-only and hybrid fixtures use the existing PSK and transcript checkpoints. The PSK-only fixture omits Absorb(H, "shs_", ...) entirely (). The hybrid fixture absorbs hybrid_1 and hybrid_2 in that order, with a separate Absorb(H, "shs_", component) call for each and no concatenation (). The server Finished uses TH_PRE_SF, the checkpoint immediately before that message. TH_SF includes the server Finished and remains the checkpoint for application traffic and exporter secrets. A client Finished would use TH_SF if no handshake messages, including client authentication messages, intervene. These checkpoints are synthetic inputs, not hashes of encoded handshake messages. The main fixture takes its early residue from the DeriveN that derives binder_key and early_residue with "rbk". The imported-PSK variant uses ipsk with "ibk" instead of "rbk". The no-PSK variant explicitly absorbs an empty "psk_" value and uses the standalone early ratchet. Both variants use the stated shared_secret and TH_SH. The terminal DeriveN calls for application record keys derive generation-1 record keys and generation-2 successor secrets in both directions. ClientHelloInner.random is the 32 octets 0x00 through 0x1f, and the ECH confirmations take TranscriptHash("ech_conf_messages") and TranscriptHash("hrr_ech_conf_messages") as their transcript hashes. Record keys use Nk = 16 and Nn = 12. The exporters use label "test label" and context "test context" with a 32-octet output. The two resumption values use ticket_nonce "nonce" and an empty ticket_nonce, which is omitted rather than framed (). The ImportedIdentity has external_identity "external psk identity", an empty context, and target_protocol 0x0304. The imported-PSK binder uses this ipsk in a fresh early trunk and TH_CH0 as its transcript hash (). The non-imported external-PSK binder uses the same PSK input and TH_CH0 as the resumption binder. The DTLS 1.3 values run the schedule over the same inputs with schedule_label "dtls13" (), with key_block and sn_key derived from the DTLS 1.3 c_ap_traffic, the client's application traffic secret, and a second sn_key from the DTLS 1.3 c_hs_traffic, the client's handshake traffic secret. The Exported Authenticator values are for a server authenticator with no authenticator request, keyed by exporter_secret (). Certificate and CertificateVerify are encoded TLS 1.3 handshake messages, including their type and length fields, as in Sections 4.5.1 and 4.5.2 of . The Certificate contains one CertificateEntry, no extensions, and the one-octet certificate_request_context 0xa5, fixed for this test. Its cert_data is the following 204-octet DER-encoded X.509v3 certificate. This self-signed Ed25519 test certificate has serial number 1, issuer and subject CN=test, validity from 2026-01-01 00:00:00 UTC through 2036-01-01 00:00:00 UTC, and no extensions. Its key is derived from the 32-octet Ed25519 seed 0x00 through 0x1f. The Certificate handshake header is 0x0b0000d6 (type 11, body length 214). The body is 0x01a5 (context length and value), 0x0000d1 (certificate_list length 209), 0x0000cc (cert_data length 204), the DER certificate above, and 0x0000 (empty extensions). The CertificateVerify handshake header is 0x0f000044 (type 15, body length 68). The body is 0x0807 (ed25519), 0x0040 (signature length 64), and 64 zero octets. The signature is a fixed test value, not a real signature over the content. These vectors test transcript hashing and the Finished MAC, without signature verification. The empty authenticator answers an authenticator request, for which the ASCII string "CertificateRequest" stands in. Its Certificate is the serialized message 0x0b00000400000000, which has an empty certificate_request_context and no CertificateEntries. The ImportedIdentity target_kdf carries a placeholder TLS KDF Identifier, 0x0100 for TLS13_TURBOSHAKE256 and 0x0101 for TLS13_SHAKE256. These are a convention of this appendix and not a request: asks for two registrations without naming values, and the registry assigns that range under Specification Required, so other values may be assigned. If they are, the ImportedIdentity, ipsk, and all imported-PSK variant vectors must be regenerated, including the binder and its handshake descendants. Every other value here is independent of the assignment, because no other derivation absorbs a code point. The key_block and app_traffic_secret_1 values are derived from c_ap_traffic.
TLS13_SHAKE256 Vectors H: 6b32f0c73d44d7d492b910a671fe6d8691164b2601892465af9c723805fb32ea 42326f24d3328fb711e1d44b0ea76184ebbc6ee187b1ca37a3f2cf250c437989 c_hs_traffic: 1b84f2043d2862e73daa0b092b426108946a37a320b94407262a8dc49fba4d51 d8553fe70d1a8d11c04fdaf7f6563312c7518a9aeabd5803a516d44ed4e0b439 s_hs_traffic: 79136406c4c81ff9f326012423654339d1e329919eee0b2555d6d8d8e2e6fc59 c72e0e2705f5401c567b9b9d1e1442753323672b124782cb8c747f355594f603 # Finished finished_key (server): 3701a80e1536d52edd7e2f1b6512f450f1065ffbe61747e7f14988b5f7b369e5 8310f2e559028e6f7c13cf4272a82c8ef8a33d25b6ce7ff32062810e9e3c46ab server verify_data: f99e0156d29ae9c59b0e7553014f7f17eba02a685fbe0b90acc42f7434a24f9e ce877dfe474b4eaf0afb96780316c94ab69bddb35c51c98b40cb95e73f17e40f finished_key (client): c1afbaa28a325027ca1e60192e194b818b68ffb51ba5b29871885a1cb84b1407 3a502bfb9735c2a1282fc7a2094c1a2453fb4355c181293d7a89f3ff3c4e9765 client verify_data: 76d9a4b58ace12e571e805367ee2df47bbac03d5dc17c9adcf5a3de9599e3b42 0524ff30edacd23a98c81758026ccdb16cc737844e8a5d89bcc5e08a97fd2965 key_block (client handshake): 7af7a8d0692a9cc398bf4ebbbd4059cdd985b8aef11bddafcd3a8d6f key_block (server handshake): 5cfaa0ba711a870ef23193ce8e735f046817c2aabf24673475d70be5 # Application stage residue H->T: df1644c0baa429a0851d3b3a1002e2d0fdf61eac4fa7da79bcc8614bdad347e9 82528f51c45ef8130e3753f90bfda0f88ee723924dd4d91f81c4126fa771b576 c_ap_traffic: 01aaa618c31d0164f8785b473e27ecd85550ffff63550b3f9203d1d908c6bb93 7a8709df8d8d69f33dcf68c60fab229f88e355de969eecb0b20a3dff846385c6 s_ap_traffic: 9a195274550c282e81761569c26a84e3f4db62c91fb0ab0a34ddd40a1acc6809 e94c63b9c39e776fa3cddb2be83bcab178ee35ac98f1f3eddcc482bdcafa9f68 exporter_secret: c1135ab09706a0dade74ef934327b3fb069885bfef68e8555db2b4d0278f6bab 976806184b0bfb65780627d1940bf55debfc197aa0ffd49776db68ec12db03e2 resumption_secret: 0a337ebc797c9fb54fc48da7edd32035ed0683a844d525b22c6bf52f955361db ed1452e598ef156c69969d661928b2a57c81ade66ff81e4647f1fb041c43babd # Record keys (Nk=16, Nn=12 of TLS_AES_128_GCM) key_block: af284e77b262205cf68cb562d7e613964d739145e704423d266f844b write_key = key_block[0..16]: af284e77b262205cf68cb562d7e61396 write_iv = key_block[16..28]: 4d739145e704423d266f844b key_block (server application): a3bdb1e1f6255f97e3f4abca9e3dd862843a47fd0000b8939795f379 key_block (early): 83df62fddb19c2da815fb6389383981864b01b336eb813f203475eb2 # Key update app_traffic_secret_1: 30cd327927225c9209b9ceec0867533c60fb939d8846a730478649e006145f8a 151d0f56eed36adfb91fde2b05cf9ea6131e19749c012f8edb47ce0b578be416 server_app_traffic_secret_1: 5dd3472248e3fd59cd8dda98408298d0900a36d0ea7c753805a242fb29d0e20e defc10a052c08618bfd40778c592d02312e6e8859b4ddd24b8c442fea7c0b0f2 key_block (client generation 1): 983db28b5aa22a1074ef711a834110bd3e845e7cb85df6de45093d7b key_block (server generation 1): 4a38b47dff8df581e123d703c6152869dd2b560ebf25c3cc04f06480 app_traffic_secret_2 (lookahead): e61255bacf37d58ef6bd16ca20b1b4285e87ebb9db05caf6fe18505ffd1bf0df 39784fdb86061ec7c417148102f1ffda969637f145ff2b18ff6e20c2d95499b9 server_app_traffic_secret_2 (lookahead): 267074740cebea789b9626bbcb88e4724b3310097c17989776991cfb9f10f3b6 f920e2eb581cb593db73e6ad5adbcd2901fd5a09ef9678ccf44781ae0164f571 # Resumption resumption_psk (nonce): a8314d04b7ea05199c1b3e10be9745b4ef0c898f34e6e48f9e2f73b0a5102bc1 cbabec5f56e5ce5cebc6589e43078ca54f0b866d5707e7fc58a9e8c30ece4879 resumption_psk (empty nonce): 383f67f84fe056c6aa98a36d5b7a53b98aca3072dade8fc0a9abcf94e8f8327f 1b6c1c71d3a8c84078575aa141285d350dd8f7e24b4c664ced929c642a42e223 # Exporters exporter_label_secret: d4b6b6351c8c08da5843bfb0e39c4ad2b2686ff71d8baa1f05c0e9d3fa06825c bab3553a3e9d0dd7a71d3c712678b6f6f06d57e37180217d97e26bc7943072a5 TLS-Exporter (32 octets): a9c3287164d223f7b88d8ddd805a7159f082146cbe44ed5987bd5195f6d34293 early_exporter_label_secret: cc8b50a689ea0e42f9e580877c58701c9ba03b98ad5e783c8bf4b3d84ecaf175 84eb76cd06f61cfc66ea7f669ee60b337da2c6b1cb4e555851887f501c00b9d2 early exporter (32 octets): 213a0a9a2b99554845a69ef666fd1a9d2fc640819360af5a3958d82f1df79d00 # PSK import ImportedIdentity: 001565787465726e616c2070736b206964656e74697479000003040101 ipsk (ipk): 1f45ffacb3bc31fed8850c58d208fbcfdd629f3ba590470356ab1b66424d6a1f ef9b93de18f8370e2aee51f844a6b85e8098dd8e3901a608d507b621977c8bce # ECH acceptance confirmations accept_confirmation: 46be340e18673ab0 hrr_accept_confirmation: 1ee441e50a2762ff # DTLS 1.3 (schedule_label "dtls13") Init() sequence (DTLS): 000664746c733133 c_hs_traffic (DTLS): 67ec6f7b6ead9facec3cc6f725ffd842cc449fbba84e752feb4fe5242a01591f aa802334a55812b79b3bdacb75a3aa8fe0fb5fbb58711fede6016e7381035c5c c_ap_traffic (DTLS): 33923ae8813f7fabb036a622d488aa4b6dffd26afbef5206464e1c577a166dd1 9056e51421d31623d949538b43f080fc26db58a4ef309596008337570bf151dc key_block (DTLS): bfeab2ebc4c7d25640ee30c2f3533a2caa071d9bfcccf1d862b5773e sn_key (DTLS, Nk=16): 67e097f7f15bf54d258ab56858cc95c2 sn_key (DTLS handshake, Nk=16): 1bc25bc88914df62c8c6c408bb5153fd # Imported PSK and no-PSK variants binder_key (ibk): 71e13244e744b4e6fea0ee0b7b323902168003e196d035ce6c9299f9dc71f76d 2e5706669142bed4700ff6821aa15640953134a748330afc47bc8bf9705c0bd7 finished_key (imported binder): a0796566140c251127544577a86c5c3916cfe8c9c52fdf491fded1def4aff1ba a5e17be48aa15c9a38a195d32716ed46c0ce3589384b172efc8c93639c70ce8d imported binder verify_data: dcf45c9beab3109b508175a3f3283cbdc8db07ca97281ec229fe67f5548ee420 3fda35f2351d07f1549df090310dad3f695458ed8293ab01d89254ad4cfab79d residue E->H (imported): 36312564653b7069d044bd369e57fcbbb43d8365948e2c84d6d43ffbca1a9534 da2e31c2edd3469ee75bb2a4ffa455002b40852591ae525aa27d5cde1599e5d6 c_hs_traffic (imported): 606000650e26a0677b2ebf236141fe472dac8ce068a299520609e2b9e4830220 e2b385f3346e7db2805f67fef8d11597397865c7d9eb3f80e3f3eed102c9ea62 s_hs_traffic (imported): ab690d18a3f3fda4996a7a809f0e2a74e67cc38aa06bc8d44d42fa890d4ecf98 7389b356ebd9d606627c30084473df5fb48ee6ab1896e0e5c31ec0c5572281d9 residue E->H (no PSK): 081006a681fb6f81f4d6a66119c4a35da517947f4f891ce5a1b6860bc2b25302 a36bf712d7d7c8248545031317c357a641808e167a564f952e575c9a66182825 c_hs_traffic (no PSK): abfee325aeeb9985442c8f07518f218fb57ac2af41bdc0df02b8aeb0dec4d291 aee4811722316b82eb6913264c757a99c6ac575920c8638ce21ff6b1dd718dc8 s_hs_traffic (no PSK): 96fbeada518e1cd9dadf1f0b6fdea84dd4df2a99b6c8167952e84815be10aa5d 570081f4c4adadf3ba7e014f997f58d2626c5a45afaf760735d7d10b37221a64 # Exported Authenticator (server) Handshake Context: 80be9be97b021ccc0a00c5366accb32361ea17e48cecf5aaa5a82ba73d82cec7 2702d2172ea935e9304f3da4895cbb878682e37ae6c2ce2928a42c4f9e60e929 Finished MAC Key: fb90d121b4d2a177cc1053627bbec1b3c9d3ebe0874875c61c0f253ae48fde72 10ea516288b471ed1dc7007dd8171b14c65ecb74c2abccd76c0d449c8c9fd091 TranscriptHash(HC || Certificate): 6182ee1d992d1704b2033739897c45e746811e1520648201673fc41029c29afa 43fd1b15f8b920f12bfdb752be15a472464f4abb7d2a54ab6b2d294f310eed21 Finished: bd4141d5f17bc78eae42c0f553f03f82573b2b2888a10671ec37fecd694b0d19 ff28730053eb3f81c0494c5b762b4e1d11a0cdbaa7283e138f02c3f2f282f4ec Finished (empty authenticator): 8231776dd1d3767cdaa519e76dbc05a02edd5195ab6864d65bd7d04c0bfd03b9 389a8d057bf625a987fdf98496e45546adde59f950494964521ee5604e005416 # PSK-only c_hs_traffic (PSK-only): 8002d2845fb5f1b98da952a729e2d1a455802417e6b8b49385c418cd148fb127 fd4dd559b94e308586b0090bb74c2b9163e36f740a1cf53383c6949c91724950 s_hs_traffic (PSK-only): 577e01db7d08e1d8356df00beb13f51795864eb02e213c9a58acab3a3bb65923 59df8a8cd0b3cff1e8c140943f4106db60547853d79791a57a348f3f088e4e56 c_ap_traffic (PSK-only): 35af7a37f2f35c50428c35486dd8776c1fcb0cb834f77ce8e690b5250754380f aa40ac0e491b2741ffa2b4b7c2fd132a0a2ea56b1b48bda90b9eb4aa2ed813cc # hybrid c_hs_traffic (hybrid): 4e725e4687624689defb14a5786f2fc4e76309c28adaa7a5fc266cb1064ab53d 207c7610d43912147b58e619427870be0c5610f42bdd6b1416fa291a330f76af s_hs_traffic (hybrid): ecd094adf9c38c21fca2ede44fd1abf9f0a806dcf556373d54a58ace6cde91c8 4ac56e31fa9a2fd1ab1c9f9195935a58134d127d60a0127222f6a439a865b6e7 c_ap_traffic (hybrid): 9eb5243783dfd08e82d91a5aca6c843a8c6467d852d269d668cbf9fc774438fd 08560544ba42f5d8935fb0cacb450a189d62f556a0cf25c7752082c56a745171 ]]>
TLS13_TURBOSHAKE256 Vectors H: 9dcb74748e2d2add94f628334609ede4b72456f307c467fc95982b3ae40e0c75 98791aebbbfc201bcecec42aa3104f3b056a4232398762f2573e6c426c55b4ac c_hs_traffic: a3cd51eca90acd358ce5c89b141d7a3cf223b3a7c1c22a4c01447cf7e54a8303 d4b7449b32a8cd4dbbc5ea810276cb9b37ec5bdb770d53ab3b5914acebefffbb s_hs_traffic: 6e6d3aa60a3a60f76629454ce0686e598464cd18546967be63deb596ff7b05e1 066810b3974005dec4706059343a81ffb857b96dbf607b15cf040bbe151eef6a # Finished finished_key (server): 67c359746c92ffbc9c50dbc378d327043ccbb3533e907240363ea1b1da194869 1a7cdc349aefbd979b27cd5e480ee9ee8ee4b212c01b3d498e0e85c555c5ed8c server verify_data: c4a8aefb9923b0265236ea84d234a32d74a9b244792318813348013674a17b5c 6055ebaf0282b256515d3e6c9cba7d390450ca0a5e7c953beec52f375062a118 finished_key (client): de3edba0f9072a335b728f2d3ad31181a6af1897ca312b96cb86de3b526c6fd8 cdc26f763dac1948e4cc4a6549e5f612fa9d80f34e39cedc6466952ebf80537a client verify_data: c8639abe8ea57b02757dec5f9898405c77657e8bd60c51348390bd936dcd92fe b84fe668b960dacc6bee0f54d4f4740422adb58747fc8445d5c1972926b3cb63 key_block (client handshake): 440142237f0440352077f641b2290685dd6f7871280773778196f6c0 key_block (server handshake): cd0eb74edcda968b6306f98eb189b43be1cab80f2972ead6ce5f5f15 # Application stage residue H->T: 85e84f6637e7596a53ed5a568e7b80d7aee0cf492b6956ba6959f40c9c3233fe 60a07eb7b086ce9e434f7de42904970064e9bb416566a8aec69a061e73c6c911 c_ap_traffic: 55c60b08ed2b8794ff3d45275f44bbc88a544f87b42c0a0839858425e237c5ec 09aa6033ffc31cc0f1672f2a67d2af8c3b8cb7996db1b13396a25f9ffe37ef5d s_ap_traffic: a0451a0f19cca5e1c13d56f95f9ddaa79d441725480066a438d22b98c0be09f7 7ef2639c50411db6d2b28f82672cdb08504ce5414f69f429449bae945b99e6d2 exporter_secret: 1e35b04f25411608bdf946e2649c2053d47fb17a13106eca78c9530d46eb44af 76d8118635dfb37de887fcbf60e31701651c50c5ce60a3147237a8f416476257 resumption_secret: 53a62b364bc1aab4eaf6cfcd1a99582f6129fcd6580869d9305d7da8618992ac 0edf033b7673251faa2fc213e537a2bbce7a93d2ff640a755567706723b905a6 # Record keys (Nk=16, Nn=12 of TLS_AES_128_GCM) key_block: 9158e02be6c399686cd31c41f54237999b301e140f9f71ef33984c4b write_key = key_block[0..16]: 9158e02be6c399686cd31c41f5423799 write_iv = key_block[16..28]: 9b301e140f9f71ef33984c4b key_block (server application): 936aeccc9b02ba973890bfeeec76362eeb62c1a2390974b78aa45d65 key_block (early): cd68a026565195a8e4d1467e9de8c0c80328519726a894eee68be9c4 # Key update app_traffic_secret_1: a7cd0868300a81ed1fd5019e528141076919ce80a83a60bb5bcf542f81bcd556 792b5e2703973c062bcf54ccd741f362ad71c8824787c69a59e0ae961c90e35e server_app_traffic_secret_1: c73d637f58c533ef64c743893cb74350ce8bf75d5a9d1ed2fa423bc6c4ce1325 fd6de6abe648b67a677a060534acf83fed321f63c8f9d2e2054755f0a4d9c5fb key_block (client generation 1): 8a9c5ef1a703528feff038ff5545595cb58cb0e639cc117913d42098 key_block (server generation 1): 34c2b340cecb28153bfe5f103a7ac8fef96a1ce27391d8abc6459bea app_traffic_secret_2 (lookahead): 7e60c0b6b70a64a9e48ea36525e4e9c9a9037b68001153830506839f31360399 b70d9d9c200108fda9e46c5e869aeebe697c295bf69df55cdba27ae82e6bdf58 server_app_traffic_secret_2 (lookahead): c6f3313c9fc672342ba9064afcb9d8d5ce8566a18e50c40a4cd23cc31ff11d45 80fbc78e712e8b13ceee303e37ad269fd6d7285e0ae6aa6fbf7b77b36733318a # Resumption resumption_psk (nonce): 6bfbcb1afaf52218f8c2c31dd1432db7178706aec94ecf1b4c07387458540ad3 bfddb1f4e42ef9c175602b2b457bae1917e80a570adb5a3424209faec2076925 resumption_psk (empty nonce): c62fa4bffe9ed5312c5b045c8a8207908a2ca2616e5165c45012c0777adf0e43 a0ddcee0f85cbb1d6679d7b067287a1551e9b83e5e7491d612172c1338cb0b01 # Exporters exporter_label_secret: a6aefd256a6bc0fd6adbff6c882f20aa5a84e2be73e50ff3f340149ee5a89bb5 f9c104a1319076860dcb193d51098d670f606e92c61a299b1b81089cba3105ef TLS-Exporter (32 octets): ed7f44dde38ef5fe6441560aed075c78dfe079a2a37a2af988f35a2ef2f0da2d early_exporter_label_secret: 1c3807bfd182fbc9d63f2e9d272c1c06b5ed593c4d5cc43befdad754e6d7c528 814e81c1a41be9a0b1c1d527ed29681792c7b4cb750430b2b0592ee76f1abddc early exporter (32 octets): 844ea5d8b5ff06f5ec6c0b916019b73c2cc25aa50e78c31cb7764519510f6490 # PSK import ImportedIdentity: 001565787465726e616c2070736b206964656e74697479000003040100 ipsk (ipk): b12977fe51dd07a1d5787324344d1fdbf03fabd8826b57e8362f9860e84e640c 1ec7a6632c56efde9ea0bb3edb21ff295b2c36c5b3bca39ef8bba2f79e835f9b # ECH acceptance confirmations accept_confirmation: 7deaf576fa50bd88 hrr_accept_confirmation: 1e89c54e87b6e455 # DTLS 1.3 (schedule_label "dtls13") Init() sequence (DTLS): 000664746c733133 c_hs_traffic (DTLS): bd6426ef1c4e54ec625fc59969f2ac06db9ea7c36f091de25d5012e0dd38d45b 373e9fd919481b8ffbd333d8c77ef4a0bf0a40981b9dc95366220dfb93f1645e c_ap_traffic (DTLS): 4fb948e90a343f759a1e893a534155633c8666b130d96b237e8cd80efcc0c816 6a3d379907bfe42c071ec4c8e49fb6ba86179dcc40dbc63f3eca73dfab8fb31d key_block (DTLS): 75fa564e876c51e0f3aec77159214f0faec0c037f59fe6037ce7c0bb sn_key (DTLS, Nk=16): e4135eeb2cdd0b73970c1a79849edaa4 sn_key (DTLS handshake, Nk=16): bb3b0c471ff1ddea6a1ca69a23de079d # Imported PSK and no-PSK variants binder_key (ibk): 92570469969ad61ec22b2a62aae01df6eabb07f0e556d43bd4812e34f786bc41 59b588ef4691884fe8d63ede4fb9c8c952a4f794e1303d4fea4249c700596061 finished_key (imported binder): 6c7db3750c45bbe6506affed036fea7eddafdc518e2b70231731e5d0c9032715 f5bfe055741fe52ce09bed53b289bce05702c7bc0b9a2a3a442c28573bd0131d imported binder verify_data: 64e3b275a7b6f6dba8b483e2de61cdec1709be224f37c8a25c4c7662e25f03d1 f8c0244b2743964f8146f7b4a22eab02dc823e857b09d6a2874f5ae03f3d52da residue E->H (imported): aa3abc64254b1650e596151908ea6b1e7ea2fc518dd4e8eb530bf6782322aa99 bb24098beadc6045831cf3d066db829c054759df974cc2f7d6f505facd3b35bb c_hs_traffic (imported): 3c98591564cb98403fa7e38f694c11839dc18de9af9eb4cc32f175c6bebe49b3 bedd96c651df4d674d22b24bfb2d3f15fad1749ab91db8c4241cccfb85ec3d4a s_hs_traffic (imported): 495bce3f95a7dbfa7e646b6db86addaf584922b04a8c6a20c41b2e48cdab6d38 d43988b37c1ac5b987ba4d1132519f0f848ad9c1d4ffde91f85f9cb98f491d48 residue E->H (no PSK): 62500b3c6c707bd445ba0adc12449e0086e9d7799fc764a13cfd3dd3db7df80c 024deb68a0e0e6926e6d51c7b3234366d9c26177d5f7298231c5f95d4afd4440 c_hs_traffic (no PSK): 472395008a3a31e4eb836d3541b22eea0003404eab0056f079a5af015f4b9900 582760af25e58f08210062351172c699be0d7fe0bd2554a00e862eb59e3edde2 s_hs_traffic (no PSK): d4cbd66dbd06bacab3494016c8eb891517697544b28cd977e72e1a413f7c69d5 579e68fc50b4b7d3291968d8a6ee3d63e3e70572ddb2c817b3db0fd4f2b1f44f # Exported Authenticator (server) Handshake Context: 13ab9c49bb0b75a2a6167a43a657f3a4234737a2439d7104ed6f3e72238eb5f1 c72158e09f39572eed012a66c2dc02043f4c9288b331c03e67d6feabcea532e3 Finished MAC Key: 245afc62d375b22b3deadf2f5b86be79595c6d44135282b404082706fddd65d9 0012464d6c3af59f986a33ef7dc5339952bcc68926d32558206b2aa59dc815ed TranscriptHash(HC || Certificate): 52f53215b9f68fba72af257f69aa55eb4aa8699d56dbd55c673e60fbd178535d 1f0f9a4d7cc01e096fa447df98299bf029ee9ea576b54fbfed659537cdf4e292 Finished: 56e620a597c178eab75173d200b29132f14d8c759f8c9c997b9fd9a9a8aefc8f a24eb6214ad70bc59745262605678634b8a53024037ee3b2a2e491729685ef1b Finished (empty authenticator): f01277743d459bb4dc67e59bcd5a0a35a410413e6773fc4b6e3eae79fce0a3ae 3bf075c3b39b8ac961c8b07820bed2bd76b213e8cfaca644a480d08f5902c141 # PSK-only c_hs_traffic (PSK-only): 6580a4de683ec8c089dac82552e74aa074d89ba694108a6fb2d8bcde0a8f1bb5 042080fd9295ba0e6f0e5840c76f391441b09fdc446fc4ece571b95737ea0144 s_hs_traffic (PSK-only): bcc778a1f97fb32f4c0668ce707bad0eaa989a81ad502dc75095c2364db5ce19 2aab04dc21ec3948d3c76bc9357fe1e17b03ee6db2b6421bbbde1da812ae7760 c_ap_traffic (PSK-only): 77463327a3609cfe97ee9c7523c8b071341450fba775a70a7b40bc1a947f064d add30d198dd1d8bd7f53d29a3b5bd994d44bd065b51e728dcf1a7be5acd66c7d # hybrid c_hs_traffic (hybrid): 2b199e54700a4992cc8df58b138564777fa58cfdb09a3cf6f474f78e81ac90e3 65a64b68ed75e9818dfe48b43b7b76a0b2ee7e2a596b6027ef960dddddcc63b8 s_hs_traffic (hybrid): ac1e433ba3fd73cb6054ddb95bc43e68a6f98346f5ed157033a38dfa07530c9f 7f5163876821a5d73599f13ea12a74a1c53bb3800f845b7eae61eed000d7f237 c_ap_traffic (hybrid): 2c3d56389ed9582a11b61d36ffeee3f78feb25fcd576fa66166314bb465534d4 e0beb9c1685e60cab2084b7db9ab0f77d30ec48a8aa8d6efa90af6250157a2b8 ]]>