[TLS]Re: Curve-popularity data?

[Hubert Kario]

On Wednesday, 12 June 2024 02:02:41 CEST, D. J. Bernstein wrote:

There will be an annoyingly large number of options on the PQ side---for
example, for different security levels and for patent avoidance---and
I'd expect a tricky discussion of which options to recommend for TLS.

I'm not sure I buy this premise. Currently there seems to be an
overwhelming convergence on ML-KEM768 for this job, with the one exception
being ML-KEM1024 being favored by the CNSA 2, but the latter also does not
recommend hybrids, leaving us with really only one choice for 
the PQ hybrid

for at least the medium term.


Within ML-KEM, NSA isn't just favoring 1024, but _forbidding_ sizes
below 1024:

   
https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/1/CSI_CNSA_2.0_FAQ_.PDF


The document doesn't forbid hybrids; on the contrary, it states that
"NSA may allow or require hybrid solutions due to protocol standards,
product availability, or interoperability requirements".

So there isn't a clear dividing line between what NSA is doing and what
the TLS WG will end up considering. Other people have already brought up
NSA's ML-KEM requirements in TLS discussions, and people who don't think
NSA should have control over IETF can still understand NSA's position as
communicating security concerns relevant to TLS decisions. This by
itself looks to me like a much more tricky discussion than any TLS curve
discussions!


while yes, the only people that will want ML-KEM-1024 are the ones that 
will

want to follow CNSA 2.0, and those people are likely already following
CNSA 1.0 (or Common Criteria), so use P-384.

So, for the defined groups, if we provide P-256+ML-KEM-768 and
P-384+ML-KEM-1024 it should cover all the bases for FIPS and (likely even
future) Common Criteria requirements.


Apple has rolled out ML-KEM-1024 in another protocol:

   https://security.apple.com/blog/imessage-pq3/

Meanwhile Meta says, regarding TLS, that they're rolling out ML-KEM-768
and, for performance reasons (TFO packet size), also ML-KEM-512:

   
https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/


Sounds like big deployments of all three ML-KEM sizes already (times
different Kyber versions, but let's assume all the different versions
switch to the final version of ML-KEM after NIST posts that, which
should happen any day now), and at least some of the underlying
rationales are certainly applicable to TLS.


yes, the question is if we want to pair P-256 with ML-KEM-512 or with
ML-KEM-768 for the "FIPS compatible fast option" hybrid key exchange group.

I don't have a strong opinion either way.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

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

[TLS]Re: Curve-popularity data?

[D. J. Bernstein]

> > There will be an annoyingly large number of options on the PQ side---for
> > example, for different security levels and for patent avoidance---and
> > I'd expect a tricky discussion of which options to recommend for TLS.
> I'm not sure I buy this premise. Currently there seems to be an
> overwhelming convergence on ML-KEM768 for this job, with the one exception
> being ML-KEM1024 being favored by the CNSA 2, but the latter also does not
> recommend hybrids, leaving us with really only one choice for the PQ hybrid
> for at least the medium term.

Within ML-KEM, NSA isn't just favoring 1024, but _forbidding_ sizes
below 1024:

   
https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/1/CSI_CNSA_2.0_FAQ_.PDF

The document doesn't forbid hybrids; on the contrary, it states that
"NSA may allow or require hybrid solutions due to protocol standards,
product availability, or interoperability requirements".

So there isn't a clear dividing line between what NSA is doing and what
the TLS WG will end up considering. Other people have already brought up
NSA's ML-KEM requirements in TLS discussions, and people who don't think
NSA should have control over IETF can still understand NSA's position as
communicating security concerns relevant to TLS decisions. This by
itself looks to me like a much more tricky discussion than any TLS curve
discussions!

Apple has rolled out ML-KEM-1024 in another protocol:

   https://security.apple.com/blog/imessage-pq3/

Meanwhile Meta says, regarding TLS, that they're rolling out ML-KEM-768
and, for performance reasons (TFO packet size), also ML-KEM-512:

   
https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/

Sounds like big deployments of all three ML-KEM sizes already (times
different Kyber versions, but let's assume all the different versions
switch to the final version of ML-KEM after NIST posts that, which
should happen any day now), and at least some of the underlying
rationales are certainly applicable to TLS.

As for the patent problem, one can _hope_ that Yunlei Zhao is wrong in
writing "Kyber is covered by our patents" in

   
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Fm4cDfsx65s/m/F63mixuWBAAJ

but I haven't seen any public analysis of, e.g., their patent

   https://patents.google.com/patent/CN107566121A/en

concluding that Kyber _isn't_ actually covered, never mind the question
of how convincing such a public analysis would be. This is just one
example of the patent minefield.

> If the only reason for revisiting the current choices in recommended curves
> is an expected large number of PQ options (or even just more than one PQ
> option), it might make sense to have that discussion first.

The PQ security issues, performance issues, further software issues, and
patent issues look much more complicated than the curve issues, and
include various issues that I'd expect to be resolved in CFRG. It's
clear that a big wave of specific PQ proposals is coming to the TLS WG
soon; this doesn't mean the wave is here yet, beyond some initial work
such as draft-ietf-tls-hybrid-design.

The curve situation is different. There's lots of experience now with
the interactions between curve choices and TLS software (and hardware).
The TLS WG doesn't have curve questions for CFRG. So the TLS WG can
settle now what it's going to look for on the curve side of PQ hybrids.

---D. J. Bernstein

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

[TLS]Re: Curve-popularity data?

[Sophie Schmieg]

> There will be an annoyingly large number of options on the PQ side---for
> example, for different security levels and for patent avoidance---and
> I'd expect a tricky discussion of which options to recommend for TLS.

I'm not sure I buy this premise. Currently there seems to be an
overwhelming convergence on ML-KEM768 for this job, with the one exception
being ML-KEM1024 being favored by the CNSA 2, but the latter also does not
recommend hybrids, leaving us with really only one choice for the PQ hybrid
for at least the medium term.
If the only reason for revisiting the current choices in recommended curves
is an expected large number of PQ options (or even just more than one PQ
option), it might make sense to have that discussion first.

Where I do see some potential contention is on the question on whether to
adopt a primitive level hybrid (such as X-Wing or the generic combiner
draft) or use a protocol level hybrid (such as X25519Kyber768Draft00), but
this question is independent of the choice of classic or PQ algorithm (with
the slight exception of X-Wing, which people have criticized for not
allowing for FIPS compliant deployment before ML-KEM has become FIPSified
due to the lack of P256, but the discussion here seems not about
discouraging the use of X25519 in favor of P256 in general, so this too is
orthogonal to the problem at hand). All in all, I see little reason to
change the recommendations for the elliptic curve part for a PQ hybrid from
what they are now for classical cryptography.

On Mon, Jun 10, 2024 at 5:46 AM John Mattsson  wrote:

