Re: [quicwg/base-drafts] Unclear what to do when QUIC Version Hints are missing (#3061)

Mike Bishop <> Mon, 07 October 2019 17:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73A881200B3 for <>; Mon, 7 Oct 2019 10:41:29 -0700 (PDT)
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 KIDOvuNKAU75 for <>; Mon, 7 Oct 2019 10:41:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D42D412004F for <>; Mon, 7 Oct 2019 10:41:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CB3506A0449 for <>; Mon, 7 Oct 2019 10:41:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1570470086; bh=Pk+F+O1iKi4i57eeK9AhYxiqdcWTPMrXrXzvFo1Sbe0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=bSGhaQI7ZtYNYguDuGN1eV/LfQyEsWsOmMhweV7PmN59L/s2w6OzoBrsctd9m73by 3EknYzG0RVoX4IvgykSPBMYIiaL6uZ78IwJthIClf//YdCC6Y1JOzi0KtOMe4wTI5f h9U0l5kN9MTtKcpvBZt+ItIRs/2dkS3wB/ZejKKM=
Date: Mon, 07 Oct 2019 10:41:26 -0700
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3061/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Unclear what to do when QUIC Version Hints are missing (#3061)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d9b78c6bbf20_40933fa6660cd9641827c6"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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, 07 Oct 2019 17:41:29 -0000

It was designed at a stage where QUIC had a fully-defined Version Negotiation mechanism.  The client could offer any version -- in fact, was *encouraged* to offer a grease version -- on the first flight, and would learn the server's list of versions in response.  But if you knew that list up front, either via Alt-Svc or because you've connected before, you could save a round-trip by selecting something that was on the list.  And if your information was wrong, or stale... oh well, you get a VN packet and learn the correct list.

Now, we don't have such a mechanism and receipt of a VN packet is fatal.  There are two ways to look at this:
- There is only one version, so we can define this mechanism once it can be paired with a version negotiation mechanism.
- Getting the server's version wrong is fatal, and therefore this mechanism is essential.

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