[TLS] WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

At IETF 121, the WG discussed “Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3”; see [0] and [1]. We also had some discussion in an information gathering thread; see [2]. We would like to now determine whether there is support to adopt this I-D. If you support adoption and are willing

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

I support adoption (and I am willing to review) > -Original Message- > From: Sean Turner > Sent: Wednesday, February 26, 2025 1:26 PM > To: TLS List > Subject: [TLS] WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key > Agreement for TLSv1.3 > > At IETF 121, the WG discussed “Post-

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

I support adoption. X25519MLKEM768 has already been widely deployed, and it is time for the standards track to catch up. David On Wed, Feb 26, 2025, 13:35 Sean Turner wrote: > At IETF 121, the WG discussed “Post-Quantum Hybrid ECDHE-MLKEM Key > Agreement for TLSv1.3”; see [0] and [1]. We also h

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

I support adoption. -Ekr On Wed, Feb 26, 2025 at 10:32 AM Sean Turner wrote: > At IETF 121, the WG discussed “Post-Quantum Hybrid ECDHE-MLKEM Key > Agreement for TLSv1.3”; see [0] and [1]. We also had some discussion in an > information gathering thread; see [2]. We would like to now determine

[TLS] Re: Implicit ECH Config for TLS 1.3 – addressing public_name fingerprinting

Nick, Thanks for proposing this. This is an interesting idea, but I'm not entirely sure it meaningfully reduces the impact of fingerprinting in practice. Specifically, it seems mainly useful when there are ECH and non-ECH domains on the same IP and there isn't a critical mass of ECH. More detail b

[TLS] Re: [EXTERNAL] WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

I support adoption, am willing to review and contribute text, planning to implement. Cheers, Andrei -Original Message- From: Sean Turner Sent: Wednesday, February 26, 2025 10:26 AM To: TLS List Subject: [EXTERNAL] [TLS] WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreeme

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

I support adoption. Chris P. On Wed, Feb 26, 2025 at 10:31 AM Sean Turner wrote: > At IETF 121, the WG discussed “Post-Quantum Hybrid ECDHE-MLKEM Key > Agreement for TLSv1.3”; see [0] and [1]. We also had some discussion in an > information gathering thread; see [2]. We would like to now determi

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

As I understand it, the purpose of this draft is to specify an interoperable key exchange mechanism that we can deploy. The draft already has code points allocated to it, and they exist in the registry , so I

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

ZjQcmQRYFpfptBannerEnd I support adoption. X25519MLKEM768 has already been widely deployed, and it is time for the standards track to catch up. Same here. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

I strongly support adoption, and we have already implemented and shipped the draft. Thanks, Joe ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call: draft-kwiatkowski-tls-ecdhe-mlkem

Perfect! Thank you Sean! On 26/02/2025 14:59, Bas Westerbaan wrote: Thank you Sean! On Wed, Feb 26, 2025 at 3:41 PM Sean Turner wrote: Hi! Just in case you missed it [0], your draft is up first in the PQ wg-call-for-adoption-o-rama.  I should have the message out later today. spt

[TLS] WG Adoption Call: draft-kwiatkowski-tls-ecdhe-mlkem

Hi! Just in case you missed it [0], your draft is up first in the PQ wg-call-for-adoption-o-rama. I should have the message out later today. spt [0] https://mailarchive.ietf.org/arch/msg/tls/KMOTm_lE5OIAKG8_chDlRKuav7c/ ___ TLS mailing list -- tls@iet

[TLS] Re: WG Adoption Call: draft-kwiatkowski-tls-ecdhe-mlkem

Thank you Sean! On Wed, Feb 26, 2025 at 3:41 PM Sean Turner wrote: > Hi! Just in case you missed it [0], your draft is up first in the PQ > wg-call-for-adoption-o-rama. I should have the message out later today. > > spt > > [0] https://mailarchive.ietf.org/arch/msg/tls/KMOTm_lE5OIAKG8_chDlRKuav

