On Wed, Apr 08, 2026 at 09:30:19PM -0000, D. J. Bernstein wrote:
> I explained that every WG-issued RFC has a prominent claim of IETF
> "consensus", and that people will interpret the RFC as IETF endorsement,
> no matter how many warnings there are inside the RFC. Are you disputing
> this?
Yes, in the sense that "endorsement" isn't the point of the exercise as
I see it. It is rather a narrower question of converging on *how*, not
whether to implement ML-KEM key exchange interoperably in TLS. The how
can be accompanied by security considerations that highlight reasons to
consider hybrids instead.
Actual *endorsement* comes in the form of a "Recommended=Y" flag in the
IANA registry, specifically designed to make it possible to distinguish
between publishing a stable specification and actual "endorsement".
Your objections do not appear to be directed at the "how", and the goal
of preventing the "whether", through delays or non-publication seems to
me to be unrealistic.
> Or are you saying that IETF endorsement wouldn't tend to increase usage
> of non-hybrid PQ? Or are you disputing CECPQ2b as an example of ECC+PQ
> providing more protection than non-hybrid PQ?
I don't see specification of TLS with pure ML-KEM as IETF "endorsement".
The endorsement of ML-KEM comes from NIST. The IETF TLS WG, as stewards
of the protocol (but not the protocol police), can now decide whether to
publish a specification describing how FIPS-203 might be used in TLS, as
one of the supported key exchange mechanisms.
> My understanding of your argument here---please correct me if I've
> misunderstood---is as follows: people saying (e.g.) "Don't use this"
> shouldn't be opposing publication as an RFC, but instead should be
> supporting publication as an RFC as an opportunity to include a "Don't
> use this" warning inside that RFC.
Well, I would say "consider the risks, which are as follows... when in
doubt, use an ECC+PQC hybrid", which is of coursedifferent from "Don't
use", I view "Don't use" as quixotic, those who, despite advice to the
contrary, see the risks differently, will use non-hybrid key exchange.
> But publishing a new problematic RFC along with a "Don't use this"
> warning is strictly worse than rejecting the RFC and publishing a
> separate "Don't use this" document, just like previous IETF documents
> deprecating various other problematic cryptographic choices.
That's where we part ways, I support making a case for prudent use of a
hybrid, but I don't see the proposed specification as "problematic", or
non-publication as an effective way to get implementations to avoid the
use of non-hybrids.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
