Re: [quicwg/base-drafts] Compatible version upgrade (#1901)

Martin Thomson <notifications@github.com> Thu, 25 October 2018 01:36 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 3C783129BBF for <quic-issues@ietfa.amsl.com>; Wed, 24 Oct 2018 18:36:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.47
X-Spam-Level:
X-Spam-Status: No, score=-8.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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_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 UftEIeoxZOtH for <quic-issues@ietfa.amsl.com>; Wed, 24 Oct 2018 18:36:55 -0700 (PDT)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 002F2126BED for <quic-issues@ietf.org>; Wed, 24 Oct 2018 18:36:54 -0700 (PDT)
Date: Wed, 24 Oct 2018 18:36:54 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1540431414; bh=0ojNb2oN4YgJB2JSblgQ6wy7Qx5Ji/f89zrovt4C9cQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=meqS6XNXVRyYZqi/rn82rLPQ3+rxqlsv1MDN5N9F/eth2M0RiVOyYXmN1rh93XQuk jc7Htqo64BIk9zFxuBdt3KotPzgiNxr7/fvDYrBUYtjKaIP28CBgiRdsObIOI5SfKO 3KyNYh+oZBkMmT6wGYYU46aHI5qVyGTIRyNA32G0=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab24cea8675d150615ee15363546ebd1f791b47fd392cf0000000117e8e03692a169ce1640b1a8@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/1901/review/168181485@github.com>
In-Reply-To: <quicwg/base-drafts/pull/1901@github.com>
References: <quicwg/base-drafts/pull/1901@github.com>
Subject: Re: [quicwg/base-drafts] Compatible version upgrade (#1901)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bd11e36476a4_5e603fa038ad45b83427d"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/mt3M7_atmCuCFMn4cyi7V-Hrifo>
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: Thu, 25 Oct 2018 01:36:57 -0000

martinthomson commented on this pull request.



> +list of QUIC versions and select an alternative version from the list of
+supported versions.  A server MAY choose a compatible version from that list and
+continue the handshake with that version.  The server sends its first packet as
+though it was continuing with the version it selects.
+
+A QUIC version is compatible with this version if the cryptographic handshake
+message sent in the first packet can be used in both versions.  A compatible
+version is also able to identifying and acknowledge the first packet sent by the
+client in some fashion.  Other QUIC versions might have different constraints in
+determining what is compatible.  In order to facilitate this process, new QUIC
+versions could define a process for transforming the first packet from other
+compatible versions into the equivalent packet in the new version.
+
+Upgrading in this manner allows a server to upgrade without incurring the round
+trip imposed by sending a Version Negotiation packet.  It also allows clients to
+send their first packet using a widely deployed version, without the risk of

Thinking of versions as being ordered is helpful, but might be constraining.  The point is that the client will use the most widely deployed to start with and accept that the server is able to choose a compatible version.  The client *hopes* that the server will choose a version that it prefers more, but leaves that to the server to decide.

In the case of monotonically increasing versions where A >> B >> C, this might seem obvious, but it's still possible that the client will advertise B and get an apparent downgrade to C.  That's a property of the design that I don't think we'll see that often, but it's nonetheless theoretically possible.

But as @kazuho says, the expected case is a client advertising vN, then being opportunistically upgraded to vN+1.  Like today, you can rely on TLS 1.0 being available widely, but you might prefer TLS 1.3.

-- 
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/1901#discussion_r228011154