[TLS] Re: [EXT] Re: ML-DSA in TLS

Blumenthal, Uri - 0553 - MITLL writes: > You don’t really need PQ DSA until CRQC is here. At this point, > everybody seems to agree that there is time before CRQC arrives. So, > keep studying/exploring/attacking PQ DSA, and prepare code and > infrastructure to deploy it – but use ECC for now. .

[TLS] Re: [EXT] Re: ML-DSA in TLS

> To clarify, are you continuing to claim that there's "no damage possible > (at least, in the TLS context) caused by PQ DSA break", despite the > facts that (1) upgrades often take a long time and (2) attackers aren't > going to announce their secret attacks? For (1) I call it not an “upgrade” (

[TLS] Re: [EXT] Re: ML-DSA in TLS

On Mon, 25 Nov 2024 at 06:55, Blumenthal, Uri - 0553 - MITLL wrote: > > To clarify, are you continuing to claim that there's "no damage possible > > (at least, in the TLS context) caused by PQ DSA break", despite the > > facts that (1) upgrades often take a long time and (2) attackers aren't > >

[TLS] Re: [EXT] Re: ML-DSA in TLS

id-MLDSA44-Ed25519 id-MLDSA65-Ed25519 id-MLDSA87-Ed448 are SUF-CMA. Cheers, John From: tirumal reddy Date: Thursday, 28 November 2024 at 07:11 To: Ilari Liusvaara Cc: tls@ietf.org Subject: [TLS] Re: [EXT] Re: ML-DSA in TLS Hi Illari, The composite signature defined in draft-ietf-lamps-pq

[TLS] Re: [EXT] Re: ML-DSA in TLS

Hi Illari, The composite signature defined in draft-ietf-lamps-pq-composite-sigs is EUF-CMA secure and achieves weak non-separability. It aligns with the security considerations for hybrid digital signatures discussed in https://datatracker.ietf.org/doc/draft-ietf-pquip-hybrid-signature-spectrums/

[TLS] Re: [EXT] Re: ML-DSA in TLS

ple of cryptographical unsoundness. > > If you have any evidence to the contrary, please share it. If you do not > have such evidence, please apologize. > > > -Original Message- > > From: Scott Fluhrer (sfluhrer) > > Sent: Saturday, November

[TLS] Re: [EXT] Re: ML-DSA in TLS

iginal Message- > From: Scott Fluhrer (sfluhrer) > Sent: Saturday, November 23, 2024 8:46 AM > To: ilariliusva...@welho.com; tls@ietf.org > Subject: [TLS] Re: [EXT] Re: ML-DSA in TLS > > > > > -Original Message- > > From: ilariliusva...@welho.com > >

[TLS] Re: [EXT] Re: ML-DSA in TLS

> To clarify, are you continuing to claim that there's "no damage possible > (at least, in the TLS context) caused by PQ DSA break", despite the > facts that (1) upgrades often take a long time and (2) attackers aren't > going to announce their secret attacks? For (1) I call it not an “upgrade”

[TLS] Re: [EXT] Re: ML-DSA in TLS

Blumenthal, Uri - 0553 - MITLL writes: > Sorry, I can’t accept the answer you’re giving. To clarify, are you continuing to claim that there's "no damage possible (at least, in the TLS context) caused by PQ DSA break", despite the facts that (1) upgrades often take a long time and (2) attackers

[TLS] Re: [EXT] Re: ML-DSA in TLS

> [ regarding encryption vs. signatures: ] >> There’s no damage possible (at least, in the TLS context) caused by PQ >> DSA break > > Not true. I already explained what's wrong with this argument: > https://mailarchive.ietf.org/arch/msg/tls/77uUYhGJYNVQIp9heMY9bkbKbaA/ >

[TLS] Re: [EXT] Re: ML-DSA in TLS

Blumenthal, Uri - 0553 - MITLL writes: > What “probability of disaster” is acceptable to you, why, The direct financial damage caused by ransomware is generally estimated as tens of billions of dollars per year. This immediately justifies, e.g., a million-dollar investment that reduces worldwi

[TLS] Re: [EXT] Re: ML-DSA in TLS

>NSA & GCHQ say is isn’t, BSI says it is. If you read my previous mail, you know that in addition to BSI, ANSSI and Swedish NCSA all says that hybrid is an absolute MUST. Many other european government also require or recommend hybrids. I personally slightly prefer guidance from agencies that ar

[TLS] Re: [EXT] Re: ML-DSA in TLS

>> Where do you draw the line? > > Simple: require hybrids. Any upgrade from pre-quantum crypto to > post-quantum crypto is obliged to keep the pre-quantum crypto and to > use the post-quantum crypto as an extra layer of defense, rather than > removing the pre-quantum crypto. Why do you draw the

[TLS] Re: [EXT] Re: ML-DSA in TLS

+1 to what Dan says below. From: D. J. Bernstein Date: Saturday, 23 November 2024 at 16:04 To: tls@ietf.org Subject: [TLS] Re: [EXT] Re: ML-DSA in TLS Ilari Liusvaara writes: > The argument forgets that to break ECC+PQ, the attacker has to break > _either_: > a) ECC and PQ. > b

[TLS] Re: [EXT] Re: ML-DSA in TLS

Ilari Liusvaara writes: > The argument forgets that to break ECC+PQ, the attacker has to break > _either_: > a) ECC and PQ. > b) The hybrid construction. The combiner is much simpler than the PQ system. Furthermore, the main way that academics manufacture literature on combiner attacks is by hypin

[TLS] Re: [EXT] Re: ML-DSA in TLS

