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

Christian Huitema <> Sat, 12 September 2020 01:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DC1E3A0A3A for <>; Fri, 11 Sep 2020 18:56:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.847
X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wVwDRNLwPvk1 for <>; Fri, 11 Sep 2020 18:56:30 -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 CFE3A3A0A39 for <>; Fri, 11 Sep 2020 18:56:29 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1kGum6-000xdm-1t for; Sat, 12 Sep 2020 03:56:25 +0200
Received: from (unknown []) by (Postfix) with ESMTPS id 4BpG1s1y8xz1Kv3 for <>; Fri, 11 Sep 2020 18:56:17 -0700 (PDT)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1kGum1-0005gx-4s for; Fri, 11 Sep 2020 18:56:17 -0700
Received: (qmail 11888 invoked from network); 12 Sep 2020 01:56:16 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 12 Sep 2020 01:56:16 -0000
To: Karthik Bhargavan <>, Ben Schwartz <>
Cc: "" <>
References: <> <> <> <>
From: Christian Huitema <>
Autocrypt:; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
Message-ID: <>
Date: Fri, 11 Sep 2020 18:56:16 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------38CEC1497C94B1BBD52D4288"
Content-Language: en-US
Authentication-Results:; 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 zJ6mVE7ewsipSVIfs4Z2XGBfENo0lcOR5D7s2MylgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+c10h9aHNaslh2Yjb8ceaq51aOsarGPChhedL2Py5oHk46jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhLSQQ4vSj0QEim26t/Moy0UPX5E73H1QfrH/5kkrV/Cr0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAm1iez9GB/vVI PBTzV+UYoQ5juR84l1u3F4RJk4edtIO8vlus/HGs5g+YLaeZslNwpZplcefmNEYxa7icSprX/uXv 5pWb82qAoDl3ILGSF0vmDvI0DEihOd7XzCAIcFZdY11677oPXF7r5zsW33ZNliqbq1iQQhopQxqA dW22RV244aYpZRc3toWQ940LqKM4TBqf27VeHOkXe82afzWlDIs7zKu1Ffv6OUjYdRcUjXJmHHAS JNUmoOHSoqgqxfHmWfZIwxxhwvMcWh0MGcvUtQib8Lgc8F74isFhfcq1FZJH1vEjHyvS2QZiR+AZ YvfxEvZFKu+ZM2mB1CpThxyaBpbeNHk15VolAGHS5rCXQKDyCQUljhSWDhWh87HBSLhNUo4qiB0X MVQG2R7iUfOzATaF5R3hQJk8CwyURYKQ0Ye0iR3bHfnMCIEU+nrglojKwJanfcoq9IsR6l/OZb9V MEM=
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 01:56:33 -0000

On 9/11/2020 4:20 PM, Karthik Bhargavan wrote:

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

I like that design a lot. It is more robust than my proposal to mix the
key share in the hint.

In other words, makes the hint dependent on the actual handshake secret.
That's pretty much what I was aiming for when asking to make the hash
dependent on the key components of the handshake secret. I was concerned
with a potential circular dependency between the secret, the hint and
the server random, which is why I was looking at mixing various elements
in the hash that computes the hint. But Karthik is of course right, the
handshake secret itself does not depend on the transcript; that
dependency is only introduced when the label is derived.

Any big issue keeping N=8?

-- Christian Huitema