[TLS] Re: ECH Proxy Mode

Dear 涛叔, On 9/10/24 11:00 PM, 涛叔 wrote: If we can use the ECH-based proxy, we could transfer all these tasks to the server side. The only task that the end user need to do is to setup a custom DoH URL, which is personalized to this user only with auth data in the URL. The proxy list is maintain

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

"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

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

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.

[TLS] Re: ECH Proxy Mode

Dear Raghu, The MiTM solution may works for self-host, because the user controls both the browser and the proxy node. However, it is not acceptable for public proxy, because the middle node could see all the plain traffic between the user and the target, which is a far more serious problem than

[TLS] Re: ECH Proxy Mode

- all I don't think need to use random, we can use Session ID, which is deprecated since TLS 1.3. Random is used to derive master key, AFAIK.  11.09.2024, 17:29, "涛叔" :Dear Raghu, The MiTM solution may works for self-host, because the user controls both the browser an

[TLS] Re: ECH Proxy Mode

According to https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.3 A client which receives a legacy_session_id_echo field that does not match what it sent in the ClientHello MUST abort the handshake with an "illegal_parameter" alert. So we can't use the legacy_session_id_echo of SH. > On

[TLS] Re: ECH Proxy Mode

How about early data? I think it's big enough to carry an inner Client/Server Hello. 11.09.2024, 17:45, "涛叔" :According to https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.3 A client which receives a legacy_session_id_echo field that does not match whatit sent in the ClientHello MUST abort

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

+1 to Sean here, it would be easier to evaluate this with a document in hand. And in particular, a list of ways that people find mTLS is failing in practice. I am generally skeptical of this idea, at least as a TLS WG item. In pure TLS terms, there is no such thing as "one-way TLS" or "mutually

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

There is also discussion of "mTLS" in the WIMSE working group as it relates to workload identity. There are some things that are unique to that environment, but in general it is not too much different from other use cases. Joe On Wed, Sep 11, 2024 at 7:24 AM Richard Barnes wrote: > +1 to Sean

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

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

[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

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.

[TLS] Early codepoint allocation for tls_flags

Hi all, It was suggested that sending this more broadly might be helpful. I'm looking to implement draft-ietf-tls-cross-sni-resumption, which depends on draft-ietf-tls-tlsflags. Both WG drafts in the data tracker appear to be in "Waiting for Implementation" state. Looking back in the list, it seem

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

On Wed, Sep 11, 2024 at 10:24:06AM -0400, Richard Barnes wrote: > In other words, I disagree with Olle's and John's assertion that there's no > definition for mTLS. There is: "TLS where the server sends a > CertificateRequest and the client sends a Certificate" Any TLS handshake > where that hap

[TLS] Re: Early codepoint allocation for tls_flags

To the extent it matters I support allocation so we can roll things out and publish. TLS flags in particular has a lot depending on it. -- Astra mortemque praestare gradatim ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le.

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

I'm with Richard on this one. Not a fan of the "mTLS" concept: it causes confusion where customers ask whether "mTLS" is a different protocol or a specific TLS implementation? However, it can be argued that this unfortunate term has already taken root. A UTA document discussing challenges of u

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

Andrei Popov writes: >I'm with Richard on this one. Not a fan of the "mTLS" concept: it causes >confusion where customers ask whether "mTLS" is a different protocol or a >specific TLS implementation? However, it can be argued that this unfortunate >term has already taken root. +1, Richard pretty