> -Original Message- > From: ilariliusva...@welho.com > Sent: Saturday, November 23, 2024 3:44 AM > To: tls@ietf.org > Subject: [TLS] Re: [EXT] Re: ML-DSA in TLS > > > But with signatures, the risks become substantial because: > > - Complexity. Som

[TLS] Re: [EXT] Re: ML-DSA in TLS

On Thu, Nov 21, 2024 at 08:45:14PM -, D. J. Bernstein wrote: > Blumenthal, Uri - 0553 - MITLL writes: > > Given how the two (KEM and DSA) are used, and what threats may exist > > against each of them, I think it’s perfectly fine to use PQ instead of > > ECC+PQ here. > > Hmmm. I don't see where

[TLS] Re: [EXT] Re: ML-DSA in TLS

Blumenthal, Uri - 0553 - MITLL writes: > we know enough now about the accepted PQ algorithms to be reasonably > certain that they won’t be the weakest part. Reasonably certain meaning, what, 90% certainty? What's the basis for this claim? And are you saying that a 10% chance of disaster is okay?

[TLS] Re: [EXT] Re: ML-DSA in TLS

Are you saying that you're now in favor of hybrids for encryption but not for signatures? What's the relevant difference? No, I’m still for non-hybrid PQ KEM and signatures. But I recognize (though disagreeing with) the arguments of those who want hybrid KEMs. I do not buy the arguments for hyb

[TLS] Re: [EXT] Re: ML-DSA in TLS

Blumenthal, Uri - 0553 - MITLL writes: > Given how the two (KEM and DSA) are used, and what threats may exist > against each of them, I think it’s perfectly fine to use PQ instead of > ECC+PQ here. Hmmm. I don't see where your previous anti-hybrid argument (https://groups.google.com/a/list.nist.

[TLS] Re: [EXT] Re: ML-DSA in TLS

Scott Fluhrer (sfluhrer) writes: > My real question is "why is there such push-back from such a small change?" For the same reason there would have been pushback if the KEM rollouts had done PQ instead of ECC+PQ: that would have been reckless from a security perspective. Given how the two (KEM a

[TLS] Re: [EXT] Re: ML-DSA in TLS

Hybrids are mandatory for protocols like IKEv2 over UDP to handle fragmentation (traditional key exchange followed by a PQ KEM), see https://datatracker.ietf.org/doc/draft-kampanakis-ml-kem-ikev2/. -Tiru On Sat, 16 Nov 2024 at 11:43, Watson Ladd wrote: > > > On Fri, Nov 15, 2024, 8:52 PM Andrey

[TLS] Re: [EXT] Re: ML-DSA in TLS

On Sat, 16 Nov 2024 at 10:23, Andrey Jivsov wrote: > On Fri, Nov 15, 2024 at 3:56 PM Watson Ladd wrote: > >> ... >> Why not hash based signatures? >> > > I think that the stateful ones are perfectly suited for certifications in > X.509 certs, but in the TLS handshake this has to be Sphincs+, at

[TLS] Re: [EXT] Re: ML-DSA in TLS

On Fri, Nov 15, 2024, 8:52 PM Andrey Jivsov wrote: > On Fri, Nov 15, 2024 at 3:56 PM Watson Ladd wrote: > >> ... >> Why not hash based signatures? >> > > I think that the stateful ones are perfectly suited for certifications in > X.509 certs, but in the TLS handshake this has to be Sphincs+, at

[TLS] Re: [EXT] Re: ML-DSA in TLS

On Fri, Nov 15, 2024 at 3:56 PM Watson Ladd wrote: > ... > Why not hash based signatures? > I think that the stateful ones are perfectly suited for certifications in X.509 certs, but in the TLS handshake this has to be Sphincs+, at 16.2KB per signature at the AES-192 security level. In addition

[TLS] Re: [EXT] Re: ML-DSA in TLS

On Fri, Nov 15, 2024, 3:32 PM Andrey Jivsov wrote: > Not sure I understand your point, Watson, but for the environments that > cannot tweak configuration, or otherwise effectively turn on/off > algorithms, a composite signature with a PQ and an ECC algorithm is the > most viable option. > Why no

[TLS] Re: [EXT] Re: ML-DSA in TLS

Not sure I understand your point, Watson, but for the environments that cannot tweak configuration, or otherwise effectively turn on/off algorithms, a composite signature with a PQ and an ECC algorithm is the most viable option. On Fri, Nov 15, 2024 at 3:02 PM Watson Ladd wrote: > > > On Fri, No

[TLS] Re: [EXT] Re: ML-DSA in TLS

On Fri, Nov 15, 2024, 2:59 PM Andrey Jivsov wrote: > Classic McEllice team shows that over the last 10 years lattice crypto > strength dropped as the equivalence of AES192 to AES128. Will this trend > continue? > > In some deployments there may be a need to turn on a PQ method soon, and > keep us

[TLS] Re: [EXT] Re: ML-DSA in TLS

Classic McEllice team shows that over the last 10 years lattice crypto strength dropped as the equivalence of AES192 to AES128. Will this trend continue? In some deployments there may be a need to turn on a PQ method soon, and keep using, e.g. when configurability is not an option. Also, if a chan

[TLS] Re: [EXT] Re: ML-DSA in TLS

ZjQcmQRYFpfptBannerEnd I happen to think that standalone ML-DSA in TLS is a controversial issue. And I respectfully disagree. As been pointed out already, you cannot authenticate tomorrow on somebody else yesterday’s connection. In practice, PQ authentication is not an immediate issue in