[TLS]Re: [EXTERNAL] Re: Curve-popularity data?

[Stephen Farrell]

On 05/06/2024 06:56, John Mattsson wrote:

I think P-384 is the most required of the NIST P-curves.


I've heard that some. Oddly, I use a test server that only supports
p384 as a way to trigger HRR when testing ECH, which seems to work for
most clients who test with my servers, so I wonder if, when using a
hybrid KEM, we're heading to a world where one large set of clients
emit x25519 and x25519+pq and another large set emit p256 and p384+pq?

I guess if that meant there wasn't a real need for much use of p256+pq
that might be a small saving and worth documenting somewhere even if
we do define a codepoint for p256+pq.

Cheers,
S.


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: [EXTERNAL] Curve-popularity data?

[Hubert Kario]

On Wednesday, 5 June 2024 07:56:21 CEST, John Mattsson wrote:

Andrei Popov wrote:

CNSA requires P384, so we’ll also need a hybrid that includes this EC.
Yes, I am not sure about the statement that P-256 is required. 
The requirement for FIPS in the next few years should be one of 
the NIST P-curves. I think P-384 is the most required of the 
NIST P-curves.


P-256 is the fastest of the NIST curves and fine for everyday use.
(both because it's one of the smaller ones but also because it has one
of the most optimised implementations around.

P-384 is the only curve allowed for CNSA 1.0, so it will be needed for the
transition period.

we need both
 

Scott Fluhrer wrote:
I believe that it is unreasonable to expect that a single 
combination would satisfy everyone’s needs.


Yes, that is completely unreasonable. TLS is MUCH larger than 
the Web. There will clearly be registrations for combinations of 
most current curves (P-curves, X-curves, Brainpool, SM, GOST) 
with most PQC KEMs (ML-KEM, BIKE/HQC, Classic McEliece, 
FrodoKEM, future Isogeny? (Isogenies was the hottest topic at 
Eurocrypt this year) ). European countries say that hybrids will 
be a must for a long-time.
 
Cheers,

John
 
From: Andrei Popov 

Date: Wednesday, 5 June 2024 at 07:24
To: Eric Rescorla , Stephen Farrell 


Cc: tls@ietf.org 
Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?

CNSA requires P384, so we’ll also need a hybrid that includes this EC.
 
Cheers,
 
Andrei
 
From: Eric Rescorla  
Sent: Monday, June 3, 2024 12:53 PM

To: Stephen Farrell 
Cc: Loganaden Velvindron ; Andrei Popov 
; Salz, Rich ; 
tls@ietf.org

Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
 
 
 
 
On Mon, Jun 3, 2024 at 11:55 AM Stephen Farrell 
 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:-)
 
Yes, this seems correct to me.
 
-Ekr
 
 
 


Cheers,
S.


--
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: [EXTERNAL] Curve-popularity data?

[Hubert Kario]

On Wednesday, 5 June 2024 09:19:51 CEST, Stephen Farrell wrote:


On 05/06/2024 06:56, John Mattsson wrote:

I think P-384 is the most required of the NIST P-curves.


I've heard that some. Oddly, I use a test server that only supports
p384 as a way to trigger HRR when testing ECH, which seems to work for
most clients who test with my servers, so I wonder if, when using a
hybrid KEM, we're heading to a world where one large set of clients
emit x25519 and x25519+pq and another large set emit p256 and p384+pq?

I guess if that meant there wasn't a real need for much use of p256+pq
that might be a small saving and worth documenting somewhere even if
we do define a codepoint for p256+pq.


1. P-256 with OpenSSL 3.1.1 on my machine is quite literally over 20
  times faster than P-384
2. While NIST FIPS 186-5 includes Ed25519 as an approved algorithm,
  it does not include X25519 as an approved algorithm.
3. we're likely years before we will get first FIPS certified ML-KEM
  implementation

so I expect that most regular servers will use x25519+ML-KEM, the ones
that have a requirement for FIPS compliance will have to use P-256+ML-KEM,
and the ones that have Common Critera requirements will have to use
P-384+ML-KEM.
--
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: [EXTERNAL] Curve-popularity data?

[John Mattsson]

Hubert Kario wrote:
>1. P-256 with OpenSSL 3.1.1 on my machine is quite literally over 20 times 
>faster than P-384

Yes, P-384 is a bit unoptimized. That will change in newer versions. But still 
much slower than P-256 which in turn is much slower than X25519 (which is 
slightly slower than ML-KEM).
https://sthbrx.github.io/blog/2023/08/07/going-out-on-a-limb-efficient-elliptic-curve-arithmetic-in-openssl/

>2. While NIST FIPS 186-5 includes Ed25519 as an approved algorithm, it does 
>not include X25519 as an approved algorithm.

Yes, that is a shame. I don’t think NIST ever gave any reasoning behind this.

>3. we're likely years before we will get first FIPS certified ML-KEM 
>implementation

Yes

>so I expect that most regular servers will use x25519+ML-KEM, the ones
>that have a requirement for FIPS compliance will have to use P-256+ML-KEM,
>and the ones that have Common Critera requirements will have to use
>P-384+ML-KEM.

I assume servers with Common Critera requirements would likely want to use 
P-384+ML-KEM-1024.

I would also very much like X25519+ML-KEM-512 for use cases where message size 
matters. ML-KEM-512 public keys are smaller than ML-KEM-768 which means that 
you can fit X25519+ML-KEM-512 in a single packet without fragmentation. I have 
quite high trust in ML-KEM from a theoretical perspective. The margin to known 
attacks is large. I don’t have much trust in implementations. Early 
implementations might have both bugs and significant side-channel leakage. I 
think implementation aspects is the main reason to do hybrid.

Cheers,
John


From: Hubert Kario 
Date: Wednesday, 5 June 2024 at 13:20
To: Stephen Farrell 
Cc: John Mattsson , tls@ietf.org 
Subject: Re: [TLS] [EXTERNAL] Curve-popularity data?
On Wednesday, 5 June 2024 09:19:51 CEST, Stephen Farrell wrote:
>
> On 05/06/2024 06:56, John Mattsson wrote:
>> I think P-384 is the most required of the NIST P-curves.
>
> I've heard that some. Oddly, I use a test server that only supports
> p384 as a way to trigger HRR when testing ECH, which seems to work for
> most clients who test with my servers, so I wonder if, when using a
> hybrid KEM, we're heading to a world where one large set of clients
> emit x25519 and x25519+pq and another large set emit p256 and p384+pq?
>
> I guess if that meant there wasn't a real need for much use of p256+pq
> that might be a small saving and worth documenting somewhere even if
> we do define a codepoint for p256+pq.

1. P-256 with OpenSSL 3.1.1 on my machine is quite literally over 20
   times faster than P-384
2. While NIST FIPS 186-5 includes Ed25519 as an approved algorithm,
   it does not include X25519 as an approved algorithm.
3. we're likely years before we will get first FIPS certified ML-KEM
   implementation

