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

[Ian Swett <[e-mail]>]

Yes, for a powerful adversary, this seems fairly tractable.

Making connection migration look like a new connection would likely help a
lot.

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]> 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
>