> Thanks Björn,
>
>
>
> I think that is a very good summary. Regarding security requirements for
> ephemeral key exchange in TLS I think it is important to discuss that we
> are actually talking about 3 quite different settings.
>
>
>1. Ephemeral key exchange authenticated with a certificate.
>2. Ephemeral key exchange authenticated with an external PSK.
>3. Ephemeral key exchange authenticated with a resumption PSK.
>
>
>
> In 1, the ephemeral key exchange is the only secret input to the Key
> derivation.
>
> In 2, the external PSK, which might have a lifetime of decades is also
> used in the key derivation.
>
> In 3, the resumption PSK, which has a lifetime of maximum a week is also
> used in the key derivation.
>
> I think the security requirements for 1. and 3. might be quite different.
>
>
>
> Cheers,
>
> John Preuß Mattsson
>
>
>
> *From: *Björn Haase 
> *Date: *Monday, 10 June 2024 at 09:32
> *To: *tls@ietf.org 
> *Subject: *[TLS]Re: Curve-popularity data?
>
> [You don't often get email from bjoern.haase=40endress@dmarc.ietf.org.
> Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Hello to all,
>
> I fear that regarding the "Curve-popularity" data there might be too much
> of "opinion" and "company policies" and "government policies" around which
> IMHO can be an obstacle for constructive discussion. And it seems again to
> be a discussion between Short-Weierstrass curves on the one side and the
> modern Montgomery/Edwards curves on the other side.
>
> I think that for getting forward, we probably best try to get a step back
> and try to formulate consensus on the actual requirements behind the
> reasonings and establish a clearer picture regarding the system
> architectures that people have in mind.
>
> In my perspective, the "security" space at least has at least 4 dimensions
> relevant here:
>
> - Firstly, the biggest security risk might be that no or worse crypto is
> used in an application (e.g. no ephemeral session keys instead of
> session-specific DH) because DH is considered to be too costly.
>
> - The second dimension might be that crypto is poorly implemented and
> implementation attacks become feasible.
>
> - The third dimension is the risk of hardware-side-channels and the risk
> of leaked private long-term keys. IMO this issue can only be resolved when
> using special hardware components for guarding and protecting the private
> keys and mandatory requires secure elements.
>
> - The fourth dimension is the fear regarding future QC attacks.
>
>
> In addition to these dimensions I believe that we need to consider where
> applications need to store their keys. For ephemeral session-key-related
> secrets I don't see the immediate use-case of storing the private keys in a
> secured hardware (TPM or Secure element). However this (IMHO) should really
> be different for all of the private long-term keys used for authenticating
> a session (e.g. server certificates). IMO its not only the fact that
> hardware elements can better protect the keys but good use of
> hardware-chips for authenticatio

[TLS]Re: Curve-popularity data?

[John Mattsson]

Thanks Björn,

I think that is a very good summary. Regarding security requirements for 
ephemeral key exchange in TLS I think it is important to discuss that we are 
actually talking about 3 quite different settings.


  1.  Ephemeral key exchange authenticated with a certificate.
  2.  Ephemeral key exchange authenticated with an external PSK.
  3.  Ephemeral key exchange authenticated with a resumption PSK.

In 1, the ephemeral key exchange is the only secret input to the Key derivation.
In 2, the external PSK, which might have a lifetime of decades is also used in 
the key derivation.
In 3, the resumption PSK, which has a lifetime of maximum a week is also used 
in the key derivation.

I think the security requirements for 1. and 3. might be quite different.

Cheers,
John Preuß Mattsson

From: Björn Haase 
Date: Monday, 10 June 2024 at 09:32
To: tls@ietf.org 
Subject: [TLS]Re: Curve-popularity data?
[You don't often get email from bjoern.haase=40endress@dmarc.ietf.org. 
Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Hello to all,

I fear that regarding the "Curve-popularity" data there might be too much of 
"opinion" and "company policies" and "government policies" around which IMHO 
can be an obstacle for constructive discussion. And it seems again to be a 
discussion between Short-Weierstrass curves on the one side and the modern 
Montgomery/Edwards curves on the other side.

I think that for getting forward, we probably best try to get a step back and 
try to formulate consensus on the actual requirements behind the reasonings and 
establish a clearer picture regarding the system architectures that people have 
in mind.

In my perspective, the "security" space at least has at least 4 dimensions 
relevant here:

- Firstly, the biggest security risk might be that no or worse crypto is used 
in an application (e.g. no ephemeral session keys instead of session-specific 
DH) because DH is considered to be too costly.

- The second dimension might be that crypto is poorly implemented and 
implementation attacks become feasible.

- The third dimension is the risk of hardware-side-channels and the risk of 
leaked private long-term keys. IMO this issue can only be resolved when using 
special hardware components for guarding and protecting the private keys and 
mandatory requires secure elements.

- The fourth dimension is the fear regarding future QC attacks.


In addition to these dimensions I believe that we need to consider where 
applications need to store their keys. For ephemeral session-key-related 
secrets I don't see the immediate use-case of storing the private keys in a 
secured hardware (TPM or Secure element). However this (IMHO) should really be 
different for all of the private long-term keys used for authenticating a 
session (e.g. server certificates). IMO its not only the fact that hardware 
elements can better protect the keys but good use of hardware-chips for 
authentication secrets also avoid slopply management of keys!

Regarding curve popularity (unfortunately) most chipsets that offer hardware 
protection are using short-Weierstrass curves, however there are also newer 
chipsets which also support Ed25519 or Ed448 but that's currently not the 
majority. However this reasoning should (IMO) apply only to the authentication 
part of TLS and not regarding the session-key establishment (and DH).

Actually in my opinion it is only the third dimension mentioned above in 
combination with today's restriction regarding secure-element chipsets from 
which an advantage for P-256 or P-384 shows up.


In my system picture, we might best optimize future TLS for a distributed 
architecture with one or two CPUs for the crypto. One CPU A which manages the 
session-key establishment and bulk crypto (the main CPU of the system) and a 
second CPU B which handles the protocol parts for authentication which might 
come with hardware-level-security and a protected persistent storage for keys 
(possibly split off to a TPM or Secure element).

As a result, I would suggest that regarding key-establishment one might be 
better off with promoting the newer and more efficient X25519 and X448 in 
combination with PQ-Algorithms for the CPU A part as this might optimize for 
the dimensions 1,2 and 4.

Regarding the algorithms for the CPU B part, we probably should try to split 
off the algorithm requirements and run a separate assessment. The better 
current support for hardware-security for key storage which is a big plus for 
P-256 today for the CPU B parts.

A big part of the discussion here might be that different people have different 
system architectures in mind.

Yours,

Björn.




Mit freundlichen Grüßen | Best Regards

Dr. Björn Haase


Senior Expert Electronics | TGREH Electronics Hardware

Endress+Hauser Liquid Analysis

Endress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839 Gerlingen | 
Germany
Phone: +49

[TLS]Re: Curve-popularity data?

[Hubert Kario]

On Saturday, 8 June 2024 03:53:16 CEST, D. J. Bernstein wrote:

Eric Rescorla writes:

It's important to distinguish between two senses of the word "recommend".


I'd expect the first wave of proposals to be asking the WG to say
Recommended=Y for various curve+PQ hybrids.

There will be an annoyingly large number of options on the PQ side---for
example, for different security levels and for patent avoidance---and
I'd expect a tricky discussion of which options to recommend for TLS.

I don't think it's a good idea to wait until then to figure out the
curve side. I'd like us to simplify the curve side by focusing on
X25519+PQ, just like most (I'm not saying all!) post-quantum hybrids so
far. This means saying no to brainpoolP256*+PQ, SM2+PQ, P-256+PQ, etc.


Just like we can live with Recommend=Y both for secp256r1 and x25519
(and also for secp384r1 and x448), we can live with Recommend=Y
for both P-256+PQ and x25519+PQ.

See the note above the IANA listing:

```
If an item is not marked as "Recommended", it does not
necessarily mean that it is flawed; rather, it indicates that
the item either has not been through the IETF consensus process,
has limited applicability, or is intended only for specific use
cases.
```

P-256 and P-384 have extensive applicability and are not limited just to
the specific use of of US governmental systems.

Or to put it other way, while most clients will likely include x25519+PQ
in their key_share over anything else, omitting P-256+PQ from the
supported_groups is likely to cause interoperability issues.
Thus, that combination should be Recommend=Y. (and to hammer the point
further: X448 is Recommend=Y, and basically nobody is including that
group in key_share, we need P-256+PQ at the same place)

--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

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

[TLS]Re: Curve-popularity data?

[Björn Haase]

Hello to all,

I fear that regarding the "Curve-popularity" data there might be too much of 
"opinion" and "company policies" and "government policies" around which IMHO 
can be an obstacle for constructive discussion. And it seems again to be a 
discussion between Short-Weierstrass curves on the one side and the modern 
Montgomery/Edwards curves on the other side.

I think that for getting forward, we probably best try to get a step back and 
try to formulate consensus on the actual requirements behind the reasonings and 
establish a clearer picture regarding the system architectures that people have 
in mind.

In my perspective, the "security" space at least has at least 4 dimensions 
relevant here:

- Firstly, the biggest security risk might be that no or worse crypto is used 
in an application (e.g. no ephemeral session keys instead of session-specific 
DH) because DH is considered to be too costly.

- The second dimension might be that crypto is poorly implemented and 
implementation attacks become feasible.

- The third dimension is the risk of hardware-side-channels and the risk of 
leaked private long-term keys. IMO this issue can only be resolved when using 
special hardware components for guarding and protecting the private keys and 
mandatory requires secure elements.

- The fourth dimension is the fear regarding future QC attacks.


In addition to these dimensions I believe that we need to consider where 
applications need to store their keys. For ephemeral session-key-related 
secrets I don't see the immediate use-case of storing the private keys in a 
secured hardware (TPM or Secure element). However this (IMHO) should really be 
different for all of the private long-term keys used for authenticating a 
session (e.g. server certificates). IMO its not only the fact that hardware 
elements can better protect the keys but good use of hardware-chips for 
authentication secrets also avoid slopply management of keys!

Regarding curve popularity (unfortunately) most chipsets that offer hardware 
protection are using short-Weierstrass curves, however there are also newer 
chipsets which also support Ed25519 or Ed448 but that's currently not the 
majority. However this reasoning should (IMO) apply only to the authentication 
part of TLS and not regarding the session-key establishment (and DH).

Actually in my opinion it is only the third dimension mentioned above in 
combination with today's restriction regarding secure-element chipsets from 
which an advantage for P-256 or P-384 shows up.


In my system picture, we might best optimize future TLS for a distributed 
architecture with one or two CPUs for the crypto. One CPU A which manages the 
session-key establishment and bulk crypto (the main CPU of the system) and a 
second CPU B which handles the protocol parts for authentication which might 
come with hardware-level-security and a protected persistent storage for keys 
(possibly split off to a TPM or Secure element).

As a result, I would suggest that regarding key-establishment one might be 
better off with promoting the newer and more efficient X25519 and X448 in 
combination with PQ-Algorithms for the CPU A part as this might optimize for 
the dimensions 1,2 and 4. 

Regarding the algorithms for the CPU B part, we probably should try to split 
off the algorithm requirements and run a separate assessment. The better 
current support for hardware-security for key storage which is a big plus for 
P-256 today for the CPU B parts.

A big part of the discussion here might be that different people have different 
system architectures in mind. 

Yours,

Björn.




Mit freundlichen Grüßen | Best Regards 

Dr. Björn Haase 


Senior Expert Electronics | TGREH Electronics Hardware

Endress+Hauser Liquid Analysis

Endress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839 Gerlingen | 
Germany
Phone: +49 7156 209 10377
bjoern.ha...@endress.com |  www.ehla.endress.com 



Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

 
Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, 
wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis 
(https://www.endress.com/de/cookies-endress+hauser-website) nach.

 

Disclaimer: 

The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential, proprietary, and/or privileged 
material. Any review, retransmission, dissemination or other use of, or taking 
of any action in reliance upon, this information by persons or entities other 
than the intended recipient is prohibited. If you receive this in error, please 
contact the sender and delete the material from any computer. This 

[TLS]Re: Curve-popularity data?

[Peter Gutmann]

Dennis Jackson  writes:

>The recently adopted Key Share Prediction draft [1] allows servers to signal
>which key shares they'd like to see.

Sure, but that both assumes you've got DNS in operation and that client and
server will go through the DNS backchannel to set up TLS parameters before
trying to connect.

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

[TLS]Re: Curve-popularity data?

[Dennis Jackson]

On 08/06/2024 11:07, Peter Gutmann wrote:

when the dominant platform only offers 25519 then the the only option 
you have (unless you want to do the HRR dance) is to select that, 
whether you want it or not.


The recently adopted Key Share Prediction draft [1] allows servers to 
signal which key shares they'd like to see.


[1] 
https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Peter Gutmann]

Robert Relyea  writes:

>I will also point out that even though x25519 is 'only' SHOULD, it's the most
>selected option, while p256 is the most 'available' (by a small margin).

See my previous comment on the likely dubious validity of this data, when the
dominant platform only offers 25519 then the the only option you have (unless
you want to do the HRR dance) is to select that, whether you want it or not.

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

[TLS]Re: Curve-popularity data?

[D. J. Bernstein]

Eric Rescorla writes:
> It's important to distinguish between two senses of the word "recommend".

I'd expect the first wave of proposals to be asking the WG to say
Recommended=Y for various curve+PQ hybrids.

There will be an annoyingly large number of options on the PQ side---for
example, for different security levels and for patent avoidance---and
I'd expect a tricky discussion of which options to recommend for TLS.

I don't think it's a good idea to wait until then to figure out the
curve side. I'd like us to simplify the curve side by focusing on
X25519+PQ, just like most (I'm not saying all!) post-quantum hybrids so
far. This means saying no to brainpoolP256*+PQ, SM2+PQ, P-256+PQ, etc.

(Yes, people can register whatever they want and use it if client and
server agree, but it's reasonable to presume that Recommended=Y makes a
difference---otherwise, why is IETF maintaining that list?)

There have been other comments instead aiming for focusing on P-256.
That's a big enough split that making progress obviously requires
understanding the reasons for the divergence. The underlying rationales
raise interesting factual questions, and continued fact-finding by the
WG is a productive way forward.

---D. J. Bernstein

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

[TLS]Re: Curve-popularity data?

[Robert Relyea]

On 6/7/24 2:36 PM, Eric Rescorla wrote:



On Fri, Jun 7, 2024 at 11:41 AM D. J. Bernstein  wrote:

Eric Rescorla writes:
> I'm struggling to understand what people think is at stake here.

The WG will soon be faced with decisions regarding which curve+PQ
hybrids to recommend for TLS.


It's important to distinguish between two senses of the word "recommend".

- Is marked "Recommended=Y" in the registry.
- Having the RFC say that you SHOULD/MUST support an algorithm.

The word "recommended" notwithstanding, these are different things.
For example, RFC 8446 says:

   A TLS-compliant application MUST support key exchange with secp256r1
   (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].

But the IANA registry also lists X4448 and secp384r1 as "Recommended=Y".


I will also point out that even though x25519 is 'only' SHOULD, it's the 
most selected option, while p256 is the most 'available' (by a small 
margin). I would expect similiar behavior with hybrid.


This has little do do with the IETF's recommendation and the actual 
behavior of the vendors. Almost certainly, no matter what is said in 
this forum, as we see deployments X25519+ML-KEM will be the most 
commonly sent variant sent in the initial hello, with some number of 
p-256+ML-KEM sent from those clients that for some compliance reason 
can't do X25519+ML-KEM (or believe they can't do that combination*). 
There will even be (very few) p385+ML-KEM sends out there. Those 
requiring compliance will almost certainly be willing to HRR to get to 
their preferred algorithm. The IEFT can make all the recommendations 
they want, but as long as it's allowed, vendors will do what they need.


As such, while this thread definitely has useful and interesting 
information (thank cloudfire for your metrix of TLS 1.3 connections!), 
it doesn't really deserve the heat it seems to generate because it's not 
really a life or death of the internet. No one is going to send multiple 
hybrid on the same connection. Vendors will choose as their business 
needs dictate.


bob




So, what configuration are you advocating for here? Here are some options:

P-256+ML-KEM                     X25519+ML-KEM

            Recommended=Y, MAY  Recommended=Y, MAY
            Recommended=N, MAY  Recommended=Y, MAY
            Recommended=Y, MAY        Recommended=Y, MUST/SHOULD
            Recommended=N, MAY        Recommended=Y, MUST/SHOULD

One of these? Or some other?
yes, and none of them say which you will put in your hello message, 
which I think Dan is asking for and which the Working Group is actively 
saying "It's up to the vendors".


-Ekr




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


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

[TLS]Re: Curve-popularity data?

[Eric Rescorla]

On Fri, Jun 7, 2024 at 11:41 AM D. J. Bernstein  wrote:

> Eric Rescorla writes:
> > I'm struggling to understand what people think is at stake here.
>
> The WG will soon be faced with decisions regarding which curve+PQ
> hybrids to recommend for TLS.


It's important to distinguish between two senses of the word "recommend".

- Is marked "Recommended=Y" in the registry.
- Having the RFC say that you SHOULD/MUST support an algorithm.

The word "recommended" notwithstanding, these are different things.
For example, RFC 8446 says:

   A TLS-compliant application MUST support key exchange with secp256r1
   (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].

But the IANA registry also lists X4448 and secp384r1 as "Recommended=Y".

So, what configuration are you advocating for here? Here are some options:

   P-256+ML-KEM X25519+ML-KEM

Recommended=Y, MAYRecommended=Y, MAY
Recommended=N, MAYRecommended=Y, MAY
Recommended=Y, MAYRecommended=Y, MUST/SHOULD
Recommended=N, MAYRecommended=Y, MUST/SHOULD

One of these? Or some other?

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

[TLS]Re: Curve-popularity data?

[D. J. Bernstein]

Sophie Schmieg writes:
> From what I have heard from NIST, there are no current plans on
> adding X25519 to the NIST approved curves, mostly in order to encourage
> people to transition to PQC instead of ECC.

Sorry, which document are you referring to? This isn't in line with the
NIST announcement quoted in my email dated 6 Jun 2024 00:14:24 -;
it also seems hard to reconcile with the fact that NIST standardized
Curve25519 and Ed25519 as part of updating its digital-signature
standard in 2023. Could it be that you're thinking of the document

   
https://web.archive.org/web/20150815072948/https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml

from NSA back in 2015? ("For those partners and vendors that have not
yet made the transition to Suite B algorithms, we recommend not making a
significant expenditure to do so at this point but instead to prepare
for the upcoming quantum resistant algorithm transition.")

> given that P256 has closed formulas these days the implementation
> benefits are on par

"These days"? Lange and I published complete formulas for P-256 in 2009.
See my email dated 3 Jun 2024 12:33:10 - for more on this and on the
implementation benefits of X25519.

---D. J. Bernstein

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

[TLS]Re: Curve-popularity data?

[D. J. Bernstein]

Richard Barnes writes:
> The TLS WG doesn't need to do anything for a curve+PQ hybrid to
> be used with TLS.

As I said, the WG will be faced with decisions regarding which of the
curve+PQ hybrids to _recommend_ for TLS. Sure, more things will be
registered, but the question of what to recommend is up to the WG.

---D. J. Bernstein

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

[TLS]Re: Curve-popularity data?

[Salz, Rich]

As has been noted elsewhere, the relevant IANA registries are Specification 
Required.  The TLS WG doesn't need to do anything for a curve+PQ hybrid to be 
used with TLS.

Then why has it adopted a draft?

I asked these of you a few days ago and you did not reply.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Sophie Schmieg]

Eliminating P256 will not be possible, primarily due to FIPS 140 compliance
concerns. From what I have heard from NIST, there are no current plans on
adding X25519 to the NIST approved curves, mostly in order to encourage
people to transition to PQC instead of ECC. From that point of view, I
would prefer a P256+PQ hybrid.

>From the security point of view I do not have a strong preference between
the two curves, given that P256 has closed formulas these days the
implementation benefits are on par, and for TLS cofactors do thankfully not
matter. I vaguely prefer P256 just for the odd cases where they do matter.

On Fri, Jun 7, 2024 at 11:40 AM D. J. Bernstein  wrote:

> Eric Rescorla writes:
> > I'm struggling to understand what people think is at stake here.
>
> The WG will soon be faced with decisions regarding which curve+PQ
> hybrids to recommend for TLS. Regarding the curve-choice part of that,
> some context factors that have been raised (such as interoperability and
> regulation) are starting with facts that are different in the hybrid
> context and the pure-curve context, and some technical considerations
> also vary (e.g., the byte cost of sending two shares rather than one is
> more of an issue when each share is curve+PQ than without PQ), while
> many other technical considerations are shared between the two contexts.
>
> Primarily because of the software-security advantages of X25519 over
> P-256, I would like to see TLS, and the ecosystem more broadly, moving
> towards eliminating P-256 in both contexts in favor of X25519. Getting
> X25519 widely deployed in TLS was already a multi-year project; further
> steps that would be helpful in the pure-curve context would be WG
> decisions to (1) make X25519 mandatory and then (2) make P-256 optional.
> The hybrid context will start with the question of what to recommend (I
> presume the WG will wait for PQ support in many more TLS stacks before
> making PQ mandatory), and in that context I think it'll be best for the
> WG to recommend X25519+PQ and not P-256+PQ.
>
> Meanwhile some arguments have been raised aiming at the opposite
> conclusion for hybrids, so it's good to figure out the reasons for the
> different conclusions. Overall I see the WG as being in a fact-finding
> phase regarding the underlying issues. I've found it very interesting to
> see the data points and considerations that people have posted, and for
> at least some issues there's progress towards a shared understanding
> that will help the WG make its curve decisions.
>
> ---D. J. Bernstein
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>


-- 

Sophie Schmieg | Information Security Engineer | ISE Crypto |
sschm...@google.com
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Richard Barnes]

On Fri, Jun 7, 2024 at 2:40 PM D. J. Bernstein  wrote:

> Eric Rescorla writes:
> > I'm struggling to understand what people think is at stake here.
>
> The WG will soon be faced with decisions regarding which curve+PQ
> hybrids to recommend for TLS.


As has been noted elsewhere, the relevant IANA registries are Specification
Required.  The TLS WG doesn't need to do anything for a curve+PQ hybrid to
be used with TLS.

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

[TLS]Re: Curve-popularity data?

[D. J. Bernstein]

Eric Rescorla writes:
> I'm struggling to understand what people think is at stake here.

The WG will soon be faced with decisions regarding which curve+PQ
hybrids to recommend for TLS. Regarding the curve-choice part of that,
some context factors that have been raised (such as interoperability and
regulation) are starting with facts that are different in the hybrid
context and the pure-curve context, and some technical considerations
also vary (e.g., the byte cost of sending two shares rather than one is
more of an issue when each share is curve+PQ than without PQ), while
many other technical considerations are shared between the two contexts.

Primarily because of the software-security advantages of X25519 over
P-256, I would like to see TLS, and the ecosystem more broadly, moving
towards eliminating P-256 in both contexts in favor of X25519. Getting
X25519 widely deployed in TLS was already a multi-year project; further
steps that would be helpful in the pure-curve context would be WG
decisions to (1) make X25519 mandatory and then (2) make P-256 optional.
The hybrid context will start with the question of what to recommend (I
presume the WG will wait for PQ support in many more TLS stacks before
making PQ mandatory), and in that context I think it'll be best for the
WG to recommend X25519+PQ and not P-256+PQ.

Meanwhile some arguments have been raised aiming at the opposite
conclusion for hybrids, so it's good to figure out the reasons for the
different conclusions. Overall I see the WG as being in a fact-finding
phase regarding the underlying issues. I've found it very interesting to
see the data points and considerations that people have posted, and for
at least some issues there's progress towards a shared understanding
that will help the WG make its curve decisions.

---D. J. Bernstein

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

[TLS]Re: Curve-popularity data?

[Hubert Kario]

On Friday, 7 June 2024 19:08:22 CEST, D. J. Bernstein wrote:

Hubert Kario writes:

I think the openssl compile is missing the `enable-ec_nistp_64_gcc_128`
option?


Results on the same Comet Lake of a fresh run of the script with that
option added to the Configure line:

  op  op/s
 256 bits ecdh (nistp256)   0.0001s  12184.0
 253 bits ecdh (X25519)   0.s  24758.0

For comparison, results that I posted before without the option:

  op  op/s
 256 bits ecdh (nistp256)   0.0001s  12186.0
 253 bits ecdh (X25519)   0.s  24753.0

Doesn't look like the option has any effect on these numbers.


hmm looks like they changed it to be the default for the P-256 since I
looked at the performance impact of it... (tried local compiles myself and
yes, no difference)


I checked the OpenSSL changelog, which says this option appeared in
3.2.0 to enable faster code for P-384, so I also tried "openssl speed
ecdhp384", and for that there's an obvious difference: 682.2 ops/sec
without the option, 1824.8 ops/sec with the option.


yes, they recently merged code to also significantly improve speed of
P-384, but the ec_nistp_64_gcc_128 option is old, I think even from 1.0.0
times

and yes, I was seeing such degree of difference with and without that 
option

for P-256, P-224, and P-521 curves


and it ignores the whole case of there being dedicated silicon for
P-256 arithmetic that makes such comparisons moot.


I presume you mean that those comparisons are moot specifically on
machines with P-256 hardware accelerators. Is there data on what
percentages of TLS clients and servers have those accelerators?


I'm not aware of any such stats, sorry.

not a good example, as they also include X25519, but Intel has P-256
in their Quick Assist Technology (which is included in certain Xeons)

the previous version, that shipped as a PCIe card might be more limited,
but I didn't work with those
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

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

[TLS]Re: Curve-popularity data?

[D. J. Bernstein]

Hubert Kario writes:
> I think the openssl compile is missing the `enable-ec_nistp_64_gcc_128`
> option?

Results on the same Comet Lake of a fresh run of the script with that
option added to the Configure line:

  op  op/s
 256 bits ecdh (nistp256)   0.0001s  12184.0
 253 bits ecdh (X25519)   0.s  24758.0

For comparison, results that I posted before without the option:

  op  op/s
 256 bits ecdh (nistp256)   0.0001s  12186.0
 253 bits ecdh (X25519)   0.s  24753.0

Doesn't look like the option has any effect on these numbers.

I checked the OpenSSL changelog, which says this option appeared in
3.2.0 to enable faster code for P-384, so I also tried "openssl speed
ecdhp384", and for that there's an obvious difference: 682.2 ops/sec
without the option, 1824.8 ops/sec with the option.

The changelog also says that this P-384 speedup is "using Solinas'
reduction". The OpenSSL P-256 code was already doing that, obviously.

> Yes, a good implementation of X25519 is faster than a good implementation
> of P-256. But it's not an orders of magnitude difference,

I agree that it isn't a 100x difference.

> and it ignores the whole case of there being dedicated silicon for
> P-256 arithmetic that makes such comparisons moot.

I presume you mean that those comparisons are moot specifically on
machines with P-256 hardware accelerators. Is there data on what
percentages of TLS clients and servers have those accelerators?

---D. J. Bernstein

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

[TLS]Re: Curve-popularity data?

[Eric Rescorla]

On Fri, Jun 7, 2024 at 8:52 AM John Mattsson  wrote:

> >so we should also remove X448, as it's much slower than X25519?
>
> That does not follow from what I said. I think the important metric is
> performance/security. P-256 does basically not have any benefits compared
> to X25519 (excepts a few bits of security more) but these are quite
> irrelevant compared to the huge advantages is implication security provided
> by X25519.
>
> I do think IETF should move to X448 instead of P-384 and P-521 for use
> cases wanting a higher security level than P-256/X25519.
>

I'm struggling to understand what people think is at stake here.

As noted by Richard and myself, nothing stops people from getting code
points for P-256/ML-KEM hybrids, and given that there are people who
clearly want them, we should clearly expect them to be registered. The only
question for this WG are whether we (1) publish them in an RFC with
Recommended=Y and (2) make them MTI. I presume that you're arguing that we
shouldn't make P-256/ML-KEM MTI. Are you arguing that we should not mark
them Recomended=Y?

-Ekr


>
>
> Cheers,
>
> John
>
> *From: *Hubert Kario 
> *Date: *Friday, 7 June 2024 at 17:41
> *To: *John Mattsson 
> *Cc: *D. J. Bernstein , tls@ietf.org 
> *Subject: *Re: [TLS] Curve-popularity data?
>
> On Friday, 7 June 2024 17:29:35 CEST, John Mattsson wrote:
> > Hubert Kario wrote:
> >>Such small differences in performance should absolutely have no effect on
> >>IETF selecting an algorithm or not.
> >
> > I completely disagree. As long as people argue that we need
> > symmetric rekeying and reuse of key share because the ephemeral
> > key exchange algorithms are slow, I think the performance
> > differences illustrated in this thread are a very strong
> > argument why IETF should chose one algorithm over another.
> > Symmetric rekeying and reuse of key shares lowers
> > confidentiality and privacy in the face of pervasive
> > surveillance. Also, I would not call the differences small at
> > all.
>
> so we should also remove X448, as it's much slower than X25519?
>
> please, be reasonable
>
> > Cheers,
> > John Preuß Mattsson
> >
> >
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7258=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844307272%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=4v8gMeGXJpoFSWo8JPxFfT6VvUJHbcSI2YGIoOVRsg0%3D=0
> <https://www.rfc-editor.org/rfc/rfc7258>
> >
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7624=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844316386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=G7rhNxEuiHpI1Ts4lyNZ8i%2By1fPqNxwtrexW79rGkcs%3D=0
> <https://datatracker.ietf.org/doc/html/rfc7624>
> >
> > From: Hubert Kario 
> > Date: Friday, 7 June 2024 at 16:36
> > To: D. J. Bernstein 
> > Cc: tls@ietf.org 
> > Subject: [TLS]Re: Curve-popularity data?
> >
> > On Friday, 7 June 2024 15:54:17 CEST, D. J. Bernstein wrote:
> >> Hubert Kario writes:
> >>> Fedora 39, openssl-3.1.1-4.fc39.x86_64, i7-10850H
> >>> x25519 derive shared secret: 35062.2 op/s
> >>> P-256 derive shared secret: 22741.1 op/s
> >>
> >> The Intel Core i7-10850H microarchitecture is Comet Lake. To see numbers
> >> from current code, I tried the script below on a Comet Lake (Intel Core
> >> i3-10110U with Turbo Boost disabled, so 2.1GHz where your i7-10850H can
> >> boost as high as 5.1GHz; Debian 11; gcc 10.2.1). The script uses shiny
> >> new OpenSSL 3.2.2 (released on Tuesday), and a beta OpenSSL "provider"
> >> for lib25519. The script prints results without and with the provider.
> >> The results with the provider are a better predictor of the user's
> >> ultimate costs than obsolete code; consider, e.g., AWS announcing in
> >>
> >>
> >>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fiacr.org%2Fsubmit%2Ffiles%2Fslides%2F2024%2Frwc%2Frwc2024%2F38%2Fslides.pdf=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844322698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=R%2BIUGXdprzl1xXpwsVcF%2FA2vKHLo%2BGvI70IlPikxGEw%3D=0

[TLS]Re: Curve-popularity data?

[Scott Fluhrer (sfluhrer)]

Does X448 actually provide "a huge advantage" in security (practically 
speaking) over X25519?

On a classical computer, the best known attack against X25519 requires circa 
2^126 point addition operations - that is generally accepted as being 
infeasible.  Attacking X448 requires far more point addition operations - 
however, all that means is that it is also infeasble.

On a Quantum Computer, an attack on X448 requires perhaps 5 times as many 
Quantum operations and 70% more Qubits than an attack on X25519.  This is nice, 
but (given as we know little about the eventual cost of either Qubit operations 
or Qubits themselves) I cannot characterize it as "huge" - it may very well be 
the case that once we have a Quantum Computer that is large/reliable enough to 
attack X25519, it is only a minor effort to scale it upwards to attack X448.

From: John Mattsson 
Sent: Friday, June 7, 2024 11:52 AM
To: Hubert Kario 
Cc: D. J. Bernstein ; tls@ietf.org
Subject: [TLS]Re: Curve-popularity data?

>so we should also remove X448, as it's much slower than X25519?

That does not follow from what I said. I think the important metric is 
performance/security. P-256 does basically not have any benefits compared to 
X25519 (excepts a few bits of security more) but these are quite irrelevant 
compared to the huge advantages is implication security provided by X25519.
I do think IETF should move to X448 instead of P-384 and P-521 for use cases 
wanting a higher security level than P-256/X25519.

Cheers,
John
From: Hubert Kario mailto:hka...@redhat.com>>
Date: Friday, 7 June 2024 at 17:41
To: John Mattsson 
mailto:john.matts...@ericsson.com>>
Cc: D. J. Bernstein mailto:d...@cr.yp.to>>, 
tls@ietf.org<mailto:tls@ietf.org> mailto:tls@ietf.org>>
Subject: Re: [TLS] Curve-popularity data?
On Friday, 7 June 2024 17:29:35 CEST, John Mattsson wrote:
> Hubert Kario wrote:
>>Such small differences in performance should absolutely have no effect on
>>IETF selecting an algorithm or not.
>
> I completely disagree. As long as people argue that we need
> symmetric rekeying and reuse of key share because the ephemeral
> key exchange algorithms are slow, I think the performance
> differences illustrated in this thread are a very strong
> argument why IETF should chose one algorithm over another.
> Symmetric rekeying and reuse of key shares lowers
> confidentiality and privacy in the face of pervasive
> surveillance. Also, I would not call the differences small at
> all.

so we should also remove X448, as it's much slower than X25519?

please, be reasonable

> Cheers,
> John Preuß Mattsson
>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7258=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844307272%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=4v8gMeGXJpoFSWo8JPxFfT6VvUJHbcSI2YGIoOVRsg0%3D=0<https://www.rfc-editor.org/rfc/rfc7258>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7624=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844316386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=G7rhNxEuiHpI1Ts4lyNZ8i%2By1fPqNxwtrexW79rGkcs%3D=0<https://datatracker.ietf.org/doc/html/rfc7624>
>
> From: Hubert Kario mailto:hka...@redhat.com>>
> Date: Friday, 7 June 2024 at 16:36
> To: D. J. Bernstein mailto:d...@cr.yp.to>>
> Cc: tls@ietf.org<mailto:tls@ietf.org> mailto:tls@ietf.org>>
> Subject: [TLS]Re: Curve-popularity data?
>
> On Friday, 7 June 2024 15:54:17 CEST, D. J. Bernstein wrote:
>> Hubert Kario writes:
>>> Fedora 39, openssl-3.1.1-4.fc39.x86_64, i7-10850H
>>> x25519 derive shared secret: 35062.2 op/s
>>> P-256 derive shared secret: 22741.1 op/s
>>
>> The Intel Core i7-10850H microarchitecture is Comet Lake. To see numbers
>> from current code, I tried the script below on a Comet Lake (Intel Core
>> i3-10110U with Turbo Boost disabled, so 2.1GHz where your i7-10850H can
>> boost as high as 5.1GHz; Debian 11; gcc 10.2.1). The script uses shiny
>> new OpenSSL 3.2.2 (released on Tuesday), and a beta OpenSSL "provider"
>> for lib25519. The script prints results without and with the provider.
>> The results with the provider are a better predictor of the user's
>> ultimate costs than obsolete code; consider, e.g., AWS announcing in
>>
>>
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fiacr.org%2Fsubmit%2Ffiles%2Fslides%2F2024%2Frwc%2Frwc2024%2F38%2Fslides.pdf=05%7C02%

[TLS]Re: Curve-popularity data?

[John Mattsson]

>so we should also remove X448, as it's much slower than X25519?

That does not follow from what I said. I think the important metric is 
performance/security. P-256 does basically not have any benefits compared to 
X25519 (excepts a few bits of security more) but these are quite irrelevant 
compared to the huge advantages is implication security provided by X25519.

I do think IETF should move to X448 instead of P-384 and P-521 for use cases 
wanting a higher security level than P-256/X25519.

Cheers,
John

From: Hubert Kario 
Date: Friday, 7 June 2024 at 17:41
To: John Mattsson 
Cc: D. J. Bernstein , tls@ietf.org 
Subject: Re: [TLS] Curve-popularity data?
On Friday, 7 June 2024 17:29:35 CEST, John Mattsson wrote:
> Hubert Kario wrote:
>>Such small differences in performance should absolutely have no effect on
>>IETF selecting an algorithm or not.
>
> I completely disagree. As long as people argue that we need
> symmetric rekeying and reuse of key share because the ephemeral
> key exchange algorithms are slow, I think the performance
> differences illustrated in this thread are a very strong
> argument why IETF should chose one algorithm over another.
> Symmetric rekeying and reuse of key shares lowers
> confidentiality and privacy in the face of pervasive
> surveillance. Also, I would not call the differences small at
> all.

so we should also remove X448, as it's much slower than X25519?

please, be reasonable

> Cheers,
> John Preuß Mattsson
>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7258=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844307272%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=4v8gMeGXJpoFSWo8JPxFfT6VvUJHbcSI2YGIoOVRsg0%3D=0<https://www.rfc-editor.org/rfc/rfc7258>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7624=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844316386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=G7rhNxEuiHpI1Ts4lyNZ8i%2By1fPqNxwtrexW79rGkcs%3D=0<https://datatracker.ietf.org/doc/html/rfc7624>
>
> From: Hubert Kario 
> Date: Friday, 7 June 2024 at 16:36
> To: D. J. Bernstein 
> Cc: tls@ietf.org 
> Subject: [TLS]Re: Curve-popularity data?
>
> On Friday, 7 June 2024 15:54:17 CEST, D. J. Bernstein wrote:
>> Hubert Kario writes:
>>> Fedora 39, openssl-3.1.1-4.fc39.x86_64, i7-10850H
>>> x25519 derive shared secret: 35062.2 op/s
>>> P-256 derive shared secret: 22741.1 op/s
>>
>> The Intel Core i7-10850H microarchitecture is Comet Lake. To see numbers
>> from current code, I tried the script below on a Comet Lake (Intel Core
>> i3-10110U with Turbo Boost disabled, so 2.1GHz where your i7-10850H can
>> boost as high as 5.1GHz; Debian 11; gcc 10.2.1). The script uses shiny
>> new OpenSSL 3.2.2 (released on Tuesday), and a beta OpenSSL "provider"
>> for lib25519. The script prints results without and with the provider.
>> The results with the provider are a better predictor of the user's
>> ultimate costs than obsolete code; consider, e.g., AWS announcing in
>>
>>
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fiacr.org%2Fsubmit%2Ffiles%2Fslides%2F2024%2Frwc%2Frwc2024%2F38%2Fslides.pdf=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49e466dab144e45ee7608dc8707d932%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533716844322698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=R%2BIUGXdprzl1xXpwsVcF%2FA2vKHLo%2BGvI70IlPikxGEw%3D=0<https://iacr.org/submit/files/slides/2024/rwc/rwc2024/38/slides.pdf>
>>
>> that they had already switched their deployments to the fast formally
>> verified X25519 code in s2n-bignum (which lib25519 supports internally).
>> The script's results using the provider are as follows:
>>
>>   op  op/s
>>  256 bits ecdh (nistp256)   0.0001s  12186.0
>>  253 bits ecdh (X25519)   0.s  24753.0
>>
>>   signverifysign/s verify/s
>>  256 bits ecdsa (nistp256)   0.s   0.0001s  27569.0   9169.0
>>   signverifysign/s verify/s
>>  253 bits EdDSA (Ed25519)   0.s   0.s  66099.0  20126.0
>>
>> Without the provider, X25519 gives 146% the operations/second of P-256
>> (close to the 154% you saw) rather than 203%. Also, OpenSSL has only
>> unoptimized code for Ed25519 and manages to be e

[TLS]Re: Curve-popularity data?

[Hubert Kario]

On Friday, 7 June 2024 17:29:35 CEST, John Mattsson wrote:

Hubert Kario wrote:

Such small differences in performance should absolutely have no effect on
IETF selecting an algorithm or not.
 
I completely disagree. As long as people argue that we need 
symmetric rekeying and reuse of key share because the ephemeral 
key exchange algorithms are slow, I think the performance 
differences illustrated in this thread are a very strong 
argument why IETF should chose one algorithm over another. 
Symmetric rekeying and reuse of key shares lowers 
confidentiality and privacy in the face of pervasive 
surveillance. Also, I would not call the differences small at 
all.


so we should also remove X448, as it's much slower than X25519?

please, be reasonable


Cheers,
John Preuß Mattsson
 
https://www.rfc-editor.org/rfc/rfc7258

https://datatracker.ietf.org/doc/html/rfc7624
 
From: Hubert Kario 

Date: Friday, 7 June 2024 at 16:36
To: D. J. Bernstein 
Cc: tls@ietf.org 
Subject: [TLS]Re: Curve-popularity data?

On Friday, 7 June 2024 15:54:17 CEST, D. J. Bernstein wrote:

Hubert Kario writes:

Fedora 39, openssl-3.1.1-4.fc39.x86_64, i7-10850H
x25519 derive shared secret: 35062.2 op/s
P-256 derive shared secret: 22741.1 op/s


The Intel Core i7-10850H microarchitecture is Comet Lake. To see numbers
from current code, I tried the script below on a Comet Lake (Intel Core
i3-10110U with Turbo Boost disabled, so 2.1GHz where your i7-10850H can
boost as high as 5.1GHz; Debian 11; gcc 10.2.1). The script uses shiny
new OpenSSL 3.2.2 (released on Tuesday), and a beta OpenSSL "provider"
for lib25519. The script prints results without and with the provider.
The results with the provider are a better predictor of the user's
ultimate costs than obsolete code; consider, e.g., AWS announcing in


https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fiacr.org%2Fsubmit%2Ffiles%2Fslides%2F2024%2Frwc%2Frwc2024%2F38%2Fslides.pdf=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cca1493f68e364934f6a108dc86fec124%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533677636426338%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=w6Bo7hxR0%2Bp6fOgkp%2B%2Fp6IWkpEBbE67HPTVTv1nRrig%3D=0


that they had already switched their deployments to the fast formally
verified X25519 code in s2n-bignum (which lib25519 supports internally).
The script's results using the provider are as follows:

  op  op/s
 256 bits ecdh (nistp256)   0.0001s  12186.0
 253 bits ecdh (X25519)   0.s  24753.0

  signverifysign/s verify/s
 256 bits ecdsa (nistp256)   0.s   0.0001s  27569.0   9169.0
  signverifysign/s verify/s
 253 bits EdDSA (Ed25519)   0.s   0.s  66099.0  20126.0

Without the provider, X25519 gives 146% the operations/second of P-256
(close to the 154% you saw) rather than 203%. Also, OpenSSL has only
unoptimized code for Ed25519 and manages to be even slower than ECDSA;
obviously this is a reflection of Ed25519 not being allowed yet in
certificates rather than of the performance users will see.

Earlier I had also posted a similar script, posted Zen 2 results, and
mentioned that OpenSSL's built-in code cheats by not measuring various
key-expansion steps, whereas lib25519 never cheats. The difference in
this script is the part downloading and compiling OpenSSL 3.2.2.


I think the openssl compile is missing the `enable-ec_nistp_64_gcc_128` 
option?


But in general, I think this discussion of off-topic.

Yes, a good implementation of X25519 is faster than a good implementation
of P-256. But it's not an orders of magnitude difference, and it ignores
the whole case of there being dedicated silicon for P-256 arithmetic that
makes such comparisons moot.

Such small differences in performance should absolutely have no effect on
IETF selecting an algorithm or not.


---D. J. Bernstein


#!/bin/sh

export LD_LIBRARY_PATH="$HOME/lib:$HOME/lib64"
export LIBRARY_PATH="$HOME/lib:$HOME/lib64"
export CPATH="$HOME/include"
export PATH="$HOME/bin:$PATH"

( version=3.2.2
   wget -m 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openssl.org%2Fsource%2Fopenssl-%24version.tar.gz=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cca1493f68e364934f6a108dc86fec124%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533677636436052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=flT7wWBKwtTBvrm1quIbsq5tua2TpNgH1sewIKU68zo%3D=0
   tar -xzf 
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.openssl.org%2Fsource%2Fopenssl-%24version.tar.gz=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cca1493f68e364934f6a108dc86fec124%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533677636443730%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7

[TLS]Re: Curve-popularity data?

[John Mattsson]

Hubert Kario wrote:
>Such small differences in performance should absolutely have no effect on
>IETF selecting an algorithm or not.

I completely disagree. As long as people argue that we need symmetric rekeying 
and reuse of key share because the ephemeral key exchange algorithms are slow, 
I think the performance differences illustrated in this thread are a very 
strong argument why IETF should chose one algorithm over another. Symmetric 
rekeying and reuse of key shares lowers confidentiality and privacy in the face 
of pervasive surveillance. Also, I would not call the differences small at all.

Cheers,
John Preuß Mattsson

https://www.rfc-editor.org/rfc/rfc7258
https://datatracker.ietf.org/doc/html/rfc7624

From: Hubert Kario 
Date: Friday, 7 June 2024 at 16:36
To: D. J. Bernstein 
Cc: tls@ietf.org 
Subject: [TLS]Re: Curve-popularity data?
On Friday, 7 June 2024 15:54:17 CEST, D. J. Bernstein wrote:
> Hubert Kario writes:
>> Fedora 39, openssl-3.1.1-4.fc39.x86_64, i7-10850H
>> x25519 derive shared secret: 35062.2 op/s
>> P-256 derive shared secret: 22741.1 op/s
>
> The Intel Core i7-10850H microarchitecture is Comet Lake. To see numbers
> from current code, I tried the script below on a Comet Lake (Intel Core
> i3-10110U with Turbo Boost disabled, so 2.1GHz where your i7-10850H can
> boost as high as 5.1GHz; Debian 11; gcc 10.2.1). The script uses shiny
> new OpenSSL 3.2.2 (released on Tuesday), and a beta OpenSSL "provider"
> for lib25519. The script prints results without and with the provider.
> The results with the provider are a better predictor of the user's
> ultimate costs than obsolete code; consider, e.g., AWS announcing in
>
>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fiacr.org%2Fsubmit%2Ffiles%2Fslides%2F2024%2Frwc%2Frwc2024%2F38%2Fslides.pdf=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cca1493f68e364934f6a108dc86fec124%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533677636426338%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=w6Bo7hxR0%2Bp6fOgkp%2B%2Fp6IWkpEBbE67HPTVTv1nRrig%3D=0<https://iacr.org/submit/files/slides/2024/rwc/rwc2024/38/slides.pdf>
>
> that they had already switched their deployments to the fast formally
> verified X25519 code in s2n-bignum (which lib25519 supports internally).
> The script's results using the provider are as follows:
>
>   op  op/s
>  256 bits ecdh (nistp256)   0.0001s  12186.0
>  253 bits ecdh (X25519)   0.s  24753.0
>
>   signverifysign/s verify/s
>  256 bits ecdsa (nistp256)   0.s   0.0001s  27569.0   9169.0
>   signverifysign/s verify/s
>  253 bits EdDSA (Ed25519)   0.s   0.s  66099.0  20126.0
>
> Without the provider, X25519 gives 146% the operations/second of P-256
> (close to the 154% you saw) rather than 203%. Also, OpenSSL has only
> unoptimized code for Ed25519 and manages to be even slower than ECDSA;
> obviously this is a reflection of Ed25519 not being allowed yet in
> certificates rather than of the performance users will see.
>
> Earlier I had also posted a similar script, posted Zen 2 results, and
> mentioned that OpenSSL's built-in code cheats by not measuring various
> key-expansion steps, whereas lib25519 never cheats. The difference in
> this script is the part downloading and compiling OpenSSL 3.2.2.

I think the openssl compile is missing the `enable-ec_nistp_64_gcc_128`
option?

But in general, I think this discussion of off-topic.

Yes, a good implementation of X25519 is faster than a good implementation
of P-256. But it's not an orders of magnitude difference, and it ignores
the whole case of there being dedicated silicon for P-256 arithmetic that
makes such comparisons moot.

Such small differences in performance should absolutely have no effect on
IETF selecting an algorithm or not.

> ---D. J. Bernstein
>
>
> #!/bin/sh
>
> export LD_LIBRARY_PATH="$HOME/lib:$HOME/lib64"
> export LIBRARY_PATH="$HOME/lib:$HOME/lib64"
> export CPATH="$HOME/include"
> export PATH="$HOME/bin:$PATH"
>
> ( version=3.2.2
>   wget -m 
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openssl.org%2Fsource%2Fopenssl-%24version.tar.gz=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cca1493f68e364934f6a108dc86fec124%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638533677636436052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=flT7wWBKwtTBvrm1quIbsq5tua2TpNgH1sewIKU68zo%3D=0<https://www.openssl.org/source/openssl-$version.tar.gz>
>   tar -xzf 
> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.openssl.org%2Fsource%2Fopenssl-%24versi

[TLS]Re: Curve-popularity data?

[A A]

But X25519, X448, which are mark as safe in safecurves are protected against certain side-channel and other attacks, not only performance advantage. 07.06.2024, 22:33, "Hubert Kario" :On Friday, 7 June 2024 15:54:17 CEST, D. J. Bernstein wrote: Hubert Kario writes: Fedora 39, openssl-3.1.1-4.fc39.x86_64, i7-10850H x25519 derive shared secret: 35062.2 op/s P-256 derive shared secret: 22741.1 op/s The Intel Core i7-10850H microarchitecture is Comet Lake. To see numbers from current code, I tried the script below on a Comet Lake (Intel Core i3-10110U with Turbo Boost disabled, so 2.1GHz where your i7-10850H can boost as high as 5.1GHz; Debian 11; gcc 10.2.1). The script uses shiny new OpenSSL 3.2.2 (released on Tuesday), and a beta OpenSSL "provider" for lib25519. The script prints results without and with the provider. The results with the provider are a better predictor of the user's ultimate costs than obsolete code; consider, e.g., AWS announcing inhttps://iacr.org/submit/files/slides/2024/rwc/rwc2024/38/slides.pdf that they had already switched their deployments to the fast formally verified X25519 code in s2n-bignum (which lib25519 supports internally). The script's results using the provider are as follows:   op op/s  256 bits ecdh (nistp256) 0.0001s 12186.0  253 bits ecdh (X25519) 0.s 24753.0   sign verify sign/s verify/s  256 bits ecdsa (nistp256) 0.s 0.0001s 27569.0 9169.0   sign verify sign/s verify/s  253 bits EdDSA (Ed25519) 0.s 0.s 66099.0 20126.0 Without the provider, X25519 gives 146% the operations/second of P-256 (close to the 154% you saw) rather than 203%. Also, OpenSSL has only unoptimized code for Ed25519 and manages to be even slower than ECDSA; obviously this is a reflection of Ed25519 not being allowed yet in certificates rather than of the performance users will see. Earlier I had also posted a similar script, posted Zen 2 results, and mentioned that OpenSSL's built-in code cheats by not measuring various key-expansion steps, whereas lib25519 never cheats. The difference in this script is the part downloading and compiling OpenSSL 3.2.2.I think the openssl compile is missing the `enable-ec_nistp_64_gcc_128`option?But in general, I think this discussion of off-topic.Yes, a good implementation of X25519 is faster than a good implementationof P-256. But it's not an orders of magnitude difference, and it ignoresthe whole case of there being dedicated silicon for P-256 arithmetic thatmakes such comparisons moot.Such small differences in performance should absolutely have no effect onIETF selecting an algorithm or not.  ---D. J. Bernstein #!/bin/sh export LD_LIBRARY_PATH="$HOME/lib:$HOME/lib64" export LIBRARY_PATH="$HOME/lib:$HOME/lib64" export CPATH="$HOME/include" export PATH="$HOME/bin:$PATH" ( version=3.2.2   wget -m https://www.openssl.org/source/openssl-$version.tar.gz   tar -xzf www.openssl.org/source/openssl-$version.tar.gz   cd openssl-$version   ./Configure --prefix=$HOME --openssldir=$HOME/ssl && make -j && make install ) ( wget -m https://randombytes.cr.yp.to/librandombytes-latest-version.txt   version=$(cat randombytes.cr.yp.to/librandombytes-latest-version.txt)   wget -m https://randombytes.cr.yp.to/librandombytes-$version.tar.gz   tar -xzf randombytes.cr.yp.to/librandombytes-$version.tar.gz   cd librandombytes-$version   ./configure --prefix=$HOME && make -j install ) ( wget -m https://cpucycles.cr.yp.to/libcpucycles-latest-version.txt   version=$(cat cpucycles.cr.yp.to/libcpucycles-latest-version.txt)   wget -m https://cpucycles.cr.yp.to/libcpucycles-$version.tar.gz   tar -xzf cpucycles.cr.yp.to/libcpucycles-$version.tar.gz   cd libcpucycles-$version   ./configure --prefix=$HOME && make -j install ) ( wget -m https://lib25519.cr.yp.to/lib25519-latest-version.txt   version=$(cat lib25519.cr.yp.to/lib25519-latest-version.txt)   wget -m https://lib25519.cr.yp.to/lib25519-$version.tar.gz   tar -xzf lib25519.cr.yp.to/lib25519-$version.tar.gz   cd lib25519-$version   ./use-s2n-bignum   ./configure --prefix=$HOME && make -j install ) ( wget -m https://cr.yp.to/2024/20240314/openssl_x25519_lib25519.c   wget -m https://cr.yp.to/2024/20240314/openssl_ed25519_lib25519.c   wget -m https://cr.yp.to/2024/20240314/xtest   wget -m https://cr.yp.to/2024/20240314/edtest   cd cr.yp.to/2024/20240314   sh xtest   sh edtest )  --Regards,Hubert KarioPrincipal Quality Engineer, RHEL Crypto teamWeb: www.cz.redhat.comRed Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic___TLS mailing list -- tls@ietf.orgTo 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: Curve-popularity data?

[Hubert Kario]

On Friday, 7 June 2024 15:54:17 CEST, D. J. Bernstein wrote:

Hubert Kario writes:

Fedora 39, openssl-3.1.1-4.fc39.x86_64, i7-10850H
x25519 derive shared secret: 35062.2 op/s
P-256 derive shared secret: 22741.1 op/s


The Intel Core i7-10850H microarchitecture is Comet Lake. To see numbers
from current code, I tried the script below on a Comet Lake (Intel Core
i3-10110U with Turbo Boost disabled, so 2.1GHz where your i7-10850H can
boost as high as 5.1GHz; Debian 11; gcc 10.2.1). The script uses shiny
new OpenSSL 3.2.2 (released on Tuesday), and a beta OpenSSL "provider"
for lib25519. The script prints results without and with the provider.
The results with the provider are a better predictor of the user's
ultimate costs than obsolete code; consider, e.g., AWS announcing in

   https://iacr.org/submit/files/slides/2024/rwc/rwc2024/38/slides.pdf

that they had already switched their deployments to the fast formally
verified X25519 code in s2n-bignum (which lib25519 supports internally).
The script's results using the provider are as follows:

  op  op/s
 256 bits ecdh (nistp256)   0.0001s  12186.0
 253 bits ecdh (X25519)   0.s  24753.0

  signverifysign/s verify/s
 256 bits ecdsa (nistp256)   0.s   0.0001s  27569.0   9169.0
  signverifysign/s verify/s
 253 bits EdDSA (Ed25519)   0.s   0.s  66099.0  20126.0

Without the provider, X25519 gives 146% the operations/second of P-256
(close to the 154% you saw) rather than 203%. Also, OpenSSL has only
unoptimized code for Ed25519 and manages to be even slower than ECDSA;
obviously this is a reflection of Ed25519 not being allowed yet in
certificates rather than of the performance users will see.

Earlier I had also posted a similar script, posted Zen 2 results, and
mentioned that OpenSSL's built-in code cheats by not measuring various
key-expansion steps, whereas lib25519 never cheats. The difference in
this script is the part downloading and compiling OpenSSL 3.2.2.


I think the openssl compile is missing the `enable-ec_nistp_64_gcc_128` 
option?


But in general, I think this discussion of off-topic.

Yes, a good implementation of X25519 is faster than a good implementation
of P-256. But it's not an orders of magnitude difference, and it ignores
the whole case of there being dedicated silicon for P-256 arithmetic that
makes such comparisons moot.

Such small differences in performance should absolutely have no effect on
IETF selecting an algorithm or not.


---D. J. Bernstein


#!/bin/sh

export LD_LIBRARY_PATH="$HOME/lib:$HOME/lib64"
export LIBRARY_PATH="$HOME/lib:$HOME/lib64"
export CPATH="$HOME/include"
export PATH="$HOME/bin:$PATH"

( version=3.2.2
  wget -m https://www.openssl.org/source/openssl-$version.tar.gz
  tar -xzf www.openssl.org/source/openssl-$version.tar.gz
  cd openssl-$version
  ./Configure --prefix=$HOME --openssldir=$HOME/ssl && make -j 
&& make install

)
( wget -m https://randombytes.cr.yp.to/librandombytes-latest-version.txt
  version=$(cat randombytes.cr.yp.to/librandombytes-latest-version.txt)
  wget -m https://randombytes.cr.yp.to/librandombytes-$version.tar.gz
  tar -xzf randombytes.cr.yp.to/librandombytes-$version.tar.gz
  cd librandombytes-$version
  ./configure --prefix=$HOME && make -j install
)
( wget -m https://cpucycles.cr.yp.to/libcpucycles-latest-version.txt
  version=$(cat cpucycles.cr.yp.to/libcpucycles-latest-version.txt)
  wget -m https://cpucycles.cr.yp.to/libcpucycles-$version.tar.gz
  tar -xzf cpucycles.cr.yp.to/libcpucycles-$version.tar.gz
  cd libcpucycles-$version
  ./configure --prefix=$HOME && make -j install
)
( wget -m https://lib25519.cr.yp.to/lib25519-latest-version.txt
  version=$(cat lib25519.cr.yp.to/lib25519-latest-version.txt)
  wget -m https://lib25519.cr.yp.to/lib25519-$version.tar.gz
  tar -xzf lib25519.cr.yp.to/lib25519-$version.tar.gz
  cd lib25519-$version
  ./use-s2n-bignum
  ./configure --prefix=$HOME && make -j install
)
( wget -m https://cr.yp.to/2024/20240314/openssl_x25519_lib25519.c
  wget -m https://cr.yp.to/2024/20240314/openssl_ed25519_lib25519.c
  wget -m https://cr.yp.to/2024/20240314/xtest
  wget -m https://cr.yp.to/2024/20240314/edtest
  cd cr.yp.to/2024/20240314
  sh xtest
  sh edtest
)



--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

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

[TLS]Re: Curve-popularity data?

[D. J. Bernstein]

Hubert Kario writes:
> Fedora 39, openssl-3.1.1-4.fc39.x86_64, i7-10850H
> x25519 derive shared secret: 35062.2 op/s
> P-256 derive shared secret: 22741.1 op/s

The Intel Core i7-10850H microarchitecture is Comet Lake. To see numbers
from current code, I tried the script below on a Comet Lake (Intel Core
i3-10110U with Turbo Boost disabled, so 2.1GHz where your i7-10850H can
boost as high as 5.1GHz; Debian 11; gcc 10.2.1). The script uses shiny
new OpenSSL 3.2.2 (released on Tuesday), and a beta OpenSSL "provider"
for lib25519. The script prints results without and with the provider.
The results with the provider are a better predictor of the user's
ultimate costs than obsolete code; consider, e.g., AWS announcing in

   https://iacr.org/submit/files/slides/2024/rwc/rwc2024/38/slides.pdf

that they had already switched their deployments to the fast formally
verified X25519 code in s2n-bignum (which lib25519 supports internally).
The script's results using the provider are as follows:

  op  op/s
 256 bits ecdh (nistp256)   0.0001s  12186.0
 253 bits ecdh (X25519)   0.s  24753.0

  signverifysign/s verify/s
 256 bits ecdsa (nistp256)   0.s   0.0001s  27569.0   9169.0
  signverifysign/s verify/s
 253 bits EdDSA (Ed25519)   0.s   0.s  66099.0  20126.0

Without the provider, X25519 gives 146% the operations/second of P-256
(close to the 154% you saw) rather than 203%. Also, OpenSSL has only
unoptimized code for Ed25519 and manages to be even slower than ECDSA;
obviously this is a reflection of Ed25519 not being allowed yet in
certificates rather than of the performance users will see.

Earlier I had also posted a similar script, posted Zen 2 results, and
mentioned that OpenSSL's built-in code cheats by not measuring various
key-expansion steps, whereas lib25519 never cheats. The difference in
this script is the part downloading and compiling OpenSSL 3.2.2.

---D. J. Bernstein


#!/bin/sh

export LD_LIBRARY_PATH="$HOME/lib:$HOME/lib64"
export LIBRARY_PATH="$HOME/lib:$HOME/lib64"
export CPATH="$HOME/include"
export PATH="$HOME/bin:$PATH"

( version=3.2.2
  wget -m https://www.openssl.org/source/openssl-$version.tar.gz
  tar -xzf www.openssl.org/source/openssl-$version.tar.gz
  cd openssl-$version
  ./Configure --prefix=$HOME --openssldir=$HOME/ssl && make -j && make install
)
( wget -m https://randombytes.cr.yp.to/librandombytes-latest-version.txt
  version=$(cat randombytes.cr.yp.to/librandombytes-latest-version.txt)
  wget -m https://randombytes.cr.yp.to/librandombytes-$version.tar.gz
  tar -xzf randombytes.cr.yp.to/librandombytes-$version.tar.gz
  cd librandombytes-$version
  ./configure --prefix=$HOME && make -j install
)
( wget -m https://cpucycles.cr.yp.to/libcpucycles-latest-version.txt
  version=$(cat cpucycles.cr.yp.to/libcpucycles-latest-version.txt)
  wget -m https://cpucycles.cr.yp.to/libcpucycles-$version.tar.gz
  tar -xzf cpucycles.cr.yp.to/libcpucycles-$version.tar.gz
  cd libcpucycles-$version
  ./configure --prefix=$HOME && make -j install
)
( wget -m https://lib25519.cr.yp.to/lib25519-latest-version.txt
  version=$(cat lib25519.cr.yp.to/lib25519-latest-version.txt)
  wget -m https://lib25519.cr.yp.to/lib25519-$version.tar.gz
  tar -xzf lib25519.cr.yp.to/lib25519-$version.tar.gz
  cd lib25519-$version
  ./use-s2n-bignum
  ./configure --prefix=$HOME && make -j install
)
( wget -m https://cr.yp.to/2024/20240314/openssl_x25519_lib25519.c
  wget -m https://cr.yp.to/2024/20240314/openssl_ed25519_lib25519.c
  wget -m https://cr.yp.to/2024/20240314/xtest
  wget -m https://cr.yp.to/2024/20240314/edtest
  cd cr.yp.to/2024/20240314
  sh xtest
  sh edtest
)

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

[TLS]Re: Curve-popularity data?

[John Mattsson]

Hubert Kario wrote:
>Because NIST is a trend-setter, many other compliance organisations reuse 
>those curves
>(French ANSSI, German BSI, Japanese IPA, etc.).

I think IETF is also a very strong trend-setter among governments. Other 
governments follow NIST when they think NIST is doing a good job or when NIST 
algorithms is what is available on the market. They do the same with CFRG 
algorithms.

Dutch NCSC recommends secp384r1, secp256r1, curve448, and curve25519
https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1

French ANSSI recommends NIST P-curves but also approves X25519 X448 and 
Brainpool
file:///Users/emanjon/Downloads/anssi-guide-recommandations_de_securite_relatives_a_tls-v1.2.pdf

Japanese IPA recommends both P-256 and X25519
https://www.ipa.go.jp/security/crypto/guideline/gmcbt8005ufv-att/ipa-cryptrec-gl-3001-3.0.1.pdf

German BSI recommends Brainpool and writes that NIST P-curves can be used if 
Brainpool curves are not available.
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-2.pdf?__blob=publicationFile=6

China recommends SM2 and Russia recommends GOST.

Government recommendations are not always suitable for industry. For military 
and government use cases performance and monetary costs are low priority. For 
many industry use cases performance and monetary costs are very important 
priorities that also affect security. If ephemeral key exchange is slow, the 
answer is often to use less ephemeral key exchange instead of decreasing 
performance.

I think it would make sense to make both P-256 and X25519 MTI. I think forcing 
any key shares in CH is wrong. I also think registering hybrids as code points 
is wrong. If TLS did the right thing like IKEv2 we would just need to register 
ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as “groups” and everybody would be 
happy because there favorite standalone of hybrid would be supported. If the 
Web want to use a single hybrid I think that should be discussed in W3C.

Cheers,
John Preuß Mattsson

From: Hubert Kario 
Date: Thursday, 6 June 2024 at 12:37
To: D. J. Bernstein 
Cc: tls@ietf.org 
Subject: [TLS]Re: Curve-popularity data?
On Wednesday, 5 June 2024 22:00:44 CEST, D. J. Bernstein wrote:
> Andrei Popov writes:
>> I support this change, willing to implement it in the Windows TLS
>> stack. We have thousands of customers concerned about increased
>> latencies due to the enablement of TLS 1.3. The services they connect
>> to require NIST curves and HRR is required to get TLS clients to send
>> appropriate key shares.
>
> To clarify, when you say "require NIST curves", do you mean "require
> conformance with NIST SP 800-56A"?

really depends on the deployment, some just want to use SP 800-56A curves,
some need actual, real, to the letter, legal compliance with FIPS 140-2 or
FIPS 140-3.

> In other words, will another curve be allowed once it's added to NIST
> SP 800-56A? Maybe faster: would the short-term problem be addressed if
> we can convince NIST to announce that it will consider X25519 and X448
> for a revision of SP 800-56A, and doesn't intend to enforce conformance
> of cryptographic modules with SP 800-56A until the revisions are done?

Short-term problem won't be solved like that for everybody. For
deployments that require FIPS compliance, the implementation itself needs
to be certified. At this moment there's no way to get it certified, so we
are at least 2-3 years away from a certified implementation of x25519
being available even if NIST marked x25519 as approved tomorrow.

> Or are you saying that, independently of NIST's decisions, the services
> in question are for some reason specifically requiring what's typically
> called the "NIST curves", namely the fifteen NSA curves that NIST
> standardized? Or the subset of those that NIST hasn't deprecated yet?

Because NIST is a trend-setter, many other compliance organisations
reuse those curves (French ANSSI, German BSI, Japanese IPA, etc.).
Similarly
Common Criteria certifications, while they're international, they're
similarly
heavily influenced by what NIST and NSA recommends. All of them will have
a lot of inertia.

And to address what John Mattsson wrote in a separate email: yes, IETF is
international and should not be bound by particular government requirements
for IETF standards to be actually usable in practice, they do need to
take into account what governmental bodies require. What gets published
by IETF can be superset of what govs want.

So, while I'd love to see x25519 in governmental standards, I think it's
better to spend energy making sure that we deploy ML-KEM as soon as
possible,
in hybrid mode, both with x25519 *and* NIST curves (at the very least P-256
and
P-384).

--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Cry

[TLS]Re: Curve-popularity data?

[Ilari Liusvaara]

On Thu, Jun 06, 2024 at 12:36:28PM +0200, Hubert Kario wrote:
> 
> So, while I'd love to see x25519 in governmental standards, I think it's
> better to spend energy making sure that we deploy ML-KEM as soon as
> possible,
> in hybrid mode, both with x25519 *and* NIST curves (at the very least P-256
> and
> P-384).

I think a good initial set of hybrids would be:

- x25519+mlkem768
- x448+mlmem1024
- p256+mlkem768
- p384+mlkem1024




-Ilari

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

[TLS]Re: Curve-popularity data?

[A A]

On my computer (Windows 10 LTSC 2021 x64), run openssl in a Debian 12 VM user@debian:~$ openssl speed ecdhp256Doing 256 bits  ecdh's for 10s: 236351 256-bits ECDH ops in 10.13sversion: 3.0.11built on: Mon Oct 23 17:52:22 2023 UTCoptions: bn(64,64)compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -fzero-call-used-regs=used-gpr -DOPENSSL_TLS_SECURITY_LEVEL=2 -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/reproducible-path/openssl-3.0.11=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2CPUINFO: OPENSSL_ia32cap=0xfffa32234f8b:0x9840079c219c27eb  op  op/s 256 bits ecdh (nistp256)   0.s  23331.8 user@debian:~$ openssl speed ecdhx25519Doing 253 bits  ecdh's for 10s: 389226 253-bits ECDH ops in 10.12sversion: 3.0.11built on: Mon Oct 23 17:52:22 2023 UTCoptions: bn(64,64)compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -fzero-call-used-regs=used-gpr -DOPENSSL_TLS_SECURITY_LEVEL=2 -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/reproducible-path/openssl-3.0.11=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2CPUINFO: OPENSSL_ia32cap=0xfffa32234f8b:0x9840079c219c27eb  op  op/s 253 bits ecdh (X25519)   0.s  38461.106.06.2024, 18:22, "Hubert Kario" :On Thursday, 6 June 2024 00:57:52 CEST, A A wrote: "E.g. a client might also have legitimate reasons to nudge  servers to use a stronger curve than P-256 in the initial CH and  only fall back to weaker curves by explicit request via HRR.  Probably the reason for Chrome for requesting HRR for P-256 is  the attempt to nudge servers to use an algorithm which is  believed to provide advantages for the client-side  implementation (possibly both, speed/power or security or  bandwidth) in comparison to P-256."   About speed: https://bench.cr.yp.to/results-dh.html shows that  on amd64; Zen 4 (a60f12); 2023 AMD Ryzen 7 7700; 8 x 3800MHz;  hertz, supercop-20240425,   nistp256(P-256) needs 202616 cycles to generate a key pair,  535274 cycles to compute a shared secret; Curve25519 needs 101289cycles to generate a key pair, 109491  cycles to compute a shared secret;   And, X25519's key share only need 32 bytes, P-256 needs 65  bytes. Conclusion: P-256 neither has security nor performance  (power) advantage compare with X25519.That's not the performance delta I see in practice.Fedora 39, openssl-3.1.1-4.fc39.x86_64, i7-10850Hx25519 derive shared secret: 35062.2 op/sP-256 derive shared secret: 22741.1 op/s(run `openssl speed ecdhp256; openssl speed ecdhx25519` to try yourself) 05.06.2024, 22:05, "Björn Haase"  : Hi Eric, Hi all,One more thing: we are finalizing RFC 8446-bis right now, so if there isWG consensus to require that clients offer all MTI curves in the key_sharesof their initial CH, then that would be a straightforward text change.  I think that we might rather keep a mechanism that preserves  the possibility of the client-side to express a preference  regarding a specific cipher suite / curve and accept other  curves only using the HRR-mechanism. E.g. a client might also have legitimate reasons to nudge  servers to use a stronger curve than P-256 in the initial CH and  only fall back to weaker curves by explicit request via HRR.  Probably the reason for Chrome for requesting HRR for P-256 is  the attempt to nudge servers to use an algorithm which is  believed to provide advantages for the client-side  implementation (possibly both, speed/power or security or  bandwidth) in comparison to P-256. Björn. Mit freundlichen Grüßen | Best Regards Dr. Björn Haase Senior Expert Electronics | TGREH Electronics Hardware Endress+Hauser Liquid Analysis Endress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839  Gerlingen | Germany Phone: +49 7156 209 10377 bjoern.ha...@endress.com | www.ehla.endress.com  Endress+Hauser Conducta GmbH+Co.KG Amtsgericht Stuttgart HRA 201908 Sitz der Gesellschaft: Gerlingen Persönlich haftende Gesellschafterin: Endress+Hauser Conducta Verwaltungsgesellschaft mbH Sitz der Gesellschaft: Gerlingen Amtsgericht Stuttgart HRA 201929 Geschäftsführer: Dr. Manfred Jagiella Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu  informieren, wenn wir personenbezogene Daten von Ihnen erheben. Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis nach.   Disclaimer: The information transmitted is intended only for the person or  entity to which it is addressed and may contain confidential,  proprietary, and/or privileged material. Any review, retransmission, dissemination or other  use of, or taking of any action in reliance upon, this  information by persons or entities other than the intended recipient is prohibited. If you receive  this in error, 

[TLS]Re: Curve-popularity data?

[Hubert Kario]

On Wednesday, 5 June 2024 22:00:44 CEST, D. J. Bernstein wrote:

Andrei Popov writes:

I support this change, willing to implement it in the Windows TLS
stack. We have thousands of customers concerned about increased
latencies due to the enablement of TLS 1.3. The services they connect
to require NIST curves and HRR is required to get TLS clients to send
appropriate key shares.


To clarify, when you say "require NIST curves", do you mean "require
conformance with NIST SP 800-56A"?


really depends on the deployment, some just want to use SP 800-56A curves,
some need actual, real, to the letter, legal compliance with FIPS 140-2 or
FIPS 140-3.


In other words, will another curve be allowed once it's added to NIST
SP 800-56A? Maybe faster: would the short-term problem be addressed if
we can convince NIST to announce that it will consider X25519 and X448
for a revision of SP 800-56A, and doesn't intend to enforce conformance
of cryptographic modules with SP 800-56A until the revisions are done?


Short-term problem won't be solved like that for everybody. For
deployments that require FIPS compliance, the implementation itself needs
to be certified. At this moment there's no way to get it certified, so we
are at least 2-3 years away from a certified implementation of x25519
being available even if NIST marked x25519 as approved tomorrow.


Or are you saying that, independently of NIST's decisions, the services
in question are for some reason specifically requiring what's typically
called the "NIST curves", namely the fifteen NSA curves that NIST
standardized? Or the subset of those that NIST hasn't deprecated yet?


Because NIST is a trend-setter, many other compliance organisations
reuse those curves (French ANSSI, German BSI, Japanese IPA, etc.). 
Similarly
Common Criteria certifications, while they're international, they're 
similarly

heavily influenced by what NIST and NSA recommends. All of them will have
a lot of inertia.

And to address what John Mattsson wrote in a separate email: yes, IETF is
international and should not be bound by particular government requirements
for IETF standards to be actually usable in practice, they do need to
take into account what governmental bodies require. What gets published
by IETF can be superset of what govs want.

So, while I'd love to see x25519 in governmental standards, I think it's
better to spend energy making sure that we deploy ML-KEM as soon as 
possible,
in hybrid mode, both with x25519 *and* NIST curves (at the very least P-256 
and

P-384).

--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

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

[TLS]Re: Curve-popularity data?

[Hubert Kario]

On Thursday, 6 June 2024 00:57:52 CEST, A A wrote:
"E.g. a client might also have legitimate reasons to nudge 
servers to use a stronger curve than P-256 in the initial CH and 
only fall back to weaker curves by explicit request via HRR. 
Probably the reason for Chrome for requesting HRR for P-256 is 
the attempt to nudge servers to use an algorithm which is 
believed to provide advantages for the client-side 
implementation (possibly both, speed/power or security or 
bandwidth) in comparison to P-256."
 
About speed: https://bench.cr.yp.to/results-dh.html shows that 
on amd64; Zen 4 (a60f12); 2023 AMD Ryzen 7 7700; 8 x 3800MHz; 
hertz, supercop-20240425,
 
nistp256(P-256) needs 202616 cycles to generate a key pair, 
535274 cycles to compute a shared secret;
Curve25519 needs 101289cycles to generate a key pair, 109491 
cycles to compute a shared secret;
 
And, X25519's key share only need 32 bytes, P-256 needs 65 
bytes. Conclusion: P-256 neither has security nor performance 
(power) advantage compare with X25519.


That's not the performance delta I see in practice.

Fedora 39, openssl-3.1.1-4.fc39.x86_64, i7-10850H
x25519 derive shared secret: 35062.2 op/s
P-256 derive shared secret: 22741.1 op/s

(run `openssl speed ecdhp256; openssl speed ecdhx25519` to try yourself)



05.06.2024, 22:05, "Björn Haase" 
:

Hi Eric, Hi all,


One more thing: we are finalizing RFC 8446-bis right now, so if there is
WG consensus to require that clients offer all MTI curves in the key_shares
of their initial CH, then that would be a straightforward text change. 


I think that we might rather keep a mechanism that preserves 
the possibility of the client-side to express a preference 
regarding a specific cipher suite / curve and accept other 
curves only using the HRR-mechanism.


E.g. a client might also have legitimate reasons to nudge 
servers to use a stronger curve than P-256 in the initial CH and 
only fall back to weaker curves by explicit request via HRR. 
Probably the reason for Chrome for requesting HRR for P-256 is 
the attempt to nudge servers to use an algorithm which is 
believed to provide advantages for the client-side 
implementation (possibly both, speed/power or security or 
bandwidth) in comparison to P-256.


Björn.





Mit freundlichen Grüßen | Best Regards

Dr. Björn Haase

Senior Expert Electronics | TGREH Electronics Hardware

Endress+Hauser Liquid Analysis

Endress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839 
Gerlingen | Germany

Phone: +49 7156 209 10377
bjoern.ha...@endress.com | www.ehla.endress.com 



Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta
Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu 
informieren, wenn wir personenbezogene Daten von Ihnen erheben.


Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis nach.

 


Disclaimer:

The information transmitted is intended only for the person or 
entity to which it is addressed and may contain confidential, 
proprietary, and/or privileged
material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon, this 
information by persons or entities
other than the intended recipient is prohibited. If you receive 
this in error, please contact the sender and delete the material 
from any computer.
This e-mail does not constitute a contract offer, a contract 
amendment, or an acceptance of a contract offer unless 
explicitly and conspicuously designated or stated as such.


 


,


--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

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

[TLS]Re: Curve-popularity data?

[A A]

More irony, X448, a ~224-bit security level curve, on Zen 4 (a60f12); 2023 AMD Ryzen 7 7700; 8 x 3800MHz; hertz, supercop-20240425, only needs 161176 cycles to generate a key pair, 530428 cycles to compute a shared secret, still faster than P-256, and it provide ~224-bit security level.06.06.2024, 06:58, "A A" :"E.g. a client might also have legitimate reasons to nudge servers to use a stronger curve than P-256 in the initial CH and only fall back to weaker curves by explicit request via HRR. Probably the reason for Chrome for requesting HRR for P-256 is the attempt to nudge servers to use an algorithm which is believed to provide advantages for the client-side implementation (possibly both, speed/power or security or bandwidth) in comparison to P-256." About speed: https://bench.cr.yp.to/results-dh.html shows that on amd64; Zen 4 (a60f12); 2023 AMD Ryzen 7 7700; 8 x 3800MHz; hertz, supercop-20240425,  nistp256(P-256) needs 202616 cycles to generate a key pair, 535274 cycles to compute a shared secret;Curve25519 needs 101289cycles to generate a key pair, 109491 cycles to compute a shared secret; And, X25519's key share only need 32 bytes, P-256 needs 65 bytes. Conclusion: P-256 neither has security nor performance (power) advantage compare with X25519.05.06.2024, 22:05, "Björn Haase" :

Hi Eric, Hi all,

>One more thing: we are finalizing RFC 8446-bis right now, so if there is
>WG consensus to require that clients offer all MTI curves in the key_shares
>of their initial CH, then that would be a straightforward text change. 

I think that we might rather keep a mechanism that preserves the possibility of the client-side to express a preference regarding a specific cipher suite / curve and accept other curves only using the HRR-mechanism.

E.g. a client might also have legitimate reasons to nudge servers to use a stronger curve than P-256 in the initial CH and only fall back to weaker curves by explicit request via HRR. Probably the reason for Chrome for requesting HRR for P-256 is the attempt
 to nudge servers to use an algorithm which is believed to provide advantages for the client-side implementation (possibly both, speed/power or security or bandwidth) in comparison to P-256.

Björn.







Mit freundlichen Grüßen | Best Regards 
Dr. Björn Haase 

Senior Expert Electronics | TGREH Electronics HardwareEndress+Hauser Liquid AnalysisEndress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839 Gerlingen | GermanyPhone: +49 7156 209 10377bjoern.ha...@endress.com |  www.ehla.endress.com 
Endress+Hauser Conducta GmbH+Co.KGAmtsgericht Stuttgart HRA 201908Sitz der Gesellschaft: GerlingenPersönlich haftende Gesellschafterin:Endress+Hauser ConductaVerwaltungsgesellschaft mbHSitz der Gesellschaft: GerlingenAmtsgericht Stuttgart HRA 201929Geschäftsführer: Dr. Manfred Jagiella

Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis nach.

 Disclaimer: 
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privilegedmaterial. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entitiesother than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer.This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.
 
,___TLS mailing list -- tls@ietf.orgTo unsubscribe send an email to tls-le...@ietf.org,___TLS mailing list -- tls@ietf.orgTo 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: Curve-popularity data?

[A A]

"E.g. a client might also have legitimate reasons to nudge servers to use a stronger curve than P-256 in the initial CH and only fall back to weaker curves by explicit request via HRR. Probably the reason for Chrome for requesting HRR for P-256 is the attempt to nudge servers to use an algorithm which is believed to provide advantages for the client-side implementation (possibly both, speed/power or security or bandwidth) in comparison to P-256." About speed: https://bench.cr.yp.to/results-dh.html shows that on amd64; Zen 4 (a60f12); 2023 AMD Ryzen 7 7700; 8 x 3800MHz; hertz, supercop-20240425,  nistp256(P-256) needs 202616 cycles to generate a key pair, 535274 cycles to compute a shared secret;Curve25519 needs 101289cycles to generate a key pair, 109491 cycles to compute a shared secret; And, X25519's key share only need 32 bytes, P-256 needs 65 bytes. Conclusion: P-256 neither has security nor performance (power) advantage compare with X25519.05.06.2024, 22:05, "Björn Haase" :

Hi Eric, Hi all,

>One more thing: we are finalizing RFC 8446-bis right now, so if there is
>WG consensus to require that clients offer all MTI curves in the key_shares
>of their initial CH, then that would be a straightforward text change. 

I think that we might rather keep a mechanism that preserves the possibility of the client-side to express a preference regarding a specific cipher suite / curve and accept other curves only using the HRR-mechanism.

E.g. a client might also have legitimate reasons to nudge servers to use a stronger curve than P-256 in the initial CH and only fall back to weaker curves by explicit request via HRR. Probably the reason for Chrome for requesting HRR for P-256 is the attempt
 to nudge servers to use an algorithm which is believed to provide advantages for the client-side implementation (possibly both, speed/power or security or bandwidth) in comparison to P-256.

Björn.







Mit freundlichen Grüßen | Best Regards 
Dr. Björn Haase 

Senior Expert Electronics | TGREH Electronics HardwareEndress+Hauser Liquid AnalysisEndress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839 Gerlingen | GermanyPhone: +49 7156 209 10377bjoern.ha...@endress.com |  www.ehla.endress.com 
Endress+Hauser Conducta GmbH+Co.KGAmtsgericht Stuttgart HRA 201908Sitz der Gesellschaft: GerlingenPersönlich haftende Gesellschafterin:Endress+Hauser ConductaVerwaltungsgesellschaft mbHSitz der Gesellschaft: GerlingenAmtsgericht Stuttgart HRA 201929Geschäftsführer: Dr. Manfred Jagiella

Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis nach.

 Disclaimer: 
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privilegedmaterial. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entitiesother than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer.This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.
 
,___TLS mailing list -- tls@ietf.orgTo 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: Curve-popularity data?

[D. J. Bernstein]

Andrei Popov writes:
> I support this change, willing to implement it in the Windows TLS
> stack. We have thousands of customers concerned about increased
> latencies due to the enablement of TLS 1.3. The services they connect
> to require NIST curves and HRR is required to get TLS clients to send
> appropriate key shares.

To clarify, when you say "require NIST curves", do you mean "require
conformance with NIST SP 800-56A"? 

In other words, will another curve be allowed once it's added to NIST
SP 800-56A? Maybe faster: would the short-term problem be addressed if
we can convince NIST to announce that it will consider X25519 and X448
for a revision of SP 800-56A, and doesn't intend to enforce conformance
of cryptographic modules with SP 800-56A until the revisions are done?

Or are you saying that, independently of NIST's decisions, the services
in question are for some reason specifically requiring what's typically
called the "NIST curves", namely the fifteen NSA curves that NIST
standardized? Or the subset of those that NIST hasn't deprecated yet?

Thanks in advance for the clarification.

---D. J. Bernstein

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

[TLS]Re: Curve-popularity data?

[Andrei Popov]

I support this change, willing to implement it in the Windows TLS stack. We 
have thousands of customers concerned about increased latencies due to the 
enablement of TLS 1.3. The services they connect to require NIST curves and HRR 
is required to get TLS clients to send appropriate key shares. TLS 1.3 with HRR 
is somewhat higher-latency than TLS 1.2 full handshake, so TLS 1.3 deployment 
causes performance regressions for these customers.

(Of course, TLS key share prediction could override this, when the server's DNS 
record indicates no P256 support. The key share prediction draft can include 
this provision.)

Cheers,

Andrei

-Original Message-
From: Peter Gutmann  
Sent: Wednesday, June 5, 2024 6:54 AM
To: Eric Rescorla 
Cc: tls@ietf.org
Subject: [EXTERNAL] [TLS]Re: Curve-popularity data?

Eric Rescorla  writes:

>One more thing: we are finalizing RFC 8446-bis right now, so if there 
>is WG consensus to require that clients offer all MTI curves in the 
>key_shares of their initial CH, then that would be a straightforward text 
>change.

That would fix things, something like saying a client has to provide at least 
one MTI cipher suite/signature/keyex in its client hello.  There's only one MTI 
curve in 8446 so "all MTI curves" isn't a big deal.

Peter.
___
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: Curve-popularity data?

[Andrei Popov]

  *   I think that we might rather keep a mechanism that preserves the 
possibility of the client-side to express a preference regarding a specific 
cipher suite / curve and accept other curves only using the HRR-mechanism.

The proposed change does not take away the client's ability to express 
preferences (the list of supported groups is prioritized), nor does it take 
away the client's ability to accept other groups via HRR.


  "When sent by the client, the "supported_groups" extension indicates
   the named groups which the client supports for key exchange, ordered
   from most preferred to least preferred."


From: Björn Haase 
Sent: Wednesday, June 5, 2024 7:04 AM
To: Eric Rescorla ; Peter Gutmann 
Cc: tls@ietf.org
Subject: [EXTERNAL] [TLS]Re: Curve-popularity data?

You don't often get email from 
bjoern.haase=40endress@dmarc.ietf.org<mailto:bjoern.haase=40endress@dmarc.ietf.org>.
 Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Hi Eric, Hi all,

>One more thing: we are finalizing RFC 8446-bis right now, so if there is
>WG consensus to require that clients offer all MTI curves in the key_shares
>of their initial CH, then that would be a straightforward text change.

I think that we might rather keep a mechanism that preserves the possibility of 
the client-side to express a preference regarding a specific cipher suite / 
curve and accept other curves only using the HRR-mechanism.

E.g. a client might also have legitimate reasons to nudge servers to use a 
stronger curve than P-256 in the initial CH and only fall back to weaker curves 
by explicit request via HRR. Probably the reason for Chrome for requesting HRR 
for P-256 is the attempt to nudge servers to use an algorithm which is believed 
to provide advantages for the client-side implementation (possibly both, 
speed/power or security or bandwidth) in comparison to P-256.

Björn.





Mit freundlichen Grüßen | Best Regards

Dr. Björn Haase



Senior Expert Electronics | TGREH Electronics Hardware

Endress+Hauser Liquid Analysis

Endress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839 Gerlingen | 
Germany
Phone: +49 7156 209 10377
bjoern.ha...@endress.com<mailto:bjoern.ha...@endress.com> | 
www.ehla.endress.com<http://www.ehla.endress.com/>



Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta
Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella



Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, 
wenn wir personenbezogene Daten von Ihnen erheben.

Dieser Informationspflicht kommen wir mit folgendem 
Datenschutzhinweis<https://www.de.endress.com/de/cookies-endress+hauser-website>
 nach.





Disclaimer:

The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential, proprietary, and/or privileged
material. Any review, retransmission, dissemination or other use of, or taking 
of any action in reliance upon, this information by persons or entities
other than the intended recipient is prohibited. If you receive this in error, 
please contact the sender and delete the material from any computer.
This e-mail does not constitute a contract offer, a contract amendment, or an 
acceptance of a contract offer unless explicitly and conspicuously designated 
or stated as such.


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

[TLS]Re: Curve-popularity data?

[Sean Turner]

Hi! I sent a similar message a couple of weeks ago, but I think thread warrants 
the same kind of message:

Let’s clam it down some.  A gentle reminder to keep it professional; see the 
IETF Guidelines for Conduct (RFC 7154).

I would also like to note that discussion of various algorithms merits and 
usage is appropriate for this list. However, please keep the discussion focused 
on the technical issues and not stray into speculation on the personal 
motivation of statements made here or in other forums.

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

[TLS]Re: Curve-popularity data?

[Hubert Kario]

On Wednesday, 5 June 2024 15:38:57 CEST, Eric Rescorla wrote:



On Wed, Jun 5, 2024 at 6:35 AM Eric Rescorla  wrote:


On Wed, Jun 5, 2024 at 6:19 AM Peter Gutmann 
 wrote:

Nick Harper  writes:


I see no requirement in section 9 nor in section 4.2.8 requiring MTI curves
be present in the key_share extension if that extension is non-empty.


Just because it's possible to rules-lawyer your way around something doesn't
make it valid (I also see nothing in the spec saying a TLS 1.3 
implementation

can't reformat your hard drive, for example, so presumably that's OK too).
The point is that P256 is a MTI algorithm and Chrome doesn't provide any MTI
keyex in its client hello, making it a noncompliant TLS 1.3 implementation.

I don't believe this analysis is correct. You state:

As Nick notes, RFC 8446 explicitly permits the extension to be empty, so
it clearly cannot be the case that mere failure to provide an MTI key_share
in CH makes an implementation noncompliant, contra your statement above.

The only question at hand is whether the specification permits you to send
a non-empty key_shares field that excludes the MTI. However, 
the specification

*also* permits you to send a subset of supported groups:

   the same order.  However, the values MAY be a non-contiguous subset
   of the "supported_groups" extension and MAY omit the most preferred
   groups.  Such a situation could arise if the most preferred groups

I think the best reading of this text is that you are free to send *any*
subset of the supported groups, whether it includes the MTI or not.

The requirement in S 9.1 is merely that the application "support
key exchange with secp256r1", which Chrome does: it's in "supported_groups"
and (presumably) works if the server sends an HRR. Given the above
more explicit text about "key_shares", I don't think it's reasonable to
infer that MTI requires more than this.

This isn't to say anything about whether this is the best 
implementation choice,

which is a distinct question from what the specification requires.

One more thing: we are finalizing RFC 8446-bis right now, so if there is
WG consensus to require that clients offer all MTI curves in the key_shares
of their initial CH, then that would be a straightforward text change. 


I definitely don't agree with such a requirement.

--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

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

[TLS]Re: Curve-popularity data?

[Bas Westerbaan]

>
>
>
> One more thing: we are finalizing RFC 8446-bis right now, so if there is
> WG consensus to require that clients offer all MTI curves in the key_shares
> of their initial CH, then that would be a straightforward text change.
>
> I think we are closer to going in the other direction and allow TLS1.3
> spec-compliant implementations aiming at post-quantum support to drop
> support for P-256 entirely.
>
Agreed.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Dennis Jackson]

Hi Peter, Mike

Peter Gutmann wrote:


Just because it's possible to rules-lawyer your way around something doesn't
make it valid (I also see nothing in the spec saying a TLS 1.3 implementation
can't reformat your hard drive, for example, so presumably that's OK too).
The point is that P256 is a MTI algorithm and Chrome doesn't provide any MTI
keyex in its client hello, making it a noncompliant TLS 1.3 implementation.


As Nick quoted from the spec:


A TLS-compliant application MUST support key exchange with secp256r1 (NIST 
P-256)
Chrome advertises support for P-256 in the supported groups extension. 
As a factual matter, Chrome can successfully connect to a site that only 
implements support for P-256. I cannot find any basis for Peter's claims 
in the spec.


Ekr wrote:


One more thing: we are finalizing RFC 8446-bis right now, so if there is
WG consensus to require that clients offer all MTI curves in the 
key_shares

of their initial CH, then that would be a straightforward text change.


I think we are closer to going in the other direction and allow TLS1.3 
spec-compliant implementations aiming at post-quantum support to drop 
support for P-256 entirely.


Best,
Dennis

On 05/06/2024 14:34, Peter Gutmann wrote:

Mike Shaver  writes:


You mentioned in another message that some embedded TLS implementations also
omit MTI support for code size or attack surface reasons.

They don't omit MTI support, they *only* support MTI (think Grigg's Law,
"there is only one mode and that is secure").  So when faced with an
implementation that doesn't, they can't talk to each other.


do you have any sense of why Chrome chose to omit this MTI support?

I suspect it's just because Google does whatever Google wants to (see e.g.
https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shattered-dream/,
section "The Warnings").  This may not be politically expendient to say out
loud :-).

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

