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

Yiannis Yiakoumis <yiannis@selfienetworks.com> Fri, 10 July 2020 01:51 UTC

Return-Path: <yiannis@selfienetworks.com>
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 64D193A0B5B for <network-tokens@ietfa.amsl.com>; Thu, 9 Jul 2020 18:51:14 -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 Mx6me3qypDgq for <network-tokens@ietfa.amsl.com>; Thu, 9 Jul 2020 18:51:10 -0700 (PDT)
Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 6BE343A0B55 for <network-tokens@ietf.org>; Thu, 9 Jul 2020 18:51:10 -0700 (PDT)
Received: by mail-ua1-x934.google.com with SMTP id p6so1332401uaq.12 for <network-tokens@ietf.org>; Thu, 09 Jul 2020 18:51:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfienetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:cc:in-reply-to:references:from:message-id:date :to; bh=2+xxcrQBsE45tsFd+fmb2dAc2bp8HXAmSDJzoVSpBbc=; b=Pe9+rYpNkwt/JMs81RilAyh5v4GiF4yGUc12pnHfH+R07P7qkrYsvo6nbpQfQIYV/O hZX5GeDYNJHdgnzgF6oPWAkHx7jc80qgVSWsU9Yr8AmjUx4KlOA9Tzdl10auGj7wHabJ 8t3xeAy4gsmdw2CeKOqMSVQjD3BGjOHVXHd3zaX2SPajlXzyqZTXTl04+1CJ0unsw/NR h3K1+EkgJJhbbhvE1MnuWLLYiuWBJ2fTshN7tsEQ3CcndWPWIErpN/CG138Uo5NUAjNi kHTX5VGHTv0VG0gqBKEdagN/ez/hMeXbqh9dV19e6m0miXUGG8vigrS3GN/3g9qTTgeB nqQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:cc:in-reply-to:references :from:message-id:date:to; bh=2+xxcrQBsE45tsFd+fmb2dAc2bp8HXAmSDJzoVSpBbc=; b=QAMNP21wkugQoCx37ZbSQTdBinXR8ke0FpzIk43jXHRObLCvBXz8pKRiFVGzFLsfiV 5TLcq0H4OScuYttgqfIHH/kEzV6BCRNiCSIkybViPSAZ1LFl0GAdnmEZkKwI8t5w5JDK 3yYR54sIPoDrDJ+ANFF+GMtOpAmyAu5RTqqsrSDFMonUEb29+IdGH9fienTvNl9yJWt/ /IJYGgLUUAzQVk+y9uRnTW/tHk3+6JDBCeysCmxxDuyAto7RZFNDoL/jAHO73IjSG6YY P8yDlb6LbNqq2QJNaDhkC1Ingk17jVzRJw8BMKrXmbPa3D5Yta4cmViyKIqkDKrbzD5N ChDg==
X-Gm-Message-State: AOAM531A21W4SKlRaCCNT+ysUrq583RpQYzzBowfla0mdn/Jyhf9j3zJ vadqUz3DVJEQr1JZmwZhJWMnc5RdePU=
X-Google-Smtp-Source: ABdhPJzo8Nh5gdFS2hjBTvmZf2Wi71ZGnNET40FDIaAdWJ40fPyBAhP6wTKjhwKlbgWiNsBOm8FrUA==
X-Received: by 2002:ab0:1892:: with SMTP id t18mr17948783uag.65.1594345868975; Thu, 09 Jul 2020 18:51:08 -0700 (PDT)
Received: from localhost (0.92.231.35.bc.googleusercontent.com. [35.231.92.0]) by smtp.gmail.com with ESMTPSA id s188sm664083vka.8.2020.07.09.18.51.08 for <network-tokens@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jul 2020 18:51:08 -0700 (PDT)
Mime-Version: 1.0
Cc: network-tokens@ietf.org, "Christian Huitema" <huitema@huitema.net>
X-Superhuman-ID: kcfkcp33.36751a4c-6132-4496-a3d5-df379181e4b9
X-Superhuman-Draft-ID: draft008afd53c25d2c17
In-Reply-To: <CALx6S35Actz2gjOf7HU2kYFP9p1ZwccCSjMEXVqhrYL3dKyGGw@mail.gmail.com>
References: <CALx6S34gnn-3SqQ6DCUw5DbVit3AwRJjw-Kq-K7DSQOaG+Reqw@mail.gmail.com> <kcfe55t6.edb05462-35e0-4a42-8e32-98e83f4612aa@we.are.superhuman.com> <CALx6S35K2FNXttGSmumDRnALLF+kuwa0A7W46843Jxg+sGfwNw@mail.gmail.com> <kcfgc96h.19a39fd9-f1a8-4330-8a60-06b615772de8@we.are.superhuman.com> <CALx6S35Actz2gjOf7HU2kYFP9p1ZwccCSjMEXVqhrYL3dKyGGw@mail.gmail.com>
From: "Yiannis Yiakoumis" <yiannis@selfienetworks.com>
Message-ID: <kcfk3umb.5e9417e6-cf17-470b-8f99-aad1193fb2d8@we.are.superhuman.com>
X-Mailer: Superhuman Desktop (2020-07-09T22:06:01Z)
Date: Fri, 10 Jul 2020 01:51:07 +0000
To: "Tom Herbert" <tom@herbertland.com>
Content-Type: multipart/alternative; boundary=536ef811959958c8e78b72d225a57270cfcfeaa662cb605d21f05a0300fa
Archived-At: <https://mailarchive.ietf.org/arch/msg/network-tokens/xsP_4wivrUiKrQU68DxZ0--q27Q>
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, 10 Jul 2020 01:51:14 -0000

