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

Ben Schwartz <bemasc@google.com> Wed, 29 July 2020 20:48 UTC

Return-Path: <bemasc@google.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 499B53A0EF6 for <tls@ietfa.amsl.com>; Wed, 29 Jul 2020 13:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 y2sw7W-yxjN0 for <tls@ietfa.amsl.com>; Wed, 29 Jul 2020 13:48:47 -0700 (PDT)
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 047703A0EF4 for <tls@ietf.org>; Wed, 29 Jul 2020 13:48:46 -0700 (PDT)
Received: by mail-wm1-x342.google.com with SMTP id x5so3890027wmi.2 for <tls@ietf.org>; Wed, 29 Jul 2020 13:48:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wJLCC986mqxFrzxfQzNf2bmedeaqCnA7UEbeUV3GmfQ=; b=efDGx4OKUD6YuArYBssgpJxnig2zGvHRH3blQtqQvv+2RkroVJI20pJRcsMFeLZcTA regPl2wXZjIxzcjRW5DuG4MnvBthBsowFUArKbYGg4IN2RKA8wIH3avy/XjlodicA9x7 jOwUMzRv7j1G9MrToVcbA/rNxajJT4JP/mf68nM60fDH1rFzVZVs0MbXv82c6iyC27X1 ZO6+pGYVV8AE8ILQhCb755RoQFG7xI/fwfPIMGxXSdUis82+2skIC135/DGgvwW7CQew PPQweLaJvARMGevqOcMayV/gquoKUuamBEGjgnVpLmIVzFxXwkJgeChkdcJS1bgKLSrB CIEQ==
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=wJLCC986mqxFrzxfQzNf2bmedeaqCnA7UEbeUV3GmfQ=; b=pMFfb4cWql5ZgpHP4AZXPwfE6dBYu4a+IjEXy/hU4ZshiE/luXXo3Umpaq15v1ZZE4 nfZu4q7Ub0GH8Va3QLDCzSo0MJZABEivINT++VDkXGM85BDmPg9/Tv23TJcSLpnky1El z0t7+YURSfxqyNbVTHB0hN01uSR4yrI2EEf+Hte1w4C7t0xgaFx5QlaLJ6FRElSZcSvP M0t5A1ZGYwM23wyNJZR643vUmq6wTtWWh8Y2Z+XcTH3rY2zswborEOyVNsCk1LMq/sOe 8R9FwVR3RJt+g2yL/4i58mwnCX72ql4drD2ndqfvrYkfFRPOhgNLETInQBZbNI9jNsYl eJig==
X-Gm-Message-State: AOAM530um5lPi49oekk1JumoGWbFC+3L3ysufK33eWG7tA+LVz5c/TOz gh7dRWbAczLtJVtMtz/cnNH/i31/6uGufkpaHPzHyHukW4k=
X-Google-Smtp-Source: ABdhPJwJy+hKA8gdW946ft46MRwQtnEK42QssB4DGLaWjE2u4wxCfD2BRE3lDE13atEh9oDrvRc1FX+aK8YSN7EyVOI=
X-Received: by 2002:a1c:4183:: with SMTP id o125mr10216871wma.101.1596055725154; Wed, 29 Jul 2020 13:48:45 -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>
In-Reply-To: <8a6e6520-9f7b-586b-42b4-3b1cab387ccb@huitema.net>
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 29 Jul 2020 16:48:33 -0400
Message-ID: <CAHbrMsDfS+oBcJjTQ77r9uAUDESFZ_QhQOz2f=GGsoJVdpcB9A@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: Yiannis Yiakoumis <yiannis@selfienetworks.com>, network-tokens@ietf.org, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000092a11305ab9aae93"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ME3LCJUgvFR3kEySMOwyoKDZT2s>
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: Wed, 29 Jul 2020 20:48:52 -0000

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.  The proposal also violates the TLS Protocol Invariants,
by attempting to process the ServerHello after forwarding an arbitrary
ClientHello.  It would also fail for QUIC, as previously noted, due to
QUIC's mobility support, which is important for performance on mobile
devices.

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

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.

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
>