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 Wed, Aug 24, 2022 at 12:06 AM 涛叔 wrote: > 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 updat

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

Hiya, On 24/08/2022 09:34, 涛叔 wrote: I am not saying ECH isn't going to work at all. Even most sites need to be deployed behind cloud services, it not means we could design a standard to make it as a requirement. So let me try see if I understand by trying to re-phrase your concern: the operat

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

On Wed, Aug 24, 2022 at 1:34 AM 涛叔 wrote: > > > 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 fac

Re: [TLS] ECH not protect SNI

On Wed, Aug 24, 2022 at 5:00 AM 涛叔 wrote: > > On Aug 24, 2022, at 18:12, Stephen Farrell > wrote: > > > I think Chris' answer wrt encrypting ALPNs etc is correct, > the ECH mechanism does still provide a (perhaps minor) > benefit in such cases, and as Ekr says, a client could send > a bogus SNI

Re: [TLS] ECH not protect SNI

Hi, Eric, Here is a more detailed proposal. Every server who want to deploy ECH must generate one key pair used for signature. The public key of this signing key pair should be published with the ECHConfig's public_name. The public_name should be a valid, but fake, domain name, which can be

Re: [TLS] ECH not protect SNI

On Wed, Aug 24, 2022 at 7:12 AM 涛叔 wrote: > Hi, Eric, > > Here is a more detailed proposal. > Thank you. > > Every server who want to deploy ECH must generate one key pair used for > signature. > > The public key of this signing key pair should be published with the > ECHConfig's public_name.

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] New Version for draft-segers-tls-cert-validation-ext

We received feedback from the aviation community that there is a need for this extension to be included in the CertificateRequest message for the case where the server rather than the client is the constrained resource (the aircraft in our use case). I have updated the draft to reflect the addit

Re: [TLS] ECH not protect SNI

On Wed, Aug 24, 2022 at 7:48 AM 涛叔 wrote: > 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 >

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

Hiya, On 24/08/2022 16:36, 涛叔 wrote: I can't agree with you. FWIW, I agree with ekr. I don't think the scheme you outlined works, nor would it be a good basis for changes to ECH. (Sorry;-) As I said before, there may be some guidance we can offer web server deployers in such cases but I real

Re: [TLS] ECH not protect SNI

On 8/24/2022 9:03 AM, Stephen Farrell wrote: Hiya, On 24/08/2022 16:36, 涛叔 wrote: I can't agree with you. FWIW, I agree with ekr. I don't think the scheme you outlined works, nor would it be a good basis for changes to ECH. (Sorry;-) The proposal to use "fake DNS names" like "c01e7ce0b61

Re: [TLS] ECH not protect SNI

On Wed, Aug 24, 2022 at 8:36 AM 涛叔 wrote: > 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 serve

Re: [TLS] New Version for draft-segers-tls-cert-validation-ext

On Wed, Aug 24, 2022 at 7:52 AM Ashley Kopman wrote: > I would greatly appreciate any feedback on this draft as well as any > feedback on the next steps for working with the TLS working group. > Maybe the best thing to remember is that we can only offer suggestions. You don't need approval, but

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 >> > wrote: >>> >>> I'd like to take a step back here. >>> >>> There are two design considerations