[TLS] [IANA #1413503] expert review for draft-ietf-tls-esni (tls-extensiontype-values)

Hi Nick, Yes, that's correct; this review request is for the two new registrations in section 11.1 in the TLS ExtensionType Values registry, which has the registration procedure of Specification Required. Thank you. Best regards, David Dong IANA Services Sr. Specialist On Wed Feb 26 08:10:28

[TLS] The TLS WG has placed draft-kwiatkowski-tls-ecdhe-mlkem in state "Call For Adoption By WG Issued"

The TLS WG has placed draft-kwiatkowski-tls-ecdhe-mlkem in state Call For Adoption By WG Issued (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/ ___ TLS mailing list -- tls@ietf.

[TLS] Re: [EXTERNAL] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

+1 to David. --- Mike Ounsworth From: David Benjamin Sent: Wednesday, February 26, 2025 12:57 PM To: Sean Turner Cc: TLS List Subject: [EXTERNAL] [TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 I support adoption. X25519MLKEM768 has already

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

On Wed, Feb 26, 2025 at 3:20 PM Christopher Wood wrote: > Being concerned about the WG's time makes sense, but given that this is a > case where the WG has gotten very very behind running code, hopefully we > can try to stamp this one with minimal fuss and time spent. After all, > we've already b

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

+1 From: Salz, Rich Date: Wednesday, 26 February 2025 at 20:56 To: David Benjamin , Sean Turner Cc: TLS List Subject: [TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 ZjQcmQRYFpfptBannerEnd I support adoption. X25519MLKEM768 has already been widely deplo

[TLS] Re: [EXTERNAL] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

I second Rob and David. RFC numbers matter outside the IETF; they are a signal that something is mature and well-vetted, and can then be re-ratified in NIST documents, ISO documents, PCI documents, etc etc. I think that for something as critical as the recommended PQ TLS cipher suite, sayin

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

I've definitely had folks ask whether it's OK to deploy this yet, so I think it would be valuable. I can't really fault them for asking---the usual story is that draft things are doomed to be replaced by their final standards and this one hasn't even been adopted. Really, I'm appreciative that thos

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

On Wed, Feb 26, 2025 at 11:43 AM Christopher Wood wrote: > As I understand it, the purpose of this draft is to specify an > interoperable key exchange mechanism that we can deploy. The draft already > has code points allocated to it, and they exist in the registry >

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

Discussed in this thread started December 16th: https://mailarchive.ietf.org/arch/msg/tls/yGZV5dBTcxHJhG-JtfaP6beTd68/ On Wed, Feb 26, 2025 at 2:46 PM Christopher Wood wrote: > As I understand it, the purpose of this draft is to specify an > interoperable key exchange mechanism that we can depl

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

> On Feb 26, 2025, at 3:03 PM, David Benjamin wrote: > > I've definitely had folks ask whether it's OK to deploy this yet, so I think > it would be valuable. I can't really fault them for asking---the usual story > is that draft things are doomed to be replaced by their final standards and >

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

Christopher Wood wrote: > I wonder: what is the point of adopting this draft when the important work is > already done? If it’s that some folks won’t implement it until there’s an RFC > number assigned to it, well, that’s pretty silly. It may seem silly to all folks who are directly involved he

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

Joining the chorus to support adoption and a speedy path to WGLC. We have already shipped X25519MLKEM768 in Go 1.24.___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

Adopt. The ordering and naming mess probably needs to be sorted out here. I'd ordinarily say that the working group can sort that out, but I'm not 100% confident that this group can. Please show me that I'm wrong. On Thu, Feb 27, 2025, at 05:26, Sean Turner wrote: > At IETF 121, the WG discus

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

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

[TLS] Re: [EXTERNAL] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

All we have for PQC right now is some individual I-Ds using "not recommended" IANA code points. We must have PQC RFCs for TLS and the first step is WG adoption. Cheers, Andrei -Original Message- From: Jan Schaumann Sent: Wednesday, February 26, 2025 1:07 PM To: tls@ietf.org Subject:

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

I'm in favour of adoption. S. OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

I support adoption. Chrome has enabled X25519-MLKEM768 by default since October 2024. On Wed, Feb 26, 2025 at 5:11 PM Russ Housley wrote: > I support adoption. > > Russ > > ___ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-l

[TLS] Re: Implicit ECH Config for TLS 1.3 – addressing public_name fingerprinting

Hi Raghu, Thank you for your response, my replies are inline. On Wed, Feb 26, 2025 at 6:40 PM Raghu Saxena wrote: > Hi Nick, > > On 2/26/25 3:14 PM, Nick Sullivan wrote: > > > > Hi everyone, > > > > > > I’ve put together a draft, “Implicit ECH Configuration for TLS 1.3” > > (https://www.ietf.or

[TLS] Impersonation attacks on protocol in draft-fossati-tls-attestation (Identity crisis in Attested TLS) for Confidential Computing

Hi all, *Context*: At IETF 121, Hannes presented draft-fossati-tls-attestation [1] mentioning Confidential Computing as the priority (slide 3 in [2]) and asked for adoption (slide 4 in [2]). *Findings of Formal Analysis*: In collaboration with the /active/ editors of the draft, we have been

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

Speaking as someone who has often expressed the opinion that we don't need an RFC because the code points have been assigned, I think that it's a good thing to publish an RFC in this case. More generally, I think the WG should publish a core set of specifications which represent our recommendation

[TLS] Re: Implicit ECH Config for TLS 1.3 – addressing public_name fingerprinting

Hi Eric, Thanks for the thoughtful response, replies inline. On Thu, Feb 27, 2025 at 2:26 AM Eric Rescorla wrote: > Nick, > > Thanks for proposing this. This is an interesting idea, but I'm not > entirely sure it meaningfully reduces the impact of fingerprinting > in practice. Specifically, it

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

On Wed, Feb 26, 2025 at 01:57:07PM -0500, David Benjamin wrote: > I support adoption. X25519MLKEM768 has already been widely deployed, and it > is time for the standards track to catch up. I support adoption. From my mail logs: Feb 26 15:41:10 chardros postfix/smtp[680168]: Untrusted TLS

[TLS] Re: [IANA #1413503] expert review for draft-ietf-tls-esni (tls-extensiontype-values)

I’m conflicted out as mentioned, but I want to clarify: this request is for the code points in the existing extension (section 11.1), not the request for the alert code point (11.2) or the new extension registry (11.3), correct? On Wed, Feb 26, 2025 at 3:15 AM Salz, Rich wrote: > I approve. > >

[TLS] Re: Implicit ECH Config for TLS 1.3 – addressing public_name fingerprinting

This looks like a reasonable change. I hope that this moves forward. On Wed, 26 Feb 2025 at 11:17, Nick Sullivan wrote: > > Hi everyone, > > > I’ve put together a draft, “Implicit ECH Configuration for TLS 1.3” > (https://www.ietf.org/archive/id/draft-sullivan-tls-implicit-ech-00.html), as > a

[TLS] Re: Implicit ECH Config for TLS 1.3 – addressing public_name fingerprinting

Hi Nick, On 2/26/25 3:14 PM, Nick Sullivan wrote: Hi everyone, I’ve put together a draft, “Implicit ECH Configuration for TLS 1.3” (https://www.ietf.org/archive/id/draft-sullivan-tls-implicit-ech-00.html ), as a poten

[TLS] Re: Implicit ECH Config for TLS 1.3 – addressing public_name fingerprinting

Hi Nick, First of all, I fully agree that current implementations with a static public SNI are trivial to block. To a certain extent this mitigates the positive effects of the ECH. However, a completely random client generated public SNI will cause a number of other issues as the public SNI is qu

[TLS] Re: Implicit ECH Config for TLS 1.3 – addressing public_name fingerprinting

Hi Raghu, On Wed, Feb 26, 2025 at 10:41 AM Raghu Saxena wrote: > > I think in the context of the censor discussion you linked, > realistically they can just block ECH (including GREASed ECH), since > there isn't really mass saturation of ECH (GREASed or not) across most > TLS clients, so they wo

[TLS] Re: 2nd Working Group Last Call for The SSLKEYLOGFILE Formatfor TLS

On Tue, Feb 25, 2025 at 12:01:00PM +, Stephen Farrell wrote: > > Hiya, > > On 24/02/2025 21:54, Martin Thomson wrote: > > but > > this is a case where that interoperation already exists. > I think the above was true of your initial draft Martin, > but is significantly less true of the current

[TLS] Dnsdir last call review of draft-ietf-tls-svcb-ech-07

Reviewer: Matt Brown Review result: Ready Hi Folks, I am the assigned DNS Directorate reviewer for this draft which I see has had two rounds of DNSDIR reviews on previous revisions already. The changes from the previously reviewed -06 revision are minimal and do not alter any of the DNS related

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

I support adoption. On Wed, 26 Feb 2025 at 22:32, Sean Turner wrote: > > At IETF 121, the WG discussed “Post-Quantum Hybrid ECDHE-MLKEM Key Agreement > for TLSv1.3”; see [0] and [1]. We also had some discussion in an information > gathering thread; see [2]. We would like to now determine whethe

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

I support adoption On the good point opened by Chris Wood and to echo Peter, I see the same syndrome from other SDOs. If not in a ratified text people won't move. Trying to find an explanation for why this is the case, for nearly all the customers I work with, teams have a lot of limits to what t

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

It's interesting, IMO, that there is so much belief that an RFC designation will drive so much adoption here, but it didn't seem to be the same consensus that enshrining SSLKEYLOGFILE in an RFC might increase the number of systems that support key exfil. To be sure, I don't confidently know which

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

Mike Shaver wrote: > It's interesting, IMO, that there is so much belief that an RFC designation > will drive so much adoption here, but it didn't seem to be the same > consensus that enshrining SSLKEYLOGFILE in an RFC might increase the number > of systems that support key exfil. My guess: Diffe