On Sat, Sep 12, 2020 at 11:41 AM Christopher Patton <cpatton= 40cloudflare....@dmarc.ietf.org> wrote:
> I agree with Christian. The reason to use the ServerHello.random trick is > to make real ECH connections look like connections in which the client > sends a dummy ECH extension to a non-ECH server. In particular, this design > pattern is needed for property (1). > > Property (2) is achievable if the ECH configuration is secret, i.e., if > the server is deployed in such a way that it does not reveal it speaks ECH > unless the client offers the right configuration. In particular, the server > need not publish the ECH config, either via DNS or the ECH retry logic. > This won't be feasible for the vast majority of deployments. > I think this is the key point: 1. If the ECH Config is public, it's trivial to tell whether the client is trying to do ECH 2. If the ECH Config is public, it's also trivial to tell whether the server does ECH 3. It's reasonable to expect that if the client is trying to do ECH and the server does ECH, you will get ECH. That limits the degree to which it is useful to conceal whether a given connection is using ECH. From my perspective, the purpose of this piece of the design is to discourage middleboxes from blindly suppressing ECH, but at the point where you are willing to actively intercept each connection, the ECH Config attack seems much easier. Note that if the deployment environment changes so that it would be desirable to fold the handshake key into this value, this can be done later with an ECH Config extension and will not need to appear on the wire. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
