[TLS] Re: [EXT] Re: Working Group Last Call for Use of ML-DSA in TLS 1.3

[David Stainton <[e-mail]>]

I am astonished at the level of disinterest with respect to the
horrible situation we'll be in if there are successful forgery
attacks.
And I am disappointed that so many of you argue for pure ML-DSA.
Successful forgery attacks will be very difficult to recover from.
I strongly oppose the pure ML-DSA and my suggestion is that only
hybrid schemes should be standardized for TLS.

And I think what is standardized for TLS might have inspirational
effects on other projects but mind you certainly not my projects.

My work is now solely focused on building a post quantum mix network.
We don't use TLS at all however, I think the comparison between the
two is illustrative.
If the Katzenpost mixnet were to use a PQ only signature scheme which
at some point becomes broken there are so many complex attacks that
could be done.
The entire set of privacy and security notions of the mixnet collapses
entirely. Attackers would be able to hijack the dirauth voting system
and install any new mix nodes they wish. Attackers will thus be able
to eventually control entire routes through the mixnet, rendering all
security guarantees meaningless but perhaps more importantly removing
all anonymity guarantees as well, exposing who is talking to whom.

At the end of the day I feel like these arguments against hybrids are
conducted in bad faith either because of NSA influence or due to some
kind of personal desire to become a power wielding bureaucrat in the
world of cryptographic and IETF standards. There's a certain type of
cryptographer that just loves to say no to good design ideas and they
are present here in multitudes. Good job guys. We've missed the train.
According to Phil Rogaway's "the moral character of cryptographic
work" we're supposed to be trying to help people, trying to help
prevent human rights violations and working on things that are
socially relevant.

