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

[Jacob Appelbaum <[e-mail]>]

Hi Guilin,

On 5/5/26 05:56, Wang Guilin wrote:
> For me, as stated previously, I support the use of ML-DSA and also
> composite ML-DSA in TLS 1.3.

Are there specific regulatory concerns that apply to your context?

> 
> (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?
> 

Indeed. It is difficult to understand.

> 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.

I agree with you. Thank you for expressing this perspective.

> 
>> 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.

We generally agree but there are additional concerns including specific 
underlying assumptions not being met. I described some of this in my 
comments to NIST[0] ( see page 80 ), so I won't repeat it in detail in 
this email.

Kind regards,
Jacob Appelbaum

[0] 
https://csrc.nist.gov/files/pubs/fips/203/ipd/docs/fips-203-initial-public-comments-2023.pdf


> 
> 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]<mailto:[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]<mailto:[e-mail]> To unsubscribe send an email to
> [e-mail]<mailto:[e-mail]>