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 ) >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > >
- Re: [Network-tokens] [TLS] Network Tokens I-D and… Yiannis Yiakoumis
- Re: [Network-tokens] [TLS] Network Tokens I-D and… Yiannis Yiakoumis
- Re: [Network-tokens] [TLS] Network Tokens I-D and… Christian Huitema
- Re: [Network-tokens] [TLS] Network Tokens I-D and… Tom Herbert
- Re: [Network-tokens] [TLS] Network Tokens I-D and… Tom Herbert
- Re: [Network-tokens] [TLS] Network Tokens I-D and… Yiannis Yiakoumis
- Re: [Network-tokens] [TLS] Network Tokens I-D and… Tom Herbert
- Re: [Network-tokens] [TLS] Network Tokens I-D and… Yiannis Yiakoumis
- Re: [Network-tokens] [TLS] Network Tokens I-D and… Tom Herbert
- Re: [Network-tokens] [TLS] Network Tokens I-D and… Yiannis Yiakoumis
- Re: [Network-tokens] [TLS] Network Tokens I-D and… Lars Eggert
- Re: [Network-tokens] [TLS] Network Tokens I-D and… Yiannis Yiakoumis
- Re: [Network-tokens] [TLS] Network Tokens I-D and… Ben Schwartz
- Re: [Network-tokens] [TLS] Network Tokens I-D and… Yiannis Yiakoumis
- Re: [Network-tokens] [TLS] Network Tokens I-D and… Tom Herbert
- Re: [Network-tokens] [TLS] Network Tokens I-D and… Ben Schwartz
- Re: [Network-tokens] [TLS] Network Tokens I-D and… Watson Ladd
- Re: [Network-tokens] [TLS] Network Tokens I-D and… Tom Herbert
- Re: [Network-tokens] [TLS] Network Tokens I-D and… Michael Richardson