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

[D. J. Bernstein]

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

I disagree. Attackers won't tell us when they have a quantum computer,
and upgrading can take a long time.

My objection to the draft is different: the draft is taking unnecessary
risks by using PQ instead of ECC+PQ.

[ tirumal reddy writes: ]
> > The deployment timeline for new algorithms and standards is lengthy.
> Of course. But we aren’t talking about new algorithms here! Unless you
> consider ECC and/or RSA that have been in the deployed codebases for
> ages now – new?

Depending on the environment, simple one-line configuration changes can
take years to roll out even when the software is already sitting there.
Getting all TLS applications to accept PQ signatures won't be a fast
process even after the software is completely ready. If people then
learn that the PQ system is broken then getting all TLS applications to
_stop_ accepting PQ signatures won't be a fast process. This means a
long period of known vulnerability (looking at the whole ecosystem, not
just the portions that are fastest to upgrade), plus however many years
attackers are secretly exploiting the same vulnerability.

Please withdraw your claim that there's "no damage possible (at least,
in the TLS context) caused by PQ DSA break".

> if/when CTQC arrives – ECC (or any other Classic algorithm) become useless

"Concretely, think about a demo showing that spending a billion dollars
on quantum computation can break a thousand X25519 keys. Yikes! We
should be aiming for much higher security than that! We don't even want
a billion-dollar attack to be able to break _one_ key! Users who care
about the security of their data will be happy that we deployed
post-quantum cryptography. But are the users going to say 'Let's turn
off X25519 and make each session a million dollars cheaper to attack'?
I'm skeptical. I think users will need to see much cheaper attacks
before agreeing that X25519 has negligible security value."

> As for PQ algorithms maturity
  [ miscellaneous timeline statements saying nothing about attacks ]

Evaluating security risks requires looking at the attack surface,
including known attacks and avenues for further attacks. Lattices are
continuing to lose security every year; it's amazing to look back at
https://eprint.iacr.org/2010/613 estimating security 2^150 for a
proposal with lattice dimension 256.

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Blumenthal, Uri - 0553 - MITLL]

> 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” (i.e., to something new and often untested 
yet), but a “downgrade” – reverting to the “old mature and well-tested ECC 
code”. Shouldn’t take long at all. 
For (2) – why do you assume there are no secret attacks against ECC? Merely 
because you couldn’t find one, and nobody announced it yet? 
>> then don’t move to PQ DSA until either CRQC is announced
>
> That would be too late. It completely fails to address the large risk of
> quantum attacks happening before the first public attack demos, plus it
> leaves users vulnerable during the upgrade period. 
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. . . . . 







The deployment timeline for new algorithms and standards is lengthy. 

Of course. But we aren’t talking about new algorithms here! Unless you consider 
ECC and/or RSA that have been in the deployed codebases for ages now – new? 

I’m repeating my points: 

* Hybrid only make any sense for one scenario: CRQC is not available, and PQ 
algorithm used is broken via Classic attack. In all the other possibilities 
Hybrid is useless from the security point of view, and only adds unnecessary 
burden. 
* Thus, if/when CTQC arrives – ECC (or any other Classic algorithm) become 
useless, regardless of whether the PQ part is or is not broken. 
* Until CRQC arrives – one can safely use ECC (or other trusted Classic 
algorithm) for TLS signatures, and keep experimenting with and studying PQ 
algorithms to one’s heart’s content. 

Moreover, it may not always be feasible to easily tweak configurations to 
enable/disable algorithms dynamically when CRQCs become publicly known. We 
would like to also consider the potential impact of zero-day vulnerabilities, 
where exploits are discovered and used before vulnerabilities are publicly 
disclosed. Proactive preparation and deployment of hybrid signature schemes 
reduces the risk of being caught unprepared in such deployments. 

When CRQC existence becomes known – hybrids would have no place anyway. At that 
point tweaking is useless. Then, either your PQ algorithm is strong, or it is 
broken. If it is broken – you’re dead, regardless. If it is strong – the fact 
that you carried (e.g.,) an ECC signature along the PQ one, was just a waste. 

As for PQ algorithms maturity (“but can we ‘really trust’ PQ? What if…?”) – 
let’s look back at, say, ECC: 

* 1985 - invented (I probably still have the original paper by Victor Miller, 
then at IBM Research) 
* 1998 – IEEE P1363 standard 
* 1999 – NSA Suite B 
* 2012 – TLS includes ECC (note that a big holding-back factor was legal: 
Certicom held ECC patents, so many people wanted to wait until they expire in 
2015 before actually deploying ECC-using commercial code) 
* 2015 – dominance 

And now compare this with, e.g., Lattice-based crypto: 

* 1950s – mathematical study of Lattices 
* 1982 – Lenstra’s LLL algorithm to approximate lattice basis reduction 
* 1996 – NTRU concept by Hoffstein, Pipher, and Silverman 
* 1997 – proposal by Ajtai for Lattice-based PK encryption scheme 
* 2001 – NTRU cryptosystem formalized 
* 2005 – new hardness assumptions (Oded Regev), LWE 
* 2010s – Ring-LWE 
* 2022 – NSA CNSA-2.0 
* 2024 – NIST standards 

Looking at the above time-scale, Lattice-based crypto appears to be roughly 
where ECC was when the crypto-world decided “we’ve studied enough, it is 
reasonably safe now to rely on ECC”. How long until you decide “yes, we’ve 
studied RLWE enough to place our bet on it”? 









smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[tirumal reddy]

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
> > going to announce their secret attacks?
>
> For (1) I call it not an “upgrade” (i.e., to something new and often
> untested yet), but a “downgrade” – reverting to the “old mature and
> well-tested ECC code”. Shouldn’t take long at all.
>
> For (2) – why do you assume there are no secret attacks against ECC?
> Merely because you couldn’t find one, and nobody announced it yet?
>
>
> >> then don’t move to PQ DSA until either CRQC is announced
> >
> > That would be too late. It completely fails to address the large risk of
> > quantum attacks happening before the first public attack demos, plus it
> > leaves users vulnerable during the upgrade period.
>
> 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. It will also
>
The deployment timeline for new algorithms and standards is lengthy. For
instance, once an IETF specification is standardized, it typically takes
around 1.5 years for 3GPP to incorporate it into their release cycle. After
that, product teams require several months for development and testing.
Additionally, operators often adopt these updates gradually, which extends
the timeline further. Moreover, it may not always be feasible to easily
tweak configurations to enable/disable algorithms dynamically when CRQCs
become publicly known. We would like to also consider the potential impact
of zero-day vulnerabilities, where exploits are discovered and used before
vulnerabilities are publicly disclosed. Proactive preparation and
deployment of hybrid signature schemes reduces the risk of being caught
unprepared in such deployments.

-Tiru


> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[John Mattsson]

draft-ietf-lamps-pq-composite-sigs writes:

“CompositeML-DSA only achieves SUF security if both components are SUF secure, 
which is not a useful property”

I don’t understand why this would not be a useful property. I don’t like that 
IETF is standardizing EUF-CMA composites of the SUF-CMA ML-DSA. There are good 
reasons that IETF made EdDSA SUF-CMA and NIST made ML-DSA SUF-CMA. Users and 
developers are very good at shooting themselves in the foot, we should help 
them avoid that. IETF should design things assuming that the user has very 
little understanding of cryptography. Many users and developers have limited 
understanding of cryptography and typically wrongly believe all signatures are 
SUF-CMA. There have been several instances are vulnerabilities due to assuming 
that EUF-CMA.

I think IETF should only make SUF-CMA composites of ML-DSA RECOMMENDED=Y. My 
understand are that

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-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/, 
which has recently completed WGLC. If there are any objections, now is the time 
to raise them within the PQUIP and LAMPS WGs.

Cheers,
-Tiru

On Sat, 23 Nov 2024 at 14:15, Ilari Liusvaara 
mailto:ilariliusva...@welho.com>> wrote:
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 your previous anti-hybrid argument
> (https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/rL9T8mpAkMs/m/i3QKJYZbEAAJ)
> distinguishes encryption from signatures.
>
> Are you saying that you're now in favor of hybrids for encryption but
> not for signatures? What's the relevant difference?

The risks posed by the hybrid construction itself.


> On the pro-hybrid side, here's the common-sense argument again, where I
> again don't see a difference between signatures and encryption:
>
>* With ECC+PQ encryption, an attacker with a PQ break still has to
>  break the ECC encryption. This makes ECC+PQ less risky than PQ for
>  encryption.
>
>* With ECC+PQ signatures, an attacker with a PQ break still has to
>  break the ECC signatures. This makes ECC+PQ less risky than PQ for
>  signatures.

The argument forgets that to break ECC+PQ, the attacker has to break
_either_:

a) ECC and PQ.
b) The hybrid construction.

The risk from b) is very different for encryption and signatures.

With encryption, it is small risk because the constructions are simple
and quite resilient to flaws (outside memory safety) in real world.

But with signatures, the risks become substantial because:

- Complexity. Some of it to deal with known non-obvious attacks.
- Known unknown attacks.

Even just the LAMPS composite signature combiner is known to be
cryptographically unsound. Sound signature combiners are in theory
impossible (practical sound signature combiners might exist).




-Ilari

___
TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org>
To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[tirumal reddy]

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/,
which has recently completed WGLC. If there are any objections, now is the
time to raise them within the PQUIP and LAMPS WGs.

Cheers,
-Tiru

On Sat, 23 Nov 2024 at 14:15, Ilari Liusvaara 
wrote:

> 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 your previous anti-hybrid argument
> > (
> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/rL9T8mpAkMs/m/i3QKJYZbEAAJ
> )
> > distinguishes encryption from signatures.
> >
> > Are you saying that you're now in favor of hybrids for encryption but
> > not for signatures? What's the relevant difference?
>
> The risks posed by the hybrid construction itself.
>
>
> > On the pro-hybrid side, here's the common-sense argument again, where I
> > again don't see a difference between signatures and encryption:
> >
> >* With ECC+PQ encryption, an attacker with a PQ break still has to
> >  break the ECC encryption. This makes ECC+PQ less risky than PQ for
> >  encryption.
> >
> >* With ECC+PQ signatures, an attacker with a PQ break still has to
> >  break the ECC signatures. This makes ECC+PQ less risky than PQ for
> >  signatures.
>
> The argument forgets that to break ECC+PQ, the attacker has to break
> _either_:
>
> a) ECC and PQ.
> b) The hybrid construction.
>
> The risk from b) is very different for encryption and signatures.
>
> With encryption, it is small risk because the constructions are simple
> and quite resilient to flaws (outside memory safety) in real world.
>
> But with signatures, the risks become substantial because:
>
> - Complexity. Some of it to deal with known non-obvious attacks.
> - Known unknown attacks.
>
> Even just the LAMPS composite signature combiner is known to be
> cryptographically unsound. Sound signature combiners are in theory
> impossible (practical sound signature combiners might exist).
>
>
>
>
> -Ilari
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Andrey Jivsov]