so I expect that most regular servers will use x25519+ML-KEM, the ones
that have a requirement for FIPS compliance will have to use P-256+ML-KEM,
and the ones that have Common Critera requirements will have to use
P-384+ML-KEM.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: 
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cz.redhat.com%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb70f391217844d5e8cc308dc855179ec%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638531832177835328%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=grHoVU8T5RN6n6a0GnVYun63svZhKjSqLu10AH%2BQc0E%3D&reserved=0
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?

[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: HRR support (was something else)

[Peter Gutmann]

Martin Thomson  writes:

>Are you saying that there are TLS 1.3 implementations out there that don't
>send HRR when they should?

There are embedded TLS 1.3 implementations [*] that, presumably for space/
complexity reasons and possibly also for attack surface reduction, only
support the MTI algorithms (AES, SHA-2, P256) and don't do HRR.

We found this out because of Google's noncompliant implementation in Chrome.
In the presence of compliant implementations that do the MTI algorithms in the
client hello, you don't need HRR.

Peter.

[*] OK, not very many since they're mostly still TLS 1.2, but there are a
small number.
___
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]

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: HRR support (was something else)

[Joseph Birr-Pixton]

On Wed, 5 Jun 2024 at 14:24, Peter Gutmann 
wrote:

> Martin Thomson  writes:
>
> >Are you saying that there are TLS 1.3 implementations out there that don't
> >send HRR when they should?
>
> There are embedded TLS 1.3 implementations [*] that, presumably for space/
> complexity reasons and possibly also for attack surface reduction, only
> support the MTI algorithms (AES, SHA-2, P256) and don't do HRR.
>
> We found this out because of Google's noncompliant implementation in
> Chrome.
> In the presence of compliant implementations that do the MTI algorithms in
> the
> client hello, you don't need HRR
>

That is not a correct interpretation, in my opinion. Offering a key_share
for every MTI key exchange is not required, because:

>   Clients MAY send an empty client_shares vector in order to request
>   group selection from the server, at the cost of an additional round
>   trip

This clause requires HRR support from all peers.

Cheers,
Joe
___
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?

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

[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: [EXTERNAL] Re: Curve-popularity data?

[Scott Fluhrer (sfluhrer)]

If we’re talking about CNSA, well CNSA 2.0 insists on ML-KEM-1024 (and would 
prefer that alone) – I had been assuming that could be better handled by the 
ML-KEM-only draft…

From: John Mattsson 
Sent: Wednesday, June 5, 2024 1:56 AM
To: tls@ietf.org
Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?

Andrei Popov wrote:
>CNSA requires P384, so we’ll also need a hybrid that includes this EC.

Yes, I am not sure about the statement that P-256 is required. The requirement 
for FIPS in the next few years should be one of the NIST P-curves. I think 
P-384 is the most required of the NIST P-curves.

Scott Fluhrer wrote:
>I believe that it is unreasonable to expect that a single combination would 
>satisfy everyone’s needs.
Yes, that is completely unreasonable. TLS is MUCH larger than the Web. There 
will clearly be registrations for combinations of most current curves 
(P-curves, X-curves, Brainpool, SM, GOST) with most PQC KEMs (ML-KEM, BIKE/HQC, 
Classic McEliece, FrodoKEM, future Isogeny? (Isogenies was the hottest topic at 
Eurocrypt this year) ). European countries say that hybrids will be a must for 
a long-time.

Cheers,
John

From: Andrei Popov 
mailto:Andrei.Popov=40microsoft@dmarc.ietf.org>>
Date: Wednesday, 5 June 2024 at 07:24
To: Eric Rescorla mailto:e...@rtfm.com>>, Stephen Farrell 
mailto:stephen.farr...@cs.tcd.ie>>
Cc: tls@ietf.org mailto:tls@ietf.org>>
Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
CNSA
 requires P384, so we’ll also need a hybrid that includes this EC.

Cheers,

Andrei

From: Eric Rescorla mailto:e...@rtfm.com>>
Sent: Monday, June 3, 2024 12:53 PM
To: Stephen Farrell 
mailto:stephen.farr...@cs.tcd.ie>>
Cc: Loganaden Velvindron mailto:logana...@gmail.com>>; 
Andrei Popov mailto:andrei.po...@microsoft.com>>; 
Salz, Rich mailto:rs...@akamai.com>>; 
tls@ietf.org
Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?




On Mon, Jun 3, 2024 at 11:55 AM 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:-)

Yes, this seems correct to me.

-Ekr




Cheers,
S.
___
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.  
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: HRR support (was something else)

[Peter Gutmann]

Joseph Birr-Pixton  writes:

>That is not a correct interpretation, in my opinion. Offering a key_share for
>every MTI key exchange is not required, because:
>
>>   Clients MAY send an empty client_shares vector in order to request
>>   group selection from the server, at the cost of an additional round
>>   trip

Chrome doesn't send an empty client_shares, it just sends one populated with
non-MTI keyex types.

Peter.
___
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?

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

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

[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]Issue 1358: Require sending MTI curves in CH.key_share

[Eric Rescorla]

In the long curve popularity thread, there has been some discussion [0] of
what curves should be included in CH.key_shares and specifically if clients
should be required to send key shares
from one or more of the MTI curves [1]. I don't believe the specification
currently requires this, but it would clearly be a small change if we
wanted to make it. I've filed the following issue to track this suggestion:

https://github.com/tlswg/tls13-spec/issues/1358

-Ekr

[0] https://mailarchive.ietf.org/arch/msg/tls/JeE2watbipk6o0FVJFDa9W6J1A8/
[1] As Peter Gutmann notes, right now only P-256 is required so these are
the same thing, but we might add more MTI curves (e.g., a PQ hybrid) in the
future.
___
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?

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

[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: [EXTERNAL] Re: Curve-popularity data?

[Blumenthal, Uri - 0553 - MITLL]

CNSA 1.0 requires P-384 or RSA-3072, and does not allow P-256. 

CNSA 2.0 requires ML-KEM, and does not approve any of the ECC curves. But 
there’s a “transition period”, during which P-384 could presumably be used. 
-- 
V/R, 
Uri 


From: Scott Fluhrer (sfluhrer) 
Date: Wednesday, June 5, 2024 at 09:54
To: John Mattsson , tls@ietf.org 

Subject: [EXT] [TLS]Re: [EXTERNAL] Re: Curve-popularity data? 

If we’re talking about CNSA, well CNSA 2. 0 insists on ML-KEM-1024 (and would 
prefer that alone) – I had been assuming that could be better handled by the 
ML-KEM-only draft… From: John Mattsson  

ZjQcmQRYFpfptBannerStart 

This Message Is From an External Sender 
This message came from outside the Laboratory. 
ZjQcmQRYFpfptBannerEnd 

If we’re talking about CNSA, well CNSA 2.0 insists on ML-KEM-1024 (and would 
prefer that alone) – I had been assuming that could be better handled by the 
ML-KEM-only draft… 

From: John Mattsson  
Sent: Wednesday, June 5, 2024 1:56 AM
To: tls@ietf.org
Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data? 



Andrei Popov wrote: 
>CNSA requires P384, so we’ll also need a hybrid that includes this EC. 

Yes, I am not sure about the statement that P-256 is required. The requirement 
for FIPS in the next few years should be one of the NIST P-curves. I think 
P-384 is the most required of the NIST P-curves. 

Scott Fluhrer wrote:
>I believe that it is unreasonable to expect that a single combination would 
>satisfy everyone’s needs. 
Yes, that is completely unreasonable. TLS is MUCH larger than the Web. There 
will clearly be registrations for combinations of most current curves 
(P-curves, X-curves, Brainpool, SM, GOST) with most PQC KEMs (ML-KEM, BIKE/HQC, 
Classic McEliece, FrodoKEM, future Isogeny? (Isogenies was the hottest topic at 
Eurocrypt this year) ). European countries say that hybrids will be a must for 
a long-time. 

Cheers, 
John 

From: Andrei Popov mailto:Andrei.Popov=40microsoft@dmarc.ietf.org>>
Date: Wednesday, 5 June 2024 at 07:24
To: Eric Rescorla mailto:e...@rtfm.com>>, Stephen Farrell 
mailto:stephen.farr...@cs.tcd.ie>>
Cc: tls@ietf.org  mailto:tls@ietf.org>>
Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data? 

CNSA 

 requires P384, so we’ll also need a hybrid that includes this EC. 

Cheers, 

Andrei 

From: Eric Rescorla mailto:e...@rtfm.com>> 
Sent: Monday, June 3, 2024 12:53 PM
To: Stephen Farrell mailto:stephen.farr...@cs.tcd.ie>>
Cc: Loganaden Velvindron mailto:logana...@gmail.com>>; 
Andrei Popov mailto:andrei.po...@microsoft.com>>; 
Salz, Rich mailto:rs...@akamai.com>>; tls@ietf.org 

Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data? 







On Mon, Jun 3, 2024 at 11:55 AM Stephen Farrell > 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:-) 


Yes, this seems correct to me. 



-Ekr 








Cheers,
S. 












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

[TLS]tls@ietf120: I-D submission deadline

[Sean Turner]

Hi! Friendly reminder that the I-D submission deadline for IETF 120 is [1]:

2024-07-08 (Monday) Internet-Draft submission cut-off (for all Internet-Drafts, 
including -00) by UTC 23:59. Upload using the I-D Submission Tool [2]

Cheers,
spt

[1] https://datatracker.ietf.org/meeting/important-dates/
[2] https://datatracker.ietf.org/submit/
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: [EXTERNAL] Re: Curve-popularity data?

[Andrei Popov]

> if, when using a hybrid KEM, we're heading to a world where one large set of 
> clients emit x25519 and x25519+pq and another large set emit p256 and p384+pq?

We are already in the world where a large set of servers will HRR to get the 
client to send a 25519 key share, while another large set of servers will HRR 
to get the client to send a NIST curve key share. TLS 1.3 with HRR is somewhat 
higher-latency than the TLS 1.2 2-RTT handshake, so enabling TLS 1.3 can 
increase connection latency for some deployments.

With traditional groups, clients have an option of offering both 25519 and NIST 
key shares. With PQC/hybrids, this will likely become impractical, this is why 
I believe TLS key share prediction 
(https://www.ietf.org/archive/id/draft-ietf-tls-key-share-prediction-00.html) 
becomes more important.

Cheers,

Andrei

-Original Message-
From: Stephen Farrell  
Sent: Wednesday, June 5, 2024 12:20 AM
To: John Mattsson ; tls@ietf.org
Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?



On 05/06/2024 06:56, John Mattsson wrote:
> I think P-384 is the most required of the NIST P-curves.

I've heard that some. Oddly, I use a test server that only supports
p384 as a way to trigger HRR when testing ECH, which seems to work for most 
clients who test with my servers, so I wonder if, when using a hybrid KEM, 
we're heading to a world where one large set of clients emit x25519 and 
x25519+pq and another large set emit p256 and p384+pq?

I guess if that meant there wasn't a real need for much use of p256+pq that 
might be a small saving and worth documenting somewhere even if we do define a 
codepoint for p256+pq.

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

[TLS]Re: Working Group Last Call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

[Sean Turner]

WGLC closes out today.

spt

> On Jun 3, 2024, at 11:43, Sean Turner  wrote:
> 
> Hi! WGLC ends on Wednesday.  I know this I-D is not all that exciting and 
> most of the “discussion" was about whether to adopt the I-D at all, but it 
> would be great if we had a couple of more people chime in.  If you remember, 
> when we used the show of hands tool to help determine whether there was 
> consensus to adopt this draft there were 36 who wanted it adopted.
> 
> spt
> 
>> On May 28, 2024, at 09:44, Sean Turner  wrote:
>> 
>> Just a reminder that this WGLC is still ongoing.
>> 
>> spt
>> 
>>> On May 22, 2024, at 10:14, Sean Turner  wrote:
>>> 
>>> This email starts the working group last call for "Legacy RSASSA-PKCS1-v1_5 
>>> codepoints for TLS 1.3” I-D, located here:
>>> 
>>> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-pkcs1/
>>> 
>>> The WG Last Call will end 5 June 2024 @ 2359 UTC.
>>> 
>>> Please review the I-D and submit issues and pull requests via the GitHub 
>>> repository that can be found at:
>>> 
>>> https://github.com/tlswg/tls13-pkcs1
>>> 
>>> Alternatively, you can also send your comments to tls@ietf.org.
>>> 
>>> Thanks,
>>> spt
>> 
> 

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

[TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345

[Sean Turner]

Gentle reminder about these two PRs. I should note there are now others.

spt

> On Jun 3, 2024, at 11:38, Sean Turner  wrote:
> 
> Since draft-ietf-tls-rfc8446bis last completed WGLC, two PRs have been 
> submitted (and discussed) that include changes to normative language:
> 
> - #1343: Forbid the sender from sending redundant update_requested KeyUpdates
> https://github.com/tlswg/tls13-spec/pull/1343
> 
> - #1345: Forbid the sender from sending duplicate supported groups entries
> https://github.com/tlswg/tls13-spec/pull/1354
> 
> The discussion so far seems to support consensus to merge these PRs. If you 
> object, please
> do so on the issue or in response to this message.  Absent any pushback, we 
> will direct the
> editors to incorporate them in two weeks' time.
> 
> Cheers,
> spt

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

[TLS]Re: [EXTERNAL] Re: Curve-popularity data?

[Andrei Popov]

This is my understanding too, and I believe a lot of deployments limited to 
P384 will want to use a P384-based hybrid, at least “in transition”. The 
duration of this transition could be years…

Cheers,

Andrei

From: Blumenthal, Uri - 0553 - MITLL 
Sent: Wednesday, June 5, 2024 7:59 AM
To: Scott Fluhrer (sfluhrer) ; John 
Mattsson ; tls@ietf.org
Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?

CNSA 1.0 requires P-384 or RSA-3072, and does not allow P-256.

CNSA 2.0 requires ML-KEM, and does not approve any of the ECC curves. But 
there’s a “transition period”, during which P-384 could presumably be used.
--
V/R,
Uri


From: Scott Fluhrer (sfluhrer) 
mailto:sfluhrer=40cisco@dmarc.ietf.org>>
Date: Wednesday, June 5, 2024 at 09:54
To: John Mattsson 
mailto:john.mattsson=40ericsson@dmarc.ietf.org>>,
 tls@ietf.org mailto:tls@ietf.org>>
Subject: [EXT] [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
If we’re talking about CNSA, well CNSA 2. 0 insists on ML-KEM-1024 (and would 
prefer that alone) – I had been assuming that could be better handled by the 
ML-KEM-only draft… From: John Mattsson 
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside the Laboratory.
ZjQcmQRYFpfptBannerEnd
If we’re talking about CNSA, well CNSA 2.0 insists on ML-KEM-1024 (and would 
prefer that alone) – I had been assuming that could be better handled by the 
ML-KEM-only draft…

From: John Mattsson 
mailto:john.mattsson=40ericsson@dmarc.ietf.org>>
Sent: Wednesday, June 5, 2024 1:56 AM
To: tls@ietf.org
Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?

Andrei Popov wrote:
>CNSA requires P384, so we’ll also need a hybrid that includes this EC.

Yes, I am not sure about the statement that P-256 is required. The requirement 
for FIPS in the next few years should be one of the NIST P-curves. I think 
P-384 is the most required of the NIST P-curves.

Scott Fluhrer wrote:
>I believe that it is unreasonable to expect that a single combination would 
>satisfy everyone’s needs.
Yes, that is completely unreasonable. TLS is MUCH larger than the Web. There 
will clearly be registrations for combinations of most current curves 
(P-curves, X-curves, Brainpool, SM, GOST) with most PQC KEMs (ML-KEM, BIKE/HQC, 
Classic McEliece, FrodoKEM, future Isogeny? (Isogenies was the hottest topic at 
Eurocrypt this year) ). European countries say that hybrids will be a must for 
a long-time.

Cheers,
John

From: Andrei Popov 
mailto:Andrei.Popov=40microsoft@dmarc.ietf.org>>
Date: Wednesday, 5 June 2024 at 07:24
To: Eric Rescorla mailto:e...@rtfm.com>>, Stephen Farrell 
mailto:stephen.farr...@cs.tcd.ie>>
Cc: tls@ietf.org mailto:tls@ietf.org>>
Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
CNSA
 requires P384, so we’ll also need a hybrid that includes this EC.

Cheers,

Andrei

From: Eric Rescorla mailto:e...@rtfm.com>>
Sent: Monday, June 3, 2024 12:53 PM
To: Stephen Farrell 
mailto:stephen.farr...@cs.tcd.ie>>
Cc: Loganaden Velvindron mailto:logana...@gmail.com>>; 
Andrei Popov mailto:andrei.po...@microsoft.com>>; 
Salz, Rich mailto:rs...@akamai.com>>; 
tls@ietf.org
Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?




On Mon, Jun 3, 2024 at 11:55 AM 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:-)

Yes, this seems correct to me.

-Ekr




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

[TLS]Re: [EXTERNAL] Re: Curve-popularity data?

[Watson Ladd]

On Wed, Jun 5, 2024 at 8:38 AM Andrei Popov
 wrote:
>
> This is my understanding too, and I believe a lot of deployments limited to 
> P384 will want to use a P384-based hybrid, at least “in transition”. The 
> duration of this transition could be years…

I really do not understand this argument, given that the DoD has
explicitly said they aren't doing that.

>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> From: Blumenthal, Uri - 0553 - MITLL 
> Sent: Wednesday, June 5, 2024 7:59 AM
> To: Scott Fluhrer (sfluhrer) ; John 
> Mattsson ; tls@ietf.org
> Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
>
>
>
> CNSA 1.0 requires P-384 or RSA-3072, and does not allow P-256.
>
>
>
> CNSA 2.0 requires ML-KEM, and does not approve any of the ECC curves. But 
> there’s a “transition period”, during which P-384 could presumably be used.
>
> --
>
> V/R,
>
> Uri
>
>
>
>
>
> From: Scott Fluhrer (sfluhrer) 
> Date: Wednesday, June 5, 2024 at 09:54
> To: John Mattsson , tls@ietf.org 
> 
> Subject: [EXT] [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
>
> If we’re talking about CNSA, well CNSA 2. 0 insists on ML-KEM-1024 (and would 
> prefer that alone) – I had been assuming that could be better handled by the 
> ML-KEM-only draft… From: John Mattsson  dmarc. ietf. org>
>
> ZjQcmQRYFpfptBannerStart
>
> This Message Is From an External Sender
>
> This message came from outside the Laboratory.
>
> ZjQcmQRYFpfptBannerEnd
>
> If we’re talking about CNSA, well CNSA 2.0 insists on ML-KEM-1024 (and would 
> prefer that alone) – I had been assuming that could be better handled by the 
> ML-KEM-only draft…
>
>
>
> From: John Mattsson 
> Sent: Wednesday, June 5, 2024 1:56 AM
> To: tls@ietf.org
> Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
>
>
>
> Andrei Popov wrote:
>
> >CNSA requires P384, so we’ll also need a hybrid that includes this EC.
>
>
>
> Yes, I am not sure about the statement that P-256 is required. The 
> requirement for FIPS in the next few years should be one of the NIST 
> P-curves. I think P-384 is the most required of the NIST P-curves.
>
>
>
> Scott Fluhrer wrote:
> >I believe that it is unreasonable to expect that a single combination would 
> >satisfy everyone’s needs.
>
> Yes, that is completely unreasonable. TLS is MUCH larger than the Web. There 
> will clearly be registrations for combinations of most current curves 
> (P-curves, X-curves, Brainpool, SM, GOST) with most PQC KEMs (ML-KEM, 
> BIKE/HQC, Classic McEliece, FrodoKEM, future Isogeny? (Isogenies was the 
> hottest topic at Eurocrypt this year) ). European countries say that hybrids 
> will be a must for a long-time.
>
>
>
> Cheers,
>
> John
>
>
>
> From: Andrei Popov 
> Date: Wednesday, 5 June 2024 at 07:24
> To: Eric Rescorla , Stephen Farrell 
> Cc: tls@ietf.org 
> Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
>
> CNSA requires P384, so we’ll also need a hybrid that includes this EC.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> From: Eric Rescorla 
> Sent: Monday, June 3, 2024 12:53 PM
> To: Stephen Farrell 
> Cc: Loganaden Velvindron ; Andrei Popov 
> ; Salz, Rich ; tls@ietf.org
> Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
>
>
>
>
>
>
>
>
>
> On Mon, Jun 3, 2024 at 11:55 AM Stephen Farrell  
> 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:-)
>
>
>
> Yes, this seems correct to me.
>
>
>
> -Ekr
>
>
>
>
>
>
>
>
> Cheers,
> S.
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org



-- 
Astra mortemque praestare gradatim

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

[TLS]Re: [EXTERNAL] Re: Curve-popularity data?

[Andrei Popov]

  *   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.
I don’t know whether there are any IETF rules about this, but changing MTI 
algorithms does not sound appropriate in a -bis document.

Cheers,

Andrei

From: Bas Westerbaan 
Sent: Wednesday, June 5, 2024 7:22 AM
To: Dennis Jackson 
Cc: tls@ietf.org
Subject: [EXTERNAL] [TLS]Re: Curve-popularity data?



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?

[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.
 Learn why this is important
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.


___
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: [EXTERNAL] Re: Curve-popularity data?

[Scott Fluhrer (sfluhrer)]

On the other hand, I was at a recent conference, and asked an NSA 
representative (William Layton, Cryptographic Solutions Technical Director) 
about “hybrid crypto”, and he responded that the NSA was “ambivalent” (his 
word); that they’d prefer straight ML-KEM/ML-DSA, but if the industry insisted 
on hybrid crypto, they’d go along.

Hence, I don’t believe that CNSA 2.0 is taking quite as hard of a stand as the 
summary states…

From: John Mattsson 
Sent: Wednesday, June 5, 2024 11:52 AM
To: Watson Ladd ; Andrei Popov 

Cc: Blumenthal, Uri - 0553 - MITLL ; Scott Fluhrer (sfluhrer) 
; tls@ietf.org
Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?

>I really do not understand this argument, given that the DoD has explicitly 
>said they aren't doing that.

I think it is a bit unclear what CNSA 2.0 says:
- They say that CNSA 2.0 compliant browsers need to support ML-KEM-1024 by 2025.
- The also say that “NSA does not approve using pre-standardized or 
non-FIPS-validated CNSA 2.0 algorithms (even in hybrid modes)”.

I don’t see how you can combine fulfill both of these if estimates for when 
FIPS compliant implementations will be ready. My five cents would be that 
P-384+ML-KEM-1024 is CNSA 1.0 compliant until ML-KEM gets FIPS validated and 
then it becomes CNSA 2.0 compliant.

https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF
Cheers,
John

From: Watson Ladd mailto:watsonbl...@gmail.com>>
Date: Wednesday, 5 June 2024 at 17:39
To: Andrei Popov mailto:andrei.po...@microsoft.com>>
Cc: Blumenthal, Uri - 0553 - MITLL mailto:u...@ll.mit.edu>>, 
Scott Fluhrer (sfluhrer) mailto:sfluh...@cisco.com>>, John 
Mattsson mailto:john.matts...@ericsson.com>>, 
tls@ietf.org mailto:tls@ietf.org>>
Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
On Wed, Jun 5, 2024 at 8:38 AM Andrei Popov
mailto:Andrei.Popov=40microsoft@dmarc.ietf.org>>
 wrote:
>
> This is my understanding too, and I believe a lot of deployments limited to 
> P384 will want to use a P384-based hybrid, at least “in transition”. The 
> duration of this transition could be years…

I really do not understand this argument, given that the DoD has
explicitly said they aren't doing that.

>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> From: Blumenthal, Uri - 0553 - MITLL mailto:u...@ll.mit.edu>>
> Sent: Wednesday, June 5, 2024 7:59 AM
> To: Scott Fluhrer (sfluhrer) 
> mailto:sfluhrer=40cisco@dmarc.ietf.org>>;
>  John Mattsson 
> mailto:john.mattsson=40ericsson@dmarc.ietf.org>>;
>  tls@ietf.org
> Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
>
>
>
> CNSA 1.0 requires P-384 or RSA-3072, and does not allow P-256.
>
>
>
> CNSA 2.0 requires ML-KEM, and does not approve any of the ECC curves. But 
> there’s a “transition period”, during which P-384 could presumably be used.
>
> --
>
> V/R,
>
> Uri
>
>
>
>
>
> From: Scott Fluhrer (sfluhrer) 
> mailto:sfluhrer=40cisco@dmarc.ietf.org>>
> Date: Wednesday, June 5, 2024 at 09:54
> To: John Mattsson 
> mailto:john.mattsson=40ericsson@dmarc.ietf.org>>,
>  tls@ietf.org mailto:tls@ietf.org>>
> Subject: [EXT] [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
>
> If we’re talking about CNSA, well CNSA 2. 0 insists on ML-KEM-1024 (and would 
> prefer that alone) – I had been assuming that could be better handled by the 
> ML-KEM-only draft… From: John Mattsson  dmarc. ietf. org>
>
> ZjQcmQRYFpfptBannerStart
>
> This Message Is From an External Sender
>
> This message came from outside the Laboratory.
>
> ZjQcmQRYFpfptBannerEnd
>
> If we’re talking about CNSA, well CNSA 2.0 insists on ML-KEM-1024 (and would 
> prefer that alone) – I had been assuming that could be better handled by the 
> ML-KEM-only draft…
>
>
>
> From: John Mattsson 
> mailto:john.mattsson=40ericsson@dmarc.ietf.org>>
> Sent: Wednesday, June 5, 2024 1:56 AM
> To: tls@ietf.org
> Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
>
>
>
> Andrei Popov wrote:
>
> >CNSA requires P384, so we’ll also need a hybrid that includes this EC.
>
>
>
> Yes, I am not sure about the statement that P-256 is required. The 
> requirement for FIPS in the next few years should be one of the NIST 
> P-curves. I think P-384 is the most required of the NIST P-curves.
>
>
>
> Scott Fluhrer wrote:
> >I believe that it is unreasonable to expect that a single combination would 
> >satisfy everyone’s needs.
>
> Yes, that is completely unreasonable. TLS is MUCH larger than the Web. There 
> will clearly be registrations for combinations of most current curves 
> (P-curves, X-curves, Brainpool, SM, GOST) with most PQC KEMs (ML-KEM, 
> BIKE/HQC, Classic McEliece, FrodoKEM, future Isogeny? (Isogenies was the 
> hottest topic at Eurocrypt this year) ). European countries say that hybrids 
> will be a must for a long-time.
>
>
>
> Cheers,
>
> John
>
>
>
> From: And

[TLS]Re: [EXTERNAL] Re: Curve-popularity data?

[Andrei Popov]

  *   …they’d prefer straight ML-KEM/ML-DSA, but if the industry insisted on 
hybrid crypto, they’d go along.
This is my understanding, too:
“Even though hybrid solutions may be allowed or required due to protocol 
standards, product availability, or interoperability requirements, CNSA 2.0 
algorithms will become mandatory to select at the given date, and selecting 
CNSA 1.0 algorithms alone will no longer be approved."

It seems that CNSA may go along with hybrids, while “in transition”, if these 
hybrids combine CNSA-approved algorithms. We are actively working to clarify 
this.

From: Scott Fluhrer (sfluhrer) 
Sent: Wednesday, June 5, 2024 9:49 AM
To: John Mattsson ; Watson Ladd 
; Andrei Popov 
Cc: Blumenthal, Uri - 0553 - MITLL ; tls@ietf.org
Subject: RE: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?

On the other hand, I was at a recent conference, and asked an NSA 
representative (William Layton, Cryptographic Solutions Technical Director) 
about “hybrid crypto”, and he responded that the NSA was “ambivalent” (his 
word); that they’d prefer straight ML-KEM/ML-DSA, but if the industry insisted 
on hybrid crypto, they’d go along.

Hence, I don’t believe that CNSA 2.0 is taking quite as hard of a stand as the 
summary states…

From: John Mattsson 
mailto:john.matts...@ericsson.com>>
Sent: Wednesday, June 5, 2024 11:52 AM
To: Watson Ladd mailto:watsonbl...@gmail.com>>; Andrei 
Popov mailto:andrei.po...@microsoft.com>>
Cc: Blumenthal, Uri - 0553 - MITLL mailto:u...@ll.mit.edu>>; 
Scott Fluhrer (sfluhrer) mailto:sfluh...@cisco.com>>; 
tls@ietf.org
Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?

>I really do not understand this argument, given that the DoD has explicitly 
>said they aren't doing that.

I think it is a bit unclear what CNSA 2.0 says:
- They say that CNSA 2.0 compliant browsers need to support ML-KEM-1024 by 2025.
- The also say that “NSA does not approve using pre-standardized or 
non-FIPS-validated CNSA 2.0 algorithms (even in hybrid modes)”.

I don’t see how you can combine fulfill both of these if estimates for when 
FIPS compliant implementations will be ready. My five cents would be that 
P-384+ML-KEM-1024 is CNSA 1.0 compliant until ML-KEM gets FIPS validated and 
then it becomes CNSA 2.0 compliant.

https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF
Cheers,
John

From: Watson Ladd mailto:watsonbl...@gmail.com>>
Date: Wednesday, 5 June 2024 at 17:39
To: Andrei Popov mailto:andrei.po...@microsoft.com>>
Cc: Blumenthal, Uri - 0553 - MITLL mailto:u...@ll.mit.edu>>, 
Scott Fluhrer (sfluhrer) mailto:sfluh...@cisco.com>>, John 
Mattsson mailto:john.matts...@ericsson.com>>, 
tls@ietf.org mailto:tls@ietf.org>>
Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
On Wed, Jun 5, 2024 at 8:38 AM Andrei Popov
mailto:Andrei.Popov=40microsoft@dmarc.ietf.org>>
 wrote:
>
> This is my understanding too, and I believe a lot of deployments limited to 
> P384 will want to use a P384-based hybrid, at least “in transition”. The 
> duration of this transition could be years…

I really do not understand this argument, given that the DoD has
explicitly said they aren't doing that.

>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> From: Blumenthal, Uri - 0553 - MITLL mailto:u...@ll.mit.edu>>
> Sent: Wednesday, June 5, 2024 7:59 AM
> To: Scott Fluhrer (sfluhrer) 
> mailto:sfluhrer=40cisco@dmarc.ietf.org>>;
>  John Mattsson 
> mailto:john.mattsson=40ericsson@dmarc.ietf.org>>;
>  tls@ietf.org
> Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
>
>
>
> CNSA 1.0 requires P-384 or RSA-3072, and does not allow P-256.
>
>
>
> CNSA 2.0 requires ML-KEM, and does not approve any of the ECC curves. But 
> there’s a “transition period”, during which P-384 could presumably be used.
>
> --
>
> V/R,
>
> Uri
>
>
>
>
>
> From: Scott Fluhrer (sfluhrer) 
> mailto:sfluhrer=40cisco@dmarc.ietf.org>>
> Date: Wednesday, June 5, 2024 at 09:54
> To: John Mattsson 
> mailto:john.mattsson=40ericsson@dmarc.ietf.org>>,
>  tls@ietf.org mailto:tls@ietf.org>>
> Subject: [EXT] [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
>
> If we’re talking about CNSA, well CNSA 2. 0 insists on ML-KEM-1024 (and would 
> prefer that alone) – I had been assuming that could be better handled by the 
> ML-KEM-only draft… From: John Mattsson  dmarc. ietf. org>
>
> ZjQcmQRYFpfptBannerStart
>
> This Message Is From an External Sender
>
> This message came from outside the Laboratory.
>
> ZjQcmQRYFpfptBannerEnd
>
> If we’re talking about CNSA, well CNSA 2.0 insists on ML-KEM-1024 (and would 
> prefer that alone) – I had been assuming that could be better handled by the 
> ML-KEM-only draft…
>
>
>
> From: John Mattsson 
> mailto:john.mattsson=40ericsson@dmarc.ietf.org>>
> Sent: Wednesday, June 5, 2024 1:56 AM
> To: tls@ietf.org

[TLS]Re: [EXTERNAL] Re: Curve-popularity data?

[John Mattsson]

>On the other hand, I was at a recent conference, and asked an NSA 
>representative (William Layton, >Cryptographic Solutions Technical Director) 
>about “hybrid crypto”, and he responded that the NSA >was “ambivalent” (his 
>word); that they’d prefer straight ML-KEM/ML-DSA, but if the industry insisted 
>>on hybrid crypto, they’d go along.

That is my understanding as well, but they seem to take a hard stand on 
non-FIPS-validated algorithms. My understanding is that a non-FIPS-validated 
standalone ML-KEM-1024 would not be CNSA 1.0 and not CNSA 2.0 compliant. A 
FIPS-validated P-384 + non-FIPS-validated ML-KEM-1024 would to my understanding 
be CNSA 1.0 compliant. My feeling is that a FIPS-validated P-384 + 
non-FIPS-validated ML-KEM-1024 would be preferred over continuing with 
standalone P-384 for several years, but I think only NSA can answer this.

Cheers,
John

From: Scott Fluhrer (sfluhrer) 
Date: Wednesday, 5 June 2024 at 18:50
To: John Mattsson , Watson Ladd 
, Andrei Popov 
Cc: Blumenthal, Uri - 0553 - MITLL , tls@ietf.org 

Subject: RE: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
On the other hand, I was at a recent conference, and asked an NSA 
representative (William Layton, Cryptographic Solutions Technical Director) 
about “hybrid crypto”, and he responded that the NSA was “ambivalent” (his 
word); that they’d prefer straight ML-KEM/ML-DSA, but if the industry insisted 
on hybrid crypto, they’d go along.

Hence, I don’t believe that CNSA 2.0 is taking quite as hard of a stand as the 
summary states…

From: John Mattsson 
Sent: Wednesday, June 5, 2024 11:52 AM
To: Watson Ladd ; Andrei Popov 

Cc: Blumenthal, Uri - 0553 - MITLL ; Scott Fluhrer (sfluhrer) 
; tls@ietf.org
Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?

>I really do not understand this argument, given that the DoD has explicitly 
>said they aren't doing that.

I think it is a bit unclear what CNSA 2.0 says:
- They say that CNSA 2.0 compliant browsers need to support ML-KEM-1024 by 2025.
- The also say that “NSA does not approve using pre-standardized or 
non-FIPS-validated CNSA 2.0 algorithms (even in hybrid modes)”.

I don’t see how you can combine fulfill both of these if estimates for when 
FIPS compliant implementations will be ready. My five cents would be that 
P-384+ML-KEM-1024 is CNSA 1.0 compliant until ML-KEM gets FIPS validated and 
then it becomes CNSA 2.0 compliant.

https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF
Cheers,
John

From: Watson Ladd mailto:watsonbl...@gmail.com>>
Date: Wednesday, 5 June 2024 at 17:39
To: Andrei Popov mailto:andrei.po...@microsoft.com>>
Cc: Blumenthal, Uri - 0553 - MITLL mailto:u...@ll.mit.edu>>, 
Scott Fluhrer (sfluhrer) mailto:sfluh...@cisco.com>>, John 
Mattsson mailto:john.matts...@ericsson.com>>, 
tls@ietf.org mailto:tls@ietf.org>>
Subject: Re: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
On Wed, Jun 5, 2024 at 8:38 AM Andrei Popov
mailto:Andrei.Popov=40microsoft@dmarc.ietf.org>>
 wrote:
>
> This is my understanding too, and I believe a lot of deployments limited to 
> P384 will want to use a P384-based hybrid, at least “in transition”. The 
> duration of this transition could be years…

I really do not understand this argument, given that the DoD has
explicitly said they aren't doing that.

>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> From: Blumenthal, Uri - 0553 - MITLL mailto:u...@ll.mit.edu>>
> Sent: Wednesday, June 5, 2024 7:59 AM
> To: Scott Fluhrer (sfluhrer) 
> mailto:sfluhrer=40cisco@dmarc.ietf.org>>;
>  John Mattsson 
> mailto:john.mattsson=40ericsson@dmarc.ietf.org>>;
>  tls@ietf.org
> Subject: [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
>
>
>
> CNSA 1.0 requires P-384 or RSA-3072, and does not allow P-256.
>
>
>
> CNSA 2.0 requires ML-KEM, and does not approve any of the ECC curves. But 
> there’s a “transition period”, during which P-384 could presumably be used.
>
> --
>
> V/R,
>
> Uri
>
>
>
>
>
> From: Scott Fluhrer (sfluhrer) 
> mailto:sfluhrer=40cisco@dmarc.ietf.org>>
> Date: Wednesday, June 5, 2024 at 09:54
> To: John Mattsson 
> mailto:john.mattsson=40ericsson@dmarc.ietf.org>>,
>  tls@ietf.org mailto:tls@ietf.org>>
> Subject: [EXT] [TLS]Re: [EXTERNAL] Re: Curve-popularity data?
>
> If we’re talking about CNSA, well CNSA 2. 0 insists on ML-KEM-1024 (and would 
> prefer that alone) – I had been assuming that could be better handled by the 
> ML-KEM-only draft… From: John Mattsson  dmarc. ietf. org>
>
> ZjQcmQRYFpfptBannerStart
>
> This Message Is From an External Sender
>
> This message came from outside the Laboratory.
>
> ZjQcmQRYFpfptBannerEnd
>
> If we’re talking about CNSA, well CNSA 2.0 insists on ML-KEM-1024 (and would 
> prefer that alone) – I had been assuming that could be better handled by the 
> ML-KEM-only draft…
>
>
>
> From: John Mattsson 

[TLS]Re: Issue 1358: Require sending MTI curves in CH.key_share

[Martin Thomson]

I would not mandate the use of an MTI curve, but instead recommend it on the 
basis that this is most likely to avoid HelloRetryRequest and so result in 
faster handshakes.

Two reasons:

1. MTI doesn't always correspond to "best", particularly as the protocol ages.
2. If we have an MTI that is very good (or "best"), then we will not see many 
HelloRetryRequest, if at all.  I'm particularly concerned that we already have 
implementations that cannot send HelloRetryRequest, but this recommendation 
would make that worse.

On Wed, Jun 5, 2024, at 15:07, Eric Rescorla wrote:
> In the long curve popularity thread, there has been some discussion [0] 
> of what curves should be included in CH.key_shares and specifically if 
> clients should be required to send key shares
> from one or more of the MTI curves [1]. I don't believe the 
> specification currently requires this, but it would clearly be a small 
> change if we wanted to make it. I've filed the following issue to track 
> this suggestion:
>
> https://github.com/tlswg/tls13-spec/issues/1358
>
> -Ekr
>
> [0] 
> https://mailarchive.ietf.org/arch/msg/tls/JeE2watbipk6o0FVJFDa9W6J1A8/
> [1] As Peter Gutmann notes, right now only P-256 is required so these 
> are the same thing, but we might add more MTI curves (e.g., a PQ 
> hybrid) in the future.
> ___
> 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: HRR support (was something else)

[Rob Sayre]

On Tue, Jun 4, 2024 at 8:36 AM Bob Beck 
wrote:

>
>
> On Tue, Jun 4, 2024 at 7:24 AM Martin Thomson  wrote:
>
>> On Mon, Jun 3, 2024, at 14:34, Bas Westerbaan wrote:
>> > [...] 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.
>>
>> Whoa.  Are you saying that there are TLS 1.3 implementations out there
>> that don't send HRR when they should?  I get that you might want to
>> optimize a little if you have to connect to a server often.
>>
>> Optimization is a very different thing to the origin not supporting HRR
>> at all.
>
>
> There are most certainly situations where you do not get an HRR when you
> should.  There is more than one implementation of buggy middleware out
> there that mishandles large client hellos
>

Yes, that's what I've noticed. The more packets the ClientHelllo spans, the
worse it gets. The Google folks did a few studies on this problem, but I'm
not sure which paper is best to cite.

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

[TLS]Re: Issue 1358: Require sending MTI curves in CH.key_share

[Richard Barnes]

This sounds like the right approach to me.  The point of the MTI is to
ensure that the connection succeeds, not that it succeeds as quickly as
possible.
--Richard

On Wed, Jun 5, 2024 at 2:57 PM Martin Thomson  wrote:

> I would not mandate the use of an MTI curve, but instead recommend it on
> the basis that this is most likely to avoid HelloRetryRequest and so result
> in faster handshakes.
>
> Two reasons:
>
> 1. MTI doesn't always correspond to "best", particularly as the protocol
> ages.
> 2. If we have an MTI that is very good (or "best"), then we will not see
> many HelloRetryRequest, if at all.  I'm particularly concerned that we
> already have implementations that cannot send HelloRetryRequest, but this
> recommendation would make that worse.
>
> On Wed, Jun 5, 2024, at 15:07, Eric Rescorla wrote:
> > In the long curve popularity thread, there has been some discussion [0]
> > of what curves should be included in CH.key_shares and specifically if
> > clients should be required to send key shares
> > from one or more of the MTI curves [1]. I don't believe the
> > specification currently requires this, but it would clearly be a small
> > change if we wanted to make it. I've filed the following issue to track
> > this suggestion:
> >
> > https://github.com/tlswg/tls13-spec/issues/1358
> >
> > -Ekr
> >
> > [0]
> > https://mailarchive.ietf.org/arch/msg/tls/JeE2watbipk6o0FVJFDa9W6J1A8/
> > [1] As Peter Gutmann notes, right now only P-256 is required so these
> > are the same thing, but we might add more MTI curves (e.g., a PQ
> > hybrid) in the future.
> > ___
> > 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]

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: [EXTERNAL] Re: Curve-popularity data?

[Andrei Popov]

> In other words, will another curve be allowed once it's added to NIST SP 
> 800-56A?
For a (large) subset of the services, I believe this would allow Azure to 
enable X25519.

There would still remain services and environments where P384 is required 
(e.g., anywhere CNSA applies). This is a significant chunk for Azure, but 
perhaps less of an issue for some other operators.

> 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?
This is a complicated compliance question. I'm not qualified to comment on this 
option.

> 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?
No, not saying this. There may be customers who prefer NIST curves, but I have 
no data showing that this is common.

Cheers,

Andrei

-Original Message-
From: D. J. Bernstein  
Sent: Wednesday, June 5, 2024 1:01 PM
To: tls@ietf.org
Subject: [EXTERNAL] [TLS]Re: Curve-popularity data?

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

[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: HRR support (was something else)

[Watson Ladd]

On Wed, Jun 5, 2024 at 6:24 AM Peter Gutmann  wrote:
>
> Martin Thomson  writes:
>
> >Are you saying that there are TLS 1.3 implementations out there that don't
> >send HRR when they should?
>
> There are embedded TLS 1.3 implementations [*] that, presumably for space/
> complexity reasons and possibly also for attack surface reduction, only
> support the MTI algorithms (AES, SHA-2, P256) and don't do HRR.
>
> We found this out because of Google's noncompliant implementation in Chrome.
> In the presence of compliant implementations that do the MTI algorithms in the
> client hello, you don't need HRR.

What wording makes you think you need the MTI algorithms in the client
hello? I certainly don't read it that way.

>
> Peter.
>
> [*] OK, not very many since they're mostly still TLS 1.2, but there are a
> small number.
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org



-- 
Astra mortemque praestare gradatim

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

[TLS]Is NIST actually prohibiting X25519?

[D. J. Bernstein]

Andrei Popov writes:
> This is a complicated compliance question. I'm not qualified to
> comment on this option.

I think it's worth investigating, considering the following NIST quote:

   Their associated key agreement schemes, X25519 and X448, will be
   considered for inclusion in a subsequent revision to SP 800-56A.  The
   CMVP does not intend to enforce compliance with SP 800-56A until
   these revisions are complete.

https://web.archive.org/web/20200810165057/https://csrc.nist.gov/projects/cryptographic-module-validation-program/notices

Does anyone have any documents showing that NIST has reneged on the
above announcement? Possibilities:

   * Yes: then I'd appreciate a pointer so that concerned members of the
 community can tell NIST what they think about this and, hopefully,
 get NIST to change course.

   * No: then the announcement and consistent handling of this by NIST
 would be another reason for IETF to not be dragged down by the
 current limitations of NIST SP 800-56A.

If nobody has ever tried asking NIST to approve an X25519 solution as
per the above announcement, surely that would be a useful experiment,
creating a path towards simplifying subsequent TLS WG discussions.

---D. J. Bernstein

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

[TLS]Re: Is NIST actually prohibiting X25519?

[Richard Barnes]

As with the earlier thread, this message is off-topic for this list.

Regardless of what NIST does, the TLS protocol does and will support a
variety of curves.


On Wed, Jun 5, 2024 at 20:14 D. J. Bernstein  wrote:

> Andrei Popov writes:
> > This is a complicated compliance question. I'm not qualified to
> > comment on this option.
>
> I think it's worth investigating, considering the following NIST quote:
>
>Their associated key agreement schemes, X25519 and X448, will be
>considered for inclusion in a subsequent revision to SP 800-56A.  The
>CMVP does not intend to enforce compliance with SP 800-56A until
>these revisions are complete.
>
>
> https://web.archive.org/web/20200810165057/https://csrc.nist.gov/projects/cryptographic-module-validation-program/notices
>
> Does anyone have any documents showing that NIST has reneged on the
> above announcement? Possibilities:
>
>* Yes: then I'd appreciate a pointer so that concerned members of the
>  community can tell NIST what they think about this and, hopefully,
>  get NIST to change course.
>
>* No: then the announcement and consistent handling of this by NIST
>  would be another reason for IETF to not be dragged down by the
>  current limitations of NIST SP 800-56A.
>
> If nobody has ever tried asking NIST to approve an X25519 solution as
> per the above announcement, surely that would be a useful experiment,
> creating a path towards simplifying subsequent TLS WG discussions.
>
> ---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: [EXT] Re: Is NIST actually prohibiting X25519?

[Blumenthal, Uri - 0553 - MITLL]

NIST cannot prohibit a curve, or an algorithm. But they may not approve it – 
and for customers that require approved technology and algorithms, it would 
prevent them from using anything that’s not explicitly approved.

--
V/R,
Uri

There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.

 -  C. A. R. Hoare


From: Richard Barnes 
Date: Wednesday, June 5, 2024 at 20:20
To: tls@ietf.org 
Subject: [EXT] [TLS]Re: Is NIST actually prohibiting X25519?
As with the earlier thread, this message is off-topic for this list.   
Regardless of what NIST does, the TLS protocol does and will support a variety 
of curves. On Wed, Jun 5, 2024 at 20: 14 D. J. Bernstein  
wrote: Andrei
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside the Laboratory.
ZjQcmQRYFpfptBannerEnd
As with the earlier thread, this message is off-topic for this list.

Regardless of what NIST does, the TLS protocol does and will support a variety 
of curves.


On Wed, Jun 5, 2024 at 20:14 D. J. Bernstein 
mailto:d...@cr.yp.to>> wrote:
Andrei Popov writes:
> This is a complicated compliance question. I'm not qualified to
> comment on this option.

I think it's worth investigating, considering the following NIST quote:

   Their associated key agreement schemes, X25519 and X448, will be
   considered for inclusion in a subsequent revision to SP 800-56A.  The
   CMVP does not intend to enforce compliance with SP 800-56A until
   these revisions are complete.

https://web.archive.org/web/20200810165057/https://csrc.nist.gov/projects/cryptographic-module-validation-program/notices

Does anyone have any documents showing that NIST has reneged on the
above announcement? Possibilities:

   * Yes: then I'd appreciate a pointer so that concerned members of the
 community can tell NIST what they think about this and, hopefully,
 get NIST to change course.

   * No: then the announcement and consistent handling of this by NIST
 would be another reason for IETF to not be dragged down by the
 current limitations of NIST SP 800-56A.

If nobody has ever tried asking NIST to approve an X25519 solution as
per the above announcement, surely that would be a useful experiment,
creating a path towards simplifying subsequent TLS WG discussions.

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