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

Tom Herbert <> Thu, 30 July 2020 01:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B82873A0B5E for <>; Wed, 29 Jul 2020 18:28:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EY1ONAKQgTpi for <>; Wed, 29 Jul 2020 18:28:29 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 605D13A0B5F for <>; Wed, 29 Jul 2020 18:28:29 -0700 (PDT)
Received: by with SMTP id d6so12432055ejr.5 for <>; Wed, 29 Jul 2020 18:28:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E0p+/Gk7i/fUaA88vEGTbXJfQg2zTw+rI7hcWjOtywA=; b=bklpAqRBQnGfK/OXHJgSbueVmOC37nnAWWvItW1a81TRykYo2RPnpUKJ3qvG0s/CUY vxzYWOnysVqhGc74ax4YHfhqr+EwcdHUA5yxiQEfmma+syvUZvKlNYwJ9Lj+yC/+aQHh KNqmQ3JuwpUuieSwHQef1V5Qij88pD3gEkSFA7qWngDU2PQzXUXia9wkZUYH2WsOgwSU gR+dnUqtrjBQxzF9o/0nDOk1IPQPjXqb/EwS3SmmkHmRQSQtJAB6FzFCIHg1QQwuEsv+ z/X4LvJ6/g3b9k+gJ+Gmfs94G3IXYgNTeaIRpS2lrnfuQSdDwFkS9wpQCnnweibTeJEi 4kiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E0p+/Gk7i/fUaA88vEGTbXJfQg2zTw+rI7hcWjOtywA=; b=WbcYHvOr/V9MYWr+AfFtjbCOVjBf4Qm+uLomFI7bIWrdGx3ESPvUX+3TDQ7Jk1d59s l+8dFxSt71sfoIyimndbSR+JFvAeF1lBcN/q9D4NbB6MRH+IV8zkceihStdRJygMaeHq aWl5CgJ9J5cvvmPdvj9yEms87b+7LV2fSmmj5j8mu+PyMLLvtWeew7vfmtn09v32rZhy 7Bhqo7PFQiWY1M3VvEGT140OD2Vju7g5WkIfBW0vKBFSZ1EiGr8vN6YhalAbp8FKtPi6 8Cizx6s1ctxQHvBeWuV+rFsemifrTYbEh/gzKYoUnarc1UCqEOY2KESetZHw7bJ/hdfc T8Fg==
X-Gm-Message-State: AOAM530gzaLDbmozaoNQgisv6QncDW73eTe+lI3Esz67VPJkTb+BTaFK 9zOA2mwpEG9tijvqyfwwVI6IW13INicNfMxjTcPuqg==
X-Google-Smtp-Source: ABdhPJxGXyMPv16A7zLMbuGX9ol6NtmuYaAh2tPvZ6K97xEwLPv6tFOKty1oe2zXDIdYztQ+mgKFt1/mxOV3irlqbgY=
X-Received: by 2002:a17:906:b146:: with SMTP id bt6mr363662ejb.138.1596072507747; Wed, 29 Jul 2020 18:28:27 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Wed, 29 Jul 2020 18:28:16 -0700
Message-ID: <>
To: Yiannis Yiakoumis <>
Cc: Ben Schwartz <>, Christian Huitema <>,, "<>" <>
Content-Type: multipart/alternative; boundary="000000000000dc41fc05ab9e969d"
Archived-At: <>
Subject: Re: [TLS] [Network-tokens] Network Tokens I-D and TLS / ESNI
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Jul 2020 01:28:33 -0000

On Wed, Jul 29, 2020 at 4:51 PM Yiannis Yiakoumis <> wrote:

