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 < huit...@huitema.net >
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
>> ( 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?
>>
>>
>
>
>
> 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
>
>
>
>_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