If a dual signature weakens the security beyond a single given signature,
there is an attack to add a second signature, and break the first target
signature by breaking the dual signature. This should not be possible, but
that would be the analysis here: what harm does adding a second signature
bring?

On Wed, Nov 27, 2024 at 12:32 PM Scott Fluhrer (sfluhrer)  wrote:

> Ilari, you have stated that:
>
> > Even just the LAMPS composite signature combiner is known to be
> > cryptographically unsound
>
> I assume that you're talking about draft-ietf-lamps-pq-composite-sigs-03.
> If so, I must ask you to back up that statement, providing either a
> citation, or a self-evident explination.
>
> When I look at it, it would appear to me that a generating a forgery
> against a valid verifier would require either:
> - Finding a collision in the hash function
> - Generating a forgery for both ML-DSA and the classical signature
> algorithm.
>
> Given that we believe that both of the two are hard problems, it would
> appear that the system is cryptographically sound.
>
> In addition, someone could take a valid composite signature and extract
> the classical signature, creating an existential forgery for the classical
> public key.  This is not a practical concern if (as the draft recommends)
> you never use that public key in another context.  Hence, it is hard to
> consider this as an example 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 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 
> > > 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. Some of it to deal with known non-obvious attacks.
> > > - Known unknown attacks.
> > >
> > > Even just the LAMPS composite signature combiner is known to be
> > > cryptographically unsound. Sound signature combiners are in theory
> > > impossible (practical sound signature combiners might exist).
> > >
> >
> > Can you expound on that?  The composite signature combiner is "place the
> > RSA signature here, place the ML-DSA signature there, we're done".
> >
> > Given that the verifier checks both the RSA signature and the ML-DSA
> > signature, I would naively expect that any successful forgery would need
> to
> > break both.
> >
> > Could you explain what I'm missing?
> >
> >
> > ___
> > TLS mailing list -- tls@ietf.org
> > To unsubscribe send an email to tls-le...@ietf.org
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Scott Fluhrer (sfluhrer)]

Ilari, you have stated that:

> Even just the LAMPS composite signature combiner is known to be
> cryptographically unsound

I assume that you're talking about draft-ietf-lamps-pq-composite-sigs-03.  If 
so, I must ask you to back up that statement, providing either a citation, or a 
self-evident explination.

When I look at it, it would appear to me that a generating a forgery against a 
valid verifier would require either:
- Finding a collision in the hash function
- Generating a forgery for both ML-DSA and the classical signature 
algorithm.

Given that we believe that both of the two are hard problems, it would appear 
that the system is cryptographically sound.

In addition, someone could take a valid composite signature and extract the 
classical signature, creating an existential forgery for the classical public 
key.  This is not a practical concern if (as the draft recommends) you never 
use that public key in another context.  Hence, it is hard to consider this as 
an example 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 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 
> > 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. Some of it to deal with known non-obvious attacks.
> > - Known unknown attacks.
> >
> > Even just the LAMPS composite signature combiner is known to be
> > cryptographically unsound. Sound signature combiners are in theory
> > impossible (practical sound signature combiners might exist).
> >
> 
> Can you expound on that?  The composite signature combiner is "place the
> RSA signature here, place the ML-DSA signature there, we're done".
> 
> Given that the verifier checks both the RSA signature and the ML-DSA
> signature, I would naively expect that any successful forgery would need to
> break both.
> 
> Could you explain what I'm missing?
> 
> 
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Blumenthal, Uri - 0553 - MITLL]

> 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” (i.e., to something new and often untested 
yet), but a “downgrade” – reverting to the “old mature and well-tested ECC 
code”. Shouldn’t take long at all. 
For (2) – why do you assume there are no secret attacks against ECC? Merely 
because you couldn’t find one, and nobody announced it yet? 

>> then don’t move to PQ DSA until either CRQC is announced
>
> That would be too late. It completely fails to address the large risk of
> quantum attacks happening before the first public attack demos, plus it
> leaves users vulnerable during the upgrade period.


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. It will also 








smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[D. J. Bernstein]

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 aren't
going to announce their secret attacks?

> then don’t move to PQ DSA until either CRQC is announced

That would be too late. It completely fails to address the large risk of
quantum attacks happening before the first public attack demos, plus it
leaves users vulnerable during the upgrade period.

> or you’re
> certain “enough” (in whatever is your definition of “enough”) that PQ
> DSA is strong/resilient “enough”.

This criterion gives wildly different results depending on who you ask,
and in any case I don't see how it's supposed to be managing the
security risks under discussion.

NSA, for example, claims that a PQ break would be a "breakthrough" and
generally gives the impression of claiming that Dilithium has negligible
risk, meaning that this criterion would say upgrade immediately---which,
of course, is a disaster if Dilithium is actually breakable.

In the opposite direction, organizations paying attention to SIKE and
Rainbow and KyberSlash and so on would take this criterion as saying not
to deploy until the attack picture has settled down. But that's failing
to address the quantum threat.

