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

Watson Ladd <watsonbladd@gmail.com> Thu, 30 July 2020 10:57 UTC

Return-Path: <watsonbladd@gmail.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 E45763A110C; Thu, 30 Jul 2020 03:57:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 7bNrle9780LN; Thu, 30 Jul 2020 03:57:11 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 6A0B33A10DB; Thu, 30 Jul 2020 03:57:09 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id 140so14703317lfi.5; Thu, 30 Jul 2020 03:57:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XqehbibD87tab9M90sAvlqecIEYENXR9fGIt55B6cMM=; b=CXC3TNt1Uo/AlgyKV3514mept1fg6XXcoa05UeKBanYPs/UhdZFvInzVbUX4bpuEL5 gMm92KJUcYOlhkq1x6FjuFj0VANwJAtRW59kViv0HXukJk0xrAvyg5NSw/uteLjvvoGC dia4kYES08nsfFylEyx/itLug3lCQejgw4Uh8WveZsOJMn9z7HlQ6p1X45c3W/ABTErB Ie6hsxaReMws60zTR92QXAaiRAjdpj2ZuIb11uCdIlGkyExvXslocswn8xOhCz+n/1/6 pn6DQPbshIJg1Udx/VQWbSoaBMy74j6zpA2aNANaj4tmmNAcctKV6HZq+6KEY+Wxmzur sBvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XqehbibD87tab9M90sAvlqecIEYENXR9fGIt55B6cMM=; b=rjTTxV5e7T9ZxQ8qFq//71573bLeFPZInysqGA4aEf/PzB4K3d1H1PbyDLw2c3ftQZ ss0qQpvZbyk3VOl4SjqxBJ/u/Gqi0M//nz5l1wUSmnZnLqeeIQaITH8+qSDImERXVRl7 aiEZVE1CQMPcPMaBJgN/PIjv+FX+e5ot2zSZslE5LOZLthaoSONbkoDoaWJU7oOfjJ+3 OsHMlWcCSDvPdt8iEJbT/fvbh7upGM28Gsa9OVyv2dh3WL3JO6UN4ukRUTaDJamx9xUf LqbSJ2BOQ5SUkT735dCwBa+B/eL/urCoEeqgxfSRdVBgzL3zOx1FF+0boA5TbG0pekL3 DJOQ==
X-Gm-Message-State: AOAM532dRH6mT4WNMoDy6ddIhpQMSPQdwzVBhKwYgec+RDHfeTOgB7Cc pmQQmJ08wbRJ2SlZ8HdiwFtL9WmKLXA/vvrJE28=
X-Google-Smtp-Source: ABdhPJz4n9lvpJ9Fm+YRh5t6qyHxwY2WTaNqJ5yp3FKgR1++7r7nC2nyZFm6uTjFIz7g/Qmc9ejBMB7R9ZTsdbwsY3I=
X-Received: by 2002:a19:8c9:: with SMTP id 192mr1394753lfi.204.1596106627274; Thu, 30 Jul 2020 03:57:07 -0700 (PDT)
MIME-Version: 1.0
References: <kbsy4785.3cb5b3af-12b1-4d09-9944-6e4e487b103d@we.are.superhuman.com> <CAKC-DJjRBZujxoLNtNCTe40Gwta9KbdCORVzJ1V54UTGpYP8xQ@mail.gmail.com> <87e6e635-d1ec-9f36-41c3-339774f510ca@nomountain.net> <38d4885d-71f0-e69c-e78c-608482036956@huitema.net> <kbwgjics.3e327ce5-1d5c-4ba4-9d8e-ae9cb79f3003@we.are.superhuman.com> <8a6e6520-9f7b-586b-42b4-3b1cab387ccb@huitema.net> <CAHbrMsDfS+oBcJjTQ77r9uAUDESFZ_QhQOz2f=GGsoJVdpcB9A@mail.gmail.com> <kd7z5bh8.4b00046a-77e4-4d6d-b6e6-60fbbd78dfe7@we.are.superhuman.com>
In-Reply-To: <kd7z5bh8.4b00046a-77e4-4d6d-b6e6-60fbbd78dfe7@we.are.superhuman.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Thu, 30 Jul 2020 06:56:52 -0400
Message-ID: <CACsn0ckLi4Y8U5wy2StttZjkh92+HqM0FBsyPjXK5LtWHkoPtA@mail.gmail.com>
To: Yiannis Yiakoumis <yiannis@selfienetworks.com>
Cc: Ben Schwartz <bemasc@google.com>, network-tokens@ietf.org, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008ada9505aba68864"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8owl6e8zW1G4VrshJg0mKanIkF8>
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: Thu, 30 Jul 2020 10:57:18 -0000

On Wed, Jul 29, 2020, 7:51 PM Yiannis Yiakoumis <yiannis@selfienetworks.com>
wrote:

> Hi Ben,
>
> Thanks for your comments. Please find some responses inline.
>
> On Wed, Jul 29, 2020 at 1:48 PM, Ben Schwartz <bemasc@google.com> 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.
>

Aren't network operators the ones interpreting these tokens? Aren't
application developers integrating these? Don't they use sockets? BSD
sockets is the API for BSD sockets.

IPv4 shouldn't be a consideration for a greenfield enhancement imho.


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

Internet is end to end and layered for a reason. The economics of
middleboxes make upgrades far slower than client and server. Even with
visibility and negotiation the problems of middleboxes remain.


> Does the group have any sense on the impact of existing DPI-based services
> on adoption of new ideas on TLS?
>

TLS 1.3 is filled with kluges to make it look like TLS 1.2 to middleboxes.

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

If you want per-flow instead of per-packet processing of priorities you can
look at the header on the first packet of a flow and copy on the rest. Flow
based does have challenges scaling, but if your hardware can't look into
extension headers this could work.


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

If tokens are per application vs. used as a tracking vector. The set of
applications people use is identifying.

I don't think pointing at a bigger leak elsewhere is a good justification
for making another hole in the boat.

>
> 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 <huitema@huitema.net>
>> 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>
>>> 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
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>