[TLS] ECH not protect SNI

[涛叔]

Hello, Guys,

I have read the draft-ietf-tls-esni-14, and found the ECH does not protect the 
SNI.

Because if the client use the outdated ECH config to encrypted the 
ClientHelloInner,
it will not be decrypted by the client facing server.

In order to correct the client, the server will finish the handshake using the
ClientHelloOuter, which has its own SNI. And the server will send new ECH 
configs
encrypted by its SSL certificate. So the client can verify the new configs is 
valid.

In my own opinion, this design only hide the original SNI, but still depends the
client-facing server's domain name. It has two drawbacks:

1. If one domain want to deploy ECH in share mode, it have to offer one 
addition domain
for the ClientHelloOuter.
2. Even the real domain will be encrypted, the shared domain don't. And if the 
outs
domain been blocked, all the inner domain will gone.

So my question is why not just use the DNSSEC method the correct the client who
has some outed ECH configs?

If the client-facing can not decrypted the ClientHelloInner, all it needs to do 
is
send the new HTTPS DNS records and their RRSIGs. And the client can validate 
them by
the DNSSEC methods.

By this design, there is no need to establish the outer TLS handshake. And no 
additional
outer domain any more. The client does not need to know or deploy two domain as 
well.

And for almost TLS handshake, their even no need to a SSL certificates. Because 
we can
deploy some public key by the DNS, 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

[涛叔]

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 in a given deployment. For 
> example, a reverse proxy might use the same public name for all hostnames it 
> terminates TLS for.

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
distinct one who doe one-to-one respond the inner one.

The leak of the outer domain is equal the leak for the inner one, which make 
the protection for the inner one useless.

> The reason we have the ECH rejection path (terminate TLS with 
> ClientHelloOuter and transmit updated ECH config list) is that the DNS record 
> obtained by the client might not be in sync with the TLS server.  Imagine an 
> ECH enabled server that rotates the ECH config list every day or even every 
> hour: The higher the rotation frequency, the more likely it becomes that 
> somewhere in the world, some client tries to use an out-of-date DNS record.

Yes, the  ECH RR should be rotated, and the client may get the outdated 
records. We need a method to send the latest records
to the client and correct it's handshake. In the meanwhile, the client needs 
some method to assure the new records sent from the
server is valid. This is why the outer domain and TLS certificate the outer 
domain are needed.

In order to make ECH suitable for indie servers, which not own some common 
outer domain, we should not depend the outer SNI and
TLS handshake at all.

What about make the server just send the ECH RR and it's responding RRSig to 
the client? By this way, the client can validate the
new ECH record by the DNSSEC means. And does not need to send the outer domain 
at all.

However, this design means the ECH depends the DNSSEC. As a result, maybe it is 
hard to deploy ECH because of the low rate
deployment of DNSSEC. But I do not think it is a real problem. Because the ECH 
depends the DNS SVCB, as well. An DNS SVCB
also need to be deployment from zero.

Make the ECH depends the DNSSEC just make the DNSSEC has additional benefit. If 
you want to protect client's SNI, you have to
deploy DNSSEC. And this will promote the deployment of DNSSEC too.

Another benefit of this DNSSEC-style method is that we may transfer to a 
CA-free world. If we do not need a certificate, 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 content by TLS.

> On Aug 19, 2022, at 07:04, 涛叔  wrote:
> 
> Hello, Guys,
> 
> I have read the draft-ietf-tls-esni-14, and found the ECH does not protect 
> the SNI.
> 
> Because if the client use the outdated ECH config to encrypted the 
> ClientHelloInner,
> it will not be decrypted by the client facing server.
> 
> In order to correct the client, the server will finish the handshake using the
> ClientHelloOuter, which has its own SNI. And the server will send new ECH 
> configs
> encrypted by its SSL certificate. So the client can verify the new configs is 
> valid.
> 
> In my own opinion, this design only hide the original SNI, but still depends 
> the
> client-facing server's domain name. It has two drawbacks:
> 
> 1. If one domain want to deploy ECH in share mode, it have to offer one 
> addition domain
> for the ClientHelloOuter.
> 2. Even the real domain will be encrypted, the shared domain don't. And if 
> the outs
> domain been blocked, all the inner domain will gone.
> 
> So my question is why not just use the DNSSEC method the correct the client 
> who
> has some outed ECH configs?
> 
> If the client-facing can not decrypted the ClientHelloInner, all it needs to 
> do is
> send the new HTTPS DNS records and their RRSIGs. And the client can validate 
> them by
> the DNSSEC methods.
> 
> By this design, there is no need to establish the outer TLS handshake. And no 
> additional
> outer domain any more. The client does not need to know or deploy two domain 
> as well.
> 
> And for almost TLS handshake, their even no need to a SSL certificates. 
> Because we can
> deploy some public key by the DNS, 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 and ECH to cover accesses to other internal names like 
> accounts.example.com  or hr.example.com 
> . I know
> there are a bunch of people who think by far the main value
> of ECH relates to CDNs, and they may be correct, but I tend
> to think the above approaches also have value.

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?

As you say, he could use  the example.com  domain to 
protect the hr.example.com . But how could he protect 
the entire example.com ?

With the current design, he could either register another domain like 
example.net  or deploy his site behind some hoster like 
Cloudflare or others.

The first case will leak example.net , which is equivalent 
to leak example.com  and make ECH useless.
The second case will make the Internet centralized more and more, and make it 
impossible for home-hosted website to deploy ECH.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 name.

> If you're saying that ECH requires an intermediary, that's true. But it's not 
> worse than the status quo. It's in the draft: "Co-located servers with 
> consistent externally visible TLS configurations, including supported 
> versions and cipher suites, form an anonymity set."

The current design needs an intermediary doe not means the ECH have to require 
one.

What ECH really does is offering a mechanism to encrypt some data before the 
TLS handshake successfully.
There is no need to depend another (partial) TLS handshake.

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 deploy ECH.

This is why I think the current design is not well enough.

Some one may argued the IP address can be blocked as well. But change IP 
address is very easy and has no
effect to the customers. But if the domain has been blocked, every thing has 
gone.

If the ECH could encrypt all data of ClientHello, why could us let the outer 
plain text SNI exposed?

Or is there any issue to verify the new ECH config by DNSSEC mechanism?___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 where I live
> (.ie) there are dozens of such hosters who run probably tens
> of thousands of web sites. ISTM making accesses to those
> less easily distinguished from one another brings potential
> benefits.

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?

> I think you're wrong to only consider there being two cases
> of interest. People are fairly inventive in how they use new
> tools like ECH. But time will tell I guess.

I have said there are two cases, but has not stated there are only two cases. 
The current design of ECH
requires an intermediary proxy with dedicated domain name and SSL certificate 
to work. And I think it is huge burden
for indie website. So again, what is your point here?

Thanks.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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, and 
send it to server by an out client hello message.

In order to minimize the risk of leaking private data of ECHConfig, the 
ECHConfig should be rotated periodically. As a result, 
the browser may use the outdated ECHConfig.