The sensible way forward is to go ahead with PQ as an extra layer of
security on top of the existing ECC layer. Then we're _trying_ to stop
quantum attacks, while at the same time not making security _worse_ in
case of further PQ breaks.

> To (2) – what makes you think there’s no ECC attack that simply hasn’t
> been announced yet? Perhaps, your whole reliance on ECC is misplaced?

See https://cr.yp.to/papers.html#safecurves for an ECC risk analysis. I
have no idea how this is supposed to be an argument for switching from
ECC to PQ instead of from ECC to ECC+PQ.

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Blumenthal, Uri - 0553 - MITLL]

> [ 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/ 
> 


Sorry, I can’t accept the answer you’re giving. Your argument basically is 
comprised of two parts: 

1. If a PQ DSA break happens, reverting back to ECC would take time, and 
2. A PQ attack may not come to public attention (for some time?), leaving 
people with (only) PQ vulnerable. 
To (1) – then don’t move to PQ DSA until either CRQC is announced, or you’re 
certain “enough” (in whatever is your definition of “enough”) that PQ DSA is 
strong/resilient “enough”. 
To (2) – what makes you think there’s no ECC attack that simply hasn’t been 
announced yet? Perhaps, your whole reliance on ECC is misplaced? 







smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[D. J. Bernstein]

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 worldwide attack
probability by 1/1.

To be clear, I'm _not_ saying that a disaster probability of 1/1
(per million dollars invested) is acceptable. Ransomware damage is only
one part of overall attack damage, and we want security to be more
cost-effective. But this _lower bound_ on damage suffices for the
purpose at hand, namely seeing why non-hybrid deployment is reckless.

> and how do you compute it?

https://cr.yp.to/papers.html#qrcsp, "Quantifying risks in cryptographic
selection processes", is the state of the art on that topic. It finds a
currently-known-failure rate of 48% among the 69 round-1 submissions to
NIST, 25% among the submissions not broken by the end of round 1, and
36% among the submissions selected by NIST for round 2.

Btw, I didn't notice answers to my previous questions about the claim of
being "reasonably certain" in the security of "accepted PQ algorithms":
"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?"

> > > Where do you draw the line?
> > Simple: require hybrids.
> Why do you draw the line there?

I already answered this: "The point is to address the concern that an
upgrade to post-quantum crypto will be to something that's actually
breakable." I also explained what's wrong with conflating that topic
with the ECC+PQ1+PQ2 topic.

  [ 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/

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[John Mattsson]

>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 are not also signal intelligence agencies.

Cheers,
John



___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Blumenthal, Uri - 0553 - MITLL]

>> 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 line there? What “probability of disaster” is acceptable to 
you, why, and how do you compute it? 

>> I recognize (though disagreeing with) the arguments of those who want
>> hybrid KEMs. I do not buy the arguments for hybrid signatures at all.
>
> Sorry, can you please say what the relevant difference is supposed to be
> between encryption and signatures?


Sorry – my fault: I should’ve stated that in my original email. 
As was shown in the thread, there’s more than one way to skin a cat (e.g., see 
Ilari’s post). But I meant a simple and obvious practical difference in TLS 
context (and given that currently there are no known attacks, or even promising 
approaches for one, on standardized PQ algorithms): 

* If a practical attack appears in the future against a PQ KEM, an adversary 
could break/decrypt sensitive traffic recorded today and protected by that KEM 
– thus, a consideration; 
* If a practical attack appears in the future against a PQ DSA, there’s no way 
the adversary could break my signature and authenticate as me into a TLS 
session that already happened – thus, unlike the KEM case, no consideration 
whatsoever, as the risk is zero, not just negligible. 
People do argue about the likelihood of (a) an attack appearing against the 
approved NIST PQC, and (b) CRQC being built ever, or within the next 10-40 
years. But that’s a different story and a different discussion. 

> Compared to just PQ, whether for encryption or for signatures, ECC+PQ
> reduces the damage caused by PQ breaks. 
We can argue about the likelihood of damage caused by PQ KEM breaks, and 
whether it’s worth hedging against it. NSA & GCHQ say is isn’t, BSI says it is. 
There’s no damage possible (at least, in the TLS context) caused by PQ DSA 
break (see above), so there’s nothing to reduce. 







smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[John Mattsson]

+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) 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
hyping obscure security properties---whereas there are many more PQ
attack papers aiming for, and often achieving, devastating breaks.

https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.cr.yp.to%2F20240102-hybrid.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C54e98d06552f4a0d47dd08dd0bd0120f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638679710470218933%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6LgFCaILSoB5xu9f3NekoIcwMQQ3QpiVzGv2PvzRfxU%3D&reserved=0<https://blog.cr.yp.to/20240102-hybrid.html>
 includes examples of how
things could go wrong with hybrids, and compares those risks to the
risks of PQ breaks.

> The risk from b) is very different for encryption and signatures.

I agree that encryption differs from signatures in the combiner details
and in the combiner security analyses. However, in both cases we're
talking about a much smaller attack surface than the PQ system. The
possibility of combiner attacks doesn't justify exposing users to the
much bigger risk of PQ breaks.

Here's a concrete example of how arguments about combiner details are
regarding much smaller security risks than PQ breaks.

