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

[[e-mail]]

> Also, attacks against authentication need not involve MITM - another approach would be an impersonation attack, which is easy if mTLS is involved.
 
You are completely right. I should not write responses this late at night.
 
> Tim, you might be happy with cryptography that is sufficient against the local Wifi provider.  Some of us deal with scenarios where nation-state actors are a legitimate threat.  I believe that this working group needs to keep that in mind.
 
Nation-state actors are a legitimate threat for my use cases as well, just not the only one. I was writing in reply to Uri's statement "but [there] can be no objection to the point that once CRQC is here, only pure PQ will make sense", arguing that this topic is multi-faceted instead of a binary situation, at least until CRQCs become a commodity. Classical cryptography does not suddenly lose *all* its value once *some* well-funded institutions have access to CRQCs.
 
Looking at the composite discussion more broadly, I understand (but don't necessarily agree with) the argument that keeping classical cryptography code around poses disproportionate risks, and also that more choice brings with it the (disproportionate) downside of more fragmentation and delay. These points are especially strong if you believe ML-DSA to be rock solid.
 
What I don't get are the positions that reject the existence of nuance in the discussion (as long as you have non-trivial doubt about the security of ML-DSA).
 
Best regards,
Tim Beckmann

> Scott Fluhrer (sfluhrer) <sfluhrer=[e-mail]> hat am 23.04.2026 01:57 CEST geschrieben:
>  
>  
> Tim, you might be happy with cryptography that is sufficient against the local Wifi provider.  Some of us deal with scenarios where nation-state actors are a legitimate threat.  I believe that this working group needs to keep that in mind.
>  
> Also, attacks against authentication need not involve MITM - another approach would be an impersonation attack, which is easy if mTLS is involved.
>  
> 
> ---------------------------------------------
> From: tim.beckmann=[e-mail] <tim.beckmann=[e-mail]>
> Sent: Wednesday, April 22, 2026 6:57 PM
> To: Blumenthal, Uri - 0553 - MITLL <[e-mail]>
> Cc: [e-mail] <[e-mail]>
> Subject: [TLS] Re: Working Group Last Call for Use of ML-DSA in TLS 1.3
>  
> 
> > Blumenthal, Uri - 0553 - MITLL <[e-mail]> hat am 22.04.2026 21:52 CEST geschrieben:
> >  
> >  
> > 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. 
> > 
> How do you come to this conclusion? Do you assume that CRQCs will quickly become a cheap commodity? My current understanding of the projected developments is that quantum computers will be very expensive for the foreseeable future and that even well-financed attackers (e.g. nation-state actors) will only have a limited throughput of keys to crack. In the short term, even just keeping the capability secret might be valuable enough to severely limit its use.
>  
> Following this projection, I would assign significant probability to a scenario where only high-value keys are at risk in the near term. Most PKIs and most TLS usage *outside of the web* would then be pretty safe against quantum computing attacks. Even more so when the authentication keys are not part of a PKI at all, e.g. self-signed certificates (or raw public keys) for use in IoT/OT.
>  
> You could even make the point that authentication keys are the keys where classical cryptography will retain its value the longest, as you always need MitM attacks for compromises, which usually have a higher risk profile for the attacker.
>  
> At the very least, I'd say ECDSA will be good enough for the foreseeable future to prevent attacks from the typical local WiFi provider (coffee shop, etc.).
>  
> Of course, any discussion about hybrids/composites is moot if you believe the security of the chosen PQC to be beyond any doubt.
>  
> Best regards,
> Tim Beckmann
>