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

Yiannis Yiakoumis <yiannis@selfienetworks.com> Fri, 26 June 2020 05:34 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 8F7903A1154 for <tls@ietfa.amsl.com>; Thu, 25 Jun 2020 22:34:17 -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 GtMG5G6zNeyd for <tls@ietfa.amsl.com>; Thu, 25 Jun 2020 22:34:15 -0700 (PDT)
Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 766C23A1153 for <tls@ietf.org>; Thu, 25 Jun 2020 22:34:15 -0700 (PDT)
Received: by mail-vs1-xe33.google.com with SMTP id k7so3510442vso.2 for <tls@ietf.org>; Thu, 25 Jun 2020 22:34:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfienetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:cc:from:in-reply-to:references:date:message-id:subject :to; bh=ELdOpZDBEsR1d15Luyj8SMpFyxnQzDnzOZqfQmtAoRM=; b=gOgEYKqzt2quhcbQ4ZKH82AQ0msIquH4h2A+DLPxpJFNE9JedMnVF7lNfDTGUhDvIt kgP571CapuknrHD5obpTDU5EI0I6mQUDl2r0+kh9VK2TdlaFAZ5pYt70crMS7bdGc3pT eaIMw2jXtbTE2H+gVYho6IjNVm96kbQmKl33z2a0RWavzoXtuDoiYJaiEAsYx//9F+Pf gq8hRIXqmRypFVrNRkvMg+M+H9A7JSogqIa6jiloWNwT9ZYU2WPVZ69oCjpxJ3yu9FUM BgTzFNgKxTbgzSJOG/33MVifbNJUjuppf8cHYSvHoSyaSsRbV7idq9/P41/ETzoTtHyG 9lXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:cc:from:in-reply-to:references:date :message-id:subject:to; bh=ELdOpZDBEsR1d15Luyj8SMpFyxnQzDnzOZqfQmtAoRM=; b=T42mvTowZHpI84IsY08YISMuYyTjwwvinNG2yW1DN81HvukNNZ4hr880s8zcK2zjie KV4teky3XgzO25oWGBwnKEX8AVacAgGEy9JIZN+ungn+zWUNdGt4V4lE57sNJCfaUVpO I5Zvq00NfqD9kpoLRk+oQeeU770aWwiXQNR66e1tPwi0XsGSXwkxPEw5obTWcu2kaDC6 dSTMy3iRjSuwpQ16NMv8hVidVdGR0P0vM06tBOUEKUso0XE0AcdORH/kjRYwgVod94R1 2SdHI/3ThYGqCfPr1CXud/+J3KY2R9BfSNyjyealMl9zT09itt/iDw235r0pA1rSWuHa bLHQ==
X-Gm-Message-State: AOAM5308GmtnSZdTFx7KC4fPB2UVYE/r67QlqlbIjWzZjrZZsJisGlnU h5rMCfAPXVvxHnb7c/ddOE9XhU5iqAw=
X-Google-Smtp-Source: ABdhPJynIBnQWMlFX/qdU4HyaoMxkH0A4MsrmBvuwVB3RQR8T6KQa8Afz/d0aGKRDsr3Jlbl/FJVGQ==
X-Received: by 2002:a67:fc08:: with SMTP id o8mr1257906vsq.188.1593149654103; Thu, 25 Jun 2020 22:34:14 -0700 (PDT)
Received: from localhost (0.92.231.35.bc.googleusercontent.com. [35.231.92.0]) by smtp.gmail.com with ESMTPSA id r139sm4022508vkr.20.2020.06.25.22.34.13 for <tls@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jun 2020 22:34:13 -0700 (PDT)
Mime-Version: 1.0
Cc: "TLS@ietf.org" <tls@ietf.org>, network-tokens@ietf.org
X-Superhuman-ID: kbvs5nf6.14a30a07-6e4d-49f3-98ca-1987f2ab8cad
From: Yiannis Yiakoumis <yiannis@selfienetworks.com>
In-Reply-To: <CAKC-DJjRBZujxoLNtNCTe40Gwta9KbdCORVzJ1V54UTGpYP8xQ@mail.gmail.com>
References: <kbsy4785.3cb5b3af-12b1-4d09-9944-6e4e487b103d@we.are.superhuman.com> <CAKC-DJjRBZujxoLNtNCTe40Gwta9KbdCORVzJ1V54UTGpYP8xQ@mail.gmail.com>
Date: Fri, 26 Jun 2020 05:34:12 +0000
Message-ID: <kbvq4fge.5a37719a-ad09-48f8-8694-4c096f9bdc09@we.are.superhuman.com>
To: Erik Nygren <erik+ietf@nygren.org>
X-Mailer: Superhuman Desktop (2020-06-25T22:05:59Z)
X-Superhuman-Draft-ID: draft00ec3fbbfa9578c5
Content-Type: multipart/alternative; boundary="697ccd776629fa39d1abd5761e4417a7ed64bb3b68c0e618b62b017daf11"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/b1skygWTI3ruSmuWZOqmXTjauHA>
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: Fri, 26 Jun 2020 05:34:18 -0000

