[TLS] Re: [EXTERNAL] draft-kwiatkowski-tls-ecdhe-mlkem and P-384

I assume draft-ietf-tls-hybrid-design will remove all mentioning of Kyber and only refer to the final standardized ML-KEM. I don't think TLS WG should publish anything with Kyber. I think hybrids with ML-KEM should be standard track and Recommended = Y. I think all hybrids of ML-KEM with curves

[TLS] Re: Is there any interest in an RFC on how to do cross-organization mTLS?

I would be very supportive of such approach. I think the scope should cover mTLS in general, not just cross-organization. The term mTLS is not even defined in IETF, in fact the TLS WG has previously used mTLS for at two other things. It would be good to a document to refer to for implementation

[TLS] Re: Is there any interest in an RFC on how to do cross-organization mTLS?

I agree here. The term “mTLS” is used more and more and there’s no specification. If we could document a few profiles for it, like internal use in a system, cross-organisation etc that would be beneficial. /O > On 10 Sep 2024, at 09:16, John Mattsson > wrote: > > I would be very supportive o

[TLS] Re: Is there any interest in an RFC on how to do cross-organization mTLS?

I agree. It is also good to cover different reference models / recommended patterns for mTLS vs one-way TLS. Best, Sudha E Iyer | Head, Data CyberSecurity Architecture Team|Chief Information Security Office| sudha.e.i...@citi.com

[TLS] Re: [EXTERNAL] draft-kwiatkowski-tls-ecdhe-mlkem and P-384

* I assume draft-ietf-tls-hybrid-design will remove all mentioning of Kyber and only refer to the final standardized ML-KEM. I don't think TLS WG should publish anything with Kyber. In fact, the current unified draft has IANA instructions to mark the KyberDraft0 assignments as obsolete.

[TLS] Re: ECH Proxy Mode

Hi, Raghu, > On Sep 10, 2024, at 00:35, Raghu Saxena wrote: > > I'm still not sure what specific benefit this has compare to a TLS HTTPS > connect proxy + HTTP CONNECT. > > In both cases, we need to modify the User-Agent behavior a little bit (e.g. > tell browser to use HTTPS proxy, vs. confi

[TLS] Re: Is there any interest in an RFC on how to do cross-organization mTLS?

Mark, Hi! I’d suggest writing the I-D [1] and then we (the royal we here) can figure out where it goes; could be ALLDISPATCH then TLS or UTA depending on ALLDISPATCH outcome. Additionally, discussing at the ALLDISPATCH session would get much a wider audience, which I think would help in genera

[TLS] Re: [EXTERNAL] draft-kwiatkowski-tls-ecdhe-mlkem and P-384

On Tuesday, 10 September 2024 16:05:51 CEST, Salz, Rich wrote: * I assume draft-ietf-tls-hybrid-design will remove all mentioning of Kyber and only refer to the final standardized ML-KEM. I don't think TLS WG should publish anything with Kyber. In fact, the current unified draft has IANA i

[TLS] Re: [EXTERNAL] draft-kwiatkowski-tls-ecdhe-mlkem and P-384

> On 10 Sep 2024, at 16:05, Salz, Rich wrote: > > • I assume draft-ietf-tls-hybrid-design will remove all mentioning of > Kyber and only refer to the final standardized ML-KEM. I don't think TLS WG > should publish anything with Kyber. > In fact, the current unified draft has IANA instruc

[TLS] Publication has been requested for draft-ietf-tls-deprecate-obsolete-kex-05

Joseph Salowey has requested publication of draft-ietf-tls-deprecate-obsolete-kex-05 as Proposed Standard on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/ _

[TLS] Re: Consensus Call: -rfc8446bis PRs #1360

Hi! Thanks to all who participated in this consensus call (and those who participated at IETF 120). Based on both the TLS WG sessions at IETF 120 and this thread, the consensus is to not merge the PR. ekr - please close the PR out and submit a new version of the I-D when you have time. spt >

[TLS] TLS Interim (was Re: interim-2024-tls-01 interim approved)

Hi! We have scheduled a virtual interim to discuss Trust Expressions / Trust Anchors Transition. We are in the process of defining some ground rules for the meeting as well as setting some expected outcomes, but we wanted to get the interim on the calendar. Cheers, spt > On Sep 10, 2024, at 13

[TLS] Re: [EXTERNAL] draft-kwiatkowski-tls-ecdhe-mlkem and P-384

