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

Kazuho Oku <> Tue, 29 October 2019 07:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D0D271200F6 for <>; Tue, 29 Oct 2019 00:17:55 -0700 (PDT)
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 ma0Yo1uSPWaf for <>; Tue, 29 Oct 2019 00:17:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 725951200F4 for <>; Tue, 29 Oct 2019 00:17:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BE8F51C0CA4 for <>; Tue, 29 Oct 2019 00:17:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1572333473; bh=vOkPx+9346ZUPQVYcEWIL7D9VAgevATtcX23wIbxRGA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=VumQ1Dq/918bV/SNKAYA2eZxTKno1ohMKDz9AXk4TMz2lU3jBRmNDUHwAuqCJru23 W4d6lYTY6woH7vQBfIsIL8lqqHBnkLBhAhYLvDQuWnxQ1TiC/5qagsmRur671IFcUh 3VtNZoU73IJ61dT7dsJV7eydQnYxC0ykmSwRi1tM=
Date: Tue, 29 Oct 2019 00:17:53 -0700
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_5db7e7a1aeb9b_cce3fbffdccd95c63173"; 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: Tue, 29 Oct 2019 07:17:56 -0000

FWIW, the discussion here relates to issue #3111 (PR #3166).

If we are to say that the scope of a token is tied to the identity of the server (i.e. server certificate), it becomes impractical to use token-based greasing for hosts that are not hosted by multiple entities (i.e. multi-CDN use-case). This is because owners of such hosts would not want to see an additional round-trip due to Version Negotiation packet being sent in response to an unknown version.

If we are to say that the scope of a token is a tuple of the server identity and the server address, maybe that becomes an non-issue, as we can assume that the tuple uniquely identifies the operator of the server.

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