From nobody Fri Sep 11 18:56:33 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC1E3A0A3A for ; Fri, 11 Sep 2020 18:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVwDRNLwPvk1 for ; Fri, 11 Sep 2020 18:56:30 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 CFE3A3A0A39 for ; Fri, 11 Sep 2020 18:56:29 -0700 (PDT) Received: from xse348.mail2web.com ([66.113.197.94] helo=xse.mail2web.com) by mx114.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kGum6-000xdm-1t for tls@ietf.org; Sat, 12 Sep 2020 03:56:25 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4BpG1s1y8xz1Kv3 for ; Fri, 11 Sep 2020 18:56:17 -0700 (PDT) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kGum1-0005gx-4s for tls@ietf.org; 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 [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.38.240]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Sep 2020 01:56:16 -0000 To: Karthik Bhargavan , Ben Schwartz Cc: "tls@ietf.org" References: <696D22EB-2B7C-47AB-946F-B3246709A10B@inria.fr> <5575396A-0588-4CF8-A88B-E9255C473D60@inria.fr> From: Christian Huitema 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: <52b2e6d6-7a18-6c18-1974-7dab7e3bda63@huitema.net> 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: <5575396A-0588-4CF8-A88B-E9255C473D60@inria.fr> Content-Type: multipart/alternative; boundary="------------38CEC1497C94B1BBD52D4288" Content-Language: en-US X-Originating-IP: 66.113.197.94 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com 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= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2020 01:56:33 -0000 This is a multi-part message in MIME format. --------------38CEC1497C94B1BBD52D4288 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 9/11/2020 4:20 PM, Karthik Bhargavan wrote: > Ok, in that case it is worth making the don=E2=80=99t =E2=80=9Cstick ou= t=E2=80=9D 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=E2=80=99t 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 > =C2=A0 signal =3D=C2=A0HKDF-Expand-Label(handshake secret,=C2=A0=E2=80=9C= s hs hmac=E2=80=9D, > 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 <=3D 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=3D8? -- Christian Huitema --------------38CEC1497C94B1BBD52D4288 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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

--------------38CEC1497C94B1BBD52D4288--