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

[Rob Sayre]

On Wed, Aug 24, 2022 at 7:52 AM Ashley Kopman 
wrote:

> I would greatly appreciate any feedback on this draft as well as any
> feedback on the next steps for working with the TLS working group.
>

Maybe the best thing to remember is that we can only offer suggestions. You
don't need approval, but everyone is here to make your draft better, if we
can.* Ultimately, internet engineers usually don't have useful things to
say about aviation, so it's best to think of it as a supportive environment
where the authors ultimately make the decision.

thanks,
Rob

* https://courses.cs.duke.edu/common/compsci092/papers/govern/consensus.pdf
___
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 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] New Version for draft-segers-tls-cert-validation-ext

[Ashley Kopman]

We received feedback from the aviation community that there is a need for this 
extension to be included in the CertificateRequest message for the case where 
the server rather than the client is the constrained resource (the aircraft in 
our use case). I have updated the draft to reflect the addition of the 
CertificateRequest extension and submitted a new draft 04. I would greatly 
appreciate any feedback on this draft as well as any feedback on the next steps 
for working with the TLS working group.

 https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-04.html 


Thank you,

Ashley Kopman


> On Aug 4, 2022, at 1:51 PM, Ashley Kopman  wrote:
> 
> Hi,
> 
> We presented this work at IETF 114. Thank you to everyone who provided 
> feedback. 
> 
> I have removed the extensibility to future path validation types and limited 
> the scope of this extension to just SCVP. I have also added discussion on how 
> the server should handle it if other path validation extensions are added in 
> the future (at the end of Section 2). Version 03 is available for review 
> https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-03.html 
> 
> 
> I am new to the IETF, so I apologize in advance if this is not the correct 
> process, but I believe the next step is to ask that this draft be considered 
> for adoption by the TLS Working Group.
> 
> Thank you,
> 
> Ashley Kopman

___
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