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] ECH not protect SNI

[Viktor Dukhovni]

On Thu, Aug 25, 2022 at 05:12:43PM -0400, Ben Schwartz wrote:

> > Here is my another undisclosed ambition, a PSI free Internet.
> 
> 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!

Well, even with DANE the client needs to elicit the correct server
certificate, by sending the matching SNI.  It is the certificate
that can (in some application protocols) omit the servername, but
not the TLS layer.  In the case of web browsers even that is not
the case as noted by Richard Barnes:

https://datatracker.ietf.org/doc/html/draft-barnes-dane-uks-00

If the client knows in advance that the server has the same underlying
EE key for all its certificates, then sure it could omit SNI and
validate the default certificate (which has the same key promised
in the _port._tcp DANE-EE TLSA record for the desired domain).

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

This is now ~5% of registered domains, and growing.  DNSSEC would of
course grow faster if we didn't stay so reluctant to put it to use.

That said, FWIW, I also don't presently see a need to change ECH.

-- 
Viktor.

___
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 >> > 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 update the database 
periodically, which
will make all new registered domains not work for a while.

> Moreover, as I mentioned earlier, the attacker can simply record the IP 
> addresses
> of the offending servers and block those. I have not yet heard you provide a
> a satisfactory response to that other than that the server can change IPs, but
> as I mentioned, this is not easy, especially for IPv4, because the old address
> is now contaminated for some time, so it's not useful for others.

They can always do such block, whether  or not there is ECH.

And let me make another summary again.

The key difference of my 

Re: [TLS] ECH not protect SNI

[Eric Rescorla]

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



> Worse more, the
> operator may set some wrong A/ record.
>

Yes, but there are already mechanisms to address this.


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

I'll defer further discussion on this topic to those who work more closely
with server systems such as David Benjamin or Chris Wood.



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


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.

Moreover, as I mentioned earlier, the attacker can simply record the IP
addresses
of the offending servers and block those. I have not yet heard you provide a
a satisfactory response to that other than that the server can change IPs,
but
as I mentioned, this is not easy, especially for IPv4, because the old
address
is now contaminated for some time, so it's not useful for others.

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

Re: [TLS] ECH not protect SNI

[Christian Huitema]

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 
"c01e7ce0b61c6b1e8f5f3392a306a847.com" can be trivially defeated by 
censors. They can detect that the DNS name is invalid, and then add a 
configuration rule to "block invalid domain names".


Taoshu, the problem that you are trying to solve is really hard, see RFC 
8744. Most of the practical solutions are in the "cat and mice" category 
-- the mice invent a new trick, and escape the cat for a while until the 
cat gets smarter, and then the mice have to invent something else. 
Putting a fake domain name in the SNI is one such trick: it will work 
for a while, and then it won't. It is probably not a good idea for the 
mice to try publish their new trick as an RFC -- the cat would just get 
smarter sooner.


-- Christian Huitema


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

Re: [TLS] ECH not protect SNI

[Stephen Farrell]

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 really can't see that involving "fake" names,
which come with all sorts of problems. (See the
recent dnsop discussion related to .alt for some
of the reasons why;-)

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
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

[Eric Rescorla]

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
> across one anonymity set.
>

Well, they have to be or it doesn't work.


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

Well it's always sent by the client, whether outdated or not, right?

So, the attacker can just use it for filtering. All it has to do is look to
see if
it's a valid registered domain, and if not, drop the connection.


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

Well, the assumption of the public_name design is that it's *already*
registered.



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

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.

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.


-Ekr
___
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

[Eric Rescorla]

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.
>
> The public_name should be a valid, but fake, domain name, which can be
> generated randomly, for example,
>
> 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.
>

Are these keys and names shared between the domains in the anonymity set?


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.


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.



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

-Ekr




>
> On Aug 24, 2022, at 20:50, Eric Rescorla  wrote:
>
>
>
> 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 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
>
>
>

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 


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

[Eric Rescorla]

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

Re: [TLS] ECH not protect SNI

[Eric Rescorla]

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

I don't think that this makes it a requirement. The requirement is that
your IP be part of an anonymity set.

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

Can you please describe the precise deployment configuration in which you
think this works? If, for instance, you are deploying your own iron, you got
your IP addresses from somewhere and you can't just trivially get others.



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

I'm asking you to describe a precise technical mechanism.

For instance, above you say:
"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."

But this doesn't work, because in order to send the right RR, the server
needs to know the
SNI! The reason that the public_name system works is that all the domains
in the
anonymity set share a public name and an ECH key, so the public name can
authenticate the key.

So what I'm asking you to do is work through your proposal in some detail
so that one
can evaluate whether it works or not.


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

More likely you misconfigure something or you lose your key.


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

I don't understand what you are saying. Perhaps try drawing a ladder
diagram.

-Ekr
___
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

[Stephen Farrell]

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

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.

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.

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.

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.

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
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

[Eric Rescorla]

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

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.

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.

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

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?

-Ekr
___
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

[Christian Huitema]

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


ECH can encrypt the ALPN and other parameters. The "QUIC Protected 
Initials" proposal 
(https://datatracker.ietf.org/doc/draft-duke-quic-protected-initial) 
protects the initial QUIC handshake against interference by third 
parties, and depends on ECH. So, even for an isolated server, ECH has value.



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.


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.


-- Christian Huitema
___
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

[Christopher Patton]

 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't think it's fair to say that smaller TLS servers
don't benefit from ECH.

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.

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.



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

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.



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

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.

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

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.

Chris P.
___
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

[Stephen Farrell]

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


"Deserve" seems like an odd term to use. If a web site
operator wants to benefit from ECH, then they need to be
part of a set of web sites where it's hard to distinguish
which is being accessed based on the TLS traffic.

Perhaps you disagree with some of the content of RFC8744
rather than the ECH mechanism?


So what is you point
here?


I think I made my point, perhaps badly, but nonetheless
it was made as well as it was:-) I don't think it'd help
either of us to only re-iterate.




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. 


I'm glad we agree there are a bunch of different ways in
which ECH could be used. I read your earlier mail as you
discounting anything other than the two cases you mentioned.
Sorry if that was wrong.


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. 


"Huge burden" seems entirely wrong based on my experience.
It's very easy to setup a web site with TLS these days in
many different ways.

Cheers,
S.


So again, what is your point
here?

Thanks.



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH not protect SNI

[Christopher Patton]

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 inadvertently leak important information in the handshake that
we would be better off encrypting.

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

Re: [TLS] ECH not protect SNI

[Rob Sayre]

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 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,
Rob
___
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

[Stephen Farrell]

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


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.


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.

Cheers,
S.



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH not protect SNI

[Rob Sayre]

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 deploy ECH.
>
> This is why I think the current design is not well enough.
>

Hi,

I agree that's basically the standoff here, but it's inherent to the design
of the protocol.

thanks,
Rob
___
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

[Rob Sayre]

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

thanks,
Rob
___
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

[Rob Sayre]

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

Maybe the other important point here is that ECH is not worse in any use
case. If anyone has evidence to the contrary, I'd like to read about it.

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

Re: [TLS] ECH not protect SNI

[Stephen Farrell]

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

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.

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
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