[TLS] Re: RFCs on weakened crypto are not fixed by warnings

[Viktor Dukhovni <[e-mail]>]

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.  🇺🇦 Слава Україні!