In order to "correct" those browser with outed ECHConfig, the server needs to 
reply the latest ECHConfig.

But how could the browser confirm the ECHConfig replied by the server is the 
correct one?

This is why the outer SNI, domain name, and certificated are needed.

In this occasion, the server use the certificate indicated by the outer SNI to 
handshake with the browser, and response
the new ECHConfig with server encrypted extension. By the server encrypted 
extension, the client can verify the ECHConfig
server respond is valid, so the client could update their local cache.

What I try to accomplish is to drop the dependence to the outer SNI/domain name.

But why? Because if small websites do not behind some common intermediary, 
which domain could it offered for the outer SNI?

As Stephen mentioned two cases,

> 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 and ECH to cover accesses to other internal names like 
> accounts.example.com  or hr.example.com 
> .

In the first one, these small sites may deploy be deployed to some small hoster 
or big one like Cloudflare. So the hoster will offer the common "public_name"
for the outer SNI.

In the second, they can chose some some subdomain as the "public_name" like 
example.com  to protect their internal names like 
hr.example.com .

The second case will expose the example.com , which is, in 
my own opinion, as sensitive as the internal one. Because when some website has 
been
blocked, their whole domain has been blocked as well. Use the apex domain to 
protect the inner domain is useless.

The first case works technically, but it is not suit for sites who deployed in 
a simple VPS or even home server.

What I try to accomplish is to let every website could deploy ECH.

And recall why the outer SNI is needed? Only because the browser need to 
confirm the updated ECHConfig offered by the server is valid.

In my opinion, there are different ways to accomplish this feature without the 
outer TLS handshake.

One of them is use DNSSEC. The sever just respond the correct HTTPS RR with its 
responding SIGRR, and the browser could verify them.
However, this way requires the browser to implement DNSSEC verify process, 
which is not an easy task to make consensus.

Another one is publish another public key by DNS to check the signature of the 
updated ECHConfig offered by server. As this key is only used
for ECHConfig updating process, there is no need to rotate it very frequently. 
This idea requires the browser to implement one small additional
signature verification, which is far more simple than the DNSSEC.

By the way, the current design of ECH is good for hosters like Cloudflare. 
Because they already have the intermediary proxy.

Wish I have made me understood.

If I offend some one, I am sorry.

> On Aug 24, 2022, at 09:33, Rob Sayre  wrote:
> 
> The design does not work without what the draft calls an "anonymity set". 
> Maybe you could explain your threat model a bit more?
> 
> For example, if every domain had an IPv6 address, encrypting the SNI wouldn't 
> conceal any information.
> 
> I have no idea what you're trying to accomplish here,
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 servers don't 
> benefit from ECH.

I never say the smaller TLS servers don't benefit from ECH. Every one does.
What I said is those standalone small VPS server, working in share mode, will 
prepare to different domain for inter and outer SNI.

As there is no common proxy, all the domains are bounded to on site. This makes 
protecting the inner domain useless, because
the outer one has a one-to-one responding to the inner one.

The current design works well for occasion using the intermediary proxy. But we 
could make it one step further to support
the occasion without intermediary proxy.

> As others have said: Ultimately, your anonymity set is no larger than the set 
> of names for which you have TLS certificates. What ECH allows you to do is 
> make all traffic to any of those names look the same. All you have to do is 
> issue a certificate for a special name, the "public_name", that you would 
> only use in case of ECH rejection.

This is why we should not depend some common outer SNI. If we want to make all 
traffic look the same, we may fill the outer SNI field with random ECHConfig 
ID, which should not
be treat as some other domain name.

> Yet there are other benefits to ECH that get less attention: Namely, 
> protection of ALPN and other privacy-sensitive extensions that get 
> transmitted in the ClientHello. I think of ECH as a way to render more of the 
> TCP packets unintelligible to an observer. This clearly has a net benefit.
> 
> I don't think this doesn't actually make the traffic to your names any more 
> anonymous. The fact that the public name might share something in common with 
> one of your names (e.g., "public-facing-name.example.com 
> " vs "real-name.example.com 
> ") doesn't really change anything: I can still 
> look up the IP address for "real-name.example.com 
> " with a standard DNS query and learn the 
> exact same information.

So we cannot share the same base domain for both outer SNI and inner. If we 
really want to make ECH works, we have to deploy
website behind some common intermediary proxy, which use it's own common share 
public_name to protect the inner one.

If we do not like the common intermediary proxy, it's hard to make ECH work. 
Because we have to choose a different name for the outer SNI.
As there is no other website sharing this name, the name used in outer SNI is 
almost equal to the inner one, even though the inner one is not exposed.

You mentioned anonymous. The real IP do be exposed by DNS lookup, but this 
issue is beyond the scope of ECH. It should be addressed by something like 
DoH/DoT/DNSSEC.

> ECH was designed for everyone, not just the big players. However, there is 
> only so much we can do in a client-server protocol like TLS. It might make 
> sense for you to start thinking beyond a single server. 

Thanks so much. But the current do require the server choose a "common" 
public_name to update ECHConfig. It is not a issue for the big player, it will 
hurt the indie player.

> 
> Something worth exploring: There is an alternative deployment model for ECH 
> called "Split-Mode", which allows the client-facing server to be 
> organizationally separated from the backend servers. The client-facing server 
> would do ECH decryption, then proxy the rest of the handshake to the 
> appropriate backend. In this setting, the client-facing server would only 
> terminate TLS for the client-facing server. (See the spec for details.)

Actually even "Split-Mode" cannot address my concern. The key problem is the 
indie server without a common proxy have to choose another "unique" domain as 
the public_name.
As this public_name can not be shared with other indie server, this public_name 
is just another id of the protected inner name.

> In theory, a coalition of "small servers" could set themselves up behind a 
> client-facing server, whose only job is to handle ECH. This entity need not 
> be a full-blown reverse proxy.

Why not let these "small servers" handle ECH themselves? What about hosting a 
simple website in a home-hosted server?

Thanks.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/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, then the IP 
> address points directly to the isolated server. A lookup of the IP address in 
> the DNS would provide the name of that server. Even if the server does not 
> registers its address in the "in-addr.arpa", we have to assume that the 
> censors run some kind of web spider and memorize the IP addresses of the 
> servers that they want to censor.
> 
> If you want to deploy servers that evade censorship, they cannot be isolated. 
> They have to join some kid of pool, and the pool has to be big enough and 
> important enough that censors cannot just block the IP address shared by all 
> pool members. And then ECH will work as expected.
> 
You are right. But it seems there is no such a pool.

Google is very common across the world. However, it is totally unreachable 
across the China mainland.

If there are too many sites protected by some common pool like Cloudflare, this 
pool will blocked absolutely.
When the Cloudflare deployed the ESNI initially, some website use Cloudflare to 
accelerate speed can be accessed in China. And then, all request with
the ESNI extension has been blocked.

If we can deploy the ECH without the public_name, all website, whether join a 
pool or not, could deploy ECH. And the censors cannot
easily block one site by its name. What the censors can only do is fetching the 
A/ record periodically and block that IP addresses.

And the server can easy change to the new IP addresses. This will not prevent 
the censors from blocking, but makes it impossible to totally bock a website.

I think we need to try to make the Internet more decentralized.

And recall why the outer public_name is required? It is used to "correct" the 
browsers' outdated ECHConfig. This feature can be accomplished by several
different ways, including DNSSEC or public some signing key by DNS. So why we 
insist to use the outer TLS handshake?___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 jurisdictions. 

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.

> 
>> If we can deploy the ECH without the public_name, all website, whether join 
>> a pool or not, could deploy ECH. And the censors cannot
>> easily block one site by its name. What the censors can only do is fetching 
>> the A/ record periodically and block that IP addresses.
> 
> Sites can do this right now by simply using a common invalid public_name, 
> e.g., "esni.invalid"
>  
>> And the server can easy change to the new IP addresses. 
> 
> Why do you believe this to be the case? It's not clear to me that this is so. 

But why not? Some IP address has been blocked, and choose another one. It is 
simple and natural.

> 
>> And recall why the outer public_name is required? It is used to "correct" 
>> the browsers' outdated ECHConfig. This feature can be accomplished by several
>> different ways, including DNSSEC or public some signing key by DNS. So why 
>> we insist to use the outer TLS handshake?
> 
> It's not clear to me what you have in mind here, so I can't tell whether 
> these are real alternatives

I have try to make my opinion clear as far as I could. If you follow all the 
mail in this thread, I wish you could get my idea.
But if you finished all the thread and still confusing, I am sorry for my 
expressive ability, because I am not a native English speaker.

> The setting in which the outer public_name is useful is the one in which the 
> ECHConfig key is wrong but the ECHConfig public_name is correct, presumably, 
> as you say, because DNS is out of date. How do you think DNSSEC fixes this 
> problem?

Why ECHConfig could be wrong? Because we choose to rotate them frequently.

In contrast, the DNSKEY using in DNSSEC do not need to change as frequent as 
ECHConfig rotated. So when the ECHConfig outed, the DNSKEY does not.

Maybe the DNSKEY do be outed. We can response all the HTTPS/RRSign/DNSKEY 
records from the server side. And the client just fetch other records for
upper lever domain(maybe top level domain) only, which will be changed more 
slowly.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 front-end doing ECH) still has to expose
> their name in the cleartext SNI, even if they publish an
> HTTPS RR with an ECH public key.
> 
> Is that about right? If so, I agree that's a limitation
> of the value one can get from ECH.

Yes, this is the occasion I am concerning.

Maybe it is wired for you to image someone will publish some website
without the help of CDN like Cloudflare.

If you live in China, you will find your website will be slow with the the
help of Cloudflare, because its edge servers are out of China mainland.

> 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 in clear in such a case and things should still
> work fine if the client gets the right ECH public key.

There is no disagreement about other Client Hello Data encrypted by ETH.
It always benefit.

I am wandering if a client could send a bogus SNI. Because the outer SNI
is used to finish another TLS handshake, and the client-facing server also
needs a SSL certificate for the outer SNI. How could the client send a
bogus SNI?

> Perhaps it could be worthwhile exploring that last point a
> bit more than the WG has, with a goal of helping get to the
> point where turning on ECH could be the norm when putting
> up any web server, just as interacting with LE is now?
> 
> I'm not sure that it'd be feasible to depend on DNSSEC in
> such cases to handle mismatched ECH public keys though.

Depending the DNSSEC maybe not a practical idea, because it is too
complicate. But if the DNSSEC has been deployed widely, could we still
need the outer SNI any more?

What we real needs here is something like a trust anchor. We needs the
outer plain text "public_name" just because it is there.

If DNSSEC is not an option, what about publish another ECHConfig signing
key by DNS. And this key will be changed more slowly than ECHConfig.

If the client use some outdated configs, the client-facing server just responds
the latest configs with additional signature. And the client could verify them.

> There's also a problem that if some clients GREASE ECH but
> real uses of ECH don't have the real DNS name as the outer
> ClientHello SNI, (e.g. the name.invalid case), or make use
> of the published ECH config_id, one could easily distinguish
> real uses of ECH vs. GREASE cases which seems a bad outcome
> too.

This is why we should not depend a real domain name in the outer SNI.

We could randomly generate some domain like

c01e7ce0b61c6b1e8f5f3392a306a847.com 


and use it as the config_id. It just looks like a real .com domain, but there
is no need, and will never be registered. It is just a config_id looks like a
domain name.

As it is a fake domain name, we cannot get a valid SSL certificate. But it
does not matter, if we do not depend the outer TLS handshake to "correct"
the client's outdated ECHConfig.

As I mentioned early, we could publish some signature key with ECHConfig,
but the signature key do not need to rotated so frequently like ECHConfig.
Because this signature key only used when the client has some outdated
ECHConfig.

In this occasion, the server signed the new ECHConfigs, and send them to
the client. The client verify them with the signature key published by DNS.

It seems works.

> I could envisage us trying to provide some guidance for such
> a scenario (maybe like; servers: don't rotate your ECH public
> key and do enable ECH trial decryption, clients: use a random
> config_id when not GREASEing if outer SNI == inner SNI). And
> I guess that might help a bit to move the overall ecosystem
> towards ECH being the norm, even if the operator of that
> isolated web server won't get much real benefit from ECH.

Maybe we can define a very simple case. In this case, there is only site on
one IP address, and there is only need one ECHConfig. So the client does not
need to send a config_id and SNI. When the server receive the encrypted
client hello, it use the default ECHConfig to decrypt. And if it failed, it 
respond
the new ECHConfig with some signature, which will be verified by some
additional 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 
generated randomly, for example,

c01e7ce0b61c6b1e8f5f3392a306a847.com 
<http://c01e7ce0b61c6b1e8f5f3392a306a847.com/>

The server operator should not register this domain. The public_name maybe a 
real common share
domain.

The server should store the relation between the public_name and the
signature private key.

When the client try to offering ECHConfig, it must fill the fake public_name 
into
the outer SNI field.

If the client use some outdated ECHConfig to encrypt the inner client hello 
message,
the server must respond all new ECHConfigs signed by the key generated before.

When the client receive the retry_configs, it will be able to use the 
public_key to check
whether these configs are valid.

While the ECHConfig is rotating, the signature key should not be changed 
frequently.

As long as the signature key not changed, the client will have no problem to 
update
their outdated ECHConfig list.

If we lost or leak the signature key, we need publish a new one. We can use 
small TTL
for the signing key. However, the client may have period not access the server. 
This is
same as some one who set a invalid A/ record for some domain.

