Re: [quicwg/base-drafts] clarify the scope of a NEW_TOKEN token (#3156)

Kazuho Oku <notifications@github.com> Mon, 28 October 2019 12: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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3C612006A for <quic-issues@ietfa.amsl.com>; Mon, 28 Oct 2019 05:13:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1J4SUdLeYnI for <quic-issues@ietfa.amsl.com>; Mon, 28 Oct 2019 05:13:15 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C35012001E for <quic-issues@ietf.org>; Mon, 28 Oct 2019 05:13:15 -0700 (PDT)
Received: from github-lowworker-45eca55.ac4-iad.github.net (github-lowworker-45eca55.ac4-iad.github.net [10.52.25.70]) by smtp.github.com (Postfix) with ESMTP id 3C5DA1C0507 for <quic-issues@ietf.org>; Mon, 28 Oct 2019 05:13:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572264793; bh=GnjfboLExt99YBYzoKuKhokjhsmME/b5r/IdIiJuugc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=2N9fkGEViXCZeLSTABCyVOsTpPbMj6Nu45feDo+ShtBQ/9pijw2TN9sWCeJzwh8uQ Xvbt9fM05Eui8MRQzgSov/z5c69R4mAIW8n5sEkveON2RQRabhZ/7vh39fIrhDV+2T gbNBrFSsxGF15OgoN5vCjDie63CZwR51RmUZbpvc=
Date: Mon, 28 Oct 2019 05:13:13 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3GR63TYRYVATK4EEF3YQG5TEVBNHHB5FNSNM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3156/review/307804409@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3156@github.com>
References: <quicwg/base-drafts/pull/3156@github.com>
Subject: Re: [quicwg/base-drafts] clarify the scope of a NEW_TOKEN token (#3156)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db6db592e667_4ab53fa0cf6cd96412021b"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/MsK0lvT7XFI-gXsS3Iz4-kbWuC0>
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: Mon, 28 Oct 2019 12:13:17 -0000

kazuho commented on this pull request.



> @@ -1698,10 +1698,14 @@ encrypted form in the token.
 It is unlikely that the client port number is the same on two different
 connections; validating the port is therefore unlikely to be successful.
 
-If the client has a token received in a NEW_TOKEN frame on a previous connection
-to what it believes to be the same server, it SHOULD include that value in the
-Token field of its Initial packet.  Including a token might allow the server to
-validate the client address without an additional round trip.
+A token received in a NEW_TOKEN frame is applicable against the servers that the
+connection is considered authoritative for (e.g., server names included in the
+certificate).  A client MUST only use a token that is applicable to the server

@martinthomson FWIW I think the attack you were discussing was something different, that works even if the tokens were perfectly encrypted.

Consider the case where an attacker is an ISP and also controls example.com, which is hosted behind the large-scale load balancer hosted by a different entity (e.g., CDN). The attacker issues tokens when clients connect to example.com through the load balancer (IP address 192.0.2.1). Then, when the clients connect to different hostnames under the same load balancer (IP address 192.0.2.1), it can (as an ISP) see which exact clients went for which exact server-names.

I think you pointing out this attack has effectively killed https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bound-token/, I appreciate that. But if it is the case that you think it's an attack we can ignore, I'm happy to revive the draft :-)

-- 
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/pull/3156#discussion_r339530240