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

[Yiannis Yiakoumis <[e-mail]>]

Hi everyone,

Just a quick follow-up that there will be the following talks on Wednesday and Thursday around network tokens.

* 

July 29 , 1:00-1:50pm UTC: TSV Open Meeting

* 

July 30 , 12:30pm-2:00pm UTC: APN Side Meeting

* 

July 30 , 4pm-5pm UTC: Network Tokens Side Meeting (details available here) ( https://github.com/Network-Tokens/network-tokens-rfc/wiki/IETF-108---Network-Tokens-Side-Meeting )

Best,

Yiannis

On Fri, Jun 26, 2020 at 10:42 AM, Christian Huitema < [e-mail] > wrote:

> 
> On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote:
> 
> 
>> 
>> 
>> 
>> 
>> 
>> On Fri, Jun 26 , 2020 at 7:29 AM, Christian Huitema < huitema@ huitema. net
>> ( [e-mail] ) > 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
> 
> 
> 
>