By this design, we do not 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, Stephen Farrell >> <mailto:stephen.farr...@cs.tcd.ie>> 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 in clear in such a case and things should still
>>> work fine if the client gets the right ECH public key.
>> 
>> There is no disagreement about other Client Hello Data encrypted by ETH.
>> It always benefit.
>> 
>> I am wandering if a client could send a bogus SNI. Because the outer SNI
>> is used to finish another TLS handshake, and the client-facing server also
>> needs a SSL certificate for the outer SNI. How could the client send a
>> bogus SNI?
> 
> This would simply cause the correction mechanism not to work.
> 
>>> Perhaps it could be worthwhile exploring that last point a
>>> bit more than the WG has, with a goal of helping get to the
>>> point where turning on ECH could be the norm when putting
>>> up any web server, just as interacting with LE is now?
>>> 
>>> I'm not sure that it'd be feasible to depend on DNSSEC in
>>> such cases to handle mismatched ECH public keys though.
>> 
>> Depending the DNSSEC maybe not a practical idea, because it is too
>> complicate. But if the DNSSEC has been deployed widely, could we still
>> need the outer SNI any more?
> 
> I think so. You need a mechanism which is tied to the anonymity set and not
> the specific user.
> 
> 
>> What we real needs here is something like a trust anchor. We needs the
>> outer plain text "public_name" just because it is there.
>> 
>> If DNSSEC is not an option, what about publish another ECHConfig signing
>> key by DNS. And this key will be changed more slowly than ECHConfig.
>> 
>> If the client use some outdated configs, the client-facing server just 
>> responds
>> the latest configs with additional signature. And the client could verify 
>> them.
> 
> It's not clear to me that this is better:
> 
> 1. It means that there is only one anonymity set for a given IP because you
> don't know what key to sign with otherwise.
> 
> 2. If you misconfigure the key -- rotation is not the only issue -- then you 
> are
> completely bricked, which is what the current design was designed mostly
> avoid.
> 
> -Ekr
> 
> 
> 
> 
> 
> 
> 
>> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 could publish a public key for all site deployed on it.
> 
> 
>> When the client try to offering ECHConfig, it must fill the fake public_name 
>> into
>> the outer SNI field.
> 
> This proposal seems to break down here for the single server case because
> the attacker just needs to read this value out of the DNS and insert it into 
> its block table.
> And, indeed, if you want to just block ECH entirely, you can largely just 
> block
> connections with unregistered domains in the outer name.

The server name in the outer SNI field is not really a valid domain. It just 
looks like a domain,
and only used as a id for protected domain when the client's ECHConfigs are 
outdated.

> 
> 
>> If the client use some outdated ECHConfig to encrypt the inner client hello 
>> message,
>> the server must respond all new ECHConfigs signed by the key generated 
>> before.
>> 
>> When the client receive the retry_configs, it will be able to use the 
>> public_key to check
>> whether these configs are valid.
>> 
>> While the ECHConfig is rotating, the signature key should not be changed 
>> frequently.
>> 
>> As long as the signature key not changed, the client will have no problem to 
>> update
>> their outdated ECHConfig list.
>> 
>> If we lost or leak the signature key, we need publish a new one. We can use 
>> small TTL
>> for the signing key. However, the client may have period not access the 
>> server. 
> 
> This seems pretty undesirable, no? The nominal advantage of the public_name
> design is that it doesn't create new failure modes: you already have to have 
> valid
> certificates for the public_name.

What I propose is drop the certificates for the public_name. Again, in my 
proposal, the
public_name is just a id but looks like a normal domain name. There is no need 
to register
it and no need to assign some certificate.

>  
>> By this design, we do not need a real outer SNI domain for a real handshake 
>> to make
>> sure the retry_configs is valid.
> 
> I don't love the public_name design, but it's not really clear to me that 
> this is
> better. In the multi-domain case it seems like it makes it easier to determine
> whether ECH is in use, and in the single-domain case, you can just block on
> the random domain, as above.


There actually no random domain here, it just generated by the server. If on 
fake random
domain has been blocked, just generate one. The key point here is that the 
random is just
some id to the inner domain.

The key benefit of this proposal is that the client can verify the retry_config 
without the outer
TLS handshake. As a result, there is no need for a real domain and 
corresponding cert
are needed. And then, we can fill a randomly generated faked domain.

As it is only a fake domain, just looks like a real one, every website, no 
matter deployed
after a proxy, can choose these fake domain freely.

But the draft's design require a real domain with valid certificate.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 is in use.
> 
> The current design is attempting to handle both. It handles the loss of the 
> key by allowing
> the holder of the certificate corresponding to the public_name to correct the 
> ECHConfig
> and handles the latter by framing it as an SNI to a valid name, which 
> (hopefully) the attacker
> is reluctant to block.
> 
> If we ignore consideration (2), then your design effectively comes down to 
> advertising
> a public key (or a hash) along with the ECHConfig and using that public key 
> to sign 
> a new ECHConfig. This seems to have potentially better operational properties 
> than
> the public_name design in ordinary use because you don't need to have a cert 
> for the
> public_name, but worse properties in terms of recovery because you can still 
> lose
> the signing key, whereas there are already processes in place to recover 
> certificates
> for public_name in case you lose all your keys. 

The signing key may be lost. But the certificated may be lost as well. Worse 
more, the
operator may set some wrong A/ record. All of this mistake will make the 
server
inaccessible. The draft's do not have any benefit than the signature one for 
the losing
occasion.

> However, looking at (2) it seems like your design is worse, because the name
> in the SNI is trivially distinguishable from a valid name (the attacker need 
> only look
> it up). It's true that it allows for recovery in situations where there is no 
> existing
> public_name that is not likely to be subject to censorship as part of the 
> anonymity
> set, but it seems like in that case you could just register one, which would 
> have
> slightly better properties in terms of SNI detection and fit better into the 
> general
> design concept, which assumes that you are hiding against that background.

I can't agree with you.

If we do not use the fake domain, we have to use some common shared domain, 
maybe offered by Cloudflare or other cloud service. Only set a small domain 
blacklist
can the censors block all the traffic using ECH, which is more worse than my 
proposal.

This is why I propose drop the common shared domain, and use some random
generated fake domain instead.

The censors could check whether the domain in SNI is existing, by means like
whois lookup. But it is not an easy task, because it needs to intercept all TLS 
handshake
and waiting for the whois lookup result. This method is hard to scale, and even
impossible for national level traffic censorship.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 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 is in use.
>>> 
>>> The current design is attempting to handle both. It handles the loss of the 
>>> key by allowing
>>> the holder of the certificate corresponding to the public_name to correct 
>>> the ECHConfig
>>> and handles the latter by framing it as an SNI to a valid name, which 
>>> (hopefully) the attacker
>>> is reluctant to block.
>>> 
>>> If we ignore consideration (2), then your design effectively comes down to 
>>> advertising
>>> a public key (or a hash) along with the ECHConfig and using that public key 
>>> to sign 
>>> a new ECHConfig. This seems to have potentially better operational 
>>> properties than
>>> the public_name design in ordinary use because you don't need to have a 
>>> cert for the
>>> public_name, but worse properties in terms of recovery because you can 
>>> still lose
>>> the signing key, whereas there are already processes in place to recover 
>>> certificates
>>> for public_name in case you lose all your keys. 
>> 
>> The signing key may be lost. But the certificated may be lost as well. 
> 
> This is not an issue because you can issue a new certificate with
> the same name.

What I want to say here is that, if we lost something, we need time to recover.
We can issue a new certificate with the same name, but it will take some time 
to deploy.

If the provider is not as big as AWS or Cloudflare, they may do not won  PKI. 
Issuing may
take time, as well.

>>> However, looking at (2) it seems like your design is worse, because the name
>>> in the SNI is trivially distinguishable from a valid name (the attacker 
>>> need only look
>>> it up). It's true that it allows for recovery in situations where there is 
>>> no existing
>>> public_name that is not likely to be subject to censorship as part of the 
>>> anonymity
>>> set, but it seems like in that case you could just register one, which 
>>> would have
>>> slightly better properties in terms of SNI detection and fit better into 
>>> the general
>>> design concept, which assumes that you are hiding against that background.
>> 
>> I can't agree with you.
>> 
>> If we do not use the fake domain, we have to use some common shared domain, 
>> maybe offered by Cloudflare or other cloud service. Only set a small domain 
>> blacklist
>> can the censors block all the traffic using ECH, which is more worse than my 
>> proposal.
> 
> I don't think this adequately reflects the threat model.
> 
> For large providers, the attacker already knows their IPs and so can block
> on that basis. What makes ECH viable or non-viable in that case is the
> attacker's level of willingness to block all the co-domains to the target
> domains. The public name doesn't change that.

Actually, the censors has blocked IP address since the birth of the Internet. 
However, blocking
IP addressed is not as efficient as block domain, because IP addresses are for 
machine, and
can be easily changed, while the domain is for human.

We can not address the IP block problem by ECH only. But we could make the 
situation a
little better. If we want to hide the domain, just do it as much as possible.

> 
>> This is why I propose drop the common shared domain, and use some random
>> generated fake domain instead.
>> 
>> The censors could check whether the domain in SNI is existing, by means like
>> whois lookup. But it is not an easy task, because it needs to intercept all 
>> TLS handshake
>> and waiting for the whois lookup result. This method is hard to scale, and 
>> even
>> impossible for national level traffic censorship.
> 
> This is not particularly hard to scale.
> 
> You build a database of every known valid domain (this is not particularly 
> large) and
> when you encounter a new request you either wait for the lookup or simply 
> terminate
> the connection until you have looked it up.

I do not think censors will do it. If they build a domain whitelist for the 
whole Internet, how do they
update their database timely? I think they can only u

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 
> selector, it is possible for the client to connect without sending SNI, and 
> for the server to reply without revealing its own hostname!
> 
> I do not support changes to the ECH specification to pursue this goal.  ECH 
> is designed specifically to avoid any dependency on DNSSEC, and this is 
> clearly the correct choice given the low usage of DNSSEC.

DNSSEC is complicate and it hard to make consensus. I did mention DNSSEC,
because it really can be be used to validate the updated ECHConfig from the 
retry_configs.
And if we reach consensus, we could promote the deployment of DNSSEC, as well.

However, nobody likes DNSSEC. So just forget it. But, making ECH depend DNSSEC 
is never the
key point of of my proposal.

Let's recall the reason why ECH depends non-ECH TLS handshake *sometimes*.

If the server realize the client using some outdated ECHConfigs, the server 
will using the outer client
hello to finish the non-ECH TLS handshake and responds retry_configs with 
ECHEncryptedExtensions.

As we have published ECHConfig using DNS without DNSSEC. Is there anything that 
stop us from
publish another signing key? If we could, the server using the outer SNI to 
find the private key and
sign the retry_configs, and send them in plain TCP link, and the client can 
verify them.

By this method, ECH does not require a non-ECH TLS handshake any more. As a 
result, there is no
need to depend another real (common) domain name for the outer SNI, and there 
is need to assign
certificate for it, as well.  And the value in the outer SNI is just some ID 
and just looks like a domain.

This method has several benefits:

- It is simpler, and clear, it does not depend TLS any more, only depend DNS
- It is indie website friendly. There is no need to register/or share an outer 
domain, no need to assign certificate
- It is hard to block. Because we can always change the fake domain in the out 
SNI.

My ambition of a PKI-free Internet is not a propose of ECH, instead, it is a 
result.

PS:

If the DNSSEC is widely used, I do not think ECH will insist on using the 
non-ECH TLS method to correct
the client's configs. But it is not.

So we re-invent something like DNSSEC, but far more simpler. But if we can, I 
still propose ECH to
reserve some mechanism to migrate to DNSSEC or others in the future.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 operator, e.g.
>> ‘operator-ech.com ’. In that case, the number of 
>> packets with the fixed
>> outer SNI is sufficiently extraordinary as to either or both:
>>  (a) visibly identify the operator, in which case the trade-off for
>> client privacy is operator exposure; and
> 
> This is incorrect: the operator is already identified unambiguously by the 
> destination IP address, so nothing new is "exposed".
> 
>>  (b) make it trivially easy for ECH to be blocked, thereby severing
>> many clients from the operator, and the Internet entirely if all
>> operators deploy.
> 
> Per the above, I do not believe ECH has any effect on this.  The hypothetical 
> "blocker" here can easily block all access to a given operator whether or not 
> ECH is in use.

I think it really does.

Without ECH, the blocker could only block some sites indicated by SNI. But with 
ECH,
the blocker can no longer distinguish the "good" site or "bad" site. They have 
no choice but to block the entire
operator if two much "bad" content serving by one operator.

> 
>> This is an ‘anti-goal’.
>> 
>> Alternatively, the operator generates a random outer-SNI for each DNS
>> query
>  
> This would not have any effect on the ability of the hypothetical "blocker" 
> to block all access to any operator that it knows is using ECH, so there's no 
> reason to do this.  It would also break the ECH mismatch fallback mechanism, 
> which requires that the operator hold a valid certificate for the outer SNI.

It depends.

If we use a real random fake domain like d0bb72000439acb2.com without any 
A/ record, 
the blocker may detect the ECH by sending a simple DNS query.

But what if we randomly choose a real domain from the list of all .com/.net 
with A/ record,
the blocker can not distinguish  ECH any more.

Besides, even one outer-SNI is blocked, the operator could choose another one 
easily and quickly.
Actually, the operator should rotate the outer-SNI as they rotating ECHConfig.

The real problem here is that the current design of ECH mismatch fallback 
mechanism requires
the operator hod a valid certificate for outer SNI. And it prevents the 
operator randomly choose
a real domain, and they have to use a fix domain, which makes the blocking very 
easily.

I have proposed two solutions, both don't require a valid certificate as trust 
anchor.

One solution is depending the DNSSEC. When the client-facing server need to 
correct the client,
just response the new HTTPS records with DNS Signing Key, and the the client 
need to verify the
new records by DNSSEC.

In my opinion, this is the most graceful design, and it makes the DNSSEC as the 
only trust anchor.