> Does it mean that both draft-ietf-tls-hybrid-design and > draft-kwiatkowski-tls-ecdhe-mlkem should be standard track or only one of > them? draft-ietf-tls-hybrid-design depends on pre-standard Kyber and does not matter any more; draft-kwiatkowski-tls-ecdhe-mlkem is completely separate, should

[TLS] Re: Consensus Call: -rfc8446bis PRs #1360

On 9/10/24 18:28, Sean Turner wrote: Hi! Thanks to all who participated in this consensus call (and those who participated at IETF 120). Based on both the TLS WG sessions at IETF 120 and this thread, the consensus is to not merge the PR. ekr - please close the PR out and submit a new version o

[TLS] Transport Layer Security (tls) WG Virtual Meeting: 2024-10-01

The Transport Layer Security (tls) WG will hold a virtual interim meeting on 2024-10-01 from 12:00 to 15:00 America/New_York (16:00 to 19:00 UTC). Agenda: Topic: Trust Expressions / Trust Anchors Agenda: TBD Information about remote participation: https://meetings.conf.meetecho.com/interim/?group

[TLS] ECH Status

I've finished my shepherd review and there are 3 PRs to merge (#625 , #624 , #623 ) There is also one additional editorial PR (#622

[TLS] Re: Planned changes to Cloudflare's post-quantum deployment

Thanks Bas! We plan to do the same for Chrome, replacing X25519Kyber768Draft00 with X25519MLKEM768. X25519MLKEM768 should be live now to a small fraction of Chrome Canary, so that servers have some clients in the wild to test against. After a little time to give early Kyber adopters time to migrat

[TLS] Re: [EXTERNAL] Re: Planned changes to Cloudflare's post-quantum deployment

Hi David, * After a little time to give early Kyber adopters time to migrate, we'll roll the change out more fully. Are you planning to offer X25519MLKEM768 key share on the initial ClientHello (in addition to X25519), or just advertise for those servers willing to burn a round-trip? Chee

[TLS] Re: [EXTERNAL] Re: Planned changes to Cloudflare's post-quantum deployment

Yup, we plan to offer it in the initial ClientHello. (We currently offer X25519Kyber768Draft00 in the initial ClientHello, so X25519MLKEM768 would just take its place.) Of course, it is still the server's responsibility to correctly evaluate ClientHellos where X25519MLKEM768 appears in supported_g

[TLS] I-D Action: draft-ietf-tls-key-share-prediction-01.txt

Internet-Draft draft-ietf-tls-key-share-prediction-01.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: TLS Key Share Prediction Author: David Benjamin Name:draft-ietf-tls-key-share-prediction-01.txt Pages: 7 Dates: 2024-

[TLS] draft-ietf-tls-key-share-prediction next steps

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 hard transition loses PQ coverage for some clients. Kyber was a draft

[TLS] Re: [EXTERNAL] draft-ietf-tls-key-share-prediction next steps

I support staying the course, continuing work on the key share prediction draft and allocating the code point. Cheers, Andrei From: David Benjamin Sent: Tuesday, September 10, 2024 2:40 PM To: Subject: [EXTERNAL] [TLS] draft-ietf-tls-key-share-prediction next steps Hi all, Now that we're w

[TLS] Re: [EXTERNAL] draft-ietf-tls-key-share-prediction next steps

Same. On Tue, Sep 10, 2024 at 11:51 PM Andrei Popov wrote: > I support staying the course, continuing work on the key share prediction > draft and allocating the code point. > > > > Cheers, > > > > Andrei > > > > *From:* David Benjamin > *Sent:* Tuesday, September 10, 2024 2:40 PM > *To:* > *

[TLS] Re: [EXTERNAL] draft-ietf-tls-key-share-prediction next steps

I also believe this should move forward. > On Sep 10, 2024, at 4:05 PM, Bas Westerbaan > wrote: > > Same. > > On Tue, Sep 10, 2024 at 11:51 PM Andrei Popov > wrote: > I support staying the course, continuing work on the key share prediction > draft and allocating the code point. > Cheers,

[TLS] Re: I-D Action: draft-ietf-tls-deprecate-obsolete-kex-05.txt

I found spelling errors in the last draft version and fixed them in this pull request: https://github.com/tlswg/draft-deprecate-obsolete-kex/pull/18 I also added wildcard cipher suite references in the security considerations chapter for better understanding. TLS_DH_* was already referenced in t

[TLS] Re: draft-ietf-tls-key-share-prediction next steps

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