Given how i am only
a) a beneficiary of TLS (thanks for all the privacy fish so far)
b) A non-cryptography-expert reader of draft-ietf-tls-mlkem-05
c) A spectator usually attending this type of TLS debates with popcorn
I hope my comments are useful, and although i definitely will not call myself
a TLS WG participant, i do not think it would make sense for me to raise the
points
later in IETF last call than now during WG work phase (more work for IESG).
I will constrain myself to two asks for textual improvements that i would like
to see.
Especially because without such textual improvements i wouldn't even
be able to come up with a good laymens opinion whether or not, or rather when
and where to apply this drafts technology (as opposed to the alternative).
1. I think this document needs a BIG BOLD FACE introductory warning. something
like
THIS RFC DOES NOT SPECIFY AN IETF STANDARDS TRACK METHOD. IT IS SOLELEY
PUBLISHED FOR INFORMATIONAL PURPOSES. THE IETF RECOMMENDS TO USE
draft-ietf-tls-ecdhe-mlkem IN ALL CIRCUMSTANCES INSTEAD OF THIS DOCUMENTS
METHOD.
If this text is too strong, then maybe the WG should try to find a text
softened sufficiently for maybe even more than rough consensus. But the document
really needs an explicit reminder about the difference in status because
it is likely that people will browse through this draft who are just pointed
to it as a reference in some "regulatory framework". Even worse: It may be
browsed by people rewieving such a regulatory framework, not understanding
that from the eyes of the IETF there is a better technology. So let's pleae
make sure we (IETF) are not so lame to think that it is sufficient to
direct user of our technologies to our preferred methods by just the document
header (heck, i just had IESG reviews that totally fell apart because IESG
didn't even check the status of RFCs correctly).
2. Given how important TLS and the evolution towards post-quantum crypto
is for many industries, it is quite frankly irresponsible to publish documents
whose only real-world discussing text is
a) Intro text: "standalone post-quantum key establishment, targeting smaller
key
sizes or less computation, and simplicity"
b) One page of "only-for-the-eyes-of-security-experts" Section 5
(security considerations)
I really think that as long as this stays a WG document instead of an
individual submission, there needs to be a much more "laymen" oriented
description of attack vectors and how draft-ietf-tls-ecdhe-mlkem vs
this draft will fare against them. A good amount of this was discussed
on the list, but none of it made it into the text. That is lazy
by the WG.
Of course, such an "operationally" focussed discussion of security
properties comparing the two mechanisms would also work very nicely
as a separate RFC, but i wouldn't know how IETF could make sure that
this RFC does not get published until such a comparison is also published
(normative references in an informational RFC ?).
At minimum, it would be lovely to have at least ONE example in the RFC, how the
added amount of storage and compute for ECDHE in the hybrid solution is
significant, given how (in my laymen understanding), both storage and compute
would predominatly be determined by MLKEM. Else the intro claim "targeting
smaller key
sizes or less computation" is just marketing that should be removed.
Or to paraphrase Uncle Ben:
With great power over crypto comes great responsibility to explain better.
Cheers
Toerless
On Thu, Feb 12, 2026 at 11:05:22AM -0800, Joseph Salowey wrote:
> This message starts the second Working Group Last Call for the pure ML-KEM
> document (draft-ietf-tls-mlkem-07).
>
>
> The file can be retrieved from:
>
> https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/
>
> The diff with the previous WGLC draft (-05) is here:
>
>
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-07&difftype=--html
> <https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-06&difftype=--html>
>
>
> The main focus of this WGLC is to review new text providing more context
> around the use of pure ML-KEM. For those who indicated they wanted this
> text, please let us know if the new text satisfies you and if you support
> publication. This working group last call will end on February 27, 2026.
>
>
> Thank You.
--
---
[email protected]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
