Return-Path: 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 0A5CC3A09B3 for ; Fri, 26 Jun 2020 10:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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_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=selfienetworks-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 ALKHbasFnwjo for ; Fri, 26 Jun 2020 10:16:30 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 00EB63A0977 for ; Fri, 26 Jun 2020 10:16:29 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id l24so3250873uar.10 for ; Fri, 26 Jun 2020 10:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfienetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:from:message-id:subject:to:cc:references :date; bh=7q2PivCoc4ZCIXMQnN4gaVu7Xi51O1PS89Xhvmjm9Nk=; b=PwhcZNKi1NW2ofu1BVrkbmYxuQONOTf3CmaqPPOd35WsAKSJ+RPUu1h9zFqrCOH6DT DoMX5mgOnTdUVxU+OlMr3fWHXT5AS+7HCUXCOxmisywoHkz4n/GCPgY1x7O8NTpPfRa0 OxCy/xO7gKrBr8DK63xoMKS5lGTmZGxSMMDoFSqgsGc7e7YT0LqAe2zdml87GiMAS/Hh M15CJJx6m6IApBLkeHpzygTvDRd8w6V+JN2iTP7wTzUPPGBxxmgdF30B4OUNLGlf8htg bqAKXwVtnCpuynvJd/1mvLGH2dHcWMCTQPp3YIwVpFAj3zoO8DOMxxOYGl4Qzf2j7Tv0 HGNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:from:message-id:subject :to:cc:references:date; bh=7q2PivCoc4ZCIXMQnN4gaVu7Xi51O1PS89Xhvmjm9Nk=; b=m9qBEx+80D1YiO3qhh4uNNCrzWd3+EZZ1w/qbvwaWSVXFaFYmFIomgD44+29XCMq+6 hw7eh8Id56aQPJnWwe3VVYgwlsvIjpe4g2sUTiR4cpzjmCimEznWV7P5nRqBybvPd/5V oIqdorV+/HWOmOf9zjtHMEBsl8XewUdtgtbHFFl9FsTP30yugq6GjDw3wcPZFVDLy6r0 FJ3xvrVfn0i2QACaQs2ibX1CQP3iW15/HUPULIKTxdL5iM/IoOgpB7wPlG2FOgltOnpm lJ5nb9b2Lm6t+dvvckrYH7Q+kDBl3qPq8CEakia2Kcch/xoSp9me93O0JcCaOh4aRNzJ wwgw== X-Gm-Message-State: AOAM531UTCsR0GeH0wlc9KFII9GWo6NsaRALL9BbkMEPL6Jov9zrV0zw da+zIUJcy8X33ecgcza1unzE8ATOeOo= X-Google-Smtp-Source: ABdhPJwQu1mzVJ24FPJX2zpZV/NC5DSo7IHL+tjOiLUFLKCd+ARO9ITVsMNrpm6Tt5tNN4LuNJHWIw== X-Received: by 2002:ab0:2695:: with SMTP id t21mr3020117uao.4.1593191788312; Fri, 26 Jun 2020 10:16:28 -0700 (PDT) Received: from localhost (0.92.231.35.bc.googleusercontent.com. [35.231.92.0]) by smtp.gmail.com with ESMTPSA id u22sm1666390vkb.19.2020.06.26.10.16.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Jun 2020 10:16:28 -0700 (PDT) Mime-Version: 1.0 X-Superhuman-ID: kbwh8pia.73cdffc6-52b8-4b57-87fa-a557c932d008 In-Reply-To: <38d4885d-71f0-e69c-e78c-608482036956@huitema.net> From: "Yiannis Yiakoumis" Message-ID: To: "Christian Huitema" Cc: "Melinda Shore" , tls@ietf.org, network-tokens@ietf.org X-Mailer: Superhuman Desktop (2020-06-25T22:05:59Z) X-Superhuman-Draft-ID: draft00707e25cb964aab References: <87e6e635-d1ec-9f36-41c3-339774f510ca@nomountain.net> <38d4885d-71f0-e69c-e78c-608482036956@huitema.net> Date: Fri, 26 Jun 2020 17:16:25 +0000 Content-Type: multipart/alternative; boundary=85299a4e6af11a79b92c42f11ed8b5cf4aeb6776b9d92be92b084c8cb9e8 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 17:16:32 -0000 --85299a4e6af11a79b92c42f11ed8b5cf4aeb6776b9d92be92b084c8cb9e8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema < huitema@huitema.net > = wrote: >=20 >=20 >=20 > On 6/25/2020 11:11 PM, Melinda Shore wrote: >=20 >=20 >=20 >>=20 >>=20 >> On 6/25/20 3:29 PM, Erik Nygren wrote: >>=20 >>=20 >>=20 >>>=20 >>>=20 >>> 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. >>>=20 >>>=20 >>=20 >>=20 >>=20 >> 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"). >>=20 >>=20 >>=20 >=20 >=20 >=20 > 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. >=20 >=20 >=20 >=20 You are right that for the duration of a token, one could use it to identif= y an endpoint (either application or most likely a combination of user/appl= ication). Tokens expire and intermediary nodes cannot correlate tokens with= each other as they are encrypted. So tracking cannot happen across differe= nt tokens (of the same user), or between token-enabled and non-token-enable= d traffic. I guess similar type of tracking happens when users are not behi= nd a NAT and their IP address can be used to track them. Would it make sens= e 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 t= racked. Would that address the privacy concerns better? >=20 >=20 >=20 > 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. >=20 >=20 >=20 >=20 Ah, I was not aware that ESNI can now include all CH extensions - thanks fo= r the pointer. Yes, the token would have to stay on the outer envelope so t= he 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 in= formation with trusted networks. >=20 >=20 >=20 > 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. >=20 >=20 >=20 >=20 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. >=20 >=20 >=20 > -- Christian Huitema >=20 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ ietf. org ( TLS@ietf.org ) > https:/ / www. ietf. org/ mailman/ listinfo/ tls ( > https://www.ietf.org/mailman/listinfo/tls ) >=20 >=20 > --85299a4e6af11a79b92c42f11ed8b5cf4aeb6776b9d92be92b084c8cb9e8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
3D"


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 durati= on of a token, one could use it to identify an endpoint (either application= or most likely a combination of user/application). Tokens expire and inter= mediary 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 o= f 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 v= alue 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 th= e privacy concerns better?

<= /div>

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.


<= div class=3D"">

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.


--85299a4e6af11a79b92c42f11ed8b5cf4aeb6776b9d92be92b084c8cb9e8--