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

Yiannis Yiakoumis <yiannis@selfienetworks.com> Wed, 29 July 2020 01:40 UTC

Return-Path: <yiannis@selfienetworks.com>
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 C7C943A0E62 for <tls@ietfa.amsl.com>; Tue, 28 Jul 2020 18:40: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=selfienetworks-com.20150623.gappssmtp.com
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 UukTH1GqZMdu for <tls@ietfa.amsl.com>; Tue, 28 Jul 2020 18:40:45 -0700 (PDT)
Received: from mail-ua1-x942.google.com (mail-ua1-x942.google.com [IPv6:2607:f8b0:4864:20::942]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F56B3A0E69 for <tls@ietf.org>; Tue, 28 Jul 2020 18:40:31 -0700 (PDT)
Received: by mail-ua1-x942.google.com with SMTP id p27so2893286uaa.12 for <tls@ietf.org>; Tue, 28 Jul 2020 18:40:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfienetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:cc:subject:to:in-reply-to:references :from; bh=iU7GUqJpwn+dI5ocoF4qrzbKc+9N0hulNNiUNZciNLk=; b=RD+gvsGhljVYeFtXpAw8KsmqoQGY5s7kZKSF3fEjtk0Q5UyqT7PAqQcMa9fgR06lza M7fLcn7pdo5w+2vgQM3hkpUluJ4tCSlE8mjFAb85IIv5oNZmlat3a2mELVAeGQpIUclt WhBNNl76PkwPzskCqbBeGFl38YUI201MQBZUN+jwaIG1mHpg5LDc/ZfYqUME9Up9Do3I N/WsLEbxWQ1nBkbkcXJ4iw3AnPkYQd6JHn1ftAC4jmNXVsefhQ5NcdW+DNaTZiMIvVUv gyoxQkZrS1ze+FdagXrD0PGtzkrlLetjm8AIZBOnUrS+jggGf630cWIhAMm8Yk7C1PbG dWdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:cc:subject:to :in-reply-to:references:from; bh=iU7GUqJpwn+dI5ocoF4qrzbKc+9N0hulNNiUNZciNLk=; b=G2QN7jvQZKSj8DLnr38o4zMCCZIZZD+6u0thupnJHuIAyOEdiGfOYU+WAkI7oHXHea VYSxNvTzebKNzd3ZA1i/GiXtZ3TjJx9FFeE9Z2BIiCsG1Dzf4hpYevnoG6VMRzNSKYyu 0BntvjK5VWg7BFEL4GVT2P0jWfl6yAIRzlLOEtKWCp94wKbHafa+tV1w88MJkPQefWQs f6rohXi5BYBovxS8S2SGscGU5BMteoM/LTsbiqhfVdIZZky1+2wDrQg7dtBjS945lbFQ 3ZWIXy4auQKBPIKzHEJPyTsDWNhFUSHG8Oh+y0R97vNU6R+FeL735IhrNfHPznYFw228 ZPqQ==
X-Gm-Message-State: AOAM530KGtAd121iiVPChB/93n8IsrR/v8V0mR6alvLtMOgSEdbQKExV qmUrDuW73SiNxhwra9Hhv+qVv64JudI=
X-Google-Smtp-Source: ABdhPJwrC26aiLGXD4hEu/hJdtaFJamL8BURmMRvhItpdlrH1uptH2KOCpMicqJWiDxo9PTQf2GqdQ==
X-Received: by 2002:ab0:6c50:: with SMTP id q16mr23065991uas.94.1595986829775; Tue, 28 Jul 2020 18:40:29 -0700 (PDT)
Received: from localhost (0.92.231.35.bc.googleusercontent.com. [35.231.92.0]) by smtp.gmail.com with ESMTPSA id p142sm63264vke.17.2020.07.28.18.40.29 for <tls@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jul 2020 18:40:29 -0700 (PDT)
Mime-Version: 1.0
X-Superhuman-ID: kd6pc4xe.497ad9dc-bb9d-4e1a-b9c4-df7659a8b750
Date: Wed, 29 Jul 2020 01:40:26 +0000
Message-ID: <kd6p9g71.6e9295d7-aad9-4064-9af6-d785402493f5@we.are.superhuman.com>
Cc: "Melinda Shore" <melinda.shore@nomountain.net>, tls@ietf.org
To: "Christian Huitema" <huitema@huitema.net>
X-Mailer: Superhuman Desktop (2020-07-27T22:06:08Z)
X-Superhuman-Draft-ID: draft004b7e29270badcd
In-Reply-To: <8a6e6520-9f7b-586b-42b4-3b1cab387ccb@huitema.net>
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> <8a6e6520-9f7b-586b-42b4-3b1cab387ccb@huitema.net>
From: "Yiannis Yiakoumis" <yiannis@selfienetworks.com>
Content-Type: multipart/alternative; boundary=2cb12b6ffc4a8f97f33df5eb8b846323fc6223cfc9cf0d53b6eced94d24f
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/tnwslB2F5yWupkH9smD3fJtP-Gs>
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: Wed, 29 Jul 2020 01:40:53 -0000

Hi everyone,

Just a quick follow-up that there will be the following talks on Wednesday and Thursday around network tokens.

* 

July 29 , 1:00-1:50pm UTC: TSV Open Meeting

* 

July 30 , 12:30pm-2:00pm UTC: APN Side Meeting

* 

July 30 , 4pm-5pm UTC: Network Tokens Side Meeting (details available here) ( https://github.com/Network-Tokens/network-tokens-rfc/wiki/IETF-108---Network-Tokens-Side-Meeting )

Best,

Yiannis

On Fri, Jun 26, 2020 at 10:42 AM, Christian Huitema < huitema@huitema.net > wrote:

> 
> On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote:
> 
> 
>> 
>> 
>> 
>> 
>> 
>> On Fri, Jun 26 , 2020 at 7:29 AM, Christian Huitema < huitema@ huitema. net
>> ( 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
> 
> 
> 
>