On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema < huit...@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?
>
>
>
> 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.
>
>
>
> -- Christian Huitema
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ ietf. org ( TLS@ietf.org )
> https:/ / www. ietf. org/ mailman/ listinfo/ tls (
> https://www.ietf.org/mailman/listinfo/tls )
>
>
>_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