On Thu, Jul 09, 2020 at 6:38 PM, Tom Herbert < tom@herbertland.com > wrote:

> 
> 
> 
> On Thu, Jul 9 , 2020 at 5:33 PM Yiannis Yiakoumis
> < yiannis@ selfienetworks. com ( yiannis@selfienetworks.com ) > wrote:
> 
> 
>> 
>> 
>> On Thu, Jul 09, 2020 at 4:51 PM, Tom Herbert < tom@ herbertland. com (
>> tom@herbertland.com ) > wrote:
>> 
>> 
>> 
>>> 
>>> 
>>> On Thu, Jul 9, 2020 at 4:28 PM Yiannis Yiakoumis < yiannis@ selfienetworks.
>>> com ( yiannis@selfienetworks.com ) > wrote:
>>> 
>>> 
>>> 
>>>> 
>>>> 
>>>> On Thu, Jul 09, 2020 at 3:46 PM, Tom Herbert < tom@ herbertland. com (
>>>> tom@herbertland.com ) > 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 ) <mailto: 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, thre 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.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> I view the use of TLS to carry tokens as a temporary hack to make
>>>>> something work quickly. There are several obvious problems that prevent
>>>>> that from being the general solution: it's specific to TLS/TCP, it
>>>>> requires intermediate nodes to parse into TCP payloads, it requires
>>>>> tracking connection state in the network.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> IMO, the real solution is to encode tokens in HBH options. This addresses
>>>>> the aforementioned problems, works with any transport protocol (including
>>>>> QUIC, IPsec tunnels, arbitrary encapsulations), eliminates state and need
>>>>> for DPI in the network.
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> + Christian as I think he posted at the tls mailing list. Lots of
>>>> interesting points.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Define "temporary" and "quickly" :) Tokens reflect a relationship between
>>>> an end-user/app and a network, so you want apps/users to be able to insert
>>>> these tokens to their traffic. Agreed that IPv6 can work with multiple
>>>> transports and is more generic, but you will then have to find ways to
>>>> pass the token all the way from the user/app down to the IPv6 socket.
>>>> TLS/QUIC is much closer to the end-user/developer, and most high-level
>>>> frameworks (e.g., OkHTTP, web browsers) expose APIs to define certain
>>>> properties. This is not the case with IPv4/IPv6 (e.g., I don't think it's
>>>> possible to set DSCP bits from OkHTTP or Javascript).
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> Hi Yiannis,
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> Hi Tom,
>> 
>> 
>> 
>>> 
>>> 
>>> We don't need to find ways to pass the token, there are already sockets
>>> APIs to do that.
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> How can an Android/iOS/web developer interact with these socket APIs? Are
>> there side ways to do it while using the high-level frameworks available
>> there, or do you have to skip them and build your code directly using
>> sockets? Both STUN and TLS support custom extensions, and we've been able
>> to use tokens with OpenSSL/BoringSSL (but we had to build and load our own
>> version along with the app). If we make tokens a standard extension, then
>> other frameworks will pick it up right away and they will become available
>> for everyone to use (the same way it happened with SNI and ALPN).
>> 
>> 
>> 
>>> 
>>> 
>>> The issue with network devices reading transport layer payload is that
>>> port numbers, which are used to distinguish TLS, QUIC payloads, etc. are
>>> not protocol numbers. They are only interpreted by the end points
>>> (RFC7605). The network never really knows if port 80 for TCP is HTTP, or
>>> for UDP is QUIC. It's an approximation that may be incorrect. Similarly,
>>> if the application uses some other port numbers for their protocols then
>>> they're out of luck unless the network knows about those. All of this was
>>> brought up in the SPUD discussions a while back, other than adding magic
>>> numbers into the payload, which is probabilistically correct, there really
>>> wasn't much of an answer to the problem.
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> Yes, you don't have guarantees here. We have an implementation were tokens
>> are carried over STUN messages during WebRTC calls. We assume that every
>> UDP packet is STUN and parse it based on expected type-len fields as long
>> as it gives us something valid. We haven't looked at the probability of
>> error and performance penalty yet, these would be good things to
>> understand. But given the trend towards programmable hardware/software
>> packet parsers, I am optimistic.
>> 
>> 
>> 
>>> 
>>> 
>>> There's other issues like segmentation of the TLS header, ossification of
>>> TLS headers, etc.
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> Would DTLS help to assume that header is within a single packet?
>> 
>> 
>> 
>>> 
>>> 
>>> Honestly, I doubt that network tokens in transport payload with the intent
>>> that intermediate devices parse them is something that could be
>>> standardized in IETF.
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> Why is that? Isn't this how all firewalls/DPI/TDF etc work today ? I think
>> it's a good point to bring up into the TSV discussion and get feedback.
>> 
>> 
>> 
> 
> 
> 
> Yiannis,
> 
> 
> 
> 
> It's because host-to-network signaling in UDP payload has been tried
> before in IETF, tsvwg specifically, and failed to go anywhere. Please take
> a look at SPUD, draft-hildebrand-spud-prototype-03 (there was even a BOF
> or two on it with some pretty animated discussion!). It's likely SPUD will
> be brought up in any TSV discussions :-).
> 
> 
> 
> 
> Firewalls and DPI typically operate outside of the auspices of IETF
> protocol specifications. Other than spin-bit in UDP, I don't believe there
> are any other cases where protocols allow intermediate devices to look at
> payload. In fact, DPI is actually one leading cause of protocol
> ossification so there's a lot of motivation to eliminate it
> (this is why transport protocols are moving to not just encrypting payload
> but also the transport headers). This is another ongoing discussion in TSV
> that will likely be brought up (see draft-ietf-tsvwg-transport-encrypt-13
> and all the animated discussion around that :-) ). To that end moving
> network tokens in extension headers eliminates the need for DPI and
> resolves the tussle around transport layer header encryption.
> 
> 
> 
> Tom
> 
> 
> 
> 

