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

[Christian Huitema <[e-mail]>]

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.

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.

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.

-- Christian Huitema