Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt

Christian Huitema <huitema@huitema.net> Tue, 02 June 2020 20:35 UTC

Return-Path: <huitema@huitema.net>
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 077983A0FCF for <tls@ietfa.amsl.com>; Tue, 2 Jun 2020 13:35:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMoIF7vdaVZd for <tls@ietfa.amsl.com>; Tue, 2 Jun 2020 13:35:10 -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 7A8A23A0FD2 for <tls@ietf.org>; Tue, 2 Jun 2020 13:35:00 -0700 (PDT)
Received: from xse125.mail2web.com ([66.113.196.125] helo=xse.mail2web.com) by mx170.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jgDcO-000eEk-WB for tls@ietf.org; Tue, 02 Jun 2020 22:34:53 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 49c2vd2TL8z6fJN for <tls@ietf.org>; Tue, 2 Jun 2020 13:00:13 -0700 (PDT)
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jgD53-0002k1-7j for tls@ietf.org; Tue, 02 Jun 2020 13:00:13 -0700
Received: (qmail 27527 invoked from network); 2 Jun 2020 20:00:13 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.64]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 2 Jun 2020 20:00:13 -0000
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Christopher Wood <caw@heapingbits.net>, "TLS@ietf.org" <tls@ietf.org>
References: <159104051676.18465.12498199656412028384@ietfa.amsl.com> <af75a707-3b6c-a1af-14c4-6e766cb4e572@huitema.net> <c7a41e95-8b21-4620-806e-db144eac2fa3@www.fastmail.com> <4385bb35-710b-311d-2b7c-fad0eb72c5d3@huitema.net> <eefa3eda-83ec-8237-167a-009a83791629@cs.tcd.ie>
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: <0e3105b1-3d43-c5e2-e526-69a187701aca@huitema.net>
Date: Tue, 02 Jun 2020 13:00:12 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <eefa3eda-83ec-8237-167a-009a83791629@cs.tcd.ie>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="wUPfcnofZlktKPMoRAR1oH4R5HGc3qK3d"
X-Originating-IP: 66.113.196.125
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.125/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.125/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: ham
X-Spampanel-Outgoing-Evidence: Combined (0.10)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T32zu7lnXf5JHTxKFqDV/OpSDasLI4SayDByyq9LIhVQMCsol8nFT4c ybECHTZe40TNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4bTu/hUqk0wB0xIGLQFdRAZgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+eYkD5a9Nw7hRCVIMRq0efq6k/ICmf4myKtZN20xbt8wI6jSvfpO+1kZkomjtjB6X7/nuj3 koRhn2BlE7dXoT0pGVmhMAaQ/AfCRwRe7yHm5oY+NYmsSGn+svMubxnbgm1cr18FZBEPC2/c16Xd 7sC9aC4xteE1WLqGS9YoqrsZ2DyteN0e+ECCv9/f+GPymkgDVo7QBKA4MctKq4ifYPcXFRL2K3LA EfDXVOdt7wDbusYnuEVWSxKMHbU0zkNM3EElFDaoLuOPKc8gc82pKfhB7T02ZXdoQxMs//iOE4Fl hiCv9TR+UxzLZWL8hwGBjhoI3W+YcuHfP5PkZb5A+wE5qGdpH54Oa3V8I76VOEvlwLCanpZsarZa LIRpEqA8mZECoO4gCQkfvynnCsTu+Y7qysYn+2WmjiNmrC+0DLVCYi8CA6FlUzy28jATJvi5EH9X dU571qBU/d2sq9m7FB7HOTKohW1LdIa7IkvZM3iuLmkvZ+pWP1s35neRYWMQUWZErSs0X3oyoTc8 j/o7qulx+Z35JsYprPLEWyJDYNOgB2re/hsBBxzR0ZxLcHZ9dOiXTyagf7f9s4ASqMhjJ9C4mHBw o0TowpIoKmXuwuW3NAEH5tktsnhMr4gG+2qXrJ35y/5W65h5idrw/xlP8KmZ9R/2gMGq0KWAzmMf +ibVDpdplkxcBm4XM6d7s4Bx3w1WbaUe4g0kgaInvdEp64qlVpe//bVkg87Xe61e30HXuSERbInM iTBIUBbQ/Dy6Ip4D1rnEhdYtY/lMQX5s39oH5ijcGdSK77ViXbmzTYWgl82XucjoLWQ7++7jcUS/ T5w=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dy4rAOcwqbe7hyt9DAwvWLcDY3w>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt
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, 02 Jun 2020 20:35:12 -0000

On 6/2/2020 11:30 AM, Stephen Farrell wrote:
> Hiya,
>
> Sorry if I'm missing a bit of context...
>
> On 02/06/2020 18:28, Christian Huitema wrote:
>>                clients prevent server identification by sending
>> an empty record_digest field in the ClientEncryptedCH, and 
> That seems to me to be an unnecessary breach
> of the do-not-stick-out requirement. In my code
> it was quite easy to attempt trial decryption
> (if so configured). I don't think there's an
> expectation of a use-case where the number of
> keys in use would be so high as to cause a problem.
> So I'd prefer the client in that case to just
> send random data of the usual length.
>
> That said, ECH is sticking out a lot already
> so this is not a huge deal;-)

I see your point, Stephen. Length=0 is a clear signal to the server, so
server processing is just a bit easier than sticking a random number
that looks like a SHA256 hash, or whatever the cipher-suite mandates.
With length=0 third parties can casually observe that "this server wants
to remain private"; with random numbers they can only observe that the
record digest does not match any of the digests that they are tracking.
Random numbers are thus a little bit better for privacy, at the cost of
a little bit more work for the server.

As I said, my first goal is to avoid silly interop issues and have a
recommended behavior for servers that desire privacy. Chris is nudging
me to create a PR;  If the consensus is for random numbers, I will put
that in the PR.

-- Christian Huitema