Hi everyone,
I do not support the publication of the document.
Overall, given the immaturity of the standards and lack of real clarity
over safe parameters, and given the importance of TLS in encrypting most of
the world’s traffic in combination with the fairly low additional overhead
of hybrid KEM mode for TLS, I think it makes sense to in general to
recommend to use hybrid mode with X25519. Of course an Informational RFC is
not a recommendation, but it can easily and will be viewed as such.
As a former W3C staff member, I do understand there is a fairly informal
process for Informational IETF RFCs and internally they are viewed more as
house-keeping for implementers, but one must remember for the outside
world, including many implementers, even Informational RFCs are treated as
de-facto standards. So additional care must be taken and a certain degree
of conservatism should be expected. As an implementer, for example, at Nym,
our VPN product uses hybrid mode with ML-KEM and X25519, and is working on
implementing support for non-lattice postquantum alternatives just to be
extra paranoid.
However this may be a bit off topic and non-technical, in addition to
various purely technical arguments, but I do think it would be healthy for
the IETF to discuss the role of the NSA inside the IETF which is the
underlying issue leading to a clear lack of consensus over what could be a
minor Informational RFC. The IETF as a body of individual engineers did a
remarkable job post-Snowden in pushing through TLS 1.3 and gained the trust
of much of the larger international community (developers, users, and
nation-states), and X25519 - due to its neutral academic background and the
personal reputation for integrity by DJB and Lange - was very well-received
as an option to the NIST curves in TLS. The IETF received a well-deserved
reputation this for being relatively free of undue US influence.
So it should come as no surprise, given the NSA’s original and
well-documented historically attempted suppression of public key
cryptography, backdoors in RNGs, and weakened standards means of course
that when the NSA asks to drop all options - in even an Informational RFC -
but ML-KEM in TLS that many people are concerned. So the real danger here
is that the IETF loses its popular legitimacy due to following the NSA’s
recommendation given to the IETF years ago to remove X25519 hybrid mode, as
the RFC may be seen not as as an “option” but as the recommended way to do
it by implementers unaware of the intricacies of the IETF and what
“Informational” means in terms of IETF process.
How to avoid this problem in the future? I understand that any process
change is outside of the scope of the TLS WG, but we will bring it up with
the IESG and IAB. The IETF is composed of individuals, not institutions
like the NSA, so it seems reasonable that while individuals can participate
as individuals, I would recommend any individual affiliated with a national
security agency like the NSA, not chair any Working Group, serve as editors
of documents, and should not “drive” a process. It is important to be
neutral so this practice should apply across any security agency, like
ANSSI in France and so forth. The problem is exceptionally important today
to make sure the IETF is not controlled by US institutions as they are
increasingly viewed globally as not trustworthy due to the current
geopolitical climate engendered by Trump, and if would be tragic for the
internet if the IETF lost its legitimacy due to a real or even just
perceived influence of any geopolitical actor. The mission to prevent the
internet from fragmenting over postquantum cryptography - or any other
issue - is of utmost importance to future generations, and minor procedural
issues can thus have outsized importance down the line, as we learned with
the standardization of DRM at W3C.
Yours,
Harry
On Wed, 8 Jul 2026 at 17:42, James <[email protected]> wrote:
> Hi,
>
> I support publishing draft-ietf-tls-mlkem-08.
>
> Best,
> James
>
> On Wed, 8 Jul 2026, 14:33 BARNETT Anthony, <
> [email protected]> wrote:
>
>> Classified as: {OPEN}
>>
>> I support publication of this document.
>>
>>
>>
>> Anthony Barnett
>>
>> {OPEN}
>>
>> The information contained in this e-mail is confidential. It is intended
>> only for the stated addressee(s) and access to it by any other person is
>> unauthorised. If you are not an addressee, you must not disclose, copy,
>> circulate or in any other way use or rely on the information contained in
>> this e-mail. Such unauthorised use may be unlawful. If you have received
>> this e-mail in error, please inform the originator immediately and delete
>> it and all copies from your system.
>>
>> Thales UK Limited. A company registered in England and Wales. Registered
>> Office: 350 Longwater Avenue
>> <https://www.google.com/maps/search/350+Longwater+Avenue?entry=gmail&source=g>,
>> Green Park, Reading, Berks RG2 6GF. Registered Number: 868273
>>
>> Please consider the environment before printing a hard copy of this
>> e-mail.
>> _______________________________________________
>> 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]
>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