However, maybe it is hard to promote the deployment of DNSSEC verification in 
the client side.

So another solution is that we could expose another long-lived signing key as 
trust anchor in ECHConfig,
which will not be rotated with the ECHConfig. Every time the server needs to 
correct the client, just send
the retry_configs with signature.

I think this is just a transitional solution, because we will reinvent 
something DNSSEC has invented.

All in all, neither solution depends a TLS handshake. It seems a litter weird a 
protection to SNI need
another SNI without protection.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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-ech.com"). However, for someone who just owns a 
>> single domain (e.g. "hub.com"), what would the "suggested value" be?
>> 
>> Section 6.1.7 implies it should NOT be an IPv4 address. If I do not wish to 
>> leak the real domain, is it "acceptable" to use something like 
>> "fakedomain.com"?
> The server needs to be able to answer a TLS connection for the ECH public 
> name or you risk an outage if the ECHConfigs get out of sync as then clients 
> will get a TLS error page if they can't get through to the public name.

I think the public name is needed, but should not be required!

We do risk an outage if the ECHConfigs get out of sync. However, it's how the 
DNS works. Image we setup a
wrong A/ record accidentally, we have no choice but to wait this wrong 
record expires. It's an outage.

For ECH, we need to rotate it periodically, so we don't want to the risk of 
outage. So ECH requires a real
public name, which will be used to transfer the latest ECHConfigs when the 
client get the outdated conf.

For platform like Cloudflare, this feature is critical, because they cannot 
afford the outage of their customers.
But for indie web services/sites, it is not so big problem. Because this 
mechanism will introduce another huge
risk!

If ECH requires the public name, then every web site need to use to domain 
name, one for their brand, and the
other for public name, both of which should be valid domain. If the use service 
from providers like Cloudfalre,
they can only need one domain name, but still depends the providers public 
domain name.

The public name is seldom used, but observed by the sensor, which makes it easy 
to block web site using ECH.

So we should consider to make the public optional. If the server do not afford 
any outage causing by ECHConfig sync, they could setup the public name, and use 
it to sync the latest config, but they should take the risk of being
blocked by the censor. If the server do not afford the risk of being blocked, 
they could just ignore the public name,
and public the ECHConfigs using some pseudo-domain, which can be changed 
freely, but they should take the
risk of outage caused by ECHConfigs out-sync.

All in all, please make the public domain name optional in the specification.

>> 
>> If the public_name leaks domain in anyway, I think it would be quite 
>> unfortunate, at least for bypassing DPI-blocks. From what I understand, the 
>> purpose of public_name is only if the server doesn't support ECH, but if a 
>> client retrieved an ECHConfig, why shouldn't the client just skip this 
>> field? I fear it will become a situation like the initial SNI extension - 
>> even when websites do not need it, browsers' TLS stacks send it anyway, 
>> causing leakage.
>> 
>> For instance, in India, a popular website, let's call it "hub.com", is 
>> blocked via SNI. However, the website itself does NOT rely on SNI, It is 
>> possible to open a pure TLS connection to it via IP, it serves the TLS cert 
>> for "hub.com" so the handshake can be completed, and then the website will 
>> load as normal. I verified this by manually using "openssl s_client", 
>> WITHOUT SNI. But since Firefox/Chrome will always send SNI, the ISPs can 
>> block it.
> 
> If the server can answer with the correct certificate without SNI, then it 
> must be the only site hosted at that IP. This means that the ISP can also 
> just block the IP without any collateral damage. The same thing is true if 
> ECH connections didn't expose an SNI at all, they'd stick out and could be 
> blocked for that reason.

We can change IP freely, but it is hard, if not impossible, to change domain 
name.

For indie web server, they can buy two domains, one for their brand, and the 
other for ECH. If the public name has
been blocked, they have to buy another one. But if we allow the usage of 
pseudo-domain, this problem will disappear.

> 
> I would describe ECH primarily as a technology for improving privacy. 
> Unfortunately, I don't think it's any kind of silver bullet for censorship 
> resistance.

Improving privacy imply censorship resistance. Although censorship resistance 
is not the goal, we should not
deliberately design *required* features which will make the censorship easy.