On Thu, Apr 23, 2026 at 4:38 AM Daniel Apon <[e-mail]> wrote:
>
> Hi Jacob,
>
> You wrote:
> " A non-exhaustive list of ways that one might avoid pure PQ:
> - if the PQ crypto fails as SIKE failed
> - if some or all of Peter Gutmann's criticisms about CRQCs are correct
> - if the PQ crypto fails in a novel way that CRQCs enable
> - if the it is impractical to break both ECC and the PQ during the
> window in which it matters
> - if the PQ crypto deployment gives adversaries an opportunity to
> sabotage previously functional cryptography and thus break security
> - recommendations and/or regulations that impose a hybrid requirement"
>
>
> Please allow me to address each (trying to delineate where reasonable points of disagreement exist versus points that don't, to me, seem reasonable):
>
>
> " - if the PQ crypto fails as SIKE failed"
>
> This is a common public misunderstanding of the NIST PQC process.
> One should not view SIKE as being broken as a knock against greater-than-decade-long PQC standardization processes, but rather a wildly successful outcome of such processes and a testament to the mathematical rigor applied to PQC standardization that SIKE *was not standardized* while waiting for an attack to be published. Full stop.
>
>
> " - if some or all of Peter Gutmann's criticisms about CRQCs are correct"
>
> Without diving down into rabbit holes about dogs and waffles or whatever other satire, was there a serious technical point worth highlighting?
> Historically, one of the best "cartoon form" arguments in Garey and Johnson's book "Computers and Intractability: A Guide to the Theory of NP-Completeness" was on page 3, captioned:
> "I can't find an efficient algorithm, but neither can all these famous people."
>
> To wit: in this situation, we have many famous people working on building CRQCs. Some have recently won the Nobel Prize in Physics for their work towards large-scale quantum computing engineering.
> To be clear, the majority corpus of expert opinion is clearly in favor of a near-to-medium-term CRQC emerging.
>
>
> " - if the PQ crypto fails in a novel way that CRQCs enable"
>
> There seems to be no such potential pathways that are believable/known, despite various attempts in the past years by Yilei Chen and Yifan Zhang.
>
>
> " - if the it is impractical to break both ECC and the PQ during the
> window in which it matters"
>
> This is somewhat of a more valid point, and it comes down to a question of the intelligence lifespan of data.
> In some scenarios, maybe an hour or a day is the relevant information content of data.
> In others, years or decades are not enough to erase the sensitivity of communications.
>
> Certainly, hybrid ECC+PQC (in whatever form it occurs) may be more reasonable for relatively less sensitive data, but for more sensitive data, the "window in which it matters" is inherently long.
>
>
> " - if the PQ crypto deployment gives adversaries an opportunity to sabotage previously functional cryptography and thus break security"
>
> I suppose that's why the world participated in a decade-long common evaluation process to vet the new cryptography, which was not only standardized without serious technical objection to the security of the PQ cryptographies, but was standardized with alternative technical opinions left objectively wanting in public. It took many years for the global conversation to reach that final point.
>
>
> " - recommendations and/or regulations that impose a hybrid requirement"
>
> This is a great reason to want an option for hybrid PQC+ECC, but it's not a reason to forbid pure PQC.
> Businesses (such as mine) that participate as vendors in multiple markets will spend the appropriate effort to satisfy local regulations in each jurisdiction, of course.
>
> Kind regards,
> --Daniel
>
> On Wed, Apr 22, 2026 at 5:49 PM Jacob Appelbaum <[e-mail]> wrote:
>>
>> Hello Uri,
>>
>> On 4/22/26 21:52, Blumenthal, Uri - 0553 - MITLL wrote:
>> > There can be arguments about the life expectancy of hybrids - from
>> > zero to CRQC appearance - but can be no objection to the point that
>> > once CRQC is here, only pure PQ will make sense.
>> >
>>
>> With respect, I suspect that there there will be measurements rather
>> than mere speculative arguments.
>>
>> The life expectancy will depend greatly on such a machine existing, who
>> has such a machine, who is willing to reveal that they have such a
>> machine, how efficient and/or useful it is for practical attacks, and
>> most importantly if the PQ cryptography actually survives contact with
>> that reality. The latter point seems particularly challenging as a
>> discussion point.
>>
>> Something that I haven't seen raised in this discussion is a possible
>> middle ground where we see something like the proposed
>> TWINKLE[0]/TWIRL[1] machines where breaking a single key may be feasible
>> but cost prohibitive at scale. Those proposed systems did not force RSA
>> into retirement. Meanwhile, LOGJAM[2] resulted in RFC8270 rather than
>> RSA's end.
>>
>> There are several kinds of PQ failures that we have seen, additional
>> failures that we expect to see, and a few that many of us hope won't
>> happen at all. SIKE remains a humbling example that is seemingly avoided
>> in many of these discussions.
>>
>> > Thus, arguing against pure PQ makes no sense in my opinion: you may
>> > be able to delay long enough to avoid hybrids, but there’s no way
>> > you’d avoid pure PQ. — Regards, Uri
>>
>> As of today, there isn't a quantum computer that is public and breaking
>> ECC. We are fairly confident that ECC is secure today modulo various
>> kinds of NOBUS and other kinds of cryptographic sabotage. We are also
>> fairly confident that ECC will fall eventually if there is a quantum
>> computer. Most people are confident that there will be a relevant
>> quantum computer and that we should prepare. It seems odd to prepare by
>> increasing the risk of attacks by computers that already exist today.
>>
>> A non-exhaustive list of ways that one might avoid pure PQ:
>> - if the PQ crypto fails as SIKE failed
>> - if some or all of Peter Gutmann's criticisms about CRQCs are correct
>> - if the PQ crypto fails in a novel way that CRQCs enable
>> - if the it is impractical to break both ECC and the PQ during the
>> window in which it matters
>> - if the PQ crypto deployment gives adversaries an opportunity to
>> sabotage previously functional cryptography and thus break security
>> - recommendations and/or regulations that impose a hybrid requirement
>>
>> Hybrid compositions make sense for encryption and for signatures.
>> Attacks with a quantum computer to break the cryptographic encryption or
>> signature system(s) may be roughly the same but I am not convinced that
>> the consequences are equal. It is remarkable that signature forgery
>> isn't considered more of a concern than HNDL.
>>
>> Arguing for a belt rather than suspenders and a belt is often a
>> reasonable fashion choice but is it an equally secure and resilient system?
>>
>> Kind regards,
>> Jacob Appelbaum
>>
>> [0] https://en.wikipedia.org/wiki/TWINKLE
>> [1] https://en.wikipedia.org/wiki/TWIRL
>> [2] https://en.wikipedia.org/wiki/Logjam_(computer_security)
>>
>> >> On Apr 22, 2026, at 13:25, Nicola Tuveri <[e-mail]>
>> >> wrote:
>> >>
>> >>  Hi Rich, thanks for your clarification, indeed my phrasing was
>> >> not ideal. I’ll take your comment as a chance to clarify my
>> >> stance. Code point assignment and deployment support are distinct
>> >> considerations. In practice, non-experimental production
>> >> ZjQcmQRYFpfptBannerStart This Message Is From an External Sender
>> >> This message came from outside the Laboratory.
>> >> ZjQcmQRYFpfptBannerEnd
>> >>
>> >> Hi Rich,
>> >>
>> >> thanks for your clarification, indeed my phrasing was not ideal.
>> >> I’ll take your comment as a chance to clarify my stance.
>> >>
>> >>
>> >> Code point assignment and deployment support are distinct
>> >> considerations. In practice, non-experimental production
>> >> deployments generally rely on both assigned code points and a
>> >> published standard.
>> >>
>> >>
>> >> Concerns about the proliferation of standards introducing support
>> >> for additional code points are not uncommon on this list. I note a
>> >> similar concern here in support of delaying this draft.
>> >>
>> >>
>> >> At present, the process risks creating the impression of a “first-
>> >> to-standard” outcome, where publication effectively determines the
>> >> direction of deployment before the trade-offs have been fully
>> >> examined, possibly even stalling the progress of other drafts. In
>> >> particular, the argument that introducing additional options
>> >> increases complexity has been raised repeatedly on this list, but
>> >> it does not seem sufficient on its own to guide decisions in a
>> >> security area WG. It would be preferable to more explicitly
>> >> evaluate the security properties of hybrid and non-hybrid
>> >> approaches and reach a position that can inform what should-and
>> >> should not-be advanced to standard.
>> >>
>> >>
>> >> Best regards,
>> >>
>> >> Nicola Tuveri
>> >>
>> >>
>> >>
>> >> On Wed, Apr 22, 2026 at 19.30 Salz, Rich <[e-mail]
>> >> <mailto:[e-mail]>> wrote:
>> >>
>> >> * I have read the draft, but I do not support its publication at
>> >> the moment.
>> >>
>> >>
>> >> * My rationale is that this draft adds complexity by adding extra
>> >> code points for pure mldsa.
>> >>
>> >>
>> >> Code points are assigned when a stable reference is available, as
>> >> you might recall from the long threads on the pure ML-KEM draft.
>> >> So I don’t think your stated rationale makes sense.
>> >>
>> >> _______________________________________________ TLS mailing list
>> >> -- [e-mail] To unsubscribe send an email to [e-mail]
>> >
>> >
>> > _______________________________________________ TLS mailing list --
>> > [e-mail] To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> TLS mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]