Got it.  Appreciate the pointers and understand reservations and concerns. I think we should take our chances for two reasons:

* network tokens attempt to do endpoint-network coordination in a way that puts privacy and security considerations first.

* having an explicit and secure way to coordinate with the network can facilitate encrypting everything else without pushback from valid business cases that are widely deployed today.

> 
> 
>> 
>>> 
>>> 
>>> A secondary issue that you might want to consider is security. A rogue
>>> application can easily spoof tokens in TLS or QUIC packets, the OS is out
>>> of the loop on what applications put in their payload. Setting an
>>> extension header on a socket requires going through the OS which can apply
>>> policy to see if the system configuration permits that, so it's going to
>>> be harder for random applications to spoof tokens.
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> The role of the OS in describing and enforcing the desired policy is an
>> important point and requires lots of discussion. Holding off for now
>> though...
>> 
>> 
>> 
>>> 
>>> 
>>> Tom
>>> 
>>> 
>>> 
>>>> 
>>>> 
>>>> In terms of connection state and whether you want to do it per-flow or per
>>>> packet. I think there is an overall trade-off here around how big is the
>>>> token, how much state it introduces at the network, and what are the
>>>> processing capabilities in terms of processing and decrypting tokens.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> For example, you can have a token which is a 128-bit random/opaque value
>>>> that you use per-packet as a HBH option, but then the network needs to
>>>> keep state for all the valid tokens, and accept some risk of a replay
>>>> attack. The other alternative is to have a token that is encrypted and is
>>>> therefore longer, but has enough information for the network to decrypt it
>>>> and process it without requiring any state at all.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> I think both are viable, and it should be up to the network operator to
>>>> decide what type of tokens it uses. if you look at how OATH2 and the IAM
>>>> industry deals with it is that they support both.
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> Of course the naysayers will bring up the fact that HBH options aren't
>>>>> ubiquitously supported by routers. I think there are some ways around
>>>>> this:
>>>>> 1) Network tokens really only make sense to the network that issued them,
>>>>> so their use could be restricted to that limited domain where they are
>>>>> consumed.
>>>>> 2) Packets that are leaving the limited domain that carry network tokens
>>>>> in HBH options could be filtered and the HBH option is removed
>>>>> (see proposal draft-herbert-6man-eh-attrib-01 to allow intermediate nodes
>>>>> to remove options).
>>>>> 
>>>>> 
>>>>> 
>>>>> Limiting the visibility of tokens to the local network also helps their
>>>>> security.
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> I am not a big fan of the assumption that tokens are relevant only to the
>>>> local network, and can be issued only by it. In a zero-rating or firewall
>>>> scenario, the token would be specific to the application provider (and
>>>> maybe issued and signed by them), which is likely not co-located with the
>>>> network. This is detailed on the application token in the I-D.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Yiannis
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> Tom
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Network-tokens mailing list
>>>>> Network-tokens@ ietf. org ( Network-tokens@ietf.org )
>>>>> https:/ / www. ietf. org/ mailman/ listinfo/ network-tokens (
>>>>> https://www.ietf.org/mailman/listinfo/network-tokens )
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 
>