BTW, if we public ECHConfig using a domain name which we do not own SSL 
certificate, it does not make thing worse. Because when the client needs to 
re-sync the ECHConfig, the SSL handshake will fail due to the invalid 
certificate. However, I prefer to make this behavior clear in the RFC.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 comments restricted strictly to members of the working group? If so, 
> please ignore this E-Mail.
> 
> I'd previously tried to raise an issue regarding requirements of a 
> public_name in the ECHConfig in the mailing list [0], and when I didn't get 
> much response there, even on Github [1], where I was further met by silence. 
> I assumed this meant since I am not in the working group I am not allowed to 
> participate in discussions, but seeing the "Last Call" I thought I'd try one 
> last time.
> 
> My concern relies around the fact that by requiring a public_name in the 
> ECHConfig, and clients "SHOULD" pass it, means we are losing basically all 
> the benefit we initially had with ESNI, since now some part is leaked anyway. 
> This was not an issue in original ESNI. Although the draft allows for a 
> client to not use this value, and/or for a server to not validate it 
> ("SHOULD" rather than "MUST"), in practice all of the most popular clients 
> (i.e. browsers) will probably end up using / sending it. We saw this for SNI, 
> where even websites which don't need it (e.g. a very popular adult website), 
> browsers will still send it, and this becomes a vector for censorship / 
> blocking.
> 
> If this requirement is unlikely to change, my question then becomes - it is  
> "acceptable", as a website operator who does not wish to leak the domain name 
> in the ECHOuter's plaintext SNI, to specify the "public_name" in the 
> ECHConfig as something random (e.g. "example.com"), acknowledging the fact 
> that as a server operator, I will disregard any value the client passes for 
> the SNI in the ClientHello anyway? Or is there another recommended approach 
> if I do not want the actual domain to be leaked on the wire. This is coming 
> as an individual operator, with no CDNs to hide behind (e.g. 
> `cloudflare-ech.com`).
> 
> Lastly, I also struggle to understand the value of this field. From reading 
> the RFC, it seems it is mostly only applicable if the server rejects ECH. I 
> would think this happens if the server does not support ECH, and therefore 
> should not have had an ECHConfig published anyway- or the client is unable to 
> satsify the server's ECH requirements. In both cases, I would think it is on 
> the client to fallback an purposely initiate a non-ECH TLS handshake, rather 
> than "downgrade" the connection. Forgive me if I am missing something 
> obvious, but as someone who used ESNI successfully back when it was in draft 
> status, and was happy with no SNI being leaked, I am unhappy that it has 
> returned.
> 
> Regards,
> 
> Raghu Saxena
> 
> [0] https://mailarchive.ietf.org/arch/msg/tls/HUG1CU0Q4PorZ7fD0yafVfj7VUY/
> 
> [1] 
> https://github.com/tlswg/draft-ietf-tls-esni/issues/572#issuecomment-1780859252
> 
> On 3/12/24 06:00, Joseph Salowey wrote:
>> This is the working group last call for TLS Encrypted Client Hello [1].  
>> Please indicate if you think the draft is ready to progress to the IESG and 
>> send any comments to the list by 31 March 2024.  The comments sent by Watson 
>> Ladd to the list [2] on 17 February 2024 will be considered last call 
>> comments.
>> 
>> Thanks,
>> 
>> Joe, Deirdre, and Sean
>> 
>> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
>> [2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/
>> 
>> 
>> 
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 
> interoperability, which means that whatever it tells the client to do must be 
> compatible with what it tells servers to do. Presently, the specification 
> tells clients to put whatever is in ECHConfig.public_name in 
> ClientHelloOuter.sni (S 6.1) and tells the server that it may check and 
> reject it otherwise (S 7.1). We extensively debated whether to forbid 
> checking in PR #575 and concluded that we should do so. The primary arguments 
> were the same ones being offered here balanced against the ecosystem benefits 
> of encouraging the client to correctly populate ClientHelloOuter.sni to 
> enable the  recovery mechanism. The WG could of course revisit that decision.
> 
> With that said, even if the specification explicitly allowed clients to 
> omit/falsify ClientHelloOuter.sni, I don't believe that generic clients 
> (e.g., the kind of Web browsers that most people use) would choose to do so. 
> The reason is that, as noted above, it would break the recovery mechanism, 
> and that's more important than the modest increment in concealing the 
> public_name of servers on non-shared IPs. One might imagine that some special 
> purpose clients would choose to do so, but that's not the case I'm talking 
> about.

The public_name is required, not naturally because it will be used by ECHConfig 
recovery, but because if the client
omit it or fill some none domain value like ensi.test, the observer could 
identify traffic equipped with ECH or normal
TLS traffic.

However, the problem we are discussing here is if you want to deploy ECH you 
have to own a dedicated domain name
and get a valid SSL certificate for it so that you can resend the latest 
ECHConfig to the client that use the outed configuration.
The process is only chosen by the draft. But it is not the only way to do it.

Here are some immature ideas.

One method is to public another public_key for signing along side with 
ECHConfig, let's call it Recovery Signing Key. 
This key will only be used to sign the latest ECHConfig during the recovery 
process. So there is not need to rotate it
as frequently as the ECHConfig itself. The client should use DNS to lookup the 
ECHConfig and the Recovery Signing Key.
If the ECHConfig is outdated, the server will respond the latest ECHConfig with 
signature signed the Recovery Signing Key.
By the way, the client could verify whether the recovered ECHConfig is valid.

Here is another immature ideas.

If the WG insist to use the outer TLS negotiation to recovery ECHConfig, it may 
works to use the self-signed certificate.
In order to let client trust the self-signed certificate only in the process of 
ECHConfig recovery, we can publish the hash of
the self-signed certificate along side the ECHConfig in the HTTPS RR. If the 
server need to recover the latest ECHConfig,
it can finish the outer TLS negotiation with its self-signed certificate. As 
the client already knows the server's self-signed
certificate by the DNS lookup, it can trust it once int this negotiation 
process and get the latest ECHConfig.

By this ways, the public_name in ECHConfig.public_name could not have to be a 
real domain, and there is no need to own it
or buy a SSL certificate for it. It is only an ID of ECHConfig, and just looks 
like a domain. And we can rotate it and the ECHConfig
as soon as need. 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[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 random embed with the accept_confirmation.

If you want to deploy ECH, you have to upgrade both the client-facing
server and the backend server. However, it is not an easy task to upgrade
all the backend server in one day. So I am wondering if it is possible
to adjust the design to allow the deployment without altering the
backend server.

Suppose we use the following topology:

browser <-> ECH-aware Client-facing server <--> normal TLS backend 
server

For any TLS backend server, for example, https://example.com,

We only upgrade the browser and the client-facing server. The browser
fetch the ECH config from DNS, and encrypt the ClientHello according
the current draft design. The client-facing decrypt the ClientHelloInner and
use it as the normal ClientHello to do the TLS handshake to the normal TLS
backend server without any ECH extension.

Upon the normal TLS backend server receive the decrypted ClientHello, it 
response
the normal ServerHello to the client-facing server.

After receiving the ServerHello from the backend server, the client-facing 
server
need to response the accept_confirmation to the browser. This is the design 
changes
I propose to change. Because the current draft requires the backed server 
generate
the accept_confirmation bytes and embed it into the random of ServerHello, which
can not be changed by the client-facing server.

In order to support ECH for normal existing TLS server, we may let the 
client-facing
response the accept_confirmation on behalf of the backend server, which means we
can not use the random field of ServerHello to store the accept_confirmation, 
because
changing it will abort the TLS handshake.

So is it possible to transfer the accept_confirmation in some plain text 
extensions
like Key Share, or other dedicated extension?

If it is possible, we can deploy ECH by only upgrading the browser and 
client-facing
server without require change all the existing backend server.

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 
site.
Even though the current draft of ECH works to protect the ClientHello, it can 
only
protect the sites that deployed the ECH.

If we can adjust the current design and let the client-facing generate and 
response
the accept_confirmation signal, we can make ECH everywhere without upgrading 
any of
current TLS backend server. Which means the client-facing can work as an 
encrypted
TLS SNI Proxy.

Please consider my proposal and give your comments

Thanks. 


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[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 site.
>> Even though the current draft of ECH works to protect the ClientHello, it 
>> can only
>> protect the sites that deployed the ECH.
>> 
>> If we can adjust the current design and let the client-facing generate and 
>> response
>> the accept_confirmation signal, we can make ECH everywhere without upgrading 
>> any of
>> current TLS backend server. Which means the client-facing can work as an 
>> encrypted
>> TLS SNI Proxy.
> 
> I'm trying to understand what exactly your use-case here is. Wouldn't a naive 
> HTTPS Proxy w/ CONNECT be sufficient?
> 
> E.g. if we have the proxy domain `https://myproxy.com` , and the website we 
> want to connect to is `https://supersecret.com`, then assuming a classic 
> HTTPS Proxy running on `myproxy.com`, the Client would make a TLS handshake 
> to `myproxy.com` and reveal the Proxy SNI, however once the TLS handshake 
> with the proxy is complete, the `CONNECT` to `supersecret.com` will be inside 
> the TLS tunnel, so it will be private.
> 
> I think this would be sufficient, since even in the split-example with ECH 
> you mention, the `public_name` of the first client-facing server will be 
> visible anyway.


Yes, the native HTTPS Proxy with CONNECT has similar feature. However, the ECH 
based SNI Proxy
still has some benefits.

First, we setup one DNS over HTTPS server, and let the user agent use the DoH 
server.

Second, we setup the client-facing ECH server as SNI proxy.

Third, in our DoH server, we "hijack" the A/ record for the original server 
and point it to the ECH client-facing server,
and add the fake HTTPS/SVCB record to indicate the user agent that the original 
"support" ECH.

Finally, when the user agent try to negotiate the TLS session to the backend 
server, it looks up both the A/ and HTTPS
records from the DoH server. Then the user agent will connect to our 
client-facing server (work as SNI proxy).
Since the user agent also derives our fake HTTPS record with ECH config, the 
user agent will try to connect the client-facing
server using this config with a proper generate config_id and public_name. We 
can dynamically generate this ECHConfig
and associate the real original domain name to some dynamic public_name.

When the client-facing server accept the ECH handshake, it can decrypt the real 
domain name of the original server, and then
it will works as a normal SNI-proxy and try to connect to the backend server 
using the ClientHelloInner.

As the server has no idea of this ECH-based proxy, it will respond a normal 
ServerHello with normal random field. Once our
ECH client-facing the ServerHello, it has to respond the accept_confirmation on 
behalf of the original. However, the current
draft requires using the last 8 bytes of random in ServerHello to indicate the 
accept_confirmation, which can not be modified
by the client-facing server, and this design makes it impossible to implement 
this ECH-based SNI proxy.

If we can implement ECH-based SNI proxy, we can "deploy" ECH to all TLS server 
without upgrading the HTTPS server
software of the backend server. All we need is to do some kind of "DNS 
hijacking". This hijacking will result in no security problem
because the client-facing server will only see the ClientHelloInner and can not 
monitor the real plain traffic under TLS.

If we can implement ECH-based SNI proxy, the user agent setup will be 
simplified as much as possible. All it needs to do is
setup a proper DoH server, and let all other configuration in the remote side 
of ECH client-facing server and DoH server.


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[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. configure a "custom" DoH server to do 
> the hijacking), and configure a remote server a bit (setup HTTPS proxy, vs. 
> setup the ECH-based SNI proxy).
> 
> In fact, I'd argue looking at the common HTTP User-Agents today, the support 
> for configuring an HTTPS proxy is already very widely supported, so it would 
> have a better reach immediately.
> 
> I'd like to hear if you have any ECH specific benefits of this proposed proxy 
> design, maybe I'm missing something.

It could simplify the configuration.

Suppose we need to proxy traffic according to one list.

If we use the classical CONNECT methods, we need install some web extension 
like Proxy Switcher
in chrome. Then we need to setup the proxy server's host/port and auth data. 
Then we need setup
the proxy rule list. It's too complicate to use for normal people who are not 
familiar with computer or network.

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 maintained on the server 
side, and the server works
as both DoH and ECH-based SNI proxy.

Once the DoH has been set, the browser will query A//ECH records for one 
domain. The server
will response "fake" records according to the proxy list. The public_name of 
the fake ECHConfig will
be used to associate to the target domain and for auth.

But the current draft requires the backed server to be ECH-aware, which makes 
it impossible to
implement something like ECH-based SNI proxy.

All in all, the ECH-based SNI proxy is not the biggest problem. The biggest 
problem, in my opinion, is that
the backed need to be upgraded to deploy ECH.

With the help like Cloudflare, we could deploy HTTPS/HTTP2/HTTP3 without change 
the backend server.
As a result, the deployment rate has been very quick.

Big thanks to Chris, I have read through the discussion on 
https://github.com/tlswg/draft-ietf-tls-esni/issues/274
The reason for the change of backend server is to respond the accept 
confirmation to simplify the client
side implementation without stick out the ECH traffic.

The cost of simplifying is to upgrade the server. It is impossible to deploy 
ECH without changing the client side, and
the whole design of ECH is very complicated. If we want to deploy ECH, why we 
prefer a more simplified client with a
must be modified server side? As the ECH its self is already, would it be more 
easy to deploy ECH if we choose the
more complicated client solution without changing backend server? I don't know.

Just FYI~

Regards.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[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 the leak of SNI.

The only obstacle of my envisioned ECH-based SNI proxy is that the server side 
accept confirmation
must be placed in the SH.random field, which will be further used to generate 
the master secret.
As a result, the middle proxy node can't respond this confirmation on  behalf 
of the backed server.

The ECH-based SNI proxy is just a possible by-product of ECH. It's not a big 
problem if we
can not implement such proxy. However, my real concern is the deployment rate 
of the current draft.

The current design requires both the client and backend server to be modified 
to be ECH-aware.

For solo web site, as the administrator has the full control and there is no 
inter node, they may
upgrade quickly.

But there are far too many sites using some proxy service, for example, 
Cloudflare, AWS ALB, etc.
For stability consideration, service provider like AWS does not upgrade their 
infrastructure very quickly.
If web site use AWS LB as their TLS terminal edge server, it may cost too long 
time to deploy ECH.

Apart from technical issues, deploy ECH does almost no benefit to this 
business. I doubt if they are
interested in ECH.

On the other hand, let's recall the origin of the server side confirmation.

According to the original discussion 
https://github.com/tlswg/draft-ietf-tls-esni/issues/274

> In the current spec, the server provides no indication of whether the inner 
> or outer ClientHello (CH) was used. This means the client must do trial 
> decryption to make this determination, which creates complexity and 
> potentially raises security concerns. 

It seems that the main consideration of the accept_confirmation is just to 
simplify the client side logic.
This simplification may cause a slow deployment of ECH. I am wondering if it 
really make sense.

The ECH is very complicated itself. The purpose of such an complicated protocol 
is to
protect the privacy of the Internet, so we should in favor of the easy 
deployment instead of
of the simplified implementation. If the simplification is the first 
consideration, the ECH should not
be considered at all.

> On Sep 11, 2024, at 15:16, Raghu Saxena  wrote:
> 
> By the way, you may be interested in this project: 
> https://github.com/quininer/nosni-proxy , which has a similar idea, but 
> instead to completely strip SNI, and relying on TLS interception. One could 
> think of an alternative, basically like the Cloudflare MiTM model you 
> mentioned, except self-hosted with certificates manually trusted. Then the 
> DoH server would return the IP of this server, which would allow an ECH-TLS 
> connection to it, but then performs a separate TLS handshake with the real 
> origin server.
> 
> It is not as elegant as what you mentioned since now there is a need to 
> manually trust certificates, but could still be an approach.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[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 Sep 11, 2024, at 17:35, A A  wrote:
> 
> 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.
> 

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[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 the deployment of ETH, in the cost of the 
complication
of client side.

The client side must be modified to deploy the ETH. However, the server-side 
modifications
is optional. Requiring modify the server-side will do harm for the deployment 
rate of ETH.

Just FYI~

> On Sep 17, 2024, at 13:05, Joseph Salowey  wrote:
> 
> ECH has been revised based on working group input and is ready to go to the 
> IESG.  You can see the diff between the latest (-22) and the one published 
> previous to the last IETF (-18) here:  
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-esni-18&url2=draft-ietf-tls-esni-22&difftype=--html.
> 
> There has been some discussion of ECH proxy on the list, but something 
> similar has already been discussed as pointed out in the thread and there 
> does not appear to be consensus to make this sort of change in this version.  
> 
> I plan to submit this early next week.  
> 
> Cheers,
> 
> Joe
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org