[quicwg/base-drafts] Linkability with preferred_address usage (#3559)

Martin Thomson <notifications@github.com> Tue, 31 March 2020 00:13 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C03A63A1621 for <quic-issues@ietfa.amsl.com>; Mon, 30 Mar 2020 17:13:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.2
X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id MmdGsH6iY2ei for <quic-issues@ietfa.amsl.com>; Mon, 30 Mar 2020 17:13:11 -0700 (PDT)
Received: from out-14.smtp.github.com (out-14.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63CAE3A1620 for <quic-issues@ietf.org>; Mon, 30 Mar 2020 17:13:06 -0700 (PDT)
Received: from github-lowworker-2ef7ba1.ac4-iad.github.net (github-lowworker-2ef7ba1.ac4-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id B6B421204E7 for <quic-issues@ietf.org>; Mon, 30 Mar 2020 17:13:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1585613585; bh=wQIZxALmcpzuKMwldcc1DKnG9ruC83KA0BtXgfj3kjY=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=abw+UFJ8lx2tLPs4TFzOikdOtp6jkzlMSWLwm6ZH6bUWDILoEXR2nSnPgo+3FSpc/ WKjMc2xXYydqzUl/fx16ypdP95h3u2UxpKp59fOxvggRsOK5UKt73M52G/3Yj7uCb8 44uUvvRNYHDdpZ3SRBpucU0d0ftvQb5Yic0eHnp8=
Date: Mon, 30 Mar 2020 17:13:05 -0700
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZVOTTWZJX7NSYQW3V4RZWBDEVBNHHCGNJGZU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3559@github.com>
Subject: [quicwg/base-drafts] Linkability with preferred_address usage (#3559)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e828b1171b4b_665a3fdaa54cd960240714"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/tyu_z9_eqFhTIxsWbvvnNZDzp9I>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
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, 31 Mar 2020 00:13:13 -0000

One way in which a server might use preferred_address is to enable routing based on the server address alone.  Just as a client might benefit from a zero-length connection ID by selecting a unique address from which to initiate a connection (i.e., an ephemeral source port), this enables the server to pick an address that is unique to the connection.

Such a server can then establish a connection by routing based on the source tuple, then move to a preferred address that is unique to the connection.  This assumes that clients aren't using connection IDs to multiplex multiple connections to the same server, or that they only open one connection at a time, or that servers are willing to do trial decryption during handshakes (that last one being unlikely. because in the general case it is more than just trial decryption).

As a result, the server does not have to request that the client not migrate.  The server can use this unique address at its end to identify which connection packets belong to.

That's all great, but it creates linkability for the client.  When it migrates, the destination address is unique to that connection, for at least as long as that connection is live (which includes the idle timeout, which we have to assume is known to an attacker).

It also potentially creates address exhaustion problems at the server as the server has to keep address allocations for a fairly long time to allow for idle connections to time out.  Stateless resets are possible, but challenging, because the server has to rely on state in order to generate one.  Stateless resets can't be static unless a port is only ever used exactly once (which seems ludicrous).

I might conclude here that a zero-length connection ID for a server is just a bad idea, as the server address is stable across migrations and links flows on different paths.  There is some uncertainty about linkability when it comes to port reuse, but this does undermine guarantees that clients might assume they have.  

I see two choices:

1. Prohibit (active) migration when there is a zero-length connection ID at the server end.  This would be on the basis that there is a privacy leak that is not obvious.

2. Acknowledge that this happens and leave this to client discretion.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: