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

[Daniel Apon <[e-mail]>]

Hi Guilin,

You wrote:
"I guess here stresses on improving security strength via using larger
parameters or key sizes, but hybrid approach concerns more about the
consequence in case  the only pure PQ algorithm is fundamentally flawed (as
what happened to SIKE) or some breakthrough cryptanalysis surpasses the
security margin. Below is the link for our recent discussions in TLS WG
mailing list on the almost same topic.

  https://mailarchive.ietf.org/arch/msg/tls/5GiyxhMA7rhvR73tKrnRd8ZeOK8/"

Yes, it is clear what the hybrid approach is. I also support both pure-PQC
and hybrid approaches; they should be available, in standard, to anyone.

But as I mentioned before on this WG mailing list, this lesson "from SIKE"
-- so easily stated -- that PQC algorithms may be fundamentally flawed, is
incredibly technically imprecise.

SIKE's mathematics had a significantly higher barrier-to-entry for the
corpus of PQC researchers to understand it, properly analyze it, and speak
about it broadly.
At the end of NIST PQC Round 3, *SIKE was adjudicated by NIST as having not
received sufficient study*, which is why it was moved into a 4th Round (as
a unique object).
Lo and behold-- with some additional study and focus, there was a break.
This was a success of the process itself; not a weakness of PQC algorithms.

This is a distinct and opposite case from the study of the concrete
security of noisy linear codes (both lattice-based and code-based). While 3
code-based schemes were moved on past the 3rd round (HQC, BIKE, and Classic
McEliece), these schemes had outstanding issues between them that hadn't
resolved yet (BIKE's decryption failure analysis, Classic McEliece's syzygy
security and high practical cost of large PKs, and HQC's larger costs vs
BIKE). These issues were significantly more mature and specialized than the
technical situation with SIKE.

By contrast to SIKE (which was eventually broken outright within a quick
sequence of works), many orders of magnitude of technical research works
have gone into the study of cryptanalysis of noise linear systems. It's
just not a good parallel to draw.


On Mon, May 4, 2026 at 11:56 PM Wang Guilin <[e-mail]> wrote:

> For me, as stated previously, *I support the use of ML-DSA and also
> composite ML-DSA in TLS 1.3*.
>
>
>
> (For the latter case, yes, the number of composites may need to be reduced
> from 13 to a few, as several other experts mentioned. )
>
>
>
> I do not understand the underlying logic about “defines A is not the place
> for an A compared-to B comparison”. As both A and B are two apparent
> approaches to solve the same problem, the authors, the readers and the
> future implementers all know this. How can we just ignore this issue in a
> specification as if B were not existing?
>
>
>
> Yes, comprehensive comparison with (rough) consensus seems very hard to
> achieve, but some middle ground or neutral wordings are also helpful for
> the readers. In the simplest (also the worst?) case, at least the
> specification can say and refer to approach B, I think.
>
>
>
> >Two hard problems at X-bit security, broken independently, should take
> 2*2^X = 2^{X+1} work.
> > One hard problem at 2X-bit security should take 2^{2X} work.
>
>
>
> I guess here stresses on improving security strength via using larger
> parameters or key sizes, but hybrid approach concerns more about the
> consequence in case  the only pure PQ algorithm is fundamentally flawed (as
> what happened to SIKE) or some breakthrough cryptanalysis surpasses the
> security margin. Below is the link for our recent discussions in TLS WG
> mailing list on the almost same topic.
>
>   https://mailarchive.ietf.org/arch/msg/tls/5GiyxhMA7rhvR73tKrnRd8ZeOK8/
>
>
> Cheers,
>
>
>
> Guilin
>
>
>
>
>
>
>
>
>
>
>
> *From:* Daniel Apon <[e-mail]>
> *Sent:* Tuesday, 5 May 2026 9:47 am
> *To:* Jacob Appelbaum <[e-mail]>
> *Cc:* Salz, Rich <rsalz=[e-mail]>; TLS List <
> [e-mail]>
> *Subject:* [TLS] Re: Working Group Last Call for Use of ML-DSA in TLS 1.3
>
>
>
> Hi Jacob,
>
> You wrote:
> "When better is defined as "two hard problems are more secure than one
> maybe hard problem""
>
> This is neither standard nor textbook in complexity theory.
>
> Two hard problems at X-bit security, broken independently, should take
> 2*2^X = 2^{X+1} work.
> One hard problem at 2X-bit security should take 2^{2X} work.
>
> If you want to increase security, you should increase parameter sizes.
> Or, you should have chimed in on the security of the hard problem a decade
> ago when it was being discussed internationally.
>
> ==========
>
> In response to:
> "a document that defines A is not the place for an A compared-to B
> comparison"
> You wrote:
> " Where should it go if not there?"
>
> My answer is *here*. Resolve that here, in this conversation. Not in a
> long-lived document.
>
> ==========
>
> I believe I agree with Rich and Uri in this conversation.
>
> Moreover, I do not think both a "Why hybrids?" and a "Why not hybrids?"
> section being added addressing any of my concerns; in fact, I believe it
> only makes shoving worse -- by shoving controversy and various arguable
> opinions into a standard.
> The standard should stand on its own standard legstands.
>
> --Daniel
>
>
>
> On Mon, May 4, 2026 at 9:52 AM Jacob Appelbaum <[e-mail]>
> wrote:
>
> Hi Rich,
>
> On 5/4/26 15:00, Salz, Rich wrote:
> > * I had sincerely proposed what I believe is a good middle ground to
> > move on. WG is free to trash my proposal.
> >
> > Okay then.  Your proposal is not a middle ground.
>
> What are the sides from your perspective and what would be a middle
> ground if not this?
>
>  > It says that hybrids are better.
>
> When better is defined as "two hard problems are more secure than one
> maybe hard problem" or "one new failure cannot result in a practical
> break of the protocol" then it follows that hybrids are better.
>
> If we're not talking about "better" in the context of security but byte
> overhead or energy efficiency, then we'd need some other definitions for
> the word better, I suppose.
>
> >
> > I still maintain that a document that defines A is not the place for
> > an A compared-to B comparison.
>
> Where should it go if not there?
>
> If it should go somewhere else, would a reference to that other place
> also be wrong?
>
> > From the mailing list traffic, several other long-timers agree with that.
> >
> This reads as an appeal to authority over a reasonable analysis that is
> related to Usama's formal proof. I do not find it compelling and it
> appears as dismissive to Usama's efforts. What's the constructive
> counter proposal other than writing as if hybrids don't exist or that
> PQC without a hybrid construction isn't a novel risk?
>
> Long-timers can be wrong and given the Dual_EC history and various
> related drafts, they might even be wrong twice for the concerns raised
> by Usama and others.
>
> Kind regards,
> Jacob Appelbaum
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>