Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

On 23/08/2022 01:39, Martin Thomson wrote: On Tue, Aug 23, 2022, at 00:11, Kris Kwiatkowski wrote: As X25519 is not FIPS-approved, the lab won't be able to test it, OK, hypothetical question, but maybe an important one. Why would a certification lab care? We compose secrets with non-secrets

Re: [TLS] ECH not protect SNI

Hi, Christopher, Thanks for reply. It seems you reply to me personally, so I resend our discussion the list. > On Aug 23, 2022, at 22:45, Christopher Patton wrote: > > You're correct that the outer SNI is sent in the clear, but there is no a > priori reason why this would leak the inner SNI i

Re: [TLS] ECH not protect SNI

Hiya, On 24/08/2022 00:39, 涛叔 wrote: It may be right for a common cloud platform, but what about indie server? Every site who need ECH have to deploy an addition outer domain to*protect* the inner one. But these indie servers can not share a common outer domain, so the have to use some distinc

Re: [TLS] ECH not protect SNI

On Tue, Aug 23, 2022 at 4:58 PM Stephen Farrell wrote: > > Hiya, > > On 24/08/2022 00:39, 涛叔 wrote: > > It may be right for a common cloud platform, but what about indie > > server? Every site who need ECH have to deploy an addition outer > > domain to*protect* the inner one. But these indie ser

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

[TLS] [Editorial Errata Reported] RFC8996 (7103)

The following errata report has been submitted for RFC8996, "Deprecating TLS 1.0 and TLS 1.1". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7103 -- Type: Editorial Reported by: Martin Thomso

Re: [TLS] ECH not protect SNI

On Tue, Aug 23, 2022 at 5:14 PM 涛叔 wrote: > > What if there is no small hoster? If a person just buy a VPS to deploy a > HTTPS server, what should he do to deploy ECH? > It might be a bit misguided, since the IP address would reveal enough in most cases. If you're saying that ECH requires an int

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

On Tue, Aug 23, 2022 at 5:45 PM 涛叔 wrote: > > Some countries and organizations will block website by SNI. If they want, > the could block all sites protected by > the common outer SNI domain. All the websites not after some intermediary > will be blocked more easily, because > they could not depl

Re: [TLS] ECH not protect SNI

Hiya, On 24/08/2022 01:11, 涛叔 wrote: What if there is no small hoster? If a person just buy a VPS to deploy a HTTPS server, what should he do to deploy ECH? 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 th

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

On Tue, Aug 23, 2022 at 6:26 PM 涛叔 wrote: > My point there is some people run their website without intermediary > proxy. They still deserve the protection of ECH. > So what is you point here? > The design does not work without what the draft calls an "anonymity set". Maybe you could explain you

Re: [TLS] ECH not protect SNI

It's also worth noting that the benefit of ECH goes well beyond encrypting SNI. There are lots of potentially sensitive things that are sent in the ClientHello, e.g., the ALPN value. There's also an important future-proofing aspect to this: We might end up with extensions in the future that inadver

Re: [TLS] ECH not protect SNI

Hiya, On 24/08/2022 02:26, 涛叔 wrote: Hi, Stephen, I actually has some trouble to understand your point. Yes, perhaps we're not understanding one another and it might help if you could describe what you think is the win here? What would you like to see? On Aug 24, 2022, at 08:58, Stephen

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 Taushu, What I try to accomplish is to let every website could deploy ECH. > I believe everyone can, and they should. 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'

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

On 8/23/2022 8:58 PM, 涛叔 wrote: 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 fa