One of my objections to X-Wing is that---even if we assume that the
application specifically wants to use Kyber---reviewing the security
claims for the X-Wing construction requires checking a claimed proof of
some properties of Kyber. It's not even clear what security level is
being claimed for those specific properties, and in any case I don't
like the fact that overloaded security reviewers are being asked to do
extra work so that X-Wing can skip a trivially affordable hash call.

But it's much more challenging to review the analyses of lattice
attacks, a complicated topic where the state of the art keeps changing,
with mistakes found all the time---often mistakes that had lasted for
years. Gentry's original ideal-lattice-based STOC 2009 FHE system wasn't
broken until 2014. The "Round2" lattice-based submission to NIST wasn't
broken until 2020. The 2010 paper introducing what's now called
"FrodoKEM" estimated security 2^150 for lattice dimension 256, which
today sounds absurd. 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2024%2F739&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C54e98d06552f4a0d47dd08dd0bd0120f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638679710470238302%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=tSiqGijBbvndrxaTOdCXMoc70ND2aqb9socrn9jeRKA%3D&reserved=0<https://eprint.iacr.org/2024/739>
 exploits a 40-bit
error in NIST's evaluation of the impact of memory-access costs upon
Kyber-512 security. Et cetera. Using the cost of security review as a
predictor of failure probability says that, whatever chance there is of
the combiner failing, we have to be much more worried about Kyber.

As for impact, Shoup pointed out in 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2001%2F112&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C54e98d06552f4a0d47dd08dd0bd0120f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638679710470249773%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=aPfzudcjGlyO1wH9BrOyzLXHjUcjJi7%2F4rNAQ7ARpSQ%3D&reserved=0<https://eprint.iacr.org/2001/112>
that most protocols are fine with "benign malleability". In that
context, a combiner that simply hashes together two session keys is just
fine, and the extra goals of X-Wing don't matter. Similarly, a signature
combiner that simply concatenates two signatures is just fine for most
applications. Meanwhile a typical PQ break recovering keys is a disaster
for all of these applications.

I'm in favor of slightly more complicated combiners (Chempat for KEMs,
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fcfrg%2FLdvasJBpseekZtQkQF1nuPPDH_s%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C54e98d06552f4a0d47dd08dd0bd0120f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638679710470260551%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s

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

[D. J. Bernstein]

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
hyping obscure security properties---whereas there are many more PQ
attack papers aiming for, and often achieving, devastating breaks.

https://blog.cr.yp.to/20240102-hybrid.html includes examples of how
things could go wrong with hybrids, and compares those risks to the
risks of PQ breaks.

> The risk from b) is very different for encryption and signatures.

I agree that encryption differs from signatures in the combiner details
and in the combiner security analyses. However, in both cases we're
talking about a much smaller attack surface than the PQ system. The
possibility of combiner attacks doesn't justify exposing users to the
much bigger risk of PQ breaks.

Here's a concrete example of how arguments about combiner details are
regarding much smaller security risks than PQ breaks.

One of my objections to X-Wing is that---even if we assume that the
application specifically wants to use Kyber---reviewing the security
claims for the X-Wing construction requires checking a claimed proof of
some properties of Kyber. It's not even clear what security level is
being claimed for those specific properties, and in any case I don't
like the fact that overloaded security reviewers are being asked to do
extra work so that X-Wing can skip a trivially affordable hash call.

But it's much more challenging to review the analyses of lattice
attacks, a complicated topic where the state of the art keeps changing,
with mistakes found all the time---often mistakes that had lasted for
years. Gentry's original ideal-lattice-based STOC 2009 FHE system wasn't
broken until 2014. The "Round2" lattice-based submission to NIST wasn't
broken until 2020. The 2010 paper introducing what's now called
"FrodoKEM" estimated security 2^150 for lattice dimension 256, which
today sounds absurd. https://eprint.iacr.org/2024/739 exploits a 40-bit
error in NIST's evaluation of the impact of memory-access costs upon
Kyber-512 security. Et cetera. Using the cost of security review as a
predictor of failure probability says that, whatever chance there is of
the combiner failing, we have to be much more worried about Kyber.

As for impact, Shoup pointed out in https://eprint.iacr.org/2001/112
that most protocols are fine with "benign malleability". In that
context, a combiner that simply hashes together two session keys is just
fine, and the extra goals of X-Wing don't matter. Similarly, a signature
combiner that simply concatenates two signatures is just fine for most
applications. Meanwhile a typical PQ break recovering keys is a disaster
for all of these applications.

I'm in favor of slightly more complicated combiners (Chempat for KEMs,
https://mailarchive.ietf.org/arch/msg/cfrg/LdvasJBpseekZtQkQF1nuPPDH_s/
for signatures), in part because some cheap extra hashing occasionally
compensates for carelessness in protocol designs, and in part to fix the
verification disconnect between

   * protocol analyses assuming IND-CCA2 (and SUF-CMA and so on) and
   * simple concatenation not generically guaranteeing IND-CCA2 against
 breaks of one component.

But the impact of attacks here is not on the same scale as a PQ break
recovering keys.

> With encryption, it is small risk because the constructions are simple
> and quite resilient to flaws (outside memory safety) in real world.

Again, having a signature that internally concatenates two signatures is
simple and works fine for most applications (e.g., TLS), the same way
that having a KEM session key that internally hashes together two KEM
session keys is simple and works fine for most applications (e.g., TLS).

