I would disagree; it does have implications on the TLS protocol. This working group does make the call as to which combinations it would like to specify in an RFC and generate TLS code points for; be it:
* P256 + ML-KEM-768 * X25519 + MK-KEM-768 * Some other combination And, as it would be reasonable to try to minimize the change to existing implementations, it would appear to be reasonable to enquire about the support for P256 vs X25519 (in addition to how well they would satisfy other requirements, such as compliance and user trust). As for my two cents (US): * I don’t personally see how relevant it is how often P256 vs X25519 are used – if they are both supported by an implementation, then it is plausible to assume (lacking further information about the implementation) that an update to that implementation would be equally easy in both cases. * Having P256 + ML-KEM-768 on the list would make my employer happier, for FIPS compliance reasons. * I believe that it is unreasonable to expect that a single combination would satisfy everyone’s needs, hence it would certainly be reasonable to allocate multiple code points for different combinations. From: Richard Barnes <r...@ipv.sx> Sent: Tuesday, June 4, 2024 2:57 PM To: Salz, Rich <rs...@akamai.com> Cc: Dennis Jackson <ietf=40dennis-jackson...@dmarc.ietf.org>; tls@ietf.org Subject: [TLS]Re: Curve-popularity data? This WG does not get to decide which hybrids will exist or be standardized, unless it has implications on the TLS protocol, which it does not. --RLB On Tue, Jun 4, 2024 at 2:51 PM Salz, Rich <rs...@akamai.com<mailto:rs...@akamai.com>> wrote: I urge the chairs to call cloture on this thread. There is nothing relevant for the working group here. I think that is premature. Yes, there is a lot of noise, but it was only one or two days ago that reasons for hybrids with both P256 and X25519 were given.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
