On Mon, 13 Jul 2026, Jacob Appelbaum wrote:
"Just to clarify", if a sentence about RNG is included in the hybrid and
pure mlkem drafts, you would then change your view ane be in favour of the
pure mlkem draft being published? Or are you going to be against it no
matter what is said on the RNG issue?
For the hybrid draft, my concrete request is simple: restore Kyber's
original defense-in-depth construction.
The draft does not define crypto, it normatively references some crypto.
It cannot both normatively reference it and modify it to make its own.
This change is compatible with the IETF making a more conservative
choice than NIST.
The IETF cannot modify things that are an external normative reference.
MLKEM is what NIST defined, not what you are trying to build now.
For draft-ietf-tls-mlkem-08, I would want at least the same fix. I am
not completely opposed to a non-hybrid ML-KEM document, but I do not
currently support publishing this one as-is.
This answer circles the answer by not distinguishing between the RNG
issue and any other issues. You still did not answer the question.
There are other outstanding concerns besides my `m` concern:
This does answer it better, it seems your answer is "no".
the approved-RBG dependency
Which is the same issue as the "m concern".
the Security Considerations gaps
Which has been discussed and to me the (also logical) consensus is that
each draft should not compare it to all other drafts. Things like
comparing features, cost and risks of different proposals would normally
go into a singular document, and not be scattered over drafts.
remote side-channel/covert-channel interaction
For one, this is not different between pure and hybrid, yet you have
no issue with the hybrid Security Considerations? Second, it seems as
people said, TLS already provides a huge amount of options and
parameters to use as a covert channel. The IETF already wrote a generic
document on this RFC 9416 https://www.rfc-editor.org/info/rfc9416/
I'm not sure citing it will be useful as the TLS 1.3 protocol has
already been designed, and the mlkem pure and hybrid documents are not
designing the TLS protocol nor the cryptographic protocol. Obviously,
you should take your concerns and write an Informational document about
the many TLS protocol covert channel options.
and the question of how the draft describes standalone ML-KEM's assumptions.
What would a TLS implementer need to know when it uses a cryptographic
library to support a new cipher, whether hybrid or pure? It is not at
all clear what you would want to describe here, unless you again just
want to compare two different crypto algorithms.
Is anyone tracking all of the outstanding concerns systematically
First, it seems most of the items you just listed are the same item, and
basically you want it to say "don't use pure, use hybrid instead", which
is not the right place in this one algorithm AND it is already obvious
by the IANA registrations.
Second, if you want this document to proceed with some newly added text,
it is up to you to propose such text to the WG. You cannot block the
continuation of a document by stating some work needs to be done, of
which there is no one who wants to do the actual work. That would be
a misguided kind of veto. So, if you want anything of the above done,
I suggest you write a PR or submit the text in a separate email thread
on the TLS list.
so they can be addressed one
by one? Do you have an authoritative list?
It is you who thinks there are issues to solve. I assume you have a
list of text modifications you want to see. Share them with us for
discussion and lets try to reach a consensus. But if you are not
offering concrete text to put into the draft, then the WG obviously
cannot process a list of issues that is in your head only.
The phrase "pure ML-KEM" is also not my preferred framing.
I'm sorry you missed the change to work with the PQUIP WG when we
worked on Terminology, eg:
RFC 9958 Post-Quantum Cryptography for Engineers
RFC 9794 Terminology for Post-Quantum Traditional Hybrid Schemes
So "pure" is what the IETF is using now for consistency.
A non-hybrid ML-KEM draft could be useful if it is descriptive, precise,
and honest about its assumptions and risks.
We have had these discussions for two+ years. It's great that you joined
us but obviously we can't keep redoing the same discussion whenever a
new individual joins. The current text is the consensus proposal of two
years of talk within the TLS WG.
But publishing it as a WG
consensus document without resolving the open technical concerns is a
different matter.
I am not aware of any technical concerns. I am aware of different groups
having different risk models. But no technical issues have been raised
that should block either publication of the mlkem hybrid of pure mlkem
documents, and that includes the raised RNG item.
So my answer is: maybe, depending on the text. If the drafts restore
Kyber's hash over `m`, clearly explain why, and address the remaining
Security Considerations issues systematically, I am open to changing my
view.
So to me that makes it clear that in practise, your answer will remain
"no". I also find it strange that you wouldn't want to add whatever
your list of items is on pure mlkem, to be added to the hybrid doc,
because once quantum computers exist and the classic part has no more
value, the hybrid has the identical concerns of the pure version.
If the proposal is only to add a generic RNG sentence, then no,
that isn't responsive to basically any concerns raised and it certainly
isn't robustly protecting the end user.
I'll let the WG Chairs and AD handle the concensus on these items then,
noting that you did not suggest any concrete text for the WG to
consider.
Given that WGLC has ended and consensus does not appear clear to me, I
would also like to understand the process question: are you suggesting
that the draft could still be declared to have consensus, or that there
would be another last call after concrete text is proposed? As in, are
you now discussing a hypothetical draft-ietf-tls-mlkem-09?
As I am no longer the AD for TLS, I will only answer this in the generic
IETF way. In general, see https://www.ietf.org/process/process/
Please read RFC 2026, RFC 7282 and RFC , specifically:
https://datatracker.ietf.org/doc/html/rfc7282#section-3
Rough consensus is achieved when all issues are addressed, but not
necessarily accommodated.
As I explained above, you providing concrete text additions/modifications
will help determine consensus of your suggestions better than a person who
just says "I mentioned a bunch of things, did anyone write them down so
others can fix them by coming up with text that might contain what I
want the document to say".
WG chairs determine the consensus. If they deem something could use
clarification, they can ask for a proposed change and do a concensus call
on that. They can also determine that the people who called for changes
didn't offer concrete suggestions and that their objections may count
less because they are just throwing obstracles in, instead of providing
text to evolve towards consensus. The WG Chairs can do as many consensus
calls as they think are needed. If during those discussions it appears
some new concensus is found, the draft is typically updated and if the
process takes long, the WG Chairs may if they deem it neccessary, do
another WGLC. But if a long discussion ends in no concrete new text
proposals, they might also call that they know enough about the rough
consensus and ask the AD to continue the publication process.
A generic sentence about the RNG is not sufficient. I am open to finding
something that is sufficient.
The Chairs will determine whether a generic sentence has consensus or not.
If someone disagrees with that, they can appeal to the AD.
I've heard some say nothing is needed, some say a generic sentence isn't
needed but could be done as compromise, and I heard some say a hashing
step must be introduced. The chairs will have to determine the consensus
on that.
The one thing that is clear to me is that what you are asking for
is basically changing the normative reference. That is simply not
possible. These documents are about MLKEM, not Kyber. Adding a generic
statement about RNG is the only compromise possible. If that is not
good enough for you, your only option is to voice that you are against
publication - and to be consistent, I would expect you to be against
publication of both the pure and hybrid mlkem drafts, as they are
identical in that part, using the same normative reference of NIST.
Paul
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