[TLS]Re: Curve-popularity data?

[Björn Haase]

Hi Eric, Hi all,

>One more thing: we are finalizing RFC 8446-bis right now, so if there is
>WG consensus to require that clients offer all MTI curves in the key_shares
>of their initial CH, then that would be a straightforward text change.

I think that we might rather keep a mechanism that preserves the possibility of 
the client-side to express a preference regarding a specific cipher suite / 
curve and accept other curves only using the HRR-mechanism.

E.g. a client might also have legitimate reasons to nudge servers to use a 
stronger curve than P-256 in the initial CH and only fall back to weaker curves 
by explicit request via HRR. Probably the reason for Chrome for requesting HRR 
for P-256 is the attempt to nudge servers to use an algorithm which is believed 
to provide advantages for the client-side implementation (possibly both, 
speed/power or security or bandwidth) in comparison to P-256.

Björn.









Mit freundlichen Grüßen | Best Regards 

Dr. Björn Haase 


Senior Expert Electronics | TGREH Electronics Hardware

Endress+Hauser Liquid Analysis

Endress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839 Gerlingen | 
Germany
Phone: +49 7156 209 10377
bjoern.ha...@endress.com |  www.ehla.endress.com 



Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

 
Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, 
wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis 
(https://www.endress.com/de/cookies-endress+hauser-website) nach.

 

Disclaimer: 

The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential, proprietary, and/or privileged 
material. Any review, retransmission, dissemination or other use of, or taking 
of any action in reliance upon, this information by persons or entities other 
than the intended recipient is prohibited. If you receive this in error, please 
contact the sender and delete the material from any computer. This e-mail does 
not constitute a contract offer, a contract amendment, or an acceptance of a 
contract offer unless explicitly and conspicuously designated or stated as such.
 
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Eric Rescorla]

