On Wed, Sep 11, 2024 at 12:41 AM John Mattsson wrote:
> "To avoid downgrade attacks, the client MUST continue to send its full
> preferences in the supported_groups extension."
>
>
>
> I don't think sending full preferences is a requirement in RFC 8446. As
> far as I can see there is no normative
ct on real web metrics?
From: David Adrian
Sent: Thursday, September 12, 2024 11:26 PM
To: Kampanakis, Panos
Cc: David Benjamin ;
Subject: RE: [EXTERNAL] [TLS] Re: draft-ietf-tls-key-share-prediction next steps
CAUTION: This email originated from outside of the organization. Do not click
links
onn. Any numbers you have to
> showcase the regression and the relevant affected web metrics?
>
>
>
>
>
> *From:* David Benjamin
> *Sent:* Wednesday, September 11, 2024 8:02 PM
> *To:* Ilari Liusvaara
> *Cc:*
> *Subject:* [EXTERNAL] [TLS] Re: draft-ietf-tls-key-share-p
content per conn. Any numbers you have to showcase the
regression and the relevant affected web metrics?
From: David Benjamin
Sent: Wednesday, September 11, 2024 8:02 PM
To: Ilari Liusvaara
Cc:
Subject: [EXTERNAL] [TLS] Re: draft-ietf-tls-key-share-prediction next steps
CAUTION: This emai
Thanks for the comments! Responses inline.
On Wed, Sep 11, 2024 at 3:39 AM John Mattsson
wrote:
> "To avoid downgrade attacks, the client MUST continue to send its full
> preferences in the supported_groups extension."
>
>
>
> I don't think sending full preferences is a requirement in RFC 8446.
On Wed, Sep 11, 2024 at 3:58 AM Ilari Liusvaara
wrote:
> On Wed, Sep 11, 2024 at 10:13:55AM +0400, Loganaden Velvindron wrote:
> > On Wed, 11 Sept 2024 at 01:40, David Benjamin
> wrote:
> > >
> > > Hi all,
> > >
> > > Now that we're working through the Kyber to ML-KEM transition, TLS
> > > 1.3's
On Wed, Sep 11, 2024 at 10:13:55AM +0400, Loganaden Velvindron wrote:
> On Wed, 11 Sept 2024 at 01:40, David Benjamin wrote:
> >
> > Hi all,
> >
> > Now that we're working through the Kyber to ML-KEM transition, TLS
> > 1.3's awkwardness around key share prediction is becoming starkly
> > visible.
"To avoid downgrade attacks, the client MUST continue to send its full
preferences in the supported_groups extension."
I don't think sending full preferences is a requirement in RFC 8446. As far as
I can see there is no normative text in RFC 8446 forbidding the client to
change the "supported_g
On Wed, 11 Sept 2024 at 01:40, David Benjamin wrote:
>
> Hi all,
>
> Now that we're working through the Kyber to ML-KEM transition, TLS 1.3's
> awkwardness around key share prediction is becoming starkly visible. (It is
> difficult for clients to efficiently offer both Kyber and ML-KEM, but a ha