> Hi Ben,
> Thanks for your comments. Please find some responses inline.
> On Wed, Jul 29, 2020 at 1:48 PM, Ben Schwartz <> wrote:
>> This proposal is highly ossifying.  Application protocols that are
>> included in this scheme become very difficult to update.  For example, in
>> the case of zero-rating, this proposal would only be able to zero-rate
>> application protocols that are understood by the network's token-parsing
>> appliance.  This seems likely to have serious negative consequences for
>> protocol innovation, as these applications would no longer be able to
>> implement novel protocols without losing whatever advantage the network
>> token offers.  For TLS, this proposal would ossify the extension format,
>> which could no longer evolve in future TLS versions without risking loss of
>> network services.
> In an ideal world, everything beyond IP would be encrypted and opaque to
> the network, and network tokens would be embedded in IPv6 extension
> headers. In practice, this has several (well-known) issues, here is my take
> on the trade-offs:
> Tokens as IPv6 extension headers have the benefit that they are applicable
> to all traffic/applications, and could potentially be enforced by the
> network in a stateless, per-packet manner. The problems are that i) IPv6
> extension headers are often dropped by network operators, ii) there are no
> good APIs to expose L3 socket APIs to the app developers who would
> eventually acquire and insert tokens, and iii) it doesn't work with IPv4.
> Tokens as TLS extensions address the major shortcomings for IPv6, i.e.,
> they have integrity protection so they cannot be dropped by intermediary
> nodes, they are closer to the app developer and can therefore expose APIs
> for them to add/remove tokens, and iii) they work across both IPv4 and
> IPv6. Obviously, they will support only the specific type of transport
> which limits the scope.
> A major drawback of using TLS for this is that it requires the network to
maintain per flow state.

> Specifically on your comment about protocol innovation, and using ESNI as
> an example: my understanding, is that dependency on existing network
> services will be an issue for ESNI adoption, and I agree that this is
> frustrating. I will counter argue though, that the problem is not that the
> network appliance doesn't adopt to a new format or novel protocol, but
> rather that there is no protocol and means in place for endpoints to
> explicitly coordinate with the network. In that sense, having a thin
> mechanism to do this coordination can accelerate innovation in all other
> aspects.
> Does the group have any sense on the impact of existing DPI-based services
> on adoption of new ideas on TLS?
> Also note that something like network tokens would be implemented in
> programmable hardware and/or software, and in principle should be much
> quicker to adopt to format changes comparing to fixed-silicon appliances.
> The proposal also violates the TLS Protocol Invariants, by attempting to
>> process the ServerHello after forwarding an arbitrary ClientHello.
> Not sure I understand this. Can you explain what you mean by arbitrary
> ClientHello, or point me to the related TLS section?
> It would also fail for QUIC, as previously noted, due to QUIC's mobility
>> support, which is important for performance on mobile devices.
> Not very familiar with QUIC, will have to read on this.
> Additionally, storing this information in the TLS handshake causes an
>> unnecessary privacy loss: it forces the token to be visible across the
>> whole internet, even though it is only relevant on the near-client network
>> segment.
> The token is not necessarily relevant only to the near-client network
> segment. For example, in a zero-rating scenario where the token comes from
> the server, there are intermediary networks that are not relevant for
> charging.
> Even if the token is entirely opaque, a pervasive surveillance adversary
>> could distinguish between connections with and without tokens, likely
>> differentiating certain applications from others.
> You can already infer use of applications just by using IP addresses.
> Also, the amount of information you can extract from the presence of tokens
> decreases rapidly with the number of users that participate in them.
> I recommend that the authors focus on the draft's proposal to use an IPv6
>> extension header, and remove the other proposed encapsulations.  Also,
>> please remove the specific extension number from Section 7.1 unless and
>> until IANA has allocated a number.  For testing, you should use a value
>> from the Private Use range, 65282-65535.
> OK - I'll pick one from them private range - thanks.
> Best,
> Yiannis
> On Fri, Jun 26, 2020 at 1:43 PM Christian Huitema <>
>> wrote:
>>> On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote:
>>> On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema <>
>>> 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
>>> _______________________________________________
>>> TLS mailing list
> --
> Network-tokens mailing list