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

[Joshua <[e-mail]>]

> I believe it depends on the threat model. In [0], I tried to explain 

> the threat model industry has got in the Confidential Computing 

> Consortium (CCC) and I believe deterministic signing puts most of the 

> work at stake. It would be helpful to understand if you disagree with 

> [0] and have a different threat model in mind.

I mean, I agree that deterministic signing can be risky, but in the case
of TLS would it not also require a fault in the RNG for a server to re-
sign the exact same plaintext? (eg, it would require a repeat of the
server's random value)

The threat model the CCC has is that key extraction cannot be allowed for
signatures of any arbitrary plaintext, whereas in TLS allowing signatures
of arbitrary plaintext to be generated in the first place would be an 

extreme weakness. Should a fault occur in deterministic signing, and a
re-sign would immediately leak the private key, it would require a second
(arguably more catastrophic) fault in TLS to actually cause that re-sign
to take place.

Best,
Joshua Nabors

On Sunday, April 12th, 2026 at 1:40 PM, Muhammad Usama Sardar <[e-mail]> wrote:

> Hi Ilari,
> 

> On 12.04.26 16:58, Ilari Liusvaara wrote:
> 

> > On Sun, Apr 12, 2026 at 01:51:58PM +0200, Muhammad Usama Sardar wrote:
> > 

> > > In particular, say you are an implementer used to reading IETF documents and
> > > not NIST documents. Security considerations being offloaded to NIST document
> > > is an additional burden for you. But let's put that aside. For your
> > > implementation, would you interpret that text as SHOULD NOT or MUST NOT in
> > > IETF sense? How would you resolve this ambiguity?
> > 

> > It is clearly SHOULD NOT.
> 

> Thanks. This confirms my concern in the very first email.
> 

> > > And I believe this ambiguity has significant high-stakes impact. Say you
> > > manage to resolve it as SHOULD NOT: All confidential computing solutions are
> > > /almost exclusively/ based on TLS protocol. Would you let attacks like
> > > BadRAM, TEE.fail and wiretap.fail continue to be exploited? To me, this
> > > seems like a disservice to the community, given a demonstrated history of
> > > exploited attacks.
> > 

> > Randomized signing does not help there.
> 

> I believe it depends on the threat model. In [0], I tried to explain the threat model industry has got in the Confidential Computing Consortium (CCC) and I believe deterministic signing puts most of the work at stake. It would be helpful to understand if you disagree with [0] and have a different threat model in mind.
> 

> > Furthemore, things like BadRAM, TEE.fail and wiretap.fail are far from
> > the worst threats.
> 

> To the best of my current knowledge, understanding, and belief, the ones I have mentioned are the worst threats as of today, in the context of Confidential Computing. So may I kindly ask you to share at least a few of those "worst threats" and help to understand the criteria for judging the severity of threats? Thank you.
> 

> IIUC, you are a cryptographer, whereas my background is in formal analysis. We don't have probabilities in our formal models. I am seeking to align my understanding with the threats you are citing.
> 

> >  And the worst threats are becoming even worse...
> 

> FWIW: It applies to everything in security -- and not specifically to confidential computing.
> 

> Best regards,
> 

> -Usama
> 

> [0] https://mailarchive.ietf.org/arch/msg/tls/w9f5MhuGiF75HoNQn1PnL9C-zSk/