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

Christian Huitema <huitema@huitema.net> Tue, 08 September 2020 15:21 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BCB133A0BB8 for <tls@ietfa.amsl.com>; Tue, 8 Sep 2020 08:21:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wpYEJl4Gb9iL for <tls@ietfa.amsl.com>; Tue, 8 Sep 2020 08:21:08 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E61283A0B71 for <tls@ietf.org>; Tue, 8 Sep 2020 08:21:04 -0700 (PDT)
Received: from xse483.mail2web.com ([] helo=xse.mail2web.com) by mx165.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kFfQI-000pb2-Ao for tls@ietf.org; Tue, 08 Sep 2020 17:20:52 +0200
Received: from xsmtp21.mail2web.com (unknown []) by xse.mail2web.com (Postfix) with ESMTPS id 4Bm82z0FldzC0l for <tls@ietf.org>; Tue, 8 Sep 2020 08:19:55 -0700 (PDT)
Received: from [] (helo=xmail05.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kFfPW-0004hV-Tm for tls@ietf.org; Tue, 08 Sep 2020 08:19:54 -0700
Received: (qmail 16190 invoked from network); 8 Sep 2020 15:19:54 -0000
Received: from unknown (HELO []) (Authenticated-user:_huitema@huitema.net@[]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 8 Sep 2020 15:19:54 -0000
To: "tls@ietf.org" <tls@ietf.org>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
Message-ID: <d33c685c-6bf3-1584-4d95-1fe2cf6695e8@huitema.net>
Date: Tue, 08 Sep 2020 08:19:53 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Spampanel-Domain: xsmtpout.mail2web.com
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Ux9i8jFyHj5FzBttN4d2CmpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4YJn2Gv1NbY9zEBwA7fauiCgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+cAdwcW/8Ox85Le8wqlbs5XUz0sPgnpAk2KA2vJwMd1uY6jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhLSQQ4vSj0QEim26t/Moy0UPX5E73H1QfrH/5kkrV/Cr0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAm65NdfLN8K9b ke08A4pcSPusgSYeYCQMSlpJmALhsMXcvE8oR8jT1FIIzowoY4o0UV0DbIweXSt9j8C2hFPsK4F8 g2fGU86cSswil+kDetUfttbLHdNhiUq2jBEvMVLlZ4GThCScvU0cCIiHSQbmcVLaS2AdKj0exU9z zU42qPClBLboNblxAkv88QN/My/4aQ5RDdpxxgoVEifJFlHG6BHR7d3UpCJnPZH25X0UN+D7XPWl FdaGOH191uXjgjQN/RTaYTLUj/RFhcnr3QktcdgisJSggBRl1V/o4yPFV0GZ1vEjHyvS2QZiR+AZ YvfxEvZFKu+ZM2mB1CpThxyaBpbeNHk15VolAGHS5rCXQKDyCQUljhSWDhWh87HBSLhNUo4qiB0X MVQG2R7iUfOzATaF5R3hQJk8CwyURYKQ0Ye0iR3bHfnMCIEU+nrglojKwJanfcoq9IsR6l/OZb9V MEM=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/EAeKCNq7JAFm8DFaoe2MwSslZTQ>
Subject: [TLS] TLS ECH, how much can the hint stick out?
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2020 15:21:10 -0000

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