The more complicated combiners mentioned above are still just a few
lines of code, with much smaller attack surfaces than PQ systems, in
both the encryption case and the signature case. I don't see why one
would assign higher risks to signature combiners than to encryption
combiners. More to the point, the PQ code is much more complicated than
the combiner code, with a vastly more complicated attack story; one has
to worry correspondingly more about PQ breaks.

> But with signatures, the risks become substantial because:
> - Complexity. Some of it to deal with known non-obvious attacks.
> - Known unknown attacks.

One could use exactly the same words to claim that encryption combiners
have "substantial" risks. Arguing about "small" vs. "substantial" risks
is pointless without quantification.

> Even just the LAMPS composite signature combiner is known to be
> cryptographically unsound. Sound signature combiners are in theory
> impossible

Again, it's easy to manufacture papers hyping minor security properties.
This is not how the TLS WG should be making security decisions.

As an analogy, imagine som

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

[Scott Fluhrer (sfluhrer)]

> -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. Some of it to deal with known non-obvious attacks.
> - Known unknown attacks.
> 
> Even just the LAMPS composite signature combiner is known to be
> cryptographically unsound. Sound signature combiners are in theory
> impossible (practical sound signature combiners might exist).
> 

Can you expound on that?  The composite signature combiner is "place the RSA 
signature here, place the ML-DSA signature there, we're done".

Given that the verifier checks both the RSA signature and the ML-DSA signature, 
I would naively expect that any successful forgery would need to break both.

Could you explain what I'm missing?


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Ilari Liusvaara]

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 your previous anti-hybrid argument
> (https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/rL9T8mpAkMs/m/i3QKJYZbEAAJ)
> distinguishes encryption from signatures.
> 
> Are you saying that you're now in favor of hybrids for encryption but
> not for signatures? What's the relevant difference?

The risks posed by the hybrid construction itself.


> On the pro-hybrid side, here's the common-sense argument again, where I
> again don't see a difference between signatures and encryption:
> 
>* With ECC+PQ encryption, an attacker with a PQ break still has to
>  break the ECC encryption. This makes ECC+PQ less risky than PQ for
>  encryption.
> 
>* With ECC+PQ signatures, an attacker with a PQ break still has to
>  break the ECC signatures. This makes ECC+PQ less risky than PQ for
>  signatures.

The argument forgets that to break ECC+PQ, the attacker has to break
_either_:

a) ECC and PQ.
b) The hybrid construction.

The risk from b) is very different for encryption and signatures.

With encryption, it is small risk because the constructions are simple
and quite resilient to flaws (outside memory safety) in real world.

But with signatures, the risks become substantial because:

- Complexity. Some of it to deal with known non-obvious attacks.
- Known unknown attacks.

Even just the LAMPS composite signature combiner is known to be
cryptographically unsound. Sound signature combiners are in theory
impossible (practical sound signature combiners might exist).




-Ilari

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[D. J. Bernstein]

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?

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

This requirement distinguishes "switch from ECC to Dilithium in TLS"
(not allowed) from "switch from ECC to ECC+Dilithium in TLS" (allowed),
for example.

The point is to address the concern that an upgrade to post-quantum
crypto will be to something that's actually breakable. This isn't a
hypothetical concern. On the mathematical side, CECPQ2b was rolled out
with ECC+SIKE, and then the SIKE part was publicly broken; on the
implementation side, PQ software is still in the early days of continual
discovery of exciting new classes of security failures.

Directly addressing this concern reduces security risks and encourages
deployment. That's exactly why we see so much hybrid deployment already.
People understand and appreciate the idea of (1) rolling something out
that _hopefully_ stops quantum attacks while (2) taking reasonable steps
to limit the damage in case #1 goes disastrously wrong.

There are contrary arguments from NSA and GCHQ for using PQ rather than
ECC+PQ. https://blog.cr.yp.to/20240102-hybrid.html quotes and answers
those arguments. For example, the generic argument about ECC+PQ being
"less efficient" than PQ is easily answered by quantification of how the
total ECC+PQ costs are dominated by the PQ communication costs.

If, hypothetically, someone proposes requiring ECC+PQ1+PQ2 rather than
ECC+PQ1, then I'd ask for that proposal to be addressed separately since
analyzing its cost acceptability is much more complicated. See also
https://mailarchive.ietf.org/arch/msg/tls/2bRwN2CUGDwDwwpjHI63uyG09Lk/
regarding the idea of making exceptions to ECC+PQ for some PQ systems.
These variations are distractions from the simple common-sense step of
requiring hybrids.

I've seen various comments that come across as "yes, of course we should
use hybrids, but the U.S. government won't buy hybrids". I'm skeptical
about the accuracy of the won't-buy rumor---NSA's official statements
don't sound like a ban on hybrids---and in any case we shouldn't allow
money to buy approval of something frivolously incurring security risks.

Realistically, what's the problem supposed to be if the TLS WG requires
hybrids? Do we really think the WG is so powerless?

> I recognize (though disagreeing with) the arguments of those who want
> hybrid KEMs. I do not buy the arguments for hybrid signatures at all.

Sorry, can you please say what the relevant difference is supposed to be
between encryption and signatures?

