Well, both this draft and the hybrid one are a little vague on this point. " [NIST-SP-800-227] includes guidelines and requirements for implementations on using KEMs securely. Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers. "
That wording is a bit strange. "encouraged"? Then, in the NIST document: "Side-channel protection. Cryptographic modules for KEMs should be designed with appropriate countermeasures against side-channel attacks. This includes protecting against timing attacks with constant-time implementations and protecting memory from leakage. Universal guidelines are unlikely to be helpful as exposure to side-channel attacks varies significantly with the desired application, and countermeasures are often costly." So, it's all a bit handwavy, but the problem is not unique to this draft. thanks, Rob On Sat, Jul 4, 2026 at 9:29 AM Henrick Hellström <[email protected]> wrote: > Hi Bas, > > That is my point. > > There are some known security issues with some ML-KEM implementations, > but no known security issues with ML-KEM that are of immediate relevance > to the way it is used in TLS. I honestly don't understand the opposition > to this draft. I can understand why it is marked as N (not recommended) > in the IANA registry, but not why there can't be an informational RFC > that specifies the way it is supposed to be implemented, if or when it > is supported by a conformant interoperable TLS implementation. > > On 2026-07-04 17:47, Bas Westerbaan wrote: > > 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] > > <mailto:[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] <mailto:[email protected]> > > To unsubscribe send an email to [email protected] <mailto:tls- > > [email protected]> > > > > _______________________________________________ > 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]
