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

Tom Herbert <tom@herbertland.com> Thu, 09 July 2020 22:46 UTC

Return-Path: <tom@herbertland.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 096EB3A0959 for <network-tokens@ietfa.amsl.com>; Thu, 9 Jul 2020 15:46:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=herbertland-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 CKAvl8Z7-YHu for <network-tokens@ietfa.amsl.com>; Thu, 9 Jul 2020 15:46:57 -0700 (PDT)
Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com [IPv6:2a00:1450:4864:20::644]) (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 747A83A0958 for <network-tokens@ietf.org>; Thu, 9 Jul 2020 15:46:57 -0700 (PDT)
Received: by mail-ej1-x644.google.com with SMTP id dp18so3952709ejc.8 for <network-tokens@ietf.org>; Thu, 09 Jul 2020 15:46:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=1MTNIzErPKk5w3a7Xjez8WD0yVeQHyEQLKqIr9Aub8A=; b=w6+BCKKInRhLq+2GouRWqe4pNp2xC/NmrCRj83DY1NAhQwpF6VKYQ+sWqAZ8Aujjjw Hm/omGpNlQq/Ol3xnVMUqkvuGeHu/78agxWZLTwjEJcGGCaZBEZbZj75r3UG1BskaoGO GX763sB+tFsjW1wa8mt8p7mpzgOnubxoU2IzjQ7+v6h9CQ6kA7I6gYIapjKHFddk9KZV aWH1ppgLpU2VsgqfvXQnx4A1TlCyboJK/kgvhR5HtW5w9sKCd4aqR6BtzfYpa+zTbu+G Tbxcs3zdH2dEcgpulFh6g3UeAgLqkdPKmdNXNkmv5Pt0FBZwn0fdxfnr6DH7848jJcP3 6QtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1MTNIzErPKk5w3a7Xjez8WD0yVeQHyEQLKqIr9Aub8A=; b=LZFT54RuJAQMbYQfH6VZOXgzoswbYNOTSIsKmobK2ugabncCutKEawFCl4vHP7msE9 EHukxfz2tdBMC4bs0uTypD/UKjPwFVfYwjVEgb4LUTpKGPfTCfHXkMbbL8JwHfqPQr76 Gs89SRvGK/yU1lrJaXV3HlYuSffhI/UUiNZZdNSfVenPmMy3xShI2ZOqdQfdgdm5JX5r QcThm1CR2dLIiI6RaqgYn17K8vG5zPnH6r2xjSGyDtW3pTFfrw6G1o1trTJ0mwrpTPZw +h/9nh9qskpHnCOqKFTDFoCBd33Hj6FoKBlzb/PQ2SYTf5WMlpea62xG03tNOIFlaByt m1XA==
X-Gm-Message-State: AOAM533pjAw8Pcr4jg1vV/DeA71g0Cho4V2QrfLZw5Vj8umK4Uy7GcGE GsugTL/Vybswsxl4fPbg4C6IXgRXHBhZN3x/bSKqNRy8eHI=
X-Google-Smtp-Source: ABdhPJxx1s0fpS7NMo9zhpG4QFY6ZQNtlELbttpvujTJOZnF7RmH+Jt1uN43Zmrc8XXr4nQLbi4ZVnKSSo8gKgsT4+M=
X-Received: by 2002:a17:906:95d6:: with SMTP id n22mr58658277ejy.138.1594334815451; Thu, 09 Jul 2020 15:46:55 -0700 (PDT)
MIME-Version: 1.0
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 9 Jul 2020 15:46:44 -0700
Message-ID: <CALx6S34gnn-3SqQ6DCUw5DbVit3AwRJjw-Kq-K7DSQOaG+Reqw@mail.gmail.com>
To: network-tokens@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/network-tokens/tYFwNxAEa5CjNWav_y2B7MIf9g8>
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, 09 Jul 2020 22:46:59 -0000

> On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote:
> >
> >
> >
> > On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema
> > <huitema@huitema.net <mailto: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, thre 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.
>
I view the use of TLS to carry tokens as a temporary hack to make
something work quickly. There are several obvious problems that
prevent that from being the general solution: it's specific to
TLS/TCP, it requires intermediate nodes to parse into TCP payloads, it
requires tracking connection state in the network.

IMO, the real solution is to encode tokens in HBH options. This
addresses the aforementioned problems, works with any transport
protocol (including QUIC, IPsec tunnels, arbitrary encapsulations),
eliminates state and need for DPI in the network.

Of course the naysayers will bring up the fact that HBH options aren't
ubiquitously supported by routers. I think there are some ways around
this:
   1) Network tokens really only make sense to the network that issued
them, so their use could be restricted to that limited domain where
they are consumed.
   2) Packets that are leaving the limited domain that carry network
tokens in HBH options could be filtered and the HBH option is removed
(see proposal draft-herbert-6man-eh-attrib-01 to allow intermediate
nodes to remove options).

Limiting the visibility of tokens to the local network also helps
their security.

Tom