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

Yiannis Yiakoumis <yiannis@selfienetworks.com> Thu, 09 July 2020 23:28 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 7D02E3A0991 for <network-tokens@ietfa.amsl.com>; Thu, 9 Jul 2020 16:28:20 -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 tDxVjZiYoYSb for <network-tokens@ietfa.amsl.com>; Thu, 9 Jul 2020 16:28:17 -0700 (PDT)
Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 B50803A0990 for <network-tokens@ietf.org>; Thu, 9 Jul 2020 16:28:16 -0700 (PDT)
Received: by mail-ua1-x933.google.com with SMTP id b24so1271538uak.2 for <network-tokens@ietf.org>; Thu, 09 Jul 2020 16:28:16 -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:to:in-reply-to:references:from:subject :cc; bh=sfPUJymQKr3ycIoknU1BdHhq4Cdqoht4QJK26wrLZqg=; b=cGFqRluWhZ/mkR9ESvhiI9Sqg0jvRawtaoL7P24rBgut+nrI1mAc/tJH719URwdVHp ZPzgb8qGORd1FVG3jhz6Ug4n4EEFWPs3iPiT1lOdHLMpx01rFaGKYE/HTObsFd9r5oDP /gsY5/EeO4kpy6HcazSwxrg5x9BvhR+FiYgRH/WEEMfJQRs8HRBjgocDPlCaxvge1K0L QNfB+bXtO01TlsTa0Pd0DK6eUdc2oHS40j/ZkNPAZtJMzG94r6jGS6tEvqjZ1bgj8uDK TTLe1nRJ7sCylNKhmu7ZTeoTv4J/OGivRi0y/VUK4xcoxfEB93g46lMXZld12XCM8egu 9W+Q==
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:to:in-reply-to :references:from:subject:cc; bh=sfPUJymQKr3ycIoknU1BdHhq4Cdqoht4QJK26wrLZqg=; b=CmFTbIvC8W0mrgjSJkU6sW1t7sOCZWjLdwAggLDc5rHS0/nRpK5f+4VbMN8AEttHjq sSSDK0+EP3l9MBHGcrw22uav2Xoya+X+Cz6vxcd1Qd4Z6ilw0ygLlargydZpytXBAHtY 16gitPECkNOozmo3RlqmLtluP9kUYlh4gmia1/0LZhqEqleJ92poM0Se32BmMU+1lYA+ nF75v2v9YqoOm8QsT0R/Ei4LrBPnyK83MWxsJGy3eI21lcx2Unj3t0pfxG5eL9RSOc5A 176O9kVIEwG1aXWVgAtU6c7F9DMtVsRweLW53LN/tVsdDvTf0UEeMx+NyBbdM1Uxv6Gt dLAQ==
X-Gm-Message-State: AOAM533EsIZkHVswY5bDb1edxVNWi7UVXjXlOGm7/UMePSQ0YCRwNmF+ OUrp1gaDHvNQbx2cbWrz643JLM/IGjk=
X-Google-Smtp-Source: ABdhPJw+10WBdMOoKcVwJBnNLLsWDUAnnLne/OyUCWwTxT1O8/onLDQbrGyyLwexWhNVkWf2IPx7Pg==
X-Received: by 2002:a9f:3f06:: with SMTP id h6mr18805685uaj.3.1594337294980; Thu, 09 Jul 2020 16:28:14 -0700 (PDT)
Received: from localhost (0.92.231.35.bc.googleusercontent.com. [35.231.92.0]) by smtp.gmail.com with ESMTPSA id o85sm607027vko.32.2020.07.09.16.28.14 for <network-tokens@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jul 2020 16:28:14 -0700 (PDT)
Mime-Version: 1.0
X-Mailer: Superhuman Desktop (2020-07-09T22:06:01Z)
X-Superhuman-Draft-ID: draft00ab2d123560bd5c
Date: Thu, 09 Jul 2020 23:28:13 +0000
Message-ID: <kcfe55t6.edb05462-35e0-4a42-8e32-98e83f4612aa@we.are.superhuman.com>
To: "Tom Herbert" <tom@herbertland.com>
X-Superhuman-ID: kcff8x1i.bc48ba43-993e-4c65-aaee-6649f612f6f7
In-Reply-To: <CALx6S34gnn-3SqQ6DCUw5DbVit3AwRJjw-Kq-K7DSQOaG+Reqw@mail.gmail.com>
References: <CALx6S34gnn-3SqQ6DCUw5DbVit3AwRJjw-Kq-K7DSQOaG+Reqw@mail.gmail.com>
From: "Yiannis Yiakoumis" <yiannis@selfienetworks.com>
Cc: network-tokens@ietf.org, "Christian Huitema" <huitema@huitema.net>
Content-Type: multipart/alternative; boundary=555e83116e7652ad7709578c3738c53a131b7a0ac6d0f6b03a69d39b1266
Archived-At: <https://mailarchive.ietf.org/arch/msg/network-tokens/Qw2cXDQlN40b-RPCCTf8aijELSI>
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: Thu, 09 Jul 2020 23:28:21 -0000

On Thu, Jul 09, 2020 at 3:46 PM, Tom Herbert < 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).

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 )
> 
> 
>