Re: [Network-tokens] [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: 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 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/network-tokens/Fv45JsbfEGH9on8Eo7KH5_hwwLk>
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, 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 >
- 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