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

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

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

[TLS]Re: [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

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

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

[TLS]Re: Curve-popularity data?

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 sayin

[TLS]Re: HRR support (was something else)

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 algori

[TLS]Re: Curve-popularity data?

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 som

[TLS]Re: Curve-popularity data?

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

[TLS]Re: HRR support (was something else)

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 possibl

[TLS]Re: Curve-popularity data?

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 som

[TLS]Re: Curve-popularity data?

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

[TLS]Re: Curve-popularity data?

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 does

[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 Sent: Wednesday, June 5, 2024 1:56 AM To: tls@ietf.org Subject: [TLS]Re: [EXTERNAL] Re: Curve-populari

[TLS]Re: Curve-popularity data?

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

[TLS]Re: HRR support (was something else)

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

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

[TLS]Re: Curve-popularity data?

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 straightforwar

[TLS]Re: Curve-popularity data?

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 preser

[TLS]Re: Curve-popularity data?

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 M

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

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 woul

[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

[TLS]Re: Curve-popularity data?

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_sh

[TLS]Re: Curve-popularity data?

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 a

[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

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

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/

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

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

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

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

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

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 th

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

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

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

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

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

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

[TLS]Re: Curve-popularity data?

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

[TLS]Re: Curve-popularity data?

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

[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

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

* …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 algorit

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

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

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 ver

[TLS]Re: HRR support (was something else)

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

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

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

[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

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

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

[TLS]Re: Curve-popularity data?

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

[TLS]Re: Curve-popularity data?

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,

[TLS]Re: HRR support (was something else)

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 poss

[TLS]Is NIST actually prohibiting X25519?

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

[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 Popov writes: > > This is a complicated compliance question. I'm not quali

[TLS]Re: [EXT] Re: Is NIST actually prohibiting X25519?

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 simpl