Hi Henrick, Would you mind explaining how an attacker would use a timing side-channel attack against ephemeral use of ML-KEM in TLS?
Best, Bas On Sat, Jul 4, 2026 at 4:53 PM Henrick Hellström <[email protected]> wrote: > I have followed the discussion on this topic and support publication of > this document as a RFC. > > Short motivation: Recognizing the there might be a high risk of > implementation bugs or timing issues with new implementations, is a > terrible reason to delay the publication of an informational > documentation of a mechanism that is given status N (not recommended) in > the IANA registry. > > Henrick Wibell Hellström > StreamSec > > On 2026-06-24 17:00, Joseph Salowey via Datatracker wrote: > > This message initiates a new Working Group Last Call for > draft-ietf-tls-mlkem[1], which defines standalone ML-KEM key establishment > for TLS 1.3. The main question before the working group is: "Should the > working group publish a document specifying stand alone ML-KEM?". If there > is rough consensus then we will push to refine and publish the document; > otherwise, we will stop discussing the draft and not progress it. Please > respond to this call indicating whether you support publishing a document > specifying a stand alone ML-KEM. Please refrain from further discussion on > this topic as most arguments have been discussed multiple times. > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
