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

Martin Thomson <> Tue, 05 November 2019 05:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36B9512002F for <>; Mon, 4 Nov 2019 21:25:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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_32=0.001, 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 3oYds5nFD7DC for <>; Mon, 4 Nov 2019 21:25:34 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 55A3E120020 for <>; Mon, 4 Nov 2019 21:25:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A750C66113A for <>; Mon, 4 Nov 2019 21:25:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1572931533; bh=rqUbRZa+q3y50W7H+Kjoe3b/cBh3mJmnPkjtb/aNyRI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=tyP3qgmEsGn9Ekwym/f1LILaK5LGJcgvYf3u4N3GW35YBewquvnjZeLoEgx3BQBqO X0EjjJVQeDE9LD426rKfoqq0mowYetn2ahgX9H52CPwltcE2larXvdisCYUFHdfrSL vUZWLtYfQaCb4hu3J8DKwi/+eCEMJdm5EId6Lh8w=
Date: Mon, 04 Nov 2019 21:25:33 -0800
From: Martin Thomson <>
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_5dc107cd98c73_6c6a3fc7ab0cd96c73646b"; 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
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: Tue, 05 Nov 2019 05:25:36 -0000

For the client, the consequences of a bad guess is a wasted token and (maybe) the wasted bytes.  That's all.  So in general, there is no reason to constrain use of tokens where the client thinks that they might be useful AND that the client is willing to risk linkability between sessions.

The latter condition is where the various linkages come into play, but the point remains that the client is responsible for making an assessment.  This text is about setting a common baseline for that.

If a client wants to extend the set of servers that might be able to link sessions, I think that's OK, but it has to do this on the understanding of what that means.  The server that issued the token might see this new usage and link it to a specific prior context.  Without ESNI, that means things like knowing where previous users are now trying to connect.

As @kazuho says, a client might choose to constrain token use to particular networks, but it doesn't have to.  I might even go so far as to say that they should probably not reuse a token from a different network location, but that depends on having information that I know is hard to acquire.  A requirement that the token only be used from a certain network location wouldn't be implemented because in some cases it couldn't be implemented reliably.

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