(cross-posting to network-tokens@ as this is the first related topic - apologies for any duplicates)

Hi Erik,

Thanks for the comments. That's a good point, and wanted to clarify the reasoning around binding fields in general, as well as  binding tokens to IP addresses specifically.

Unlike access and security tokens, network tokens are not protected by a secure TLS connection and can be read by any intermediary node. Therefore, they are open to replay attacks, and unless  used in a fully trusted environment, one should take measures against such attacks. There are two main approaches here:

* Limit a token's lifetime, to make replay attacks hard. The extreme here is to make tokens single use (e.g., through a nonce), and reject tokens with previously seen nonces (within a time window).

* Bind the token to a field that limits the scope it can be used (e.g., a user, a device, a set of exit gateways, etc). The network should be able to separately verify that the token is used within this scope. A binding field can be in an IP address, an IMSI, or any other field the network operator may use to limit the scope of a token.

Note that the binding value matters only at the point of enforcement ( the place where the network checks the scope). It doesn't play any role on the client, the server, or other network nodes.  Moreover, when tokens are encrypted, the binding field itself is not visible to anyone other than the network that issued the token, which should cover privacy concerns.

Two use cases where binding tokens to IP addresses should be fine are i) when users (a home or a mobile subscriber) are assigned a static IP address ( or a DHCP lease that lasts beyond a token's expiration time), and ii) for public IP addresses. Consider the following scenario:

home device → home NAT → operator network (static IP addresses) → operator NAT → Internet .

Despite multiple NATs, the operator can bind the token to the IP address it assigns to the modem and not worry about the downstream and upstream NAT.

As you mentioned, there will be cases where IP binding won't work, either because the endpoint that gets the token doesn't have an assigned IP address, because the enforcement point is behind a NAT, or because of heavy use of proxies etc. In such cases one could bind tokens to a different field, or use short-lived tokens and/or nonces to prevent replay attacks. The overall benefit of binding tokens to certain fields is that they can have a longer lifetime and require less state in the network.

Does this address your concern? Also, any ideas/references on how common it is to have static/long-leased IP addresses in different scenarios (e.g., residential networks and mobile networks)?

Thanks,

Yiannis

On Thu, Jun 25, 2020 at 4:29 PM, Erik Nygren < erik+ietf@nygren.org > 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.
> 
> (Even in IPv6-only, privacy addressing causes problems here.)  Even if you
> have a way to convert tokens over
> 
> for your set of IP addresses (eg, to deal with dual-stack) that still may
> not help enough with NAT environments.
> 
> 
> 
> Erik
> 
> 
> 
> 
> On Thu, Jun 25, 2020 at 4:29 PM Yiannis Yiakoumis < yiannis@ selfienetworks.
> com ( yiannis@selfienetworks.com ) > wrote:
> 
> 
>> Hi all,
>> 
>> 
>> 
>> I wanted to briefly introduce network tokens ( https://networktokens.org )
>> into this list, how they relate with TLS and ESNI, and kindly ask anyone
>> that is interested to share feedback and join the discussion.
>> 
>> 
>> 
>> Network tokens is a method for endpoints to explicitly and securely
>> coordinate with networks about how their traffic is treated. They are
>> inserted by endpoints in existing protocols, interpreted by trusted
>> networks, and may be signed or encrypted to meet security and privacy
>> requirements. Network tokens provide a means for network operators to
>> expose datapath services (such as a zero-rating service, a user-driven QoS
>> service, or a firewall whitelist), and for end users and application
>> providers to access such services. Network tokens are inspired and derived
>> by existing security tokens (like JWT and CWT), borrowing several of their
>> security and privacy properties, and adjusting them for use in a
>> networking context.
>> 
>> 
>> 
>> There are two ways that network tokens relate with TLS:
>> 
>> * They can support ESNI adoption: in a world where ESNI is widely adopted,
>> network tokens can enable use cases where endpoint-network coordination is
>> required, without having to go back to plaintext SNI that everyone can
>> read.
>> 
>> * Network tokens are embedded as TLS handshake extensions (among others).
>> 
>> We are shooting for a BoF in November, and are very much interested into
>> feedback around the concept, use cases, what we need to do to make network
>> tokens adopted as a TLS handshake extension, and folks that are interested
>> to get involved in the effort!
>> 
>> 
>> 
>> Links to an IETF I-D, a mailing list, and initial implementation are
>> available at https:/ / networktokens. org ( https://networktokens.org/ ).
>> 
>> 
>> 
>> Best,
>> 
>> Yiannis
>> 
>> 
>> =====================
>> 
>> Yiannis Yiakoumis
>> Co-Founder & CEO
>> 
>> https:/ / selfienetworks. com ( https://selfienetworks.com ) |
>> +1-650-644-7857
>> 
>> 
>> 
>> _______________________________________________
>> TLS mailing list
>> TLS@ ietf. org ( TLS@ietf.org )
>> https:/ / www. ietf. org/ mailman/ listinfo/ tls (
>> https://www.ietf.org/mailman/listinfo/tls )
> 
> 
>