Gentlemen,

Are we really optimizing TLS 1.3 around 32 bytes? If so, then why?

ML-KEM-768 public keys are 1184 bytes. X25519 adds 32 bytes. In the
context of kilobyte scale key shares, certificate chains, and network
latency, that delta is not the dominant cost for general purpose
deployments.

If the goal of this transition is risk reduction under uncertainty,
hybrid key exchange is the conservative engineering choice.

On IoT specifically:

If a device can afford a ~1 KB ML-KEM public key, it is difficult to
argue that an additional 32 bytes is categorically infeasible. The
real constraints in IoT tend to be code footprint, CPU cycles, update
mechanisms, and operational simplicity, not raw 32 byte bandwidth
differences.

If a constrained profile needs a non hybrid option, that should be
justified explicitly in the profile. But constrained environments
should not automatically determine the default posture for the entire
Internet.

On “most people are satisfied with NIST’s PQC project”:

Rough consensus among active participants is not the same as universal
agreement across the broader cryptographic community. There are
serious and diverse threat models in play, including surveillance
resistant and adversarial deployment contexts, where conservative
transition strategies matter greatly.

The transition to post quantum cryptography is one of the largest
cryptographic migrations ever undertaken. The safest available path
during transition should be the baseline, not the exception.


Sincerely,
David Stainton


On Fri, Feb 27, 2026 at 10:28 AM John Mattsson
<john.mattsson=40ericsson.com@dmarc.ietf.org> wrote:
>
> 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" <jacob@appelbaum.net> 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
> >> <stephen.farrell@cs.tcd.ie> 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 --
> > tls@ietf.org To unsubscribe send an email to tls-leave@ietf.org
>
>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org