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

[Martin Thomson <[e-mail]>]

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
>