On Wed, Jun 5, 2024 at 6:54 AM Peter Gutmann 
wrote:

> Eric Rescorla  writes:
>
> >One more thing: we are finalizing RFC 8446-bis right now, so if there is
> WG
> >consensus to require that clients offer all MTI curves in the key_shares
> of
> >their initial CH, then that would be a straightforward text change.
>
> That would fix things, something like saying a client has to provide at
> least
> one MTI cipher suite/signature/keyex in its client hello.  There's only one
> MTI curve in 8446 so "all MTI curves" isn't a big deal.
>

I have filed https://github.com/tlswg/tls13-spec/issues/1358 to record this
and will start a separate thread.

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

[TLS]Re: Curve-popularity data?

[Peter Gutmann]

Eric Rescorla  writes:

>One more thing: we are finalizing RFC 8446-bis right now, so if there is WG
>consensus to require that clients offer all MTI curves in the key_shares of
>their initial CH, then that would be a straightforward text change.

That would fix things, something like saying a client has to provide at least
one MTI cipher suite/signature/keyex in its client hello.  There's only one
MTI curve in 8446 so "all MTI curves" isn't a big deal.

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

[TLS]Re: Curve-popularity data?

[John Mattsson]

My interpretation is the same as EKR. Chrome’s behavior seems compliant to me. 
I also think Chrome’s behavior makes sense and I think Chrome should continue 
doing that. The server’s Peter talk about do on the other hand not follow the 
implementation guidance in Appendix C.



