[quicwg/base-drafts] Simplify version negotiation (#2133)

ekr <notifications@github.com> Wed, 12 December 2018 20:44 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 84177130FEB for <quic-issues@ietfa.amsl.com>; Wed, 12 Dec 2018 12:44:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.459
X-Spam-Status: No, score=-9.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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, URIBL_BLOCKED=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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kLYgl23JaoER for <quic-issues@ietfa.amsl.com>; Wed, 12 Dec 2018 12:44:42 -0800 (PST)
Received: from out-1.smtp.github.com (out-1.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE56A130F82 for <quic-issues@ietf.org>; Wed, 12 Dec 2018 12:44:41 -0800 (PST)
Date: Wed, 12 Dec 2018 12:44:40 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1544647480; bh=PTk639MlrnkCkbAhoNMwKnmyLUbMGv19ZWluRFk3aOw=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=xEsY/ZmB/1Lye978+89Dn4JSGjXMozPM1Ufa1hdoymKHnQ/tP7xX4p6AQmbXLdjqP 36nQLhF0+SFn5i8owCL/FYEG7jQ+TmiQGERZ09qRtYk3PXiR93yhPI1TQlVHB7A13C Gdklh6gZWrjoJSaB+mEJvDQIXgtsx++98j58bGT4=
From: ekr <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab553b779ed0ae8d0003319ea54177fd8f689a999a92cf000000011829353892a169ce17450cf5@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2133@github.com>
Subject: [quicwg/base-drafts] Simplify version negotiation (#2133)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c11733862f30_422b3fee95ed45b81033af"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ekr
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/_O_-6S8sln_FU071lHIqpKMZDsQ>
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: Wed, 12 Dec 2018 20:44:45 -0000

Following the discussions in BKK I've been thinking about version
negotiation a bit, and I think we can improve things while also
simplifying them. The TL;DR version of this is that instead of having
the client send any version and the server correct it, the client
offers a list of versions and the server picks one. This makes
things a lot simpler at the cost of some unnecessary flexibility.

The basic insight is that the current VN process is complicated
because it's got an axis of flexibility we don't need, namely allowing
the client to send an Initial packet with no idea whatsoever of what
the server supports. This means that you have to be able to have the
server blindly generate a VN no matter what the client sends, which
has the following negative consequences:

- It burns up a round trip if the client's initial version is not
  the one the server wants, even if the client and server are
  basically compatible.

- We want it to be stateless, so we have this clumsy validation

What I propose is a simpler approach, which is pretty much what
all other other IETF protocols that do version negotiation do:

- The client sends an Initial packet using a version which is
  acceptable to every server for a given application (e.g., Web,
  e-mail, etc.). This packet contains a list of the versions
  the client supports.

- The server responds with its preferred version out of this list.

- If the client's Initial packet is totally incomprehensible to
  the server, then you get a hard failure (and we repurpose
  and simplify VN for this).

This has the following advantages:

- All version negotiation happens in one round trip.

- Negotiation validation is mostly a matter of checking that the
  server-selected version is acceptable [0].

The main cost is that the client needs to be able to safely send an
Initial that can be read by the server, which means that it needs to
agree with the server on Initial format, though this can span multiple
QUIC versions.

Importantly, this doesn't preclude having totally incompatible
versions of QUIC (e.g., with a different CRYPTO handshake). You can
obviously have two disjoint sets of clients and servers that support
QUIC X and QUIC Y. Additionally, the case where you have a server
which supports A and B and clients which either support A or B works
fine.  The client's version appears in the header and the server can
demux on that. So, it's not like we're promising that every version of
QUIC has the same CRYPTO values, just that the client knows enough
about the server to know an Initial format it will accept.

What won't work is where the client has no knowledge of the server's
capabilities at all, specifically where (a) the client supports
incompatible versions A and B and (b) the server might support only A
or only B and the client doesn't know which one.  It's not clear how
this could happen in practice; it's like the client wanting to speak
either TLS or SSH and not knowing which one the server speaks [1].

[0] You also want to put the server's selected version in the crypto
handshake, so you need to check that the inner and outer versions

[1] If we ever did want this, we could always design it as an
extension later, presumably cribbing from the current VN design.

You can view, comment on, or merge this pull request online at:


-- Commit Summary --

  * Refactor
  * Versions
  * Version error
  * Add vesions back to VE
  * Remove VN from recovery
  * Remove version list from VE

-- File Changes --

    M draft-ietf-quic-recovery.md (12)
    M draft-ietf-quic-transport.md (309)

-- Patch Links --


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