[quicwg/base-drafts] Neccessity and viability of hidden connection migration linkage (#990)

MikkelFJ <notifications@github.com> Tue, 05 December 2017 19:54 UTC

Return-Path: <bounces+848413-a050-quic-issues=ietf.org@sgmail.github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096691270A7 for <quic-issues@ietfa.amsl.com>; Tue, 5 Dec 2017 11:54:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.019
X-Spam-Level:
X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zV90zxvzrDk6 for <quic-issues@ietfa.amsl.com>; Tue, 5 Dec 2017 11:54:24 -0800 (PST)
Received: from o7.sgmail.github.com (o7.sgmail.github.com [167.89.101.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C3112025C for <quic-issues@ietf.org>; Tue, 5 Dec 2017 11:54:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=sO8CxpirWn/tQOOJOPHCM1VTIAE=; b=oBSc7gMPrnPicLN9 bDrjWQV0tZ3ONOAKSYt1rCkDNY10yxi3zXk8oDuYiUUQ2thaNE4vdYn5CETa3BYn +adisa6aU+Ft+wyFDkuWRtAMOGoL6GSyJ0nFebSpWSJiWyuDShqHd79vzY/XeDmf gfjvnsNoRzIWijmvj4QRvCTyjQg=
Received: by filter1106p1mdw1.sendgrid.net with SMTP id filter1106p1mdw1-23325-5A26F96D-11 2017-12-05 19:54:21.324467129 +0000 UTC
Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2b-ext-cp1-prd.iad.github.net [192.30.253.17]) by ismtpd0024p1iad2.sendgrid.net (SG) with ESMTP id 0Anoy454Qwabl5tC8j5abA for <quic-issues@ietf.org>; Tue, 05 Dec 2017 19:54:21.125 +0000 (UTC)
Date: Tue, 05 Dec 2017 19:54:21 +0000
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab8b3105e2542966014a19a61e73615d812d55196592cf00000001163ebb6d92a169ce10a8f624@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/990@github.com>
Subject: [quicwg/base-drafts] Neccessity and viability of hidden connection migration linkage (#990)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5a26f96d1cac6_5ff83f8e896c6f2c21593d"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak1ykUZcZHTjvJrO/cy0Q0QneZ9AAGURY9jjjy 46uRJltlyerztF/uxPNuLnL4uS3cSTYlj5GeP3Uis5z7PtogNQI0C/CynyvNLPrD/CU/EEK5ZgUK+K Y1tJgPGIa5enIlLPyXdxYc+WyyXvNa9vP0OMOzqtzDWfE1QUsiCCRS5+tk7ee/t+kW+4dXszD1goD7 4=
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/Q1jzJXBJ_MU2ENNQMsLJD08borQ>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Dec 2017 19:54:26 -0000

If it is desirable to break linkage between connections during path migration then the current approach of skipping random 2^32 packet numbers is likely insufficient.

An oberserver can easily detect decrease in traffic on one connection and a sudden new packet sequence that is higher at some offset. Depending on how many packets have been sent, the migration might just look like a new connection, or it might fall in a higher packet range indicating a migratin with some propability.

If packet numbers are reset upon migration with a new random number in the range 0..2^32 (ca.) such linkage is more limited. The argument goes both ways - resetting adds complexity, and it might not solve the problem:

The silence of one connection and the activity of a new connection could suggest linkage with some probability. When further considering GeoIP, even if on a different network, say wired vs mobile the chances of association increases. Add traffic pattern and timing analysis, and you can probably pin-point migrations with high accuracy.

So, what is the objective of preventing linkage and if it is worthwhile, shouldn't at least packet numbers be encrypted?

Network operators would likely be very upset about non-public packet numbers due to latency and loss monitoring.

Even with encrypted packet numbers linkage might not be too difficult given the amount of data available.

Would it make sense to encrypt the connection ID? Not likely due information in IP/UDP.

Some links on user tracking in Tor networks:
https://www.scmagazine.com/researchers-discover-dns-exploit-that-can-identify-tor-users/article/527591/
https://securelist.com/uncovering-tor-users-where-anonymity-ends-in-the-darknet/70673/


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/990