C.3<https://datatracker.ietf.org/doc/html/rfc8446#appendix-C.3>.  
Implementation Pitfalls



   Implementation experience has shown that certain parts of earlier TLS

   specifications are not easy to understand and have been a source of

   interoperability and security problems.  Many of these areas have

   been clarified in this document, but this appendix contains a short

   list of the most important things that require special attention from

   implementors.

   ...

   -  As a server, do you send a HelloRetryRequest to clients which
  support a compatible (EC)DHE group but do not predict it in the
  "key_share" extension?  As a client, do you correctly handle a
  HelloRetryRequest from the server?


From: Eric Rescorla 
Date: Wednesday, 5 June 2024 at 15:44
To: Peter Gutmann 
Cc: tls@ietf.org 
Subject: [TLS]Re: Curve-popularity data?


On Wed, Jun 5, 2024 at 6:19 AM Peter Gutmann 
mailto:pgut...@cs.auckland.ac.nz>> wrote:
Nick Harper mailto:i...@nharper.org>> writes:

>I see no requirement in section 9 nor in section 4.2.8 requiring MTI curves
>be present in the key_share extension if that extension is non-empty.

Just because it's possible to rules-lawyer your way around something doesn't
make it valid (I also see nothing in the spec saying a TLS 1.3 implementation
can't reformat your hard drive, for example, so presumably that's OK too).
The point is that P256 is a MTI algorithm and Chrome doesn't provide any MTI
keyex in its client hello, making it a noncompliant TLS 1.3 implementation.

I don't believe this analysis is correct. You state:

As Nick notes, RFC 8446 explicitly permits the extension to be empty, so
it clearly cannot be the case that mere failure to provide an MTI key_share
in CH makes an implementation noncompliant, contra your statement above.

The only question at hand is whether the specification permits you to send
a non-empty key_shares field that excludes the MTI. However, the specification
*also* permits you to send a subset of supported groups:

   the same order.  However, the values MAY be a non-contiguous subset
   of the "supported_groups" extension and MAY omit the most preferred
   groups.  Such a situation could arise if the most preferred groups

I think the best reading of this text is that you are free to send *any*
subset of the supported groups, whether it includes the MTI or not.

The requirement in S 9.1 is merely that the application "support
key exchange with secp256r1", which Chrome does: it's in "supported_groups"
and (presumably) works if the server sends an HRR. Given the above
more explicit text about "key_shares", I don't think it's reasonable to
infer that MTI requires more than this.

This isn't to say anything about whether this is the best implementation choice,
which is a distinct question from what the specification requires.

-Ekr


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

[TLS]Re: Curve-popularity data?

[Filippo Valsorda]

2024-06-05 15:17 GMT+02:00 Peter Gutmann :
> Nick Harper  writes:
> 
> >I see no requirement in section 9 nor in section 4.2.8 requiring MTI curves
> >be present in the key_share extension if that extension is non-empty.
> 
> Just because it's possible to rules-lawyer your way around something doesn't
> make it valid (I also see nothing in the spec saying a TLS 1.3 implementation
> can't reformat your hard drive, for example, so presumably that's OK too).
> The point is that P256 is a MTI algorithm and Chrome doesn't provide any MTI
> keyex in its client hello, making it a noncompliant TLS 1.3 implementation.

This is not rules lawyering. P-256 is MTI as a supported group, and Chrome 
supports it and will successfully negotiate with a server that only supports 
P-256 (through a Hello Retry Request, which is a perfectly valid—if 
inefficient—mechanism). That's following both the letter and the spirit of the 
MTI requirement. If the spec wanted to make a key share mandatory, it could 
have said so.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Eric Rescorla]

On Wed, Jun 5, 2024 at 6:35 AM Eric Rescorla  wrote:

>
>
> On Wed, Jun 5, 2024 at 6:19 AM Peter Gutmann 
> wrote:
>
>> Nick Harper  writes:
>>
>> >I see no requirement in section 9 nor in section 4.2.8 requiring MTI
>> curves
>> >be present in the key_share extension if that extension is non-empty.
>>
>> Just because it's possible to rules-lawyer your way around something
>> doesn't
>> make it valid (I also see nothing in the spec saying a TLS 1.3
>> implementation
>> can't reformat your hard drive, for example, so presumably that's OK too).
>> The point is that P256 is a MTI algorithm and Chrome doesn't provide any
>> MTI
>> keyex in its client hello, making it a noncompliant TLS 1.3
>> implementation.
>>
>
> I don't believe this analysis is correct. You state:
>
> As Nick notes, RFC 8446 explicitly permits the extension to be empty, so
> it clearly cannot be the case that mere failure to provide an MTI key_share
> in CH makes an implementation noncompliant, contra your statement above.
>
> The only question at hand is whether the specification permits you to send
> a non-empty key_shares field that excludes the MTI. However, the
> specification
> *also* permits you to send a subset of supported groups:
>
>the same order.  However, the values MAY be a non-contiguous subset
>of the "supported_groups" extension and MAY omit the most preferred
>groups.  Such a situation could arise if the most preferred groups
>
> I think the best reading of this text is that you are free to send *any*
> subset of the supported groups, whether it includes the MTI or not.
>
> The requirement in S 9.1 is merely that the application "support
> key exchange with secp256r1", which Chrome does: it's in "supported_groups"
> and (presumably) works if the server sends an HRR. Given the above
> more explicit text about "key_shares", I don't think it's reasonable to
> infer that MTI requires more than this.
>
> This isn't to say anything about whether this is the best implementation
> choice,
> which is a distinct question from what the specification requires.
>

One more thing: we are finalizing RFC 8446-bis right now, so if there is
WG consensus to require that clients offer all MTI curves in the key_shares
of their initial CH, then that would be a straightforward text change.

That might be a more productive discussion than debating whether Chrome is
compliant with the specification as it currently stands.

-Ekr


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

[TLS]Re: Curve-popularity data?

[Eric Rescorla]

On Wed, Jun 5, 2024 at 6:19 AM Peter Gutmann 
wrote:

> Nick Harper  writes:
>
> >I see no requirement in section 9 nor in section 4.2.8 requiring MTI
> curves
> >be present in the key_share extension if that extension is non-empty.
>
> Just because it's possible to rules-lawyer your way around something
> doesn't
> make it valid (I also see nothing in the spec saying a TLS 1.3
> implementation
> can't reformat your hard drive, for example, so presumably that's OK too).
> The point is that P256 is a MTI algorithm and Chrome doesn't provide any
> MTI
> keyex in its client hello, making it a noncompliant TLS 1.3 implementation.
>

I don't believe this analysis is correct. You state:

As Nick notes, RFC 8446 explicitly permits the extension to be empty, so
it clearly cannot be the case that mere failure to provide an MTI key_share
in CH makes an implementation noncompliant, contra your statement above.

The only question at hand is whether the specification permits you to send
a non-empty key_shares field that excludes the MTI. However, the
specification
*also* permits you to send a subset of supported groups:

   the same order.  However, the values MAY be a non-contiguous subset
   of the "supported_groups" extension and MAY omit the most preferred
   groups.  Such a situation could arise if the most preferred groups

I think the best reading of this text is that you are free to send *any*
subset of the supported groups, whether it includes the MTI or not.

The requirement in S 9.1 is merely that the application "support
key exchange with secp256r1", which Chrome does: it's in "supported_groups"
and (presumably) works if the server sends an HRR. Given the above
more explicit text about "key_shares", I don't think it's reasonable to
infer that MTI requires more than this.

This isn't to say anything about whether this is the best implementation
choice,
which is a distinct question from what the specification requires.

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

[TLS]Re: Curve-popularity data?

[Peter Gutmann]

Mike Shaver  writes:

>You mentioned in another message that some embedded TLS implementations also
>omit MTI support for code size or attack surface reasons.

They don't omit MTI support, they *only* support MTI (think Grigg's Law,
"there is only one mode and that is secure").  So when faced with an
implementation that doesn't, they can't talk to each other.

>do you have any sense of why Chrome chose to omit this MTI support?

I suspect it's just because Google does whatever Google wants to (see e.g.
https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shattered-dream/,
section "The Warnings").  This may not be politically expendient to say out
loud :-).

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

[TLS]Re: Curve-popularity data?

[Mike Shaver]

On Wed, Jun 5, 2024 at 9:19 AM Peter Gutmann 
wrote:

> Nick Harper  writes:
>
> >I see no requirement in section 9 nor in section 4.2.8 requiring MTI
> curves
> >be present in the key_share extension if that extension is non-empty.
>
> Just because it's possible to rules-lawyer your way around something
> doesn't
> make it valid (I also see nothing in the spec saying a TLS 1.3
> implementation
> can't reformat your hard drive, for example, so presumably that's OK too).
> The point is that P256 is a MTI algorithm and Chrome doesn't provide any
> MTI
> keyex in its client hello, making it a noncompliant TLS 1.3 implementation.


Hi Peter,

As you describe it, this seems like a somewhat material issue in Chrome’s
TLS 1.3 support, which I confess is surprising to hear about given Google’s
experience and level of investment in that space.

You mentioned in another message that some embedded TLS implementations
also omit MTI support for code size or attack surface reasons. Not to ask
you to speak for Chrome (though perhaps someone else on this list might be
able to!), but do you have any sense of why Chrome chose to omit this MTI
support?

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

[TLS]Re: Curve-popularity data?

[Peter Gutmann]

Nick Harper  writes:

>I see no requirement in section 9 nor in section 4.2.8 requiring MTI curves
>be present in the key_share extension if that extension is non-empty.

Just because it's possible to rules-lawyer your way around something doesn't
make it valid (I also see nothing in the spec saying a TLS 1.3 implementation
can't reformat your hard drive, for example, so presumably that's OK too).
The point is that P256 is a MTI algorithm and Chrome doesn't provide any MTI
keyex in its client hello, making it a noncompliant TLS 1.3 implementation.

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

[TLS]Re: Curve-popularity data?

[D. J. Bernstein]

Richard Barnes writes:
> Popularity of algorithms is entirely
> irrelevant to this working group's charter.

To clarify, are you saying that there was some relevant charter change
after the extensive TLS WG discussions that decided on the algorithms to
include in TLS 1.3---which, naturally, included discussions of algorithm
popularity? If so, can you please say which change you're referring to?
Thanks in advance.

---D. J. Bernstein

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

[TLS]Re: Curve-popularity data?

[Eric Rescorla]

I largely agree with Richard here.

To recap some basic facts

0. TLS is algorithm agile and Supported Groups [0] are listed in an IANA
registry
1. The TLS Supported Groups registry has the "Specification Required"
policy which means that in practice anyone can register groups.
2. Setting a group to "Recommended=Y" requires IETF Consensus (and hence
the approval of TLS WG). Typically "Recommended=Y" is intended to mean we
think it provides an acceptable security. As background, right now P-256
and X25519 have "Recommended=Y"
3. Making an algorithm mandatory to implement requires IETF Consensus (and
hence the approval of TLS WG). Currently P-256 is MTI, but X25519 is not.

I find it fairly hard to believe that there will not be settings in which
people want to use both X25519+ML-KEM and P-256+ML-KEM, just as they do
X25519 and P-256 now, so I would certainly expect that we would see code
point registrations for both, with the question being whether the TLS WG
takes them up. The TLS WG could obviously choose not to document one of
these hybrids but not the other, but assuming that there is demand, I think
the most reasonable thing to do would be to document them both and mark
them both Recommended=Y. I haven't heard a proposal to mark *either* MTI,
so that discussion may be premature. I agree with Richard and others that
the precise deployment numbers probably aren't dispositive on whether we
should publish and/or standardize each of these.

-Ekr

[0] TLS models hybrids as if they were EC groups.

On Tue, Jun 4, 2024 at 11:58 AM Richard Barnes  wrote:

> This WG does not get to decide which hybrids will exist or be
> standardized, unless it has implications on the TLS protocol, which it does
> not.
>
> --RLB
>
> On Tue, Jun 4, 2024 at 2:51 PM Salz, Rich  wrote:
>
>> I urge the chairs to call cloture on this thread.  There is nothing
>> relevant for the working group here.
>>
>>
>>
>> I think that is premature.  Yes, there is a lot of noise, but it was only
>> one or two days ago that reasons for hybrids with both P256 and X25519 were
>> given.
>>
> ___
> 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: Curve-popularity data?