Compared to just PQ, whether for encryption or for signatures, ECC+PQ
reduces the damage caused by PQ breaks. Quantifying costs of ECC vs. PQ
doesn't give the same numbers for encryption as it does for signatures,
but in both cases the total costs of communication and computation for
ECC are much smaller than the costs of PQ communication.

> This boils down to the need to maintain infrastructure, codebase, etc.
> for ECC and PQ,

Pointing to the PQ software is wrong when the comparison is between PQ
and ECC+PQ. The difference is only the ECC software, which is simpler
and vastly more mature than the PQ software.

> plus the possible intricacies of their interactions

The only ECC+PQ failures that matter are the ones so extreme that they
make ECC+PQ _less_ secure than PQ alone would have been.

Sure, this can happen: e.g., a quantum computer comes along and then it
turns out that someone forgot to verify the PQ part of an ECC+PQ
signature. So we build tests for that. The risks here are much more
controlled than the risks of further PQ breaks.

It makes no sense to worry more about failures in the combiner code than
in orders of magnitude more code for the PQ system. Analogous comments
apply to mathematical attacks: sure, combiners have an attack surface,
but the PQ attack surface is much larger.

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Blumenthal, Uri - 0553 - MITLL]

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 hybrid signatures at all. 
On the pro-hybrid side, here's the common-sense argument again, where I
again don't see a difference between signatures and encryption:

* With ECC+PQ encryption, an attacker with a PQ break still has to
break the ECC encryption. This makes ECC+PQ less risky than PQ for
encryption. 
And adding another KEM based on a different math concept, e.g., code-based – 
would decrease the risk even more. So, why not ECC+Kyber+McEliece? Where do you 
draw the line? I draw it on PQ itself, willing to put my eggs into the Lattice 
basket. 
* With ECC+PQ signatures, an attacker with a PQ break still has to
break the ECC signatures. This makes ECC+PQ less risky than PQ for
signatures. 
This boils down to the need to maintain infrastructure, codebase, etc. for ECC 
and PQ, plus the possible intricacies of their interactions – vs. the concern 
that the PQ part would fail while the ECC part would not . One line of thought 
says “the longer it’s been around – the less likely it is to fail, so ECC will 
last at least until CRQC”. Another view is – “ECC has been around for so long 
that there’s bound to be a breakthrough”. 
In short, you strengthened my conviction that hybrid KEMs don’t make practical 
sense (diminishing returns), because we know enough now about the accepted PQ 
algorithms to be reasonably certain that they won’t be the weakest part. 
As I understand, that’s the position that GCHQ and NSA took – unless you really 
believe that they secretly aim to weaken the crypto used by US and GB military 
& (especially) civilian government departments/organizations. 

See also https://blog.cr.yp.to/20240102-hybrid.html 
 for a more detailed
analysis, again covering both cases. Of course, the concrete examples
(such as SIKE) vary between signatures and encryption. 
I did. For how long has SIKE been around? Compared to, e.g., NTRU? How many 
Classic PKC systems came up and got broken? 







smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[D. J. Bernstein]

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.gov/g/pqc-forum/c/rL9T8mpAkMs/m/i3QKJYZbEAAJ)
distinguishes encryption from signatures.

Are you saying that you're now in favor of hybrids for encryption but
not for signatures? What's the relevant difference?

On the pro-hybrid side, here's the common-sense argument again, where I
again don't see a difference between signatures and encryption:

   * With ECC+PQ encryption, an attacker with a PQ break still has to
 break the ECC encryption. This makes ECC+PQ less risky than PQ for
 encryption.

   * With ECC+PQ signatures, an attacker with a PQ break still has to
 break the ECC signatures. This makes ECC+PQ less risky than PQ for
 signatures.

See also https://blog.cr.yp.to/20240102-hybrid.html for a more detailed
analysis, again covering both cases. Of course, the concrete examples
(such as SIKE) vary between signatures and encryption.

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Blumenthal, Uri - 0553 - MITLL]

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 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. 
> however if we believe that ML-DSA has a real security vulnerability,
> we ought to abandon it entirely

We're not talking about the extreme case of deploying something today
that has already been broken. We're talking about managing _risks_ of
_future_ attacks. 
My crystal ball says that ECC will get broken before PQ, at least in case of 
ML-DSA. 







smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[tirumal reddy]

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 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 16.2KB
>> per signature at the AES-192 security level. In addition to size concerns,
>> it's not allowed in CNSA 2.0. Are vendors considering SPHINCS+ for this
>> purpose?
>>
>
> If CNSA 2.0 is the guide why consider hybrids?
>
>> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[tirumal reddy]

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 16.2KB
> per signature at the AES-192 security level. In addition to size concerns,
> it's not allowed in CNSA 2.0. Are vendors considering SPHINCS+ for this
> purpose?
>

Yes, we are considering SPHINCS+ for long-lived TLS sessions in telco
deployments for interfaces where computational costs of signature
generation and validation are minor compared to data transmission and
processing demands of user data. The findings in Amazon

paper

shows that while PQ algorithms increase the TLS 1.3 handshake data size,
their effect on connection performance is minimal for large data transfers,
especially in low-loss networks.

-Tiru


> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Watson Ladd]

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 16.2KB
> per signature at the AES-192 security level. In addition to size concerns,
> it's not allowed in CNSA 2.0. Are vendors considering SPHINCS+ for this
> purpose?
>

If CNSA 2.0 is the guide why consider hybrids?

>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Andrey Jivsov]

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 to size concerns,
it's not allowed in CNSA 2.0. Are vendors considering SPHINCS+ for this
purpose?
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Watson Ladd]

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 not hash based signatures?

>
> On Fri, Nov 15, 2024 at 3:02 PM Watson Ladd  wrote:
>
>>
>>
>> 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 using, e.g. when configurability is not an option. Also, if a change
>>> in configuration is possible at a later time to enable a PQ method, ECC may
>>> still be secure.
>>>
>>> Overall, I think it is safer to deploy a hybrid solution as the main
>>> option, and either enable it soon, or later.
>>>
>>
>> If you don't want to depend on being able to switch there is one
>> signature algorithm secure if any of the candidates are.
>>
>>
>>> On Fri, Nov 15, 2024 at 11:46 AM Blumenthal, Uri - 0553 - MITLL <
>>> u...@ll.mit.edu> wrote:
>>>
 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 a sense of
 "record now, decrypt later".



 Exactly. Except that my conclusion from this is – no hybrid is
 necessary. Either move to PQ, or remain with Classic and keep
 observing/studying PQ.



 There is also an issue of what signatures in X.509 certs will look
 like. Especially in CA certificates, these may favor ML-DSA+ECC v.s.
 ML-DSA, so there would need to be support by TLS stack for the hybrid for
 that reason.



 This all is based on the assumption that ML-DSA would fail, but ECC
 won’t. I find this highly improbable.

>>> ___
>>> TLS mailing list -- tls@ietf.org
>>> To unsubscribe send an email to tls-le...@ietf.org
>>>
>>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Andrey Jivsov]

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, 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 using, e.g. when configurability is not an option. Also, if a change
>> in configuration is possible at a later time to enable a PQ method, ECC may
>> still be secure.
>>
>> Overall, I think it is safer to deploy a hybrid solution as the main
>> option, and either enable it soon, or later.
>>
>
> If you don't want to depend on being able to switch there is one signature
> algorithm secure if any of the candidates are.
>
>
>> On Fri, Nov 15, 2024 at 11:46 AM Blumenthal, Uri - 0553 - MITLL <
>> u...@ll.mit.edu> wrote:
>>
>>> 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 a sense of
>>> "record now, decrypt later".
>>>
>>>
>>>
>>> Exactly. Except that my conclusion from this is – no hybrid is
>>> necessary. Either move to PQ, or remain with Classic and keep
>>> observing/studying PQ.
>>>
>>>
>>>
>>> There is also an issue of what signatures in X.509 certs will look like.
>>> Especially in CA certificates, these may favor ML-DSA+ECC v.s. ML-DSA, so
>>> there would need to be support by TLS stack for the hybrid for that reason.
>>>
>>>
>>>
>>> This all is based on the assumption that ML-DSA would fail, but ECC
>>> won’t. I find this highly improbable.
>>>
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Watson Ladd]

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 using, e.g. when configurability is not an option. Also, if a change
> in configuration is possible at a later time to enable a PQ method, ECC may
> still be secure.
>
> Overall, I think it is safer to deploy a hybrid solution as the main
> option, and either enable it soon, or later.
>

If you don't want to depend on being able to switch there is one signature
algorithm secure if any of the candidates are.


> On Fri, Nov 15, 2024 at 11:46 AM Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
>
>> 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 a sense of
>> "record now, decrypt later".
>>
>>
>>
>> Exactly. Except that my conclusion from this is – no hybrid is necessary.
>> Either move to PQ, or remain with Classic and keep observing/studying PQ.
>>
>>
>>
>> There is also an issue of what signatures in X.509 certs will look like.
>> Especially in CA certificates, these may favor ML-DSA+ECC v.s. ML-DSA, so
>> there would need to be support by TLS stack for the hybrid for that reason.
>>
>>
>>
>> This all is based on the assumption that ML-DSA would fail, but ECC
>> won’t. I find this highly improbable.
>>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Andrey Jivsov]

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 change
in configuration is possible at a later time to enable a PQ method, ECC may
still be secure.

Overall, I think it is safer to deploy a hybrid solution as the main
option, and either enable it soon, or later.

On Fri, Nov 15, 2024 at 11:46 AM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> 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 a sense of
> "record now, decrypt later".
>
>
>
> Exactly. Except that my conclusion from this is – no hybrid is necessary.
> Either move to PQ, or remain with Classic and keep observing/studying PQ.
>
>
>
> There is also an issue of what signatures in X.509 certs will look like.
> Especially in CA certificates, these may favor ML-DSA+ECC v.s. ML-DSA, so
> there would need to be support by TLS stack for the hybrid for that reason.
>
>
>
> This all is based on the assumption that ML-DSA would fail, but ECC won’t.
> I find this highly improbable.
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Blumenthal, Uri - 0553 - MITLL]

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 a sense of "record 
now, decrypt later". 

Exactly. Except that my conclusion from this is – no hybrid is necessary. 
Either move to PQ, or remain with Classic and keep observing/studying PQ. 


There is also an issue of what signatures in X.509 certs will look like. 
Especially in CA certificates, these may favor ML-DSA+ECC v.s. ML-DSA, so there 
would need to be support by TLS stack for the hybrid for that reason. 

This all is based on the assumption that ML-DSA would fail, but ECC won’t. I 
find this highly improbable. 








smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org