[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: Re: [TLS] Network Tokens I-D and TLS / ESNI
From: Christian Huitema <huitema () huitema ! net>
Date: 2020-06-26 17:42:36
Message-ID: 8a6e6520-9f7b-586b-42b4-3b1cab387ccb () huitema ! net
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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, 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
[Attachment #5 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 6/26/2020 10:16 AM, Yiannis
Yiakoumis wrote:<br>
</div>
<blockquote type="cite"
cite="mid:kbwgjics.3e327ce5-1d5c-4ba4-9d8e-ae9cb79f3003@we.are.superhuman.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div>
<div>
<div style="display: none; border: 0px; width: 0px; height:
0px; overflow: hidden; visibility: hidden;"><img
src="https://r.superhuman.com/QGNzsNycXV-SVAjZuLFvqxCT43SJN6nOhZjQiS2l9pcwOa7HOo2AIV4W \
Z_GnPfj2XmtkaobTWThSrYOSwWzj9RttBgAmYeq35nAzgveY3EsqOup4AQ2r7ezxGCDMmXaW_2vBysmCLR6PxBAv4C6PVFAkeE-ETBTiwlL9rQh6UratLAeWbjmI.gif"
alt=" " style="display: none; border: 0px; width: 0px;
height: 0px; overflow: hidden; visibility: hidden;"
moz-do-not-send="true" width="1" height="0"><!-- \
--></div> <div>
<div class="">
<div class="">
<div class="">
<div class=""><br>
</div>
</div>
<div class="gmail_signature"><br>
</div>
</div>
<br>
<div class="">
<div class="gmail_quote">On Fri, Jun 26, 2020 at 7:29
AM, Christian Huitema <span dir="ltr" class=""><<a
href="mailto:huitema@huitema.net" target="_blank"
moz-do-not-send="true">huitema@huitema.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_extra">
<div class="gmail_quote" style="null" id="null">
<p class="">On 6/25/2020 11:11 PM, Melinda Shore
wrote:
<br>
</p>
<blockquote class="">
<p class="">
On 6/25/20 3:29 PM, Erik Nygren wrote:
<br>
</p>
<blockquote class="">
<p class="">
One quick comment is that binding tokens
to IP addresses is strongly
counter-recommended.
<br>
It doesn't survive NATs or proxies,
mobility, and it is especially
problematic in IPv6+IPv4 dual-stack
environments.
</p>
</blockquote>
<p class="">
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").
<br>
</p>
</blockquote>
<p class="">
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.
<br>
</p>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<div class="">
<div class=""><br>
</div>
</div>
<div class="">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?<br>
</div>
</div>
</div>
</div>
</blockquote>
<p>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.<br>
</p>
<blockquote type="cite"
cite="mid:kbwgjics.3e327ce5-1d5c-4ba4-9d8e-ae9cb79f3003@we.are.superhuman.com">
<div>
<div>
<div>
<div class="">
<div class=""><br>
</div>
</div>
<div class="">
<div class="">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_extra">
<div class="gmail_quote" style="null" id="null">
<p class="">
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.
<br>
</p>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<div>
<div><br>
</div>
<div>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. <br>
</div>
<div><br>
</div>
</div>
<div class="">
<div class="">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_extra">
<div class="gmail_quote" style="null" id="null">
<p class="">
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.
<br>
</p>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<div>
<div><br>
</div>
<div>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. <br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p>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.<br>
</p>
<p>-- Christian Huitema<br>
</p>
</body>
</html>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic