[TLS] ECH not protect SNI

and make a PSK handshake to the server. So why the working group does not choose the DNSSEC method? Thanks Taoshu(涛叔) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH not protect SNI

icate, we do not need a CA. Drop the outer domain is the first step. If we did, the server could also publish some public key for (EC)DHE key exchange. Theses key can be verified by DNSSEC, and be used for the real TLS handshake. You register a domain, deploy the DNSSEC and then you can serve

Re: [TLS] ECH not protect SNI

Hi, Stephen, > On Aug 24, 2022, at 07:57, Stephen Farrell wrote: > > I don't believe that is the case. A small hoster can choose a > "public_name" and use that for customers. An enterprise of > whatever size can choose a "public_name" like example.com > and > then use that

Re: [TLS] ECH not protect SNI

Hi, Rob, > On Aug 24, 2022, at 08:25, Rob Sayre wrote: > > It might be a bit misguided, since the IP address would reveal enough in most > cases. There is a essential difference between IP address and domain. You can change IP address easily, but it is almost impossible to change a domain nam

Re: [TLS] ECH not protect SNI

Hi, Stephen, I actually has some trouble to understand your point. > On Aug 24, 2022, at 08:58, Stephen Farrell wrote: > > Factually, many people do deploy a web server hosted as a > VPS by a small hoster, so could benefit from ECH, to some > extent. I know in the small part of the world wher

Re: [TLS] ECH not protect SNI

Hi, Rob, Also CC Stephen, I am not make my opinion clear, sorry for disturbing. And I try my best to summary my opinion again. If people want to deploy ECH, they need to public the ECHConfig by the HTTPS/SVCB DNS record. The browser use the ECHConfig to encrypted the inner client hello data,

Re: [TLS] ECH not protect SNI

Hi, Christopher, > On Aug 24, 2022, at 11:19, Christopher Patton wrote: > > It's true that reverse proxies, like Cloudflare, terminate TLS for a large > number of names and therefore have the potential to provide a higher degree > of privacy. But I don't think it's fair to say that smaller TLS

Re: [TLS] ECH not protect SNI

Hi, Christian, > On Aug 24, 2022, at 14:23, Christian Huitema wrote: > > Yes, the server might tell its clients to use a fake external SNI, and that > might fool some of the current censorship services. But that will only work > until the next update to these services. If there is no proxy, th

Re: [TLS] ECH not protect SNI

> On Aug 24, 2022, at 16:11, Eric Rescorla wrote: > > As a practical matter, most sites need to be deployed on cloud services like > AWS, Cloudflare, etc., so if this is true, > then ECH just isn't going to work at all. But, I don't think it's in fact > going to be the case in many jurisdicti

Re: [TLS] ECH not protect SNI

Hi Stephen, Thank you for understanding :) > On Aug 24, 2022, at 18:12, Stephen Farrell wrote: > > So let me try see if I understand by trying to re-phrase > your concern: the operator of a single web server with a > single DNS name and nobody else to help (no CDN, no hoster > no split-mode fro

Re: [TLS] ECH not protect SNI

need a real outer SNI domain for a real handshake to make sure the retry_configs is valid. > On Aug 24, 2022, at 20:50, Eric Rescorla wrote: > > > > On Wed, Aug 24, 2022 at 5:00 AM 涛叔 mailto:h...@taoshu.in>> > wrote: >> >>> On Aug 24, 2022, at 18:12, St

Re: [TLS] ECH not protect SNI

Hi, Eric, Thank your for reviewing. > On Aug 24, 2022, at 22:25, Eric Rescorla wrote: > > Are these keys and names shared between the domains in the anonymity set? This keys are only used for ECHConfig correction. And the could be shared across one anonymity set. For example, Cloudflare coul

Re: [TLS] ECH not protect SNI

Hi, Eric, Thanks for offering the detailed design considerations. > On Aug 24, 2022, at 23:08, Eric Rescorla wrote: > > I'd like to take a step back here. > > There are two design considerations here: > > 1. Managing the situation where the server loses its ECH key. > 2. Concealing that ECH i

Re: [TLS] ECH not protect SNI

> On Aug 25, 2022, at 04:00, Eric Rescorla wrote: > > On Wed, Aug 24, 2022 at 8:36 AM 涛叔 mailto:h...@taoshu.in>> > wrote: >> >>> On Aug 24, 2022, at 23:08, Eric Rescorla >> <mailto:e...@rtfm.com>> wrote: >>> >>> I'd like

Re: [TLS] ECH not protect SNI

Hi, Ben > On Aug 26, 2022, at 05:12, Ben Schwartz > wrote: > > I think you would be better off starting with DANE (RFC 7671), rather than > ECH. If you're willing to accept DNSSEC as a requirement, all sorts of > strange things become possible. For example, with DANE-EE and the SPKI > sele

Re: [TLS] 115 Proposal - ECH, server-side deploy risks and trade-offs

Hi, Ben, > On Oct 13, 2022, at 22:35, Ben Schwartz > wrote: > > On Thu, Oct 13, 2022 at 8:58 AM Marwan Fayed > > wrote: > ... >> There are really only two ways to populate the outer-SNI. One way is a >> fixed name that easily identifies the content oper

Re: [TLS] Encrypted Client Hello - SNI leaks via public name?

Hi, Dennis, > On Oct 6, 2023, at 19:31, Dennis Jackson > wrote: > On 06/10/2023 10:45, Raghu Saxena wrote: >> Specifically, I am concerned about the "public name" field in the ECHConfig. >> For services such as cloudflare, they can "hide" everything behind a single >> domain (e.g. "cloudflare-

Re: [TLS] Working Group Last Call for ECH

I have risen similar discussion before and have tried to suggest some solutions, but none of them got any support. Here is the previous discuss thread, just FYI https://mailarchive.ietf.org/arch/msg/tls/HlwYX16Y4W2BevKTpI6a81eO1JE/ > On Mar 13, 2024, at 13:20, Raghu Saxena wrote: > > Are comm

Re: [TLS] Working Group Last Call for ECH

Hi, Eric, > On Mar 14, 2024, at 00:45, Eric Rescorla wrote: > > There are two questions here: > > 1. What the specification says > 2. What implementations choose to do within the envelope of that > specification. > > The specification needs to prescribe a set of behaviors that promote > inte

[TLS] ECH Proxy Mode

Hi, In the split mode of the current draft of ECH, both the client-facing server and the backend server are needed to be ECH-aware. As upon the client-facing server decrypted the ClientHelloOut, it will forward the ClientHelloInner to the backend server, and waiting the backend's ServerHello with

[TLS] Re: ECH Proxy Mode

Hi, > On Sep 4, 2024, at 11:28, Raghu Saxena wrote: > > On 9/3/24 10:52 PM, 涛叔 wrote: >> This idea was derived from my attempt to implement encrypted TLS SNI Proxy. >> The SNI >> does not only expose privacy information, many ISP use it to block certain >> web

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

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 status

I personally propose the community to reconsider the design of accept_confirmation. May be it sounds crazy, I advise to drop the requirements of the accept_confirmation. So that we can deploy the IETF without touching the backend server in the Split-Mode. And this will be a big promotion for th