[TLS]Re: Curve-popularity data?

[Dennis Jackson]

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

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

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

Maybe the TLS co-chair has a comment?


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

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


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


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


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


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

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

[TLS]Re: Curve-popularity data?

[Loganaden Velvindron]

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

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

Who is claiming that P-256 has a backdoor ?


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


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

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

[TLS]HRR support (was something else)

[Martin Thomson]

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.

Are you concerned that this sort of coddling removes some useful incentive to 
implement HRR?

I've held this concern for a while, particularly for QUIC.  If we have a very 
homogeneous profile of support for primitives, we're risking having the 
negotiation mechanisms fail when we need them.

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

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

[Bob Beck]

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, so if you send a large key share
you are out of luck. This doesn't mean the implementation is not attempting
to implement HRR, it's just the bugs effectively mean if you hit the
problem case, you lose. While hopefully ecosystem pressure eventually gets
fixed versions deployed,  the number of these in the wild is far from zero
today.


>


> Are you concerned that this sort of coddling removes some useful incentive
> to implement HRR?
>
> I've held this concern for a while, particularly for QUIC.  If we have a
> very homogeneous profile of support for primitives, we're risking having
> the negotiation mechanisms fail when we need them.
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Kampanakis, Panos]

+1 .

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

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


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


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


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

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

-Ekr



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

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

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

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

[Kampanakis, Panos]

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

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



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

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

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

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

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

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

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

[TLS]Re: Curve-popularity data?

[D. J. Bernstein]

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

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

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

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

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

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

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

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

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

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

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

---D. J. Bernstein

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

[TLS]Re: Curve-popularity data?

[Richard Barnes]

Thanks for refocusing this discussion, Dennis.

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

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

--Richard


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

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

[TLS]Re: Curve-popularity data?

[Salz, Rich]

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

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

[TLS]Re: Curve-popularity data?

[Richard Barnes]

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

--RLB

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

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

[TLS]Re: Curve-popularity data?

[Salz, Rich]

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

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

[TLS]Re: Curve-popularity data?

[Scott Fluhrer (sfluhrer)]

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

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


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

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

As for my two cents (US):

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


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

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

--RLB

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

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

[TLS]Re: Curve-popularity data?

[Eric Rescorla]

I largely agree with Richard here.

To recap some basic facts

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

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

-Ekr

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

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

> This WG does not get to decide which hybrids will exist or be
> standardized, unless it has implications on the TLS protocol, which it does
> not.
>
> --RLB
>
> On Tue, Jun 4, 2024 at 2:51 PM Salz, Rich  wrote:
>
>> I urge the chairs to call cloture on this thread.  There is nothing
>> relevant for the working group here.
>>
>>
>>
>> I think that is premature.  Yes, there is a lot of noise, but it was only
>> one or two days ago that reasons for hybrids with both P256 and X25519 were
>> given.
>>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[D. J. Bernstein]

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

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

---D. J. Bernstein

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

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

[Andrei Popov]

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

[John Mattsson]

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