[TLS] Re: New Version Notification for draft-sullivan-tls-xo f-ciphers-00.txt

Ilari Liusvaara <[email protected]> Mon, 20 Jul 2026 19:05:03 +0300
Newsgroups gmane.ietf.tls
Message-ID <[email protected]>
On Mon, Jul 06, 2026 at 07:23:41PM -0400, Nick Sullivan wrote:
> 
> I'm sharing a draft for the group's consideration.
> draft-sullivan-tls-xof-ciphers-00 runs the entire TLS 1.3 key schedule
> on a single Keccak permutation, instead of HKDF built on HMAC built on
> the cipher suite's hash, which today is always SHA-2. This is newly
> practical because deployments using SHA-3, ML-KEM, or ML-DSA already
> carry a Keccak permutation, so the primitive is already in the stack.
> 
> Each derived value comes out in one pass, so a full handshake costs
> about a third of the permutation calls an HKDF schedule over the same
> permutation would spend.
>
> https://datatracker.ietf.org/doc/draft-sullivan-tls-xof-ciphers/
> 
> This is a big change to the key schedule, and the draft is very
> preliminary. Feedback on the approach, or interest in implementing it,
> would help a lot.

I took a new look. There seems to be a lot of extraneous stuff.

- Extraneous labels.

  An example of 3 labels when only one would do:

  c_e_traffic  = Squeeze(Absorb(Fork(E, "c e traffic", suite),
                              "th", TH_CH), "out", SecretLen)

  There is at least one another triplicate label, and number of
  duplicate ones.

- Ciphersuite seems to get re-injected a lot, should only be
  injected once.

- Both c_e_traffic and e_exp_master have TH_CH, whereas rest of the
  handshake pre-injects transcript hashes to state instead.

- Exporters and resumption PSK fork the state without using the
  original.

- Ratchet() is not useful: The only place that needs it (key update)
  does not use it.

  There is no long-term hash state, and early/rest can be handled by
  cloning the state, so nothing needs ratchet.

- Binders/Finished probably do not need two layers of hashing. Might
  have been needed with SHA-2, but Keccak is far stronger.

- There also looks to be a lot more text than what is needed.


Other stuff:

- The two-layer exporter construct from TLS 1.3 can not be replaced by
  single-layer one without changing semantics.

- The labels from TLS 1.3 lack the implicit prefix.

- The split shared secret is going to be very nasty surprise for
  implementations. Many implementations have no idea if group is
  hybrid or not.

- Also, using postfix syntax would probably look cleaner than prefix
  syntax.




-Ilari

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]