Re: [TLS] TLS ECH, how much can the hint stick out?

[Ben Schwartz <[e-mail]>]

Karthik: That approach works, but unless the ECH echo is universally
deployed, it still reveals to a passive observer whether the server is
ECH-enabled.  That means, at least for several years, exchanges that are
using ECH will likely "stick out" to a passive observer.  This is something
we are trying to avoid.

On Fri, Sep 11, 2020 at 10:00 AM Karthik Bhargavan <
[e-mail]> wrote:

> Perhaps I am misunderstanding the design constraints and the following idea
> has been thought of and discarded, but could we not remove trial decryption
> and replace it with a trial HMAC, at the cost of adding yet more crypto.
>
> - The outer ClientHello contains an ECH extension as usual.
> - The ServerHello ALWAYS echoes the ECH extension, whether it chooses the
> inner or outer ClientHello.
> - This ServerHello extension contains an HMAC  of (say) an empty
> bytestring (or the current transcript)
>    with a key derived from the chosen handshake secret (i.e. either using
> the innerCH or outerCH),
> - On receiving the ServerHello, the client generates both possible
> handshake secrets and both
>   possible HMAC keys, verifies the HMAC and uses it to choose the correct
> handshake secret.
>
> Does the above still conflict with QUIC and open up active MitM attacks?
>
> Best,
> Karthik
>
> > On 8 Sep 2020, at 17:19, Christian Huitema <[e-mail]> wrote:
> >
> > The ECH proposal for Encrypted SNI is almost ready, but for a very small
> > debate. The original proposal was using trial description to distinguish
> > between ECH aware responses to the encrypted inner Client-Hello from non
> > ECH aware response to the "cover" outer CH. This is problematic in the
> > QUIC use case. The latest proposal is to embed a "hint" in 8 bytes of
> > the Server Random. The proposal was for ECH-aware servers to use eight
> > bytes of a hash of the inner Client Random as a hint. Analysis shows
> > that this enables two attacks:
> >
> > 1) If the Client Hello is replayed, the same hint will be present in the
> > response to the original CH and to the response to the copy, providing
> > observers with a clear indication that ECH was used.
> >
> > 2) If the Client Hello is intercepted by an MITM attacker, the attacker
> > can rewrite the server's response before presenting it to the client.
> > The attacker formats its own Server Hello that reuses the Server Random
> > from the original server response, but use its own key share, etc. The
> > hint will cause the ECH aware client to create an handshake key using
> > the inner CH. In a QUIC set up, the MITM attacker can easily detect
> > that, before even transmitting the server's certificate. Thus, the MITM
> > attacker can detect usage of ECH.
> >
> > We have a simple proposal that solves the replay attack: set the hint as
> > a hash of both the inner Client Random and the "non-hint" bytes of the
> > Server Random. That's clearly a good idea, but it does not solve the
> > active MITM attack. Solving that requires tying the hint with the
> > handshake key derived by the original server, for example by hashing the
> > inner Client Random, the "non-hint" bytes of the Server Random, and the
> > server key share. That's harder to implement, so the question is about
> > cost and opportunity.
> >
> > This all relates to how much ECH is "sticking out". The current stance
> > is that a passive attacker cannot distinguish between a client using ECH
> > to access a hidden SNI and a client merely greasing the ECH extension.
> > The observation is that there may be many potential active attacks,
> > especially if the server shares its ESNI/ECH configuration publicly. If
> > there are many such attacks, and if defense of the hint against MITM is
> > hard to implement, implementing the defense might make the code more
> > fragile, with little actual gain. But I am not convinced by that
> > argument, because it smells a lot like "the other side of the boat is
> > leaking too, why should I plug this particular leak?"
> >
> > And so, at Chris Wood's request, I am sending this message to the list.
> >
> > -- Christian Huitema
> >
> >
> > _______________________________________________
> > TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>