[Scott Fluhrer (sfluhrer)]

I would disagree; it does have implications on the TLS protocol.

This working group does make the call as to which combinations it would like to 
specify in an RFC and generate TLS code points for; be it:


  *   P256 + ML-KEM-768
  *   X25519 + MK-KEM-768
  *   Some other combination

And, as it would be reasonable to try to minimize the change to existing 
implementations, it would appear to be reasonable to enquire about the support 
for P256 vs X25519 (in addition to how well they would satisfy other 
requirements, such as compliance and user trust).

As for my two cents (US):

  *   I don’t personally see how relevant it is how often P256 vs X25519 are 
used – if they are both supported by an implementation, then it is plausible to 
assume (lacking further information about the implementation) that an update to 
that implementation would be equally easy in both cases.
  *   Having P256 + ML-KEM-768 on the list would make my employer happier, for 
FIPS compliance reasons.
  *   I believe that it is unreasonable to expect that a single combination 
would satisfy everyone’s needs, hence it would certainly be reasonable to 
allocate multiple code points for different combinations.


From: Richard Barnes 
Sent: Tuesday, June 4, 2024 2:57 PM
To: Salz, Rich 
Cc: Dennis Jackson ; tls@ietf.org
Subject: [TLS]Re: Curve-popularity data?

This WG does not get to decide which hybrids will exist or be standardized, 
unless it has implications on the TLS protocol, which it does not.

--RLB

On Tue, Jun 4, 2024 at 2:51 PM Salz, Rich 
mailto:rs...@akamai.com>> wrote:
I urge the chairs to call cloture on this thread.  There is nothing relevant 
for the working group here.

I think that is premature.  Yes, there is a lot of noise, but it was only one 
or two days ago that reasons for hybrids with both P256 and X25519 were given.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Salz, Rich]

This WG does not get to decide which hybrids will exist or be standardized, 
unless it has implications on the TLS protocol, which it does not.

Then I do not understand what a WG adoption really means.  Please elighten me.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Richard Barnes]

This WG does not get to decide which hybrids will exist or be standardized,
unless it has implications on the TLS protocol, which it does not.

--RLB

On Tue, Jun 4, 2024 at 2:51 PM Salz, Rich  wrote:

> I urge the chairs to call cloture on this thread.  There is nothing
> relevant for the working group here.
>
>
>
> I think that is premature.  Yes, there is a lot of noise, but it was only
> one or two days ago that reasons for hybrids with both P256 and X25519 were
> given.
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Salz, Rich]

I urge the chairs to call cloture on this thread.  There is nothing relevant 
for the working group here.

I think that is premature.  Yes, there is a lot of noise, but it was only one 
or two days ago that reasons for hybrids with both P256 and X25519 were given.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Richard Barnes]

Thanks for refocusing this discussion, Dennis.

To put it even more bluntly: Popularity of algorithms is entirely
irrelevant to this working group's charter.  TLS has algorithm agility.
Even if everyone loves one choice, the protocol doesn't care.  Because some
people might disagree, or the beloved choice might change in the future.
Literally the only say this WG has w.r.t. algorithms is the "Y" bit in the
algorithm registry.  Even the MTIs for TLS 1.3 are fixed until we start up
work on 1.4 or 2.0 or whatever.

I urge the chairs to call cloture on this thread.  There is nothing
relevant for the working group here.

--Richard


On Tue, Jun 4, 2024 at 7:03 AM Dennis Jackson  wrote:

> On 03/06/2024 17:25, D. J. Bernstein wrote:
>
> I'm still puzzled as to what led to the statement that I quoted at the 
> beginning:
>
>P 256 is the most popular curve in the world besides the bitcoin
>curve. And I don’t have head to head numbers, and the bitcoin curve
>is SEC P, but P 256 is most popular curve on the internet. So
>certificates, TLS, handshakes, all of that is like 70 plus percent
>negotiated with the P 256 curve.
>
> Maybe the TLS co-chair has a comment?
>
> On 03/06/2024 22:19, D. J. Bernstein wrote:
>
> As I said, the statement is from one of the current TLS co-chairs, a
> month before the co-chair appointment. The position as co-chair adds to
> the importance of ensuring accurate information.
>
> Dan, this is unsavory conduct. We are here to have reasoned, impersonal
> discussions. Please see in particular the second guideline for conduct at
> the IETF (RFC 7154).
>
> Trying to call out an individual for a comment made informally, in some
> other corner of the internet, some time ago, is rather unbecoming of you
> and looks as though you're trying to use the working group's time and
> energy to settle a playground squabble. Especially when the referenced
> comment was unconnected to any active discussion within the WG or decisions
> made by the chairs.
>
> Your thread has raised two technical & impersonal questions relevant to
> the TLS WG. Let's keep the focus on them:
>
> 1) What cryptographic algorithms are popularly used with TLS today?
>
> 2) Does this popularity matter for deciding which PQ hybrids to
> standardize in TLS?
> ___
> 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: Curve-popularity data?

[D. J. Bernstein]

Dennis Jackson writes:
> Especially when the referenced comment was unconnected to any active
> discussion within the WG or decisions made by the chairs.

Hybrids are an ongoing topic of active discussion within the WG, with
hundreds of messages on the WG mailing list in the past year (including
18 from me before this thread) that simultaneously mention post-quantum
crypto and X25519. Beyond X25519 hybrids, there have been proposals to
use, or at least allow, other curves in hybrids. It's clear that the WG
will end up deciding what exactly to do for TLS.

I designed X25519 in the first place to address various problems created
by the NSA/NIST curves. Subsequent research has found even more reasons
to recommend X25519 over P-256. So, of course, I recommend focusing on
X25519 as the default curve for hybrids, as in the PQ deployment in
OpenSSH, ALTS, etc., rather than using P-256 as in PQ3.

(Sure, NIST took until 2023 to standardize Ed25519 and still hasn't
standardized X25519. But my understanding is that NIST allows X25519+PQ
when the PQ part is a NIST standard. More fundamentally, I think NIST
standards shouldn't be allowed to drag down IETF standards---this would
have stopped TLS from using X25519 in the first place!)

Recently some people have instead been advocating P-256 over X25519---
not just for TLS, but certainly including TLS. See, e.g., the WG email
dated 02 Jun 2024 23:02:39 +0200, confirming that there was already a
plan to raise this on the WG list:

   I actually meant to bring this up ... it would actually make my life
   much easier if the one universal hybrid (and/or default client key
   share) was P-256+ML-KEM-768.

I had, obviously before seeing that email, been pointed to a statement
from October of one of the explicit rationales for considering P-256:

   Should we still use 25519 for all new designs? Or should we take
   seriously at the idea of using the P curves again? ... I think we
   should take seriously because P 256 is the most popular curve in the
   world besides the bitcoin curve. And I don’t have head to head
   numbers, and the bitcoin curve is SEC P, but P 256 is most popular
   curve on the internet. So certificates, TLS, handshakes, all of that
   is like 70 plus percent negotiated with the P 256 curve.

That was in another venue. That venue isn't a mailing list allowing open
discussion. The TLS WG mailing list is an obvious venue for discussion:
the source was appointed TLS co-chair in November; the quote mentions
specifically "TLS, handshakes"; and, again, the TLS WG is certainly
going to be taking action here. So I'm baffled at the notion that this
is off topic for the TLS WG.

I started this thread explicitly asking for the basis for the "world",
"internet", and "handshake" popularity claims quoted above. I would
expect the response to simply be a pointer to the data source (or a
retraction of the claims if they aren't based on data), so that
subsequent decisions can take that information into account.

The TLS measurements that have been posted to the list so far are all
very far from the "70 plus percent" claim, but they also have noticeable
differences from each other (e.g., P-256 is reportedly 15% of the curves
selected by Chrome handshakes on Windows, while other reports give much
smaller percentages of handshakes selecting P-256), so it seems possible
that the claims are coming from different measurements. Such divergence
would be very interesting to study.

---D. J. Bernstein

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

[TLS]Re: Curve-popularity data?

[Kampanakis, Panos]

> and (crucially) for the verified modules with ML-KEM.

True, but the NIST queue is over 2+ years right now. Check out the Modules In 
Process which go back to 2022 
https://csrc.nist.gov/Projects/cryptographic-module-validation-program/modules-in-process/modules-in-process-list
 So, if we only got X25519+ML-KEM we would not be able to use PQ-hybrid in 
endpoints that require compliance for >=2.5 years



From: Bas Westerbaan 
Sent: Monday, June 3, 2024 4:31 PM
To: Stephen Farrell 
Cc: Andrei Popov ; Salz, Rich 
; tls@ietf.org
Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?

X25519+ML-KEM will be acceptable for FIPS, just like P-256+Kyber is today. We 
just need to wait for the final standard, and (crucially) for the verified 
modules with ML-KEM.

On Mon, Jun 3, 2024 at 8:56 PM Stephen Farrell 
mailto:stephen.farr...@cs.tcd.ie>> wrote:

I'm afraid I have no measurements to offer, but...

On 03/06/2024 19:05, Eric Rescorla wrote:
> The question is rather what the minimum set of algorithms we need is. My
>   point is that that has to include P-256. It may well be the case that
> it needs to also include X25519.

Yep, the entirely obvious answer here is we'll end up defining at least
x25519+PQ and p256+PQ. Arguing for one but not the other (in the TLS
WG) seems pretty pointless to me. (That said, the measurements offered
are as always interesting, so the discussion is less pointless than
the argument:-)

Cheers,
S.
___
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: Curve-popularity data?

[Kampanakis, Panos]

+1 .

I was of the impression that 
https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-10#name-iana-considerations
 was going to get final codepoints for both combinations.

Also, “PQ hybrid automatically FIPSed with P256” is an important factor. Using 
a FIPS certified ML-KEM implementation in X25519+MLKEM would address this too, 
but certified implementations of ML-KEM are 2.5+ years out due to NIST’s FIPS 
queue.


From: Eric Rescorla 
Sent: Monday, June 3, 2024 12:31 PM
To: David Adrian 
Cc: Salz, Rich ; tls@ietf.org
Subject: [EXTERNAL] [TLS]Re: Curve-popularity data?


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Indeed. I'd like to pull this back a bit to the question of what we 
specify/mandate.

As I understand the situation, there are a number of environments that require 
P-256, so it seems like it would not be practical to just standardize/mandate 
X25519 + MLKEM if we want to get to 100% PQ algorithms.

-Ekr



On Mon, Jun 3, 2024 at 7:20 AM David Adrian 
mailto:davad...@umich.edu>> wrote:
I don't really see why popularity of previous methods is relevant to picking 
what the necessarily new method will be is, but from the perspective of Chrome 
on Windows, across all ephemeral TCP TLS (1.2 and 1.3, excluding 1.2 RSA), the 
breakdown is roughly:

15% P256
3% P384
56% X25519
26% X25519+Kyber

On Mon, Jun 3, 2024 at 10:05 AM Filippo Valsorda 
mailto:fili...@ml.filippo.io>> wrote:
2024-06-03 15:34 GMT+02:00 Bas Westerbaan 
mailto:b...@cloudflare.com>>:
More importantly, there are servers that will HRR to X25519 if presented a 
P-256 keyshare. (Eg. BoringSSL's default behaviour.) Unfortunately I don't have 
data at hand how often that happens.

Are you saying that some of the 97.6% of servers that support P-256 still HRR 
to X25519 if presented a P-256 keyshare and a {P-256, X25519} supported groups 
list, and that's BoringSSL's default behavior? I find that very surprising and 
would be curious about the rationale.
___
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<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: Curve-popularity data?

[Loganaden Velvindron]

On Tue, 4 Jun 2024 at 09:22, John Mattsson
 wrote:
>
> D. J. Bernstein wrote:
>
> >Again, I understand that certificates haven't upgraded t allowing Ed25519 
> >yet;
>

>
>
> The WebPKI forbids EdDSA and my understanding is that TLS library support is 
> lacking [1], but otherwise I don't think there are any problems with using 
> EdDSA certificates [2] in general. Ericsson is planning to start using 
> EdDSA+PQC hybrids soon. For new systems I think X25519, EdDSA, and SHAKE are 
> superior to P-256, ECDSA, and SHA-2. For existing systems it does not make 
> much sense to update, especially as most systems need to move to PQC 
> signatures soon.
>
>
>
> [1] https://github.com/netty/netty/issues/10916
>
> [2] https://datatracker.ietf.org/doc/html/rfc8410
>
>
Thanks.
> Loganaden Velvindron wrote:
>
> >My personal view is that it's important to have at least one "independent" 
> >curve like X25519
>
>
>
> I am very positive to using X25519 as I think it has better properties than 
> P-256. I am strongly against the idea that TLS needs an "independent" curve. 
> I think the idea that P-256 is backdoored is conspiracy theory nonsense.
>
Hi John,

Who is claiming that P-256 has a backdoor ?


> I really like Filippo Valsorda’s challenge to recover the seeds. I think NSA 
> should take on the challenge and give the bounty to charity. They have the 
> capability to win and they should have an interest in increasing trust in the 
> P-curves.
>
> https://words.filippo.io/dispatches/seeds-bounty/
>
Thanks for sharing.


> Cheers,
>
> John Preuß Mattsson
>
> ___
> 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: Curve-popularity data?

[Dennis Jackson]

On 03/06/2024 17:25, D. J. Bernstein wrote:

I'm still puzzled as to what led to the statement that I quoted at the 
beginning:

P 256 is the most popular curve in the world besides the bitcoin
curve. And I don’t have head to head numbers, and the bitcoin curve
is SEC P, but P 256 is most popular curve on the internet. So
certificates, TLS, handshakes, all of that is like 70 plus percent
negotiated with the P 256 curve.

Maybe the TLS co-chair has a comment?


On 03/06/2024 22:19, D. J. Bernstein wrote:

As I said, the statement is from one of the current TLS co-chairs, a
month before the co-chair appointment. The position as co-chair adds to
the importance of ensuring accurate information.


Dan, this is unsavory conduct. We are here to have reasoned, impersonal 
discussions. Please see in particular the second guideline for conduct 
at the IETF (RFC 7154).


Trying to call out an individual for a comment made informally, in some 
other corner of the internet, some time ago, is rather unbecoming of you 
and looks as though you're trying to use the working group's time and 
energy to settle a playground squabble. Especially when the referenced 
comment was unconnected to any active discussion within the WG or 
decisions made by the chairs.


Your thread has raised two technical & impersonal questions relevant to 
the TLS WG. Let's keep the focus on them:


1) What cryptographic algorithms are popularly used with TLS today?

2) Does this popularity matter for deciding which PQ hybrids to 
standardize in TLS?
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[John Mattsson]

D. J. Bernstein wrote:
>Again, I understand that certificates haven't upgraded t allowing Ed25519 yet;

The WebPKI forbids EdDSA and my understanding is that TLS library support is 
lacking [1], but otherwise I don't think there are any problems with using 
EdDSA certificates [2] in general. Ericsson is planning to start using 
EdDSA+PQC hybrids soon. For new systems I think X25519, EdDSA, and SHAKE are 
superior to P-256, ECDSA, and SHA-2. For existing systems it does not make much 
sense to update, especially as most systems need to move to PQC signatures soon.

[1] https://github.com/netty/netty/issues/10916
[2] https://datatracker.ietf.org/doc/html/rfc8410


Loganaden Velvindron wrote:
>My personal view is that it's important to have at least one "independent" 
>curve like X25519

I am very positive to using X25519 as I think it has better properties than 
P-256. I am strongly against the idea that TLS needs an "independent" curve. I 
think the idea that P-256 is backdoored is conspiracy theory nonsense.

I really like Filippo Valsorda’s challenge to recover the seeds. I think NSA 
should take on the challenge and give the bounty to charity. They have the 
capability to win and they should have an interest in increasing trust in the 
P-curves.

https://words.filippo.io/dispatches/seeds-bounty/

Cheers,
John Preuß Mattsson
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Peter Gutmann]

D. J. Bernstein  writes:

>Sorry, can you please clarify which statistics would be heavily skewed by
>Chrome retrying connections to 0.6% of servers?

Since Chrome does 25519 but not the MTI P256 in its client hello, and Chrome
and the Chrome code base are everywhere, this will skew the statistics in
favor of 25519 because P256 is never even tried.

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

[TLS]Re: Curve-popularity data?

[D. J. Bernstein]

Peter Gutmann writes:
> This will also heavily skew any statistics

Sorry, can you please clarify which statistics would be heavily skewed
by Chrome retrying connections to 0.6% of servers?

Here's why I'm saying 0.6% here: My understanding is that you're talking
specifically about connections from Chrome to servers that support P-256
and not X25519. Cloudflare just said that 97.6% of servers they connect
to support P-256 and 97.0% support X25519. I presume that approximately
all X25519 servers also support P-256 as required by the current specs.

Of course, if there are measurements coming up with a different number
from 0.6%, I'd be interested in seeing that too.

---D. J. Bernstein

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

[TLS]Re: Curve-popularity data?

[D. J. Bernstein]

Dennis Jackson writes:
> This was used by Eli Biham and Lior Neumann to break Bluetooth pairing
> standard back in 2018 [1]. The Bluetooth standard previously said
> implementers could choose to do full point validation or always use
> ephemeral keys, and folks opted for the less complex choice. This isn't a
> clear separator between X25519 and P-256 though, since X25519 would also
> need to reject small order points in order to avoid the same attack.

Unless I'm confused, the attack against Bluetooth's use of P-224 relied
on the fact that Bluetooth's authentication covered only x-coordinates
and failed to cover y-coordinates---so the attacker was free to
manipulate y-coordinates. (And, yes, of course implementors didn't check
whether (x,y) was on the curve.)

X25519 sends just an x-coordinate. Upgrading Bluetooth to X25519 would
have simply scrapped the y-coordinate. Doesn't this mean that the full
points would have been authenticated, stopping the attack? What exactly
do you mean when you say "the same attack"?

To be clear, looking around enough _does_ find literature on protocols
that, unlike the original DH protocol, need "contributory" behavior. In
those protocols, points of low order (e.g., the point at infinity, which
exists on any curve and is allowed by some point encodings) have to be
rejected. The very first version of the Curve25519 web page---

   https://web.archive.org/web/20060210045513/https://cr.yp.to/ecdh.html

---already spelled out the list of inputs to reject for this case:

   How do I validate Curve25519 public keys?

   Don't. The Curve25519 function was carefully designed to allow all
   32-byte strings as Diffie-Hellman public keys. Relevant lower-level
   facts: ... This is discussed in more detail in the curve25519 paper.

   There are some unusual non-Diffie-Hellman elliptic-curve protocols
   that need to ensure "contributory" behavior. In those protocols, you
   should reject the 32-byte strings that, in little-endian form,
   represent 0, 1, [various further numbers], and 2(2^255 - 19) + 1.
   But these exclusions are unnecessary for Diffie-Hellman.

For NSA/NIST ECC, ensuring contributory behavior is considerably more
error-prone: sure, the list of low-order points is shorter per curve,
but people again and again fail to check whether the input (x,y) is on
the curve to begin with, and then the attacker has an infinite pool of
low-order points to exploit. This is also a major reason that NSA/NIST
ECC keeps failing to protect the secrecy of long-term DH keys.

Given how well known the oops-I-forgot-to-check failure mode is, why
isn't every encryption protocol designed to just send an x-coordinate?
Here are two answers:

   * For the NSA/NIST curves, people complain about the implementation
 impact of using x instead of (x,y).

   * Patent 6141420 (filed in 1994, expired 2014) claimed recovery of
 (x,y) from x and limited information about y. There's clear prior
 art (Eurocrypt 1992, page 171), but Certicom was scaring people for
 many years.

Montgomery curves neatly dodge both of these issues: the Montgomery
ladder never looks at y, and it's simpler and faster than any other
approach.

---D. J. Bernstein

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

[TLS]Re: Curve-popularity data?

[Nick Harper]

On Mon, Jun 3, 2024 at 3:02 PM Peter Gutmann 
wrote:

> Filippo Valsorda  writes:
>
> >The most important performance consideration in TLS is avoiding Hello
> Retry
> >Request round-trips due to the server supporting none of the client's key
> >shares.
>
> This is already a huge problem with Chrome because it doesn't support any
> MTI
> curves in its client hello, which means it triggers a hello retry on
> *every*
> *single* *connect* to a compliant implementation.
>

RFC 8446 section 9.1:

> A
> TLS-compliant application MUST support key exchange with secp256r1
> (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].

Section 9.3:

>   -  If containing a "supported_groups" extension, it MUST also contain
>  a "key_share" extension, and vice versa.  An empty
>  KeyShare.client_shares vector is permitted.

Looking at a ClientHello from Chrome, I see secp256r1 in the
supported_groups extension. By my understanding of the RFC, this
ClientHello meets the MTI requirements in RFC 8446. I see no requirement in
section 9 nor in section 4.2.8 requiring MTI curves be present in the
key_share extension if that extension is non-empty. (The RFC is explicit
about permitting the extension to be empty.)

>
> This will also heavily skew any statistics, because Chrome's noncompliant
> behaviour will show up almost everywhere.  So I'm not sure that a
> popularity
> poll on curves has much meaning.
>
> Peter.
> ___
> 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: Curve-popularity data?

[Peter Gutmann]

Filippo Valsorda  writes:

>The most important performance consideration in TLS is avoiding Hello Retry
>Request round-trips due to the server supporting none of the client's key
>shares.

This is already a huge problem with Chrome because it doesn't support any MTI
curves in its client hello, which means it triggers a hello retry on *every*
*single* *connect* to a compliant implementation.

This will also heavily skew any statistics, because Chrome's noncompliant
behaviour will show up almost everywhere.  So I'm not sure that a popularity
poll on curves has much meaning.

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

[TLS]Re: Curve-popularity data?

[D. J. Bernstein]

David Adrian writes:
> I believe we were also discussing _certificates_

Yes, I quoted that from the outset:

   P 256 is the most popular curve in the world besides the bitcoin
   curve. And I don’t have head to head numbers, and the bitcoin curve
   is SEC P, but P 256 is most popular curve on the internet. So
   certificates, TLS, handshakes, all of that is like 70 plus percent
   negotiated with the P 256 curve.

Immediately after quoting that, I wrote the following: "Last I heard,
_certificates_ hadn't upgraded to allowing Ed25519 yet. My question is
about the 'handshake' claim, and more broadly about the 'internet' and
'world' claims."

> you decided to take the comment out of context

No. The specific quote that I had been pointed to was shorter. I looked
at quite a bit of text before and after that, and ended up giving the
longer quote shown above.

If you think that the puzzling aspects of what I quoted are explained by
further context, please give a fuller quote and explain the relevance.
In any event, please refrain from personal attacks. Thanks in advance.

> and single out "the TLS co-chair"

As I said, the statement is from one of the current TLS co-chairs, a
month before the co-chair appointment. The position as co-chair adds to
the importance of ensuring accurate information.

> in a quote that begins with "I don't have the numbers".

