Summary

  • The 27 October revision of an individual TLS Internet-Draft would negotiate a SHAKE256 or TurboSHAKE256 key schedule beside an unchanged TLS 1.3 cipher suite. Its July version left Exported Authenticators and DTLS outside the proposal; the new version specifies both.
  • For an Exported Authenticator implemented outside the TLS library, the proposal requires the negotiated KDF identifier, or the fact that no new KDF was chosen, plus whether the connection uses TLS or DTLS. An exporter-only interface lacks those facts.

Imagine an inventory screen that reads TLS_AES_128_GCM_SHA256 and files the connection under SHA-256. That suite still names a hash. Under revision 01 of the XOF key-schedule draft, however, a separate schedule_profile extension can select SHAKE256 or TurboSHAKE256 to run the entire key schedule and transcript hash. The suite chooses an AEAD; its hash no longer runs the schedule when one of those KDFs is negotiated. The name tag and the engine can disagree without either side changing its label.

The revision, dated 27 October, makes that split matter beyond the handshake. Revision 00 explicitly left DTLS 1.3 and Exported Authenticators out of scope. Revision 01 proposes updates to four RFCs, including RFC 9261, which lets either peer authenticate after the handshake. The Datatracker still lists an individual draft at I-D Exists; this is a proposed interface, not a change already made to TLS deployments.

RFC 9261 builds its authenticator with exporter values, a hash associated with the cipher suite and a Finished computation. Section 14.2 of the new draft changes those calculations on a connection that selected the XOF schedule. The authenticator hash becomes the KDF's 64-octet TranscriptHash; exporter output and the Finished MAC follow that KDF. When the extension is absent, the ordinary TLS 1.3 schedule and the existing authenticator rules remain in force.

Now put the authenticator in application code outside the TLS library. The new text says that code must receive the negotiated KDF identifier, or a clear indication that no alternative KDF was selected. It must also learn whether the connection is TLS or DTLS, because the latter uses a distinct schedule label. The existing TLS-Exporter(label, context, length) interface supplies neither choice. A library vendor can implement the new handshake while the application beside it still calculates a post-handshake proof under the old assumptions. The draft itself calls that outcome an incompatible authenticator.

The same boundary limits a sweeping product claim. Switching the key schedule away from SHA-2 does not switch the certificate signature scheme with it. ECDSA, RSASSA-PSS and Ed25519 can still bring SHA-2 through authentication or the certificate chain; Section 12 tells deployments seeking an entirely SHA-2-free connection to select matching signatures and chains or PSK-only authentication. RFC 9258 supplies the separate KDF identifiers used for PSK import. The revised draft binds PSKs and session tickets to their KDF, so the choice follows a resumed connection as well as a fresh one.

The reviewed record contains no independent cross-library interoperability result for this new handoff. A successful post-handshake authenticator test with the selected XOF KDF, including a DTLS case, would answer the open implementation question.