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

Karthik Bhargavan <> Sat, 12 September 2020 16:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C3773A0C23 for <>; Sat, 12 Sep 2020 09:59:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WK2879IyUJRL for <>; Sat, 12 Sep 2020 09:59:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 642FA3A0C20 for <>; Sat, 12 Sep 2020 09:59:38 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.76,359,1592863200"; d="scan'208,217";a="467366252"
Received: from (HELO []) ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Sep 2020 18:59:36 +0200
From: Karthik Bhargavan <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F2E7136B-4264-408F-8617-84A50E54CF27"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Sat, 12 Sep 2020 18:59:36 +0200
In-Reply-To: <>
Cc: Christian Huitema <>, "" <>
To: Ben Schwartz <>
References: <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [TLS] TLS ECH, how much can the hint stick out?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 12 Sep 2020 16:59:41 -0000

> 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.

I would like to return to this point, after some discussion with Chris Wood, who points out that anybody can query a server to see if it supports ECH.

So, hiding whether a server supports ECH or not (which I called level 2) is a significantly higher bar than hiding whether a particular connection is using ECH or not (level 1).
I would like to understand how the WG feels about this requirement and that there is consensus that we need (2) and not just (1).

If we only need (1) then using a ServerHello ECH extension feels more principled to me.
Of course, the ServerHello.random trick should work for both, but at the cost of implementation complexity.


> On Fri, Sep 11, 2020 at 10:00 AM Karthik Bhargavan < <>> 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 < <>> 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 mailing list
> <>
> <>