Let's look again at what I quoted:

   P 256 is the most popular curve in the world besides the bitcoin
   curve. And I don’t have head to head numbers, and the bitcoin curve
   is SEC P, but P 256 is most popular curve on the internet. So
   certificates, TLS, handshakes, all of that is like 70 plus percent
   negotiated with the P 256 curve.

The reader understands "I don't have head to head numbers" as referring
to P-256 vs. the Bitcoin curve. That's not the part I'm asking about.
Where does the "certificates, TLS, handshakes, all of that is like 70
plus percent negotiated with the P 256 curve" number come from? Where's
the data showing that "P 256 is most popular curve on the internet", or
"in the world besides the bitcoin curve"?

> the utter irrelevance of current popularity of curves to the
> introduction of a _new_ standard

It's obviously not _the same_ question, but I don't agree with the
extreme claim of "utter irrelevance".

The original text also doesn't agree. It says that P-256 should be taken
"seriously" for "new designs" because P-256 is "the most popular curve"
(aside from maybe the Bitcoin curve):

   Should we still use 25519 for all new designs? Or should we take
   seriously at the idea of using the P curves again? ... I think we
   should take seriously because P 256 is the most popular curve in the
   world besides the bitcoin curve. And I don’t have head to head
   numbers, and the bitcoin curve is SEC P, but P 256 is most popular
   curve on the internet. So certificates, TLS, handshakes, all of that
   is like 70 plus percent negotiated with the P 256 curve.

People hearing that P-256 is the most popular curve on the Internet
_presume_ that other curves don't have important advantages, and _worry_
that moving to another curve will incur tremendous startup costs.

Are these guarantees? Of course not. Every solution that takes over
because of its advantages has some initial time where it hasn't taken
over; extrapolating from the initial unpopularity would be a mistake.
But popularity measurements still give us _some_ sort of aggregate idea
of what people care about.

The picture is very different if the facts are instead that X25519 is
the most popular curve in handshakes, and more broadly on the Internet.
Readers hearing this become much less worried about the startup costs,
and _presume_ that people actually do care about the advantages. Again:
relationships, not guarantees.

---D. J. Bernstein

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

[TLS]Re: Curve-popularity data?

[David Adrian]

Dan,

> I'm still puzzled as to what led to the statement that
I quoted at the beginning:

I was also hosting the same podcast you were quoting, and I believe we were
also discussing _certificates_, which have the following breakdown
according to Censys:

SHA512-RSA0.002%
SHA384-RSA4.6%
ECDSA-SHA256 (P256)   5.3%
ECDSA-SHA384 (P384)   7.5%
SHA256-RSA82.7%

Notably, none of those are Curve25519 variants. I also find it odd, given
that it's a conversational podcast, that you decided to take the comment
out of context and single out "the TLS co-chair", in a quote that begins
with "I don't have the numbers".

Given your behavior on other lists, and the utter irrelevance of current
popularity of curves to the introduction of a _new_ standard, I fail to see
the purpose of this thread other than to harass one of the chairs,
especially given that this episode was released 8 months ago.

-dadrian

On Mon, Jun 3, 2024 at 12:34 PM D. J. Bernstein  wrote:

> Thanks to Martin Thomson, Bas Westerbaan, and David Adrian for the
> measurement data. I'm still puzzled as to what led to the statement that
> I quoted at the beginning:
>
>P 256 is the most popular curve in the world besides the bitcoin
>curve. And I don’t have head to head numbers, and the bitcoin curve
>is SEC P, but P 256 is most popular curve on the internet. So
>certificates, TLS, handshakes, all of that is like 70 plus percent
>negotiated with the P 256 curve.
>
> Maybe the TLS co-chair has a comment? Again, I understand that
> certificates haven't upgraded to allowing Ed25519 yet; my question is
> about the "handshake", "internet", and "world" claims.
>
> In context, these popularity claims were presented as an argument for
> regressing to P-256: "Should we still use 25519 for all new designs? Or
> should we take seriously at the idea of using the P curves again? ... I
> think we should take seriously because P 256 is the most popular curve
> in the world besides the bitcoin curve."
>
> John Mattsson writes:
> > If you are doing hybrid for reason number 1, and you are currently
> > using P-384 or P-521 to get a higher security level, you likely want
> > to continue to use P-384 or P-521.
>
> I agree that the obvious way to address the "Yikes this could be losing
> security" objection to post-quantum rollout---which is a reasonable
> objection both because of attacks against the math and because of
> attacks against the software---is to have a hybrid choose whichever
> pre-quantum system people were using already.
>
> However, endless combinations create their own slowdowns. If most
> connections are using X25519 anyway, then what's best for fast rollout
> is to get X25519+PQ moving as quickly as possible, not delaying that to
> figure out what should be done for the fringe cases (maybe X448+PQ).
>
> > I think the NIST P-curves are well-designed for being published in
> > 1998.
>
> No, the Montgomery ladder was already introduced in Montgomery's 1987
> paper. The speed and simplicity of the ladder were clear from the paper.
> NSA's rationale for taking Weierstrass curves in Jacobian coordinates
> was the false claim that this provides "the fastest arithmetic on
> elliptic curves". That's a quote from IEEE P1363, so there can't have
> been any serious review. See the "fake mathematics" section in
> https://blog.cr.yp.to/20220805-nsa.html for another example.
>
> ---D. J. Bernstein
>
> ___
> 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: Curve-popularity data?

[Eric Rescorla]

Indeed. I'd like to pull this back a bit to the question of what we
specify/mandate.

As I understand the situation, there are a number of environments that
require P-256, so it seems like it would not be practical to just
standardize/mandate X25519 + MLKEM if we want to get to 100% PQ algorithms.

-Ekr



On Mon, Jun 3, 2024 at 7:20 AM David Adrian  wrote:

> I don't really see why popularity of previous methods is relevant to
> picking what the necessarily new method will be is, but from the
> perspective of Chrome on Windows, across all ephemeral TCP TLS (1.2 and
> 1.3, excluding 1.2 RSA), the breakdown is roughly:
>
> 15% P256
> 3% P384
> 56% X25519
> 26% X25519+Kyber
>
> On Mon, Jun 3, 2024 at 10:05 AM Filippo Valsorda 
> wrote:
>
>> 2024-06-03 15:34 GMT+02:00 Bas Westerbaan :
>>
>> More importantly, there are servers that will HRR to X25519 if presented
>> a P-256 keyshare. (Eg. BoringSSL's default behaviour.) Unfortunately I
>> don't have data at hand how often that happens.
>>
>>
>> Are you saying that some of the 97.6% of servers that support P-256 still
>> HRR to X25519 if presented a P-256 keyshare and a {P-256, X25519} supported
>> groups list, and that's BoringSSL's default behavior? I find that very
>> surprising and would be curious about the rationale.
>> ___
>> 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: Curve-popularity data?

[D. J. Bernstein]

Thanks to Martin Thomson, Bas Westerbaan, and David Adrian for the
measurement data. I'm still puzzled as to what led to the statement that
I quoted at the beginning:

   P 256 is the most popular curve in the world besides the bitcoin
   curve. And I don’t have head to head numbers, and the bitcoin curve
   is SEC P, but P 256 is most popular curve on the internet. So
   certificates, TLS, handshakes, all of that is like 70 plus percent
   negotiated with the P 256 curve.

Maybe the TLS co-chair has a comment? Again, I understand that
certificates haven't upgraded to allowing Ed25519 yet; my question is
about the "handshake", "internet", and "world" claims.

In context, these popularity claims were presented as an argument for
regressing to P-256: "Should we still use 25519 for all new designs? Or
should we take seriously at the idea of using the P curves again? ... I
think we should take seriously because P 256 is the most popular curve
in the world besides the bitcoin curve."

John Mattsson writes:
> If you are doing hybrid for reason number 1, and you are currently
> using P-384 or P-521 to get a higher security level, you likely want
> to continue to use P-384 or P-521.

I agree that the obvious way to address the "Yikes this could be losing
security" objection to post-quantum rollout---which is a reasonable
objection both because of attacks against the math and because of
attacks against the software---is to have a hybrid choose whichever
pre-quantum system people were using already.

However, endless combinations create their own slowdowns. If most
connections are using X25519 anyway, then what's best for fast rollout
is to get X25519+PQ moving as quickly as possible, not delaying that to
figure out what should be done for the fringe cases (maybe X448+PQ).

> I think the NIST P-curves are well-designed for being published in
> 1998.

No, the Montgomery ladder was already introduced in Montgomery's 1987
paper. The speed and simplicity of the ladder were clear from the paper.
NSA's rationale for taking Weierstrass curves in Jacobian coordinates
was the false claim that this provides "the fastest arithmetic on
elliptic curves". That's a quote from IEEE P1363, so there can't have
been any serious review. See the "fake mathematics" section in
https://blog.cr.yp.to/20220805-nsa.html for another example.

---D. J. Bernstein

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

[TLS]Re: Curve-popularity data?

[Dennis Jackson]

On 02/06/2024 22:02, Filippo Valsorda wrote:

Third, we learned to make key shares always ephemeral which makes 
invalid curve attacks irrelevant.


Although using ephemeral keys does effectively prevent key recovery 
through invalid points, you can still use invalid points to perform 
confinement attacks on an otherwise prime order curve.


This was used by Eli Biham and Lior Neumann to break Bluetooth pairing 
standard back in 2018 [1]. The Bluetooth standard previously said 
implementers could choose to do full point validation or always use 
ephemeral keys, and folks opted for the less complex choice. This isn't 
a clear separator between X25519 and P-256 though, since X25519 would 
also need to reject small order points in order to avoid the same attack.


Best,
Dennis

[1] 
https://biham.cs.technion.ac.il/BT/bt-fixed-coordinate-invalid-curve-attack.pdf 



(Also summarized in 7.2 of Prime Order Please 
https://eprint.iacr.org/2019/526.pdf)
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[David Adrian]

I don't really see why popularity of previous methods is relevant to
picking what the necessarily new method will be is, but from the
perspective of Chrome on Windows, across all ephemeral TCP TLS (1.2 and
1.3, excluding 1.2 RSA), the breakdown is roughly:

15% P256
3% P384
56% X25519
26% X25519+Kyber

On Mon, Jun 3, 2024 at 10:05 AM Filippo Valsorda 
wrote:

> 2024-06-03 15:34 GMT+02:00 Bas Westerbaan :
>
> More importantly, there are servers that will HRR to X25519 if presented a
> P-256 keyshare. (Eg. BoringSSL's default behaviour.) Unfortunately I don't
> have data at hand how often that happens.
>
>
> Are you saying that some of the 97.6% of servers that support P-256 still
> HRR to X25519 if presented a P-256 keyshare and a {P-256, X25519} supported
> groups list, and that's BoringSSL's default behavior? I find that very
> surprising and would be curious about the rationale.
> ___
> 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: Curve-popularity data?

[Bas Westerbaan]

On Mon, Jun 3, 2024 at 4:02 PM Filippo Valsorda 
wrote:

> 2024-06-03 15:34 GMT+02:00 Bas Westerbaan :
>
> More importantly, there are servers that will HRR to X25519 if presented a
> P-256 keyshare. (Eg. BoringSSL's default behaviour.) Unfortunately I don't
> have data at hand how often that happens.
>
>
> Are you saying that some of the 97.6% of servers that support P-256 still
> HRR to X25519 if presented a P-256 keyshare and a {P-256, X25519} supported
> groups list, and that's BoringSSL's default behavior?
>

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

[TLS]Re: Curve-popularity data?

[Filippo Valsorda]

2024-06-03 15:34 GMT+02:00 Bas Westerbaan :
> More importantly, there are servers that will HRR to X25519 if presented a 
> P-256 keyshare. (Eg. BoringSSL's default behaviour.) Unfortunately I don't 
> have data at hand how often that happens.

Are you saying that some of the 97.6% of servers that support P-256 still HRR 
to X25519 if presented a P-256 keyshare and a {P-256, X25519} supported groups 
list, and that's BoringSSL's default behavior? I find that very surprising and 
would be curious about the rationale.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Loganaden Velvindron]

On Mon, 3 Jun 2024 at 01:03, Filippo Valsorda  wrote:
>
> I expect X25519 to be the most commonly selected (as opposed to supported) 
> TLS key exchange on the open Internet, due to browsers preferring it for its 
> marginal performance benefit. This is not a popularity contest though and 
> that's not the most useful metric for choosing the ECC component of a PQC 
> hybrid.
>
> The most important performance consideration in TLS is avoiding Hello Retry 
> Request round-trips due to the server supporting none of the client's key 
> shares. Moreover, clients want to reuse the ECC component of the hybrid key 
> share as a pure ECC key share (e.g. send X25519, X25519+ML-KEM-768 vs P-256, 
> X25519+ML-KEM-768 so that the X25519 key generation can be reused).
>
> Given those goals, the important metric is server support. We should indeed 
> collect data on what are the most supported key exchanges server-side, 
> probably weighted by website or implementation popularity. (I expect X25519 
> and P-256 to have nearly equivalent support, maybe with some FIPS-related 
> delta in favor of P-256.)
>
> I actually meant to bring this up, because as an implementer I also want to 
> avoid proliferation of hybrid options, but it would actually make my life 
> much easier if the one universal hybrid (and/or default client key share) was 
> P-256+ML-KEM-768.
>
> The WebPKI is overwhelmingly RSA and P-256. Ed25519 is simply not allowed by 
> the CA/B Baseline Requirements. This is not changing soon. That means I am on 
> the hook to carry an optimized and secure P-256 implementation no matter what.

Maybe it's time for WebPKI to have more flexibility. They are going to
have to make changes anyway. Might as well push forward for Ed25519 ?

>
> If most clients send X25519 and/or X25519+ML-KEM-768 key shares, then I am 
> also on the hook to carry an optimized and secure X25519 implementation. 
> That's double the work, double the opportunity for mistakes, double the 
> complexity, double the attack surface.
>
> If we standardize around P-256+ML-KEM-768 in TLS, then performance of X25519 
> becomes much less important, and I can carry a simpler less efficient (e.g. 
> without assembly) implementation for it, and focus my limited resources on 
> P-256.

My personal view is that it's important to have at least one
"independent" curve like X25519 in hybrid mode for TLS in addition to
the NIST approved curve, even
at the cost of a little bit of performance.

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

[TLS]Re: Curve-popularity data?

[Bas Westerbaan]

On Mon, Jun 3, 2024 at 3:24 PM Salz, Rich 
wrote:

> Thank you for collecting and sharing these numbers! I think this here is
> the most interesting bit in terms of curve popularity, since any difference
> in CPU time is ultimately marginal compared to the cost of a HRR.
>
>
>
> I’m not so sure.   This is really CDN to origin, or server-to-server
> traffic. You’d expect latency to not be as important as client to server,
> but more importantly that persistent connections and resumption would
> amortize the cost hugely.
>

We do care about it. We're scanning origins so that we can send a supported
keyshare immediately and avoid HRR (not rolled out yet.) That's not just
for performance, but also to deal with origins that don't support HRR.

I also don't think this data supports the conclusion that P-256 will have
fewer HRRs. As you mention the population is quite skewed: only origins
that configured Cloudflare in front. More importantly, there are servers
that will HRR to X25519 if presented a P-256 keyshare. (Eg. BoringSSL's
default behaviour.) Unfortunately I don't have data at hand how often that
happens.

Best,

 Bas

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

[TLS]Re: Curve-popularity data?

[Salz, Rich]

Thank you for collecting and sharing these numbers! I think this here is the 
most interesting bit in terms of curve popularity, since any difference in CPU 
time is ultimately marginal compared to the cost of a HRR.

I’m not so sure.   This is really CDN to origin, or server-to-server traffic. 
You’d expect latency to not be as important as client to server, but more 
importantly that persistent connections and resumption would amortize the cost 
hugely.

I do not find the argument that you have to maintain TWO implementations of 
popular curves in a popular language compelling at all.


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

[TLS]Re: Curve-popularity data?

[Filippo Valsorda]

2024-06-03 14:38 GMT+02:00 Bas Westerbaan :
> We're not just a server, but also a client proxying requests to our 
> customer's origins. We routinely scan customer's origin servers for their 
> support of keyshares. [...]
> 
> We also measure server support for each. (We send just the single keyshare 
> for the group and only advertise support for that group.)
> 
> 97.6% P-256
> 97.0% X25519
> 94% P-384
> 89% P-521
> 0.54% X25519Kyber768

Thank you for collecting and sharing these numbers! I think this here is the 
most interesting bit in terms of curve popularity, since any difference in CPU 
time is ultimately marginal compared to the cost of a HRR. It looks like X25519 
and P-256 are approximately as popular, as expected, but {P-256, 
P-256+ML-KEM-768} would save a round-trip compared to {X25519, 
X25519+ML-KEM-768} for one connection every ~170 (on top of the 
complexity/maintenance advantage of reusing the certificate signature 
implementation).___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Bas Westerbaan]

Numbers from Cloudflare server-side in the last hour. Restricted to TLS 1.3
and counting by handshake. "sent" column lists the group identifiers for
the keyshares sent by the cleint, and "supported" lists the identifiers for
the groups the client reports being supported. Both lists are sorted, and
grease has been removed. Recall X25519=29, X25519Kyber768=25497, P-256=23.
[1] "frac" is percents.

┌─frac─┬─sent───┬─supported──┐
│46.08025597692571 │ [29]   │ [23,24,29]
  │
│19.10472730561162 │ [29]   │ [23,24,25,29]
 │
│   12.634492333471034 │ [29]   │ [23,24,25,29,30]
  │
│9.969397483263833 │ [29,25497] │ [23,24,29,25497]
  │
│7.245082433725522 │ [29]   │ [23,24,25,29,30,256,257,258,259,260]
  │
│   0.9836423280948468 │ [23,29]│ [23,24,25,29,256,257]
 │
│   0.9693757351437323 │ [23,29]│ [23,24,25,29,30,256,257,258,259,260]
  │
│   0.7147137542915519 │ [23]   │ [16,19,21,23,24,25,256]
 │
│   0.5387597287371817 │ [23]   │ [23,24,25]
  │
│   0.3216808337902684 │ [24]   │ [23,24]
 │
│   0.3077268972274922 │ [29]   │ [23,24,29,30]
 │
│   0.2895491193771448 │ [23]   │ [23,24,25,256,257,258,259,260]
  │
│   0.2310142062284145 │ [23,29]│ [23,24,25,29]
 │
│  0.13238812679791004 │ [29]   │ [23,24,25,29,25497,65074]
 │
│   0.0837752734900604 │ [23]   │ [23]
  │
│ 0.057858939606985335 │ [29]   │ [23,24,25,29,256,257,258,259,260]
 │
│   0.0405672284711662 │ [29]   │ [23,24,25,29,30,249]
  │
│ 0.036025019042332365 │ [23]   │ [23,24]
 │
│ 0.027518977252528012 │ [23]   │
[9,10,11,12,13,14,22,23,24,25,256,257,258,259,260] │
│ 0.021650399459822143 │ [23,29]│ [23,24,25,29,256,257,258,259,260]
 │
└──┴┴┘

We're not just a server, but also a client proxying requests to our
customer's origins. We routinely scan customer's origin servers for their
support of keyshares. [2]

When we sent an empty ClientHello, advertising support for X25519,
X25519Kyber768, P-256, P-384 and P-521, those origins that support TLS 1.3
(and HelloRetryRequest [3]) picked as follows. We can call this server
preference.

96.7% X25519
1.8% P-384
0.7% P-256
0.54% X25519Kyber768
0.15% P-521

We also measure server support for each. (We send just the single keyshare
for the group and only advertise support for that group.)

97.6% P-256
97.0% X25519
94% P-384
89% P-521
0.54% X25519Kyber768

Best,

 Bas


[1] For your convenience link to the full list:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
[2] https://blog.cloudflare.com/post-quantum-to-origins
[3] About 1% of origins fails to do HelloRetryRequest.


On Mon, Jun 3, 2024 at 12:09 PM Martin Thomson  wrote:

> Some numbers from our telemetry.  This is purely connection-volume-based
> (so sites with lots of connections will be over-represented), but overall
> fairly stable.
>
> Key exchange:
>   ECDHE 99.21%, RSA 0.76%, ECDHE+KYBER: 0.03%
> ECDHE curve: X25519 84.50%, P-256 14.03%, P-384 0.93%, P-521 0.53%
> RSA size: 1024 0.25% (!), 2048 98.45%, 3072 0.26%, 4096 1.03%
>
> Authentication:
>   RSA Sign 70.10%, ECDSA 29.14%, RSA KEA 0.76%
> ECDSA curve:  P-256 99.69%, P-384 0.31%
> RSA size: 1024 0.09% (!), 2048 97.22%, 3072 0.28%, 4096 2.41%
>
> We do not expose Ed25519 signing in TLS at this stage, even though we
> could use delegated credentials so that it could be enabled without needing
> certificate support.
>
> On Sun, Jun 2, 2024, at 19:47, D. J. Bernstein wrote:
> > Information about the popularity of specific cryptosystems plays a role
> > in decisions of what to standardize and deploy. I've been pointed to a
> > surprising statement (quoted below) regarding popularity of curves, in
> > particular in TLS handshakes. The statement is from one of the current
> > TLS co-chairs, a month before the co-chair appointment. I'm wondering
> > what data the statement is based on; the statement doesn't have a
> > description of the data sources, and the statement seems impossible to
> > reconcile with various public statements that have clear data sources.
> >
> > A specific reason that I'd like to resolve this is that I'm concerned
> > about the impact on post-quantum deployment. To explain:
> >
> >* We're failing to protect confidentiality of most user data against
> >  future quantum attacks---but switching to a post-quantum system has
> >  an unacceptably high chance of making security even worse. See
> >  https://cr.yp.to/papers.html#qrcsp for how much has been broken.
> >
> >* The obvious path forward is to immediately roll out ECC+PQ hybrids,
> >  as illustrated by X25519+sntrup761 in 

[TLS]Re: Curve-popularity data?

[D. J. Bernstein]

Filippo Valsorda writes:
> For what it's worth, implementing P-256 these days is way easier than
> when X25519 was designed. First, Renes, Costello, and Batina published
> complete formulas for it in https://eprint.iacr.org/2015/1060

Actually, Lange and I published complete formulas for P-256 six years
before that, on pages 23-24 of https://cr.yp.to/talks.html#2009.07.17.
The P-256 curve was just one example; the talk title was "Complete
addition laws for all elliptic curves over finite fields".

The bigger picture, however, is that completeness is just one of many
desiderata for ECC implementations. What's amazing about the Montgomery
ladder for Montgomery curves---

   def x25519(x1,n):
 A = 486662
 x2,z2,x3,z3 = 1,0,x1,1
 for i in reversed(range(255)):
   ni = bit(n,i)
   x2,x3 = cswap(x2,x3,ni)
   z2,z3 = cswap(z2,z3,ni)
   x3,z3 = 4*(x2*x3-z2*z3)**2,4*x1*(x2*z3-z2*x3)**2
   x2,z2 = (x2**2-z2**2)**2,4*x2*z2*(x2**2+A*x2*z2+z2**2)
   x3,z3 = x3%p,z3%p
   x2,z2 = x2%p,z2%p
   x2,x3 = cswap(x2,x3,ni)
   z2,z3 = cswap(z2,z3,ni)
 return (x2*pow(z2,p-2,p))%p

---is that it's complete _and_ fast _and_ simpler than any other
approach to ECDH. Part of this streamlining comes from not having any
special cases; part of it comes from the formulas being short; part of
it comes from skipping point-on-curve checks. (The curve is chosen to
be twist-secure, and the formulas work with just the x-coordinate as
input, so _all_ inputs are on secure curves.)

Edwards curves are similarly amazing for signatures---simultaneously
complete and fast and simpler than any other approach to elliptic-curve
signatures. Of course, signatures are more code than ECDH, and there's
correspondingly more to say about how EdDSA is simpler than ECDSA; see
https://blog.cr.yp.to/20140323-ecdsa.html for an introduction.

P-256 ECDH doesn't have code as simple or fast as X25519, and P-256
ECDSA doesn't have code as simple or fast as Ed25519. What's especially
harmful about the NSA/NIST approach to ECC is how large the gaps are
between simple code, fast code, and secure code. Sure, the complete
formulas for P-256 etc. provide further options, but they're more
complicated in other ways---again, it's _not_ the amazing combination
illustrated by the Python code above.

We've seen repeatedly how tensions between streamlined code and secure
code lead to attacks. As https://safecurves.cr.yp.to puts it:

   Most of these attacks would have been ruled out by better choices of
   curves that allow _simple_ implementations to be _secure_
   implementations. This is the primary motivation for SafeCurves. **The
   SafeCurves criteria are designed to ensure ECC security, not just
   ECDLP security.**

The word "most" is important---it's not that the curve choice can
magically solve all problems---but comparative attack examples such as
Minerva (see https://blog.cr.yp.to/20191024-eddsa.html) illustrate how
successful this approach has been at reducing risks.

> although interestingly P-256 still has a red False in the "complete"
> column in version 2017.01.22 of https://safecurves.cr.yp.to

https://safecurves.cr.yp.to/complete.html defines that column:
"SafeCurves requires curves to support simple, fast, _complete_,
constant-time single-coordinate single-scalar multiplication. This
includes the SafeCurves ladder requirement but goes further by requiring
completeness. SafeCurves also requires curves to support simple, fast,
_complete_, constant-time multi-scalar multiplication."

A bait-and-switch game---this code is complete, that code is simple,
etc.; when implementations use the simple code and end up not being
complete, blame the implementor---doesn't meet the definition of this
column. There has to be a single-coordinate single-scalar multiplication
method that's _simultaneously_ simple and fast and so on. Ditto for
multi-scalar multiplication.

The same page also explains why this is important, referring to the
Montgomery/Edwards completeness results from 2006/2007 and then
summarizing why the subsequent completeness results for various other
curves aren't as good:

   Subsequent research has introduced other complete
   scalar-multiplication formulas. However, many of these formulas are
   considerably slower and more complicated than standard incomplete
   scalar-multiplication formulas, creating major conflicts between
   simplicity, efficiency, and security.

We're not living in some fantasy world where implementors are magically
doing what has to be done for security. Implementors are typically
writing the simplest code that they can that passes some tests, and then
modifying it for speed if there are speed complaints (or fears of speed
complaints). Sure, _sometimes_ implementors can be convinced to take
extra steps for security (especially if there are tools enforcing those
steps), but needing more of those steps means more chances of disaster.

Understanding the goal of SafeCurves also makes clear 

[TLS]Re: Curve-popularity data?

[John Mattsson]

Filippo Valsorda wrote:
>Third, we learned to make key shares always ephemeral which makes invalid 
>curve attacks irrelevant.

Have we? TLS 1.3 key shares are semi-static and may be reused an unlimited 
number of times.

IKEv2 and (D)TLS 1.3 are doing quite a lot of questionable optimizations such 
as reuse of key shares, sending external PSK identifiers in cleartext, allowing 
replay protection to be turned off, and allowing symmetric key exchange instead 
of ECDHE.

That TLS 1.3 has such high reputation makes it hard to argue against. As a 
result of TLS 1.3 marking psk_ke as RECOMMENDED, 3GPP ended up allowing it 
again. 3GPP had previously required ECDHE in TLS 1.2. I like that the CNSA RFCs 
provides additional hardening. That RFC 9206 states:

"IKEv2 allows for the reuse of Diffie-Hellman private keys; see Section 2.12 of 
[RFC7296]. However, there are security concerns related to this practice. 
Section 5.6.3.3 of [SP80056A] states that an ephemeral private key MUST be used 
in exactly one key establishment transaction and MUST be destroyed (zeroized) 
as soon as possible. Section 5.8 of [SP80056A] states that any shared secret 
derived from key establishment MUST be destroyed (zeroized) immediately after 
its use. CNSA-compliant IPsec systems MUST follow the mandates in [SP80056A]."

allowed me to forbid key reuse of ephemeral keys when IKEv2 is used in 3GPP. 
3GPP already forbids turning off replay protection. I hope that the CNSA 2.0 
RFCs for TLS, X.509, IPsec, SSH etc., will forbid even more weak configurations 
that does not belong in high-security deployments.

Cheers,
John

From: Filippo Valsorda 
Date: Sunday, 2 June 2024 at 23:03
To: tls@ietf.org 
Subject: [TLS]Re: Curve-popularity data?
I expect X25519 to be the most commonly selected (as opposed to supported) TLS 
key exchange on the open Internet, due to browsers preferring it for its 
marginal performance benefit. This is not a popularity contest though and 
that's not the most useful metric for choosing the ECC component of a PQC 
hybrid.

The most important performance consideration in TLS is avoiding Hello Retry 
Request round-trips due to the server supporting none of the client's key 
shares. Moreover, clients want to reuse the ECC component of the hybrid key 
share as a pure ECC key share (e.g. send X25519, X25519+ML-KEM-768 vs P-256, 
X25519+ML-KEM-768 so that the X25519 key generation can be reused).

Given those goals, the important metric is server support. We should indeed 
collect data on what are the most supported key exchanges server-side, probably 
weighted by website or implementation popularity. (I expect X25519 and P-256 to 
have nearly equivalent support, maybe with some FIPS-related delta in favor of 
P-256.)

I actually meant to bring this up, because as an implementer I also want to 
avoid proliferation of hybrid options, but it would actually make my life much 
easier if the one universal hybrid (and/or default client key share) was 
P-256+ML-KEM-768.

The WebPKI is overwhelmingly RSA and P-256. Ed25519 is simply not allowed by 
the CA/B Baseline Requirements. This is not changing soon. That means I am on 
the hook to carry an optimized and secure P-256 implementation no matter what.

If most clients send X25519 and/or X25519+ML-KEM-768 key shares, then I am also 
on the hook to carry an optimized and secure X25519 implementation. That's 
double the work, double the opportunity for mistakes, double the complexity, 
double the attack surface.

If we standardize around P-256+ML-KEM-768 in TLS, then performance of X25519 
becomes much less important, and I can carry a simpler less efficient (e.g. 
without assembly) implementation for it, and focus my limited resources on 
P-256.

P-256+ML-KEM-768 also has the added benefit of being FIPS 140 compliant today, 
without waiting for ML-KEM-768 modules to get certified (which can take years), 
speeding up PQC adoption in settings that—unfortunately—are constrained by FIPS 
140. It also avoids divergence between regular and compliance modes, again 
reducing implementer workload and attack surface.

For what it's worth, implementing P-256 these days is way easier than when 
X25519 was designed. First, Renes, Costello, and Batina published complete 
formulas for it in https://eprint.iacr.org/2015/1060 (although interestingly 
P-256 still has a red False in the "complete" column in version 2017.01.22 of 
https://safecurves.cr.yp.to<https://safecurves.cr.yp.to/>, which maybe I am 
misinterpreting). Second, we have formally verified field implementation 
generators such as fiat-crypto. Third, we learned to make key shares always 
ephemeral which makes invalid curve attacks irrelevant.

2024-06-02 20:47 GMT+02:00 D. J. Bernstein 
mailto:d...@cr.yp.to>>:
Information about the popularity of specific cryptosystems plays a role
in decisions of what to standardize and deploy. I've been pointed to a
surprising statement (quoted below) regardi

[TLS]Re: Curve-popularity data?

[Martin Thomson]

On Mon, Jun 3, 2024, at 11:23, Filippo Valsorda wrote:
> Thank you for sharing those! Could you filter down to TLS 1.3 only 

That's not possible, sadly.

> (since we are not going to add hybrids to TLS 1.2 anyway)? I assume 
> that after filtering to TLS 1.3, any non-X25519 connections are Hello 
> Retry Requests, since you only send an X25519 key share?

We send a P-256 share in addition to an X25519 share.  That might push our 
P-256 numbers higher than other implementations, to address your speculation.  
Those are answers that are better addressed with scanning tools though.

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

[TLS]Re: Curve-popularity data?

[Filippo Valsorda]

2024-06-03 12:07 GMT+02:00 Martin Thomson :
> Some numbers from our telemetry.  This is purely connection-volume-based (so 
> sites with lots of connections will be over-represented), but overall fairly 
> stable.
> 
> Key exchange:
>   ECDHE 99.21%, RSA 0.76%, ECDHE+KYBER: 0.03%
> ECDHE curve: X25519 84.50%, P-256 14.03%, P-384 0.93%, P-521 0.53%
> RSA size: 1024 0.25% (!), 2048 98.45%, 3072 0.26%, 4096 1.03%

Thank you for sharing those! Could you filter down to TLS 1.3 only (since we 
are not going to add hybrids to TLS 1.2 anyway)? I assume that after filtering 
to TLS 1.3, any non-X25519 connections are Hello Retry Requests, since you only 
send an X25519 key share?

I think the relevant question to selecting an ECC hybrid is "how many of the 
X25519 connections would have supported P-256, and vice-versa?" If you are 
sending a X25519 key share and getting an HRR to P-256, I guess the 
would-also-support-X25519 number is zero. The would-also-support-P256 number is 
harder to get: either you sample a small percentage of connections and send a 
P-256 key share, or we rely on internet scan data like Censys's.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Martin Thomson]

Some numbers from our telemetry.  This is purely connection-volume-based (so 
sites with lots of connections will be over-represented), but overall fairly 
stable.

Key exchange:
  ECDHE 99.21%, RSA 0.76%, ECDHE+KYBER: 0.03%
ECDHE curve: X25519 84.50%, P-256 14.03%, P-384 0.93%, P-521 0.53%
RSA size: 1024 0.25% (!), 2048 98.45%, 3072 0.26%, 4096 1.03%

Authentication:
  RSA Sign 70.10%, ECDSA 29.14%, RSA KEA 0.76%
ECDSA curve:  P-256 99.69%, P-384 0.31%
RSA size: 1024 0.09% (!), 2048 97.22%, 3072 0.28%, 4096 2.41%

We do not expose Ed25519 signing in TLS at this stage, even though we could use 
delegated credentials so that it could be enabled without needing certificate 
support.

On Sun, Jun 2, 2024, at 19:47, D. J. Bernstein wrote:
> Information about the popularity of specific cryptosystems plays a role
> in decisions of what to standardize and deploy. I've been pointed to a
> surprising statement (quoted below) regarding popularity of curves, in
> particular in TLS handshakes. The statement is from one of the current
> TLS co-chairs, a month before the co-chair appointment. I'm wondering
> what data the statement is based on; the statement doesn't have a
> description of the data sources, and the statement seems impossible to
> reconcile with various public statements that have clear data sources.
>
> A specific reason that I'd like to resolve this is that I'm concerned
> about the impact on post-quantum deployment. To explain:
>
>* We're failing to protect confidentiality of most user data against
>  future quantum attacks---but switching to a post-quantum system has
>  an unacceptably high chance of making security even worse. See
>  https://cr.yp.to/papers.html#qrcsp for how much has been broken.
>
>* The obvious path forward is to immediately roll out ECC+PQ hybrids,
>  as illustrated by X25519+sntrup761 in OpenSSH, X25519+ntruhrss701
>  in ALTS, X25519+kyber768 in https://blog.cloudflare.com/pq-2024,
>  X25519+kyber512 in 
> https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/,
>  etc. Then we're not making security worse, and _hopefully_ we're
>  making it better.
>
>* This still leaves the challenge of minimizing post-quantum risks.
>  That's hard enough without the combinatorial explosion of combining
>  each post-quantum option with a profusion of curves. Adding many
>  curve choices is the sort of thing that _sounds_ simple until you
>  start writing software, tests, etc. (I designed X25519 after
>  suffering through implementing an example of NSA/NIST ECDH; see
>  https://cr.yp.to/nistp224.html and the accompanying talks. NSA's
>  harder-to-implement approach to ECC also ends up more likely to
>  fail later; see, e.g., https://blog.cr.yp.to/20191024-eddsa.html.)
>
> Here's the specific statement I'm asking about:
>
>P 256 is the most popular curve in the world besides the bitcoin
>curve. And I don’t have head to head numbers, and the bitcoin curve
>is SEC P, but P 256 is most popular curve on the internet. So
>certificates, TLS, handshakes, all of that is like 70 plus percent
>negotiated with the P 256 curve.
>
> Last I heard, _certificates_ hadn't upgraded to allowing Ed25519 yet.
> My question is about the "handshake" claim, and more broadly about the
> "internet" and "world" claims.
>
> Examples of why I find the above TLS-handshake claim surprising:
>
>* https://blog.cloudflare.com/towards-post-quantum-cryptography-in-tls/
>  (2019) says that "the most commonly used key exchange algorithm
>  (according to Cloudflare's data) is the non-quantum X25519".
>
>* https://blog.cloudflare.com/post-quantum-for-all/ (2022) says that
>  "Almost every server supports the X25519 key-agreement and almost
>  every client (98% today) sends a X25519 keyshare."
>
>* https://eprint.iacr.org/2023/734 recorded TLS connections from many
>  different apps and noted that X25519 was used in "the vast majority
>  of the recorded handshakes".
>
>* https://blog.cloudflare.com/pq-2024 says "Today almost all traffic
>  is secured with X25519, a Diffie–Hellman-style key agreement".
>
>* The handshake simulations in, e.g.,
>  
> https://www.ssllabs.com/ssltest/analyze.html?d=google.com=142.250.217.142=on=on
>  show current browsers using X25519 (while showing older client
>  software using P-256). Clicking on random servers listed on the
>  same site also consistently shows X25519.
>
> To be clear, this isn't saying that _all_ handshakes are using X25519.
> NIST didn't manage to standardize Ed25519 until 2023, and still hasn't
> managed to standardize X25519, so probably it's not too hard to find
> servers that insist on P-256 for "FIPS compliance". I figured I'd be
> able to give easy examples of this by trying nist.gov and nsa.gov---
>
>
> 

[TLS]Re: Curve-popularity data?

[John Mattsson]

Hi,

I think it is very hard to get any reliable statistics on what is the most 
popular curve in the world. I agree with you that X25519 is now used in the 
vast majority of TLS handshake on the Web, which is great. But curves are used 
outside of TLS, and TLS is a lot bigger than just the Web, and popularity can 
be interpreted differently.

The two things I love about X25519 is its speed and that there is no need to do 
point validation in most cases. There have been a huge amount of practical 
vulnerabilities due to implementations not doing point validation. My feeling 
is that there is still a worring amount of deployed implementation that do not 
do point validation. Solutions to this are X25519, including some part from 
point the point validation calculation in the key derivation, and negative test 
vectors. I strongly hope that NIST will have a large amount of negative test 
vectors for the PQC algorithms and that FIPS validation require failing these. 
Positive test vectors are for interoperability, negative test vectors are for 
security.

I think X25519+ML-KEM should be the first choice for hybrid key exchange, but 
there is also a need for curves with higher security. There are as I see it two 
reasons to do hybrid:
1. Protect against potential future theoretical attacks on lattice- or 
code-based crypto
2. Protect aganst bad implementations of lattice- or code-based crypto. My 
understanding is that the side-channel protection of many current 
pre-standardization implementations are quite bad.

If you are doing hybrid for reason number 1, and you are currently using P-384 
or P-521 to get a higher security level, you likely want to continue to use 
P-384 or P-521. X448 is to my understanding not as supported as X25519.

>NSA's harder-to-implement approach to ECC
I think the NIST P-curves are well-designed for being published in 1998. I 
think NSA should have credit for designing and pushing adoption of ECC. I wish 
that the world would had followed Suite B (2005) and completely moved to ECC. 
Unfortunatly we still have to deal with RSA and FFDH.

Cheers,
John

From: D. J. Bernstein 
Date: Sunday, 2 June 2024 at 20:48
To: tls@ietf.org 
Subject: [TLS]Curve-popularity data?
Information about the popularity of specific cryptosystems plays a role
in decisions of what to standardize and deploy. I've been pointed to a
surprising statement (quoted below) regarding popularity of curves, in
particular in TLS handshakes. The statement is from one of the current
TLS co-chairs, a month before the co-chair appointment. I'm wondering
what data the statement is based on; the statement doesn't have a
description of the data sources, and the statement seems impossible to
reconcile with various public statements that have clear data sources.

A specific reason that I'd like to resolve this is that I'm concerned
about the impact on post-quantum deployment. To explain:

   * We're failing to protect confidentiality of most user data against
 future quantum attacks---but switching to a post-quantum system has
 an unacceptably high chance of making security even worse. See
 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcr.yp.to%2Fpapers.html%23qrcsp=05%7C02%7Cjohn.mattsson%40ericsson.com%7C05c07d548ae2483fefd008dc833497ea%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638529509123054408%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=aJEyMJ505bdg7b%2BMePETQui%2FVgcYmTt7%2FQpMomMuXBA%3D=0
 for how much has been broken.

   * The obvious path forward is to immediately roll out ECC+PQ hybrids,
 as illustrated by X25519+sntrup761 in OpenSSH, X25519+ntruhrss701
 in ALTS, X25519+kyber768 in 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.cloudflare.com%2Fpq-2024=05%7C02%7Cjohn.mattsson%40ericsson.com%7C05c07d548ae2483fefd008dc833497ea%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638529509123061366%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=WzfdrqSiWT%2B6BCVXMbE2qKb9E9tmy1RBc1fX81vqtSo%3D=0,
 X25519+kyber512 in 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fengineering.fb.com%2F2024%2F05%2F22%2Fsecurity%2Fpost-quantum-readiness-tls-pqr-meta%2F=05%7C02%7Cjohn.mattsson%40ericsson.com%7C05c07d548ae2483fefd008dc833497ea%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638529509123066403%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=292CeJkqAaXFq7ZzOXHWXXYQP%2BlbaTxlrrFF79rwmg0%3D=0,
 etc. Then we're not making security worse, and _hopefully_ we're
 making it better.

   * This still leaves the challenge of minimizing post-quantum risks.
 That's hard enough without the combinatorial explosion of combining

[TLS]Re: Curve-popularity data?

[Filippo Valsorda]

I expect X25519 to be the most commonly *selected *(as opposed to supported) 
TLS key exchange on the open Internet, due to browsers preferring it for its 
marginal performance benefit. This is not a popularity contest though and 
that's not the most useful metric for choosing the ECC component of a PQC 
hybrid.

The most important performance consideration in TLS is avoiding Hello Retry 
Request round-trips due to the server supporting none of the client's key 
shares. Moreover, clients want to reuse the ECC component of the hybrid key 
share as a pure ECC key share (e.g. send X25519, X25519+ML-KEM-768 vs P-256, 
X25519+ML-KEM-768 so that the X25519 key generation can be reused).

Given those goals, the important metric is server support. *We should indeed 
collect data on what are the most supported key exchanges server-side*, 
probably weighted by website or implementation popularity. (I expect X25519 and 
P-256 to have nearly equivalent support, maybe with some FIPS-related delta in 
favor of P-256.)

I actually meant to bring this up, because as an implementer I also want to 
avoid proliferation of hybrid options, but *it would actually make my life much 
easier if the one universal hybrid (and/or default client key share) was 
P-256+ML-KEM-768*.

The WebPKI is overwhelmingly RSA and P-256. Ed25519 is simply not allowed by 
the CA/B Baseline Requirements. This is not changing soon. That means I am on 
the hook to carry an optimized and secure P-256 implementation no matter what.

If most clients send X25519 and/or X25519+ML-KEM-768 key shares, then I am 
*also *on the hook to carry an optimized and secure X25519 implementation. 
That's double the work, double the opportunity for mistakes, double the 
complexity, double the attack surface.

If we standardize around P-256+ML-KEM-768 in TLS, then performance of X25519 
becomes much less important, and I can carry a simpler less efficient (e.g. 
without assembly) implementation for it, and focus my limited resources on 
P-256.

P-256+ML-KEM-768 also has the added benefit of being FIPS 140 compliant today, 
without waiting for ML-KEM-768 modules to get certified (which can take years), 
speeding up PQC adoption in settings that—unfortunately—are constrained by FIPS 
140. It also avoids divergence between regular and compliance modes, again 
reducing implementer workload and attack surface.

For what it's worth, implementing P-256 these days is way easier than when 
X25519 was designed. First, Renes, Costello, and Batina published complete 
formulas for it in https://eprint.iacr.org/2015/1060 (although interestingly 
P-256 still has a red False in the "complete" column in version 2017.01.22 of 
https://safecurves.cr.yp.to, which maybe I am misinterpreting). Second, we have 
formally verified field implementation generators such as fiat-crypto. Third, 
we learned to make key shares always ephemeral which makes invalid curve 
attacks irrelevant.

2024-06-02 20:47 GMT+02:00 D. J. Bernstein :
> Information about the popularity of specific cryptosystems plays a role
> in decisions of what to standardize and deploy. I've been pointed to a
> surprising statement (quoted below) regarding popularity of curves, in
> particular in TLS handshakes. The statement is from one of the current
> TLS co-chairs, a month before the co-chair appointment. I'm wondering
> what data the statement is based on; the statement doesn't have a
> description of the data sources, and the statement seems impossible to
> reconcile with various public statements that have clear data sources.
> 
> A specific reason that I'd like to resolve this is that I'm concerned
> about the impact on post-quantum deployment. To explain:
> 
>* We're failing to protect confidentiality of most user data against
>  future quantum attacks---but switching to a post-quantum system has
>  an unacceptably high chance of making security even worse. See
>  https://cr.yp.to/papers.html#qrcsp for how much has been broken.
> 
>* The obvious path forward is to immediately roll out ECC+PQ hybrids,
>  as illustrated by X25519+sntrup761 in OpenSSH, X25519+ntruhrss701
>  in ALTS, X25519+kyber768 in https://blog.cloudflare.com/pq-2024,
>  X25519+kyber512 in 
> https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/,
>  etc. Then we're not making security worse, and _hopefully_ we're
>  making it better.
> 
>* This still leaves the challenge of minimizing post-quantum risks.
>  That's hard enough without the combinatorial explosion of combining
>  each post-quantum option with a profusion of curves. Adding many
>  curve choices is the sort of thing that _sounds_ simple until you
>  start writing software, tests, etc. (I designed X25519 after
>  suffering through implementing an example of NSA/NIST ECDH; see
>  https://cr.yp.to/nistp224.html and the accompanying talks. NSA's
>  harder-to-implement approach to ECC also ends up