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

[Jacob Appelbaum <[e-mail]>]

Hi Daniel,

On 5/5/26 03:47, Daniel Apon wrote:
> 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.

Agreed; my summary of another person's use of "better" was not intended
as a complexity-theory claim.

My point was not that "two X-bit problems equal one 2X-bit problem." It
was a risk-management point: a hybrid construction reduces the chance
that a single new break results in a practical break of the protocol.

> 
> If you want to increase security, you should increase parameter
> sizes.

That only addresses the problem if the underlying hard problem remains a
sound basis for security. What counts as a secure bit level in one
system may be wholly inadequate in another.

Increasing parameter sizes and using hybrids are not the same design
choice and do not address exactly the same risk. My concern here is not
just nominal strength, but the transition risk of relying on one new
primitive family by itself.

> Or, you should have chimed in on the security of the hard problem a
> decade ago when it was being discussed internationally.

I do not think that captures the actual concern.

First, it is not too late to discuss protocol-level risk management.
That is exactly what we are doing now.

Second, I did in fact raise objections in the NIST process at the time,
including objections related to specific mathematical design choices.
Those concerns were not addressed or resolved by NIST in that process.

Indeed, NIST later required changes in moving from Kyber to ML-KEM,
which only underscores that protocol-level caution remains relevant now.

Finally, hybrids are not merely a statement about one hard problem
versus another. They are also a hedge against overconfidence by
mathematicians, implementers, and protocol designers when deploying
relatively new primitive families.

> 
> ==========
> 
> 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 think we partly agree.

I agree that it should be discussed here. But in practice, related
discussion has already been cut short as "veering" off-topic, so
"resolve it here" has not actually produced a durable resolution.

Where we disagree is that if the issue is relevant enough to debate
here, it is relevant enough for the document to at least acknowledge the
tradeoff briefly, or to cite to a text that does. Otherwise the
document presents a design choice while pretending the adjacent risk
tradeoff does not exist.

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

I am not asking for a long argumentative appendix.

What I would prefer is a concise description of the tradeoffs, ideally a
risk matrix that includes the mathematical and deployment concerns in a
way that lets readers make an informed judgment, along with hybrids as a
default safer transition plan.

> The standard should stand on its own standard legstands.
> 

Perhaps, but many, including, if I understood Usama's statement
correctly, a majority of countries in Europe are still preferring hybrid
approaches during the transition. That is not an argument to freeze
progress. It is an argument to surface the tradeoffs clearly and to keep
the safer hedge where appropriate.

Hybrids and explicit discussion of the risks help address both immediate
and transition-specific concerns. I do not see the benefit in rushing to
remove that hedge or in omitting mention of the hedge.

Kind regards,
Jacob Appelbaum

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