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

[Kazuho Oku <[e-mail]>]

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