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

[Karthik Bhargavan <[e-mail]>]

Ok, in that case it is worth making the don’t “stick out” property more precise.

1) We can either try to prevent the attacker from learning whether ECH was actually used in a particular connection, or
2) We can try to prevent the attacker from learning whether the server supports ECH at all.

I gather the consensus is that we should try to obtain (2) at least until ECH support becomes ubiquitous on the server side?
Since TLS 1.3 moves all but a few SH extensions to EE, I suppose there isn’t any other extension to hide this signal in.

In that case, I guess using a value derived from the handshake key as part of the ServerRandom should probably work.
That is, when constructing the ServerHello:

- first set the first N bytes of the server random to 0
- compute the hanshake secret (based on either the inner or outer CH)
- compute the signal of N bytes as
  signal = HKDF-Expand-Label(handshake secret, “s hs hmac”, Transcript-Hash(ClientHello..ServerHello), N)
- replace the first N bytes of the server random with signal

This is a somewhat icky design, but I think we should be able to justify it for (say) N <= 16 bytes.



> On 11 Sep 2020, at 16:08, Ben Schwartz <[e-mail]> wrote:
> 
> 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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> 
> _______________________________________________
> TLS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>