Hi, Eric,
Thank your for reviewing.
> On Aug 24, 2022, at 22:25, Eric Rescorla <e...@rtfm.com> 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
