Jacob Appelbaum wrote: >Those who want post-quantum protections should not be less secure for >hedging security concerns with the use of hybrid constructions. TLS >enjoyers and myriad unknowing users should not need to take special >steps to ensure they aren't accidentally using the less conservative, >riskier strategy.
This is handled by the RECOMMENDED column, application profiles, and the default configuration in libraries, not by registering code points. Limiting available options for real-world deployments can be detrimental to security. Highly constrained IoT devices are unlikely to deploy hybrids. The IETF is expected to soon publish a quantum-vulnerable TLS profile for IoT. I would already prefer standalone ML-KEM over standalone ECC in a forward-looking profile, but this can be debated. Demonizing standalone ML-KEM will likely slow the urgently needed PQC migration in IoT. https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/ >Targeted and mass surveillance collection of data is part of a >larger pervasive attack strategy that is practiced by many adversaries >more or less continuously. Fully agree. Beyond signal intelligence agencies, I wish more focus were given to private data hoarders. Meta’s business model relies on massive data hoarding and behavioral surveillance, with well-documented negative effects on users, particularly young women exposed to addictive and appearance-driven content optimization. The expansion of this model into wearable devices, highlighted by recent scandals involving sensitive data captured through Meta’s smart glasses, raises serious concerns about consent, privacy, and the normalization of pervasive surveillance in everyday life. >With regard to Kyber/ML-KEM, NIST dismissed or did not address important >technical concerns, and they ignored other related concerns of >significance that were raised in the public comment period[0]. The >effect of that overall disappointment has been immensely harmful to >NIST's international standing, which was already lying down, to >paraphrase a great American poet. Do you have any concrete examples? I think it is nearly impossible to address all comments, as many of them are mutually contradictory. Based on my personal experience, I believe NIST pays close attention to the feedback it receives and makes reasonable trade-offs. Overall, I think most people are quite satisfied with NIST’s PQC project. At least, NIST offers public email lists, workshops, comment periods, and specifications, something that organizations such as ISO and ECCG do not. >should see hybrids listed as RECOMMENDED (i.e.: recommend=Y). In an >ideal world with prudent risk management, hybrids would be listed as a >MUST, and PQ only should be a MUST NOT[1]. I agree that X25519MLKEM768 should be MTI as soon as possible. Two questions: where would you place quantum-vulnerable ECC-only key exchange on this scale, and do you think non-hybrids should be forbidden even in what ANSSI refers to as Phase 3? https://na.eventscloud.com/file_uploads/b635298de1c10be6d3732863e8b1beca_Day2-1600-ANSSI.pdf Cheers, John Preuß Mattsson On 2026-02-27, 00:57, "Jacob Appelbaum" <[email protected]> wrote: Hello, On 2/26/26 04:44, Nadim Kobeissi wrote: > Dear Stephen, > > Thank you for your note. I appreciate your shared reservations > regarding the publication of this document. > > I agree entirely with both you and Rich that a single participant > does not possess a unilateral veto, and that assessing consensus > requires judgement calls by the chairs. IETF procedures do not allow > one person to hold a document hostage based merely on contention or > preference. > > However, there is a fundamental difference between a generic > complaint and a substantive, detailed technical objection. As > outlined in RFC 7282, the essence of rough consensus is that all > legitimate technical concerns must be addressed—not necessarily > accommodated, but technically resolved or refuted. > > If a severe technical flaw is demonstrated, or if prerequisites—such > as FATT review—aren’t met, and the Working Group's only response is > to state that they "still want to move forward" without engaging > with the realities of the flaw, then the technical issue remains > unaddressed. Proceeding under such circumstances is not rough > consensus; it is the administrative dismissal of an unresolved > technical reality. > > My objective is simply to ensure that the cryptographic standards we > produce are sound. I remain fully prepared to engage with any > rigorous technical refutation of the vulnerabilities I have > detailed. Until the substance of those concerns is actually met, my > objection stands on its technical merits. I am in full agreement with Nadim and others on the list pushing back against publication of this draft. I find the counter arguments, and the motivations or rather the lack of motivations, to be unconvincing. It is important to model and verify, and indeed to think about changes very carefully. It is surprising that the FATT review isn't the starting point for serious consideration. It is prudent from a risk management perspective to use hybrid constructions with an appropriate combiner. Even if an attack against ECC were to be demonstrated tomorrow using a quantum computer, does anyone expect every adversary to have the same capability and the same datasets instantly? It seems unlikely, and various issues in post-quantum implementations seem to be much more likely to arrive again and again, and sooner. Those who want post-quantum protections should not be less secure for hedging security concerns with the use of hybrid constructions. TLS enjoyers and myriad unknowing users should not need to take special steps to ensure they aren't accidentally using the less conservative, riskier strategy. The longer cryptographers and security researchers have to discover and fix various issues while hedging safely, the better. Those who only want post-quantum security are always free to publish their ECC secret keys as a sign of their confidence. The compositional security properties mentioned by Nadim and others are table stakes for deploying post-quantum cryptography. The math, the various implementation details, and the deployment contexts that are secure today using ECC today should remain at least as secure today and tomorrow. Targeted and mass surveillance collection of data is part of a larger pervasive attack strategy that is practiced by many adversaries more or less continuously. Practical cryptanalysis of data collected through such surveillance or other means of data collection is by no means limited to a hypothetical quantum computer. In the tremendous volume of email on list there has not been a compelling technical argument against hybrids to the contrary presented. I oppose publication of the draft and furthermore think that for TLS, we should see hybrids listed as RECOMMENDED (i.e.: recommend=Y). In an ideal world with prudent risk management, hybrids would be listed as a MUST, and PQ only should be a MUST NOT[1]. With regard to Kyber/ML-KEM, NIST dismissed or did not address important technical concerns, and they ignored other related concerns of significance that were raised in the public comment period[0]. The effect of that overall disappointment has been immensely harmful to NIST's international standing, which was already lying down, to paraphrase a great American poet. Given this experience with NIST, I oppose publication of this draft for another reason: it will further damage IETF's standing as an independent and fair forum that seeks to protect users and the internet without advantaging any Adversary. Probably others have already received emails about this very WGLC where they have been asked if this will be an example of Project BULLRUN's latest victory. Exclusionary hostility and anti-competitive concerns aside, I am cautiously optimistic that it is at least possible that the WG and indeed the IETF won't be such an example (again). Kind regards and happy hacking, Jacob Appelbaum [0] https://csrc.nist.gov/files/pubs/fips/203/ipd/docs/fips-203-initial-public-comments-2023.pdf [1] Pure PQ in TLS, not even once! > > Nadim Kobeissi Symbolic Software • https://symbolic.software > >> On 25 Feb 2026, at 11:38 PM, Stephen Farrell >> <[email protected]<mailto:[email protected]>> wrote: >> >> >> >>> On 25/02/2026 21:50, Salz, Rich wrote: You misunderstand what >>> “addressed” means here. A perfectly reasonable response is “the >>> issue has been discussed by the WG and they still want to move >>> forward.” As another recent example, the LAMPS WG went ahead >>> even though one participant (repeatedly:) raised patent >>> concerns. >> >> Despite me not wanting to see this document published, Rich is >> correct here. There are always judgement calls required and one >> participant being convinced there's a fatal flaw in something is >> not sufficient in itself to block that thing. If a participant >> convinces others of the fatality of the flaw, that may be >> different, but if something is generally contentious, (as in this >> case), a claim of a fatal flaw by itself blocks nothing. >> >> Cheers, S. <OpenPGP_signature.asc> > > _______________________________________________ TLS mailing list -- > [email protected]<mailto:[email protected]> To unsubscribe send an email to > [email protected]<mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
