RE: Privacy holes (was: Re: Getting to consensus on packet number encryption)

[Mike Bishop <[e-mail]>]

+1.  There are too many sharp corners on trying to make migration look like 0-RTT, while still enabling the recipient to know which Initial/0-RTT packets are really Initial/0-RTT with consistency.

-----Original Message-----
From: QUIC [mailto:[e-mail]] On Behalf Of Martin Thomson
Sent: Thursday, April 12, 2018 6:09 PM
To: Kazuho Oku <[e-mail]>
Cc: Praveen Balasubramanian <pravb=[e-mail]>; IETF QUIC WG <[e-mail]>; Ian Swett <ianswett=[e-mail]>
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)

This is also my preference, in full realization of the downsides of that.  Trying to make migration look like a handshake is also really hard to get right.

On Fri, Apr 13, 2018 at 10:32 AM, Kazuho Oku <[e-mail]> wrote:
> 2018-04-13 8:36 GMT+09:00 Ian Swett <ianswett=[e-mail]>:
>> Yes, for a powerful adversary, this seems fairly tractable..
>>
>> Making connection migration look like a new connection would likely 
>> help a lot.
>
> I am not sure if that is the right path.
>
> We have three ways in which a new set of 5-tuple starts getting used.
>
> * new connection
> * voluntary migration
> * involuntary migration (i.e. NAT rebinding)
>
> For the involuntary migration case, the first packet will always be a 
> short header packet.
>
> If we make voluntary migration look like a new connection, the chance 
> of involuntary migration getting blocked by a middlebox becomes higher 
> (as we have seen gateways blocking the TLS 1.3 records, or the '07'
> case).
>
> Therefore, my preference goes to making all the three cases 
> indistinguishable (which is ideal but hard), or keeping voluntary and 
> non-voluntary migration look the same (as we do now) at the same time 
> making sure that the middlebox developers understand migration happens 
> [1].
>
> [1] https://www.ietf.org/mail-archive/web/quic/current/msg03820.html
>
>> On Wed, Apr 11, 2018 at 3:18 PM Praveen Balasubramanian 
>> <pravb=[e-mail]> wrote:
>>>
>>> Going back to Christian's original question on privacy holes, there 
>>> is an attack for linking IP addresses in the voluntary migration case.
>>>
>>> Let's consider the parking lot problem or in general case losing one 
>>> network and roaming to another network. This is the primary use case 
>>> for connection migration. In this case all active QUIC connections 
>>> that can migrate, will do so. When these connections migrate they 
>>> can change the CID, the local port number and packet numbers. 
>>> However do notice that only the local 2-tuple changes for each 
>>> connection, the server's 2-tuple remains the same.
>>>
>>> Let's assume a powerful adversary can collect a network sniff of all 
>>> this traffic and builds a massive dataset. The adversary can then 
>>> run a machine learning algorithm to identify time instants where a 
>>> bunch of connections change their local 2-tuple at near the same 
>>> time instant but continue going to the same server side 2-tuples. 
>>> This will allow the adversary to link two IP addresses. The more 
>>> times the user roams between networks back and forth the richer the 
>>> correlation. The more open connections to different servers, the 
>>> richer the correlation. Geolocation information can minimize the number of addresses the adversary needs to correlate.
>>>
>>> The fundamental problem seems to be that the substrate is UDP/IP and 
>>> it is in the clear and allows linkability.
>>>
>>> -----Original Message-----
>>> From: QUIC [mailto:[e-mail]] On Behalf Of Christian 
>>> Huitema
>>> Sent: Thursday, April 5, 2018 8:34 AM
>>> To: Mirja Kühlewind <[e-mail]>
>>> Cc: [e-mail]
>>> Subject: Privacy holes (was: Re: Getting to consensus on packet 
>>> number
>>> encryption)
>>>
>>>
>>>
>>> > On Apr 5, 2018, at 2:26 AM, Mirja Kühlewind 
>>> > <[e-mail]..ethz.ch> wrote:
>>> > ...
>>> > Timing doesn’t help here either because you still have the same 
>>> > destination IP, both port numbers and the fact that a migrated 
>>> > connection does not have a handshake. If we want to address the 
>>> > linkability problem, we would need to do much more, probably baring more hits on performance.
>>>
>>> Mirja,
>>>
>>> You rightly point out that the connection ID and the Packet Number 
>>> are not the only elements that provide linkability. There is also of 
>>> course the UDP source port. That one is not much of an issue for 
>>> servers, but it is an issue for clients. We are not spelling that 
>>> out in the draft. We should, because clients can trivially close that hole when doing migration.
>>>
>>> I am not sure that the absence of negotiation divulges much data. It 
>>> marks the path as originating from a migration, but it does not tell from where.
>>> But there might be an ossification issue. We will get that 
>>> ossification if we train middleboxes to believe that connection 
>>> always start with an observable negotiation. So maybe we should explore ways to grease that.
>>>
>>> Any other privacy hole that we should fix?
>>>
>>> -- Christian Huitema
>
>
>
> --
> Kazuho Oku
>