Re: [TLS] Network Tokens I-D and TLS / ESNI

Christian Huitema <huitema@huitema.net> Fri, 26 June 2020 14:30 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 535C63A03F3 for <tls@ietfa.amsl.com>; Fri, 26 Jun 2020 07:30:26 -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 fQRc0UR4K7-K for <tls@ietfa.amsl.com>; Fri, 26 Jun 2020 07:30:24 -0700 (PDT)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 A64453A040F for <tls@ietf.org>; Fri, 26 Jun 2020 07:30:24 -0700 (PDT)
Received: from xse448.mail2web.com ([66.113.197.194] helo=xse.mail2web.com) by mx171.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jopMw-0011WI-AI for tls@ietf.org; Fri, 26 Jun 2020 16:30:22 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 49tfRl2FRTz9m6 for <tls@ietf.org>; Fri, 26 Jun 2020 07:30:11 -0700 (PDT)
Received: from [10.5.2.14] (helo=xmail04.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 1jopMp-000379-6M for tls@ietf.org; Fri, 26 Jun 2020 07:30:11 -0700
Received: (qmail 23722 invoked from network); 26 Jun 2020 14:30:11 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.153]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 26 Jun 2020 14:30:10 -0000
To: Melinda Shore <melinda.shore@nomountain.net>, tls@ietf.org
References: <kbsy4785.3cb5b3af-12b1-4d09-9944-6e4e487b103d@we.are.superhuman.com> <CAKC-DJjRBZujxoLNtNCTe40Gwta9KbdCORVzJ1V54UTGpYP8xQ@mail.gmail.com> <87e6e635-d1ec-9f36-41c3-339774f510ca@nomountain.net>
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: <38d4885d-71f0-e69c-e78c-608482036956@huitema.net>
Date: Fri, 26 Jun 2020 07:29:59 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <87e6e635-d1ec-9f36-41c3-339774f510ca@nomountain.net>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rKgdl2dGY4fkXomXmV9AJ12H9ATKXOKUE"
X-Originating-IP: 66.113.197.194
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: ham
X-Spampanel-Outgoing-Evidence: Combined (0.10)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0f6LF1GdvkEexklpcFpSF5apSDasLI4SayDByyq9LIhVD46G4TYzZFwY VGJsUVc8QETNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4aphbx4Ckv2LkcssKAxtcblgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+eYkD5a9Nw7hRCVIMRq0efqTAas0edmB2q/yBRqnQY9Wo6jSvfpO+1kZkomjtjB6X7/nuj3 koRhn2BlE7dXoT0pGVmhMAaQ/AfCRwRe7yHm5oY+NYmsSGn+svMubxnbgm1cr18FZBEPC2/c16Xd 7sC9aC4xteE1WLqGS9YoqrsZ2DyteN0e+ECCv9/f+GPymkgDVo7QBKA4MctKq4ifYPcXFRL2K3LA EfDXVOdt7wDbusYnuEVWSxKMHbU0zkNM3EElFDaoLuOPKc8gc82pKfhB7T02ZXdoQxMs//iOE4Fl hiCv9TR+UxzLZWL8hwGBjhoI3W+YcuHfP5PkZb5A+wE5qGdpH54Oa3V8I76VOEvlwLCanpZsarZa LIRpEqA8mZHBhkQd7hzuzHZPvYWKxpxJznbr/iPR0U8WqNWDtD9jyQKkFr/2op3xdDB5v9zdhnH2 ie80q3LAG2MiIaIREzT1xNjuO97khcUFBr/guEWv1bdCp3Zd9clP8wSiJZWbJCj+xRrjVmRxpGtS cvUmgj1LI+VSQJN/ZrCApq+UVRTKzF2jZAOanSBpz6Rja2u/0jLCoYGlDFqUCGkiW9JlgLvfS45r yi4J4ZFsGB+VEKPBnPysta6u1iHEyuS7GD1uvcqtGg2OYXXlB2xa18mpR0uPJOYIJd4MvQ0Nf4Ec bvHO1diDanHV9KirFAIIecsyj+YNTo81GR+jDXFsz/ZQnbbTizvwlZsrbltGiZoUh+c+5pFVgpT1 b21uZVckGp0ccOa2XhkGbmsUNPNkere1WheNsVXmhO8BzADiszcWR9bz/SDtF09JpSbuuCeiIDK0 C/0=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pyXGE4_G0nyjvVkGKZcfW19e3b4>
Subject: Re: [TLS] Network Tokens I-D and TLS / ESNI
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: Fri, 26 Jun 2020 14:30:26 -0000

On 6/25/2020 11:11 PM, Melinda Shore wrote:

> On 6/25/20 3:29 PM, Erik Nygren wrote:
>> One quick comment is that binding tokens to IP addresses is strongly
>> counter-recommended.
>> It doesn't survive NATs or proxies, mobility, and it is especially
>> problematic in IPv6+IPv4 dual-stack environments.
> There's been a bunch of past work done developing similar sorts of
> protocols, and for what it's worth I wrote up a mechanism for
> using address tags and address rewrites, but unfortunately Cisco
> decided to patent it.  Anyway, there are ways of dealing with this
> problem that don't require binding the address to the token ("all
> technical problems can be solved by introducing a layer of
> indirection").


There is also an interesting privacy issue. The token is meant to let a
provider identify some properties of the connection. I suppose there are
ways to do that without having it become a unique identifier that can be
tracked by, well, pretty much everybody. But you have better spell out
these ways.

Then, there are potential interactions with ESNI/ECH. The whole point of
ECH is to keep private extensions private. The token extension would
need to be placed in the outer envelope, which is public but does not
expose seemingly important information like the SNI or the ALPN.

There are also implications for QUIC, in which the TLS data is part of
an encrypted payload. The encryption key of the TLS carrying initial
packets is not secret in V1, but it might well become so in a future
version.

-- Christian Huitema