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 <bem...@google.com> 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 > <karthikeyan.bharga...@inria.fr <mailto:karthikeyan.bharga...@inria.fr>> > 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 <huit...@huitema.net > > <mailto:huit...@huitema.net>> 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 > > TLS@ietf.org <mailto:TLS@ietf.org> > > https://www.ietf.org/mailman/listinfo/tls > > <https://www.ietf.org/mailman/listinfo/tls> > > _______________________________________________ > TLS mailing list > TLS@ietf.org <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
