Hi, Ben
> On Aug 26, 2022, at 05:12, Ben Schwartz <bemasc=40google....@dmarc.ietf.org>
> 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
