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

Christian Huitema <huitema@huitema.net> Fri, 26 June 2020 17:42 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: network-tokens@ietfa.amsl.com
Delivered-To: network-tokens@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0BC3A0BC2 for <network-tokens@ietfa.amsl.com>; Fri, 26 Jun 2020 10:42:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 x3PO3w0zCWcR for <network-tokens@ietfa.amsl.com>; Fri, 26 Jun 2020 10:42:51 -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 931543A0BB8 for <network-tokens@ietf.org>; Fri, 26 Jun 2020 10:42:50 -0700 (PDT)
Received: from xse27.mail2web.com ([66.113.196.27] helo=xse.mail2web.com) by mx171.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1josN5-000soB-QS for network-tokens@ietf.org; Fri, 26 Jun 2020 19:42:47 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 49tkjp1PKlz22N5 for <network-tokens@ietf.org>; Fri, 26 Jun 2020 10:42:38 -0700 (PDT)
Received: from [10.5.2.12] (helo=xmail02.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 1josN4-0008RA-1O for network-tokens@ietf.org; Fri, 26 Jun 2020 10:42:38 -0700
Received: (qmail 3943 invoked from network); 26 Jun 2020 17:42:37 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.153]) (envelope-sender <huitema@huitema.net>) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for <network-tokens@ietf.org>; 26 Jun 2020 17:42:37 -0000
To: Yiannis Yiakoumis <yiannis@selfienetworks.com>
Cc: Melinda Shore <melinda.shore@nomountain.net>, tls@ietf.org, network-tokens@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> <38d4885d-71f0-e69c-e78c-608482036956@huitema.net> <kbwgjics.3e327ce5-1d5c-4ba4-9d8e-ae9cb79f3003@we.are.superhuman.com>
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: <8a6e6520-9f7b-586b-42b4-3b1cab387ccb@huitema.net>
Date: Fri, 26 Jun 2020 10:42:36 -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: <kbwgjics.3e327ce5-1d5c-4ba4-9d8e-ae9cb79f3003@we.are.superhuman.com>
Content-Type: multipart/alternative; boundary="------------A1EF4775B662EB83EE14254E"
Content-Language: en-US
X-Originating-IP: 66.113.196.27
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.27/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.27/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0f6LF1GdvkEexklpcFpSF5apSDasLI4SayDByyq9LIhVMVvqKlQUtLwO BOP0oQh1dUTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDu+ZMnHdqR5lrAvYSrWZKV7G1 j4g3vdJamd/Z6fSfIiHdU1BL/P5hTT+OvEiz9qXZ4pWx7WxWFZpsjT/483ewgnBpqZvo8S/Elh6D JFe855DL6NyqkIUkLn9rMCCYletN+pjMDAnHbx51+ktdTzWdCBPPepdU31W1Q8sT13sYZmrc04qw ljHpN4lSYpddDpUXRMgAAXrc+wN5PJ8Hvw8qjNtd4QSmv7okquJYqeLcsFjptQHeGNL6keepTGFH NE3ltXmdhPE/B5jGda2JMHgPHs2ogEUyAFrL6xLUkoxsZrgDeXiBgAUsswQZtXl8NZGxKvWTUIuw AP+Be6QqMx/OK6S8tu2KVBI79Uufvsp4JVs0tmVR44MWLHxoXhMb/NjbpLoGJLWmCsNj3IOUYF8t pBgYrswXUAHW7yTWdn+ESHMVibkyMxsuFG9+hHfpakcKugBtfK1Us0vBD0buxpxtOHMcN6qoXPje nLhIOF1oeRa93bZBPAvAmAYOpRI1LnOV0w/MKeNOaXszKnCGxKAR82sQF5eEonGNErCSq6uQ5bcT vLtGoOPovZCzlvXEZ2pHTtEkY40nhC5Zxe2O3klyWvGISNE/hO231c8s4dw5L8oMhGfTGKeYohdq JlHBQlshIY4dBdqa97Zg80cTGQZwTycAnpQIMSNxxOCOU1F642aSds6cKKUBNABU6wvYxqC9kAE+ iGSwlgUiPUpnvID06WbjO41FyBEqIaDudcVplPG+p74YeLeIIaxGpHmiNjwWGKmjVsw7m7anl4XU W1v/FvOi6HTmY+/cXUo8ym6keVx5NKotYZMP4QxilpD1WJVxdwYWcRoGRTsLxqa8TRmmuv9qwM7R XpJS8RjTdyh2j5DIweuSooT6tSPU1x5zpUpIPziDkWQ5faPk5nJXHz00MDRj9D8HLKHAKpPGP8EP nuB53cHIFHavQpo3FUDrLYIQ
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/network-tokens/H5BdwuDgOzQPO4NuFBoCpKbz5FU>
Subject: Re: [Network-tokens] [TLS] Network Tokens I-D and TLS / ESNI
X-BeenThere: network-tokens@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for network tokens <network-tokens.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/network-tokens>, <mailto:network-tokens-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/network-tokens/>
List-Post: <mailto:network-tokens@ietf.org>
List-Help: <mailto:network-tokens-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/network-tokens>, <mailto:network-tokens-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2020 17:42:53 -0000

On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote:
>
>
>
> On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema
> <huitema@huitema.net <mailto:huitema@huitema.net>> wrote:
>
>     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.
>
>
> You are right that for the duration of a token, one could use it to
> identify an endpoint (either application or most likely a combination
> of user/application). Tokens expire and intermediary nodes cannot
> correlate tokens with each other as they are encrypted. So tracking
> cannot happen across different tokens (of the same user), or between
> token-enabled and non-token-enabled traffic. I guess similar type of
> tracking happens when users are not behind a NAT and their IP address
> can be used to track them. Would it make sense to have the user add a
> random value to a token, and then encrypt it with the network's public
> key, so that each token becomes unique and cannot be tracked. Would
> that address the privacy concerns better?

That would certainly be better. The basic rule is that any such
identifier should be used only once. Pretty much the same issue as the
session resume tickets.

>
>     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.
>
>
> Ah, I was not aware that ESNI can now include all CH extensions -
> thanks for the pointer. Yes, the token would have to stay on the outer
> envelope so the network can process it. The main idea is you can
> encrypt everything that is client-server specific, and just keep a
> token to explicitly exchange information with trusted networks. 
>
>     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.
>
>
> Haven't looked into QUIC yet, but is on the list of things to do. If
> anyone is interested to help us explore this, please let me know.

You may want to have that discussion in the QUIC WG. If you are building
some kind of QoS service, you probably want it to work with QUIC too.

-- Christian Huitema