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

[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 ; S

[TLS]Re: Curve-popularity data?

Richard Barnes writes: > Popularity of algorithms is entirely > irrelevant to this working group's charter. To clarify, are you saying that there was some relevant charter change after the extensive TLS WG discussions that decided on the algorithms to include in TLS 1.3---which, naturally, include

[TLS]Re: Curve-popularity data?

I largely agree with Richard here. To recap some basic facts 0. TLS is algorithm agile and Supported Groups [0] are listed in an IANA registry 1. The TLS Supported Groups registry has the "Specification Required" policy which means that in practice anyone can register groups. 2. Setting a group t

[TLS]Re: Curve-popularity data?

I would disagree; it does have implications on the TLS protocol. This working group does make the call as to which combinations it would like to specify in an RFC and generate TLS code points for; be it: * P256 + ML-KEM-768 * X25519 + MK-KEM-768 * Some other combination And, as it

[TLS]Re: Curve-popularity data?

This WG does not get to decide which hybrids will exist or be standardized, unless it has implications on the TLS protocol, which it does not. Then I do not understand what a WG adoption really means. Please elighten me. ___ TLS mailing list -- tls@iet

[TLS]Re: Curve-popularity data?

This WG does not get to decide which hybrids will exist or be standardized, unless it has implications on the TLS protocol, which it does not. --RLB On Tue, Jun 4, 2024 at 2:51 PM Salz, Rich wrote: > I urge the chairs to call cloture on this thread. There is nothing > relevant for the working

[TLS]Re: Curve-popularity data?

I urge the chairs to call cloture on this thread. There is nothing relevant for the working group here. I think that is premature. Yes, there is a lot of noise, but it was only one or two days ago that reasons for hybrids with both P256 and X25519 were given. __

[TLS]Re: Curve-popularity data?

Thanks for refocusing this discussion, Dennis. To put it even more bluntly: Popularity of algorithms is entirely irrelevant to this working group's charter. TLS has algorithm agility. Even if everyone loves one choice, the protocol doesn't care. Because some people might disagree, or the beloved

[TLS]Re: Curve-popularity data?

Dennis Jackson writes: > Especially when the referenced comment was unconnected to any active > discussion within the WG or decisions made by the chairs. Hybrids are an ongoing topic of active discussion within the WG, with hundreds of messages on the WG mailing list in the past year (including 18

[TLS]Re: Curve-popularity data?

> and (crucially) for the verified modules with ML-KEM. True, but the NIST queue is over 2+ years right now. Check out the Modules In Process which go back to 2022 https://csrc.nist.gov/Projects/cryptographic-module-validation-program/modules-in-process/modules-in-process-list So, if we only go

[TLS]Re: Curve-popularity data?

+1 . I was of the impression that https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-10#name-iana-considerations was going to get final codepoints for both combinations. Also, “PQ hybrid automatically FIPSed with P256” is an important factor. Using a FIPS certified ML-KEM imple

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

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 orig

[TLS]HRR support (was something else)

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 th

[TLS]Re: Curve-popularity data?

On Tue, 4 Jun 2024 at 09:22, John Mattsson wrote: > > D. J. Bernstein wrote: > > >Again, I understand that certificates haven't upgraded t allowing Ed25519 > >yet; > > > > The WebPKI forbids EdDSA and my understanding is that TLS library support is > lacking [1], but otherwise I don't think the

[TLS]Re: Curve-popularity data?

On 03/06/2024 17:25, D. J. Bernstein wrote: I'm still puzzled as to what led to the statement that I quoted at the beginning: P 256 is the most popular curve in the world besides the bitcoin curve. And I don’t have head to head numbers, and the bitcoin curve is SEC P, but P 256 is m