Re: [quicwg/base-drafts] The method of identifying "the same server" (#3155)

Kazuho Oku <> Mon, 04 November 2019 12:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F30B1200C3 for <>; Mon, 4 Nov 2019 04:46:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 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_IMAGE_ONLY_28=1.404, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dNOJXpfskcNd for <>; Mon, 4 Nov 2019 04:46:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A872D120255 for <>; Mon, 4 Nov 2019 04:46:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 036956604D3 for <>; Mon, 4 Nov 2019 04:46:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1572871563; bh=uvuYaYxFKLFGxi1z8UDP6iOQQc7djDCLuqCG4Bva9lg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=dmS2uyktOckhYMWg4ASfDLwYO3Knx7jwQEP0PAst4OJiLfsQ95QO3WdGfQfxNWe3j e4bc5pc16hSx+G9zSO6J3gAtS+xvXLs8v8+fZveJmvA9n58WcbfLTsDoDSP1++DI3Z SX7BL5nrUTCUBBtd32aE5BKwNqSwBzCzz2k20/Bk=
Date: Mon, 04 Nov 2019 04:46:02 -0800
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3155/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] The method of identifying "the same server" (#3155)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dc01d8ae930b_10003f83d30cd96014554"; 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
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Nov 2019 12:46:06 -0000

@igorlord No.

The concern is on the server-side, where three parties are involved: a) owner of LB (that only sees unencrypted traffic), b) owner of one server behing _a_, c) owner of another backend server behind _a_, who can also monitor the traffic between clients and _a_.

The attack goes like this:
1. _c_ accepts a connection from a legitimate client (through _a_), and issues a NEW_TOKEN token
2. The client reconnects to _b_ (through _a_), using the the token obtained in step 1. At this point, _c_ can tell that who connected to _b_.

Going back to our design principle; we require NEW_TOKEN tokens (and also TLS session tickets) to be sent using an encrypted channel, and to be used only once, because the fact that the client is connecting to a particular server should not be exposed to a third party. In this example, we are violating that requirement.

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