Transport parameters for version negotiation and v2

Martin Thomson <mt@lowentropy.net> Fri, 18 November 2022 00:15 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811DDC14CF13 for <quic@ietfa.amsl.com>; Thu, 17 Nov 2022 16:15:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=G7gg1Of+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=e1wd8BdD
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejkXFsTYi_n1 for <quic@ietfa.amsl.com>; Thu, 17 Nov 2022 16:15:50 -0800 (PST)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74CEBC14CF09 for <quic@ietf.org>; Thu, 17 Nov 2022 16:15:50 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 8518B32009A8 for <quic@ietf.org>; Thu, 17 Nov 2022 19:15:47 -0500 (EST)
Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Thu, 17 Nov 2022 19:15:47 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-type:date:date:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to; s=fm2; t= 1668730547; x=1668816947; bh=LYd7inTtZ0xTVaAA31E2S8UkSEeV94UMnSq QaCHyz94=; b=G7gg1Of+Ue/b5OdaM7hev5p9EhBt/l2kbsUAEstRuLNZdGyszGi /3hbWCSQ5zyCFiuCc240zRWeK6a9OHsKEBxZZRog9Ywmc7ZSppV41r2LuJriNqbu mu7HZNbmVTboNEpen0Ujdxz33nGAoP8/9S0DBT64zj+siJ3DTsT3aSlF3FQw3cP5 qcVqJ9/I1sQGcYDK9eUxlIL4ZTFmLOwbIUFE2OtAR0J6UAKqGbbloI99eEaM4YGy A5s57iGE2DKuiGT24z0EAh29rD7NPDgZUCOXYM3IYAYXciLkOfjpZya3M6TVJkZP FSz2e6PWiVI3ynOLcyg5cVT810ZBAsPgqNg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1668730547; x= 1668816947; bh=LYd7inTtZ0xTVaAA31E2S8UkSEeV94UMnSqQaCHyz94=; b=e 1wd8BdDCDnQw7UBeO2/2f+EM8HXOhZ3Qb7rSPC+EEkdO2be9E+NACNhgiCKTy4T5 iC1Dz61tKTRrzZsmoG9r51sgFUoVZFIDQLfH0gVswebxC6lqg6+Dwh6qDeOk49rG Y8S47UQ61+5W1pAJnAH50ZyRvanm4dmSfrfiTS9IFohmJKucTCthZxKT8U5zifEj AFRWZwd2IbpQ5jg+Il3mK/kM4yEeu9g/Z+3m2bHwoKdeqVf/MA4C/B3Lw8jWt/Mu BtKytWZ+prEI6TfrIsF2XAWdaR1cMb3rjIFtB3Q89KpJ9PvvwVD2/KjPYJdIgBvG KWkayy1LorG4/yZmDAthw==
X-ME-Sender: <xms:ss52Y0tk9ju2ehC-wjKdTP5FjSLQaUaEI48xxqHC0NOFGaMkkU0ZPw> <xme:ss52YxcyHq2C6BXvuSFaUzixC9LQpMUGJiPeiRGhMRXon4CNfSDNSVXcZJaO3Lpkg mvbVbNq1KSBsL5czDQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrgeelgddulecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghn thhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepjeetfefgjeduledttdeiudfgff effeekffduteeggeejuefftdeuuefggfetfeehnecuffhomhgrihhnpehquhhitgifghdr ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:s852Y_xVcO3ftwdXsObELNEi05da2etR-Cllt3bW_Z4zLP29DVYOFw> <xmx:s852Y3NwSBfR5SNMIuMWvSvLSwSqh3_FYtAiEF1Rk8SmE0Xq2gNCwQ> <xmx:s852Y0_3Jp8i-dxOpss2aTBLGJ0Uzms6GFm_0DbtoUH95GFBYOvT3A> <xmx:s852Y3LtNGPKdO9BAO59iDsksfmEyODGbe2lTu9LZRFnjT5Yaxahcg>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id E327C234007B; Thu, 17 Nov 2022 19:15:46 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead
Mime-Version: 1.0
Message-Id: <85208613-d3b1-4955-a71a-b22ac7ada0a1@betaapp.fastmail.com>
Date: Fri, 18 Nov 2022 11:15:26 +1100
From: Martin Thomson <mt@lowentropy.net>
To: quic@ietf.org
Subject: Transport parameters for version negotiation and v2
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/f4kdku9pqI6raepT_L3z_pth3Uo>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Nov 2022 00:15:55 -0000

How many people have shipped version negotiation and v2 already?

I assume that implementations are using the codepoints for the transport parameter in the draft (0xFF73DB), but the drafts says this:

> When this document is approved, it will request permanent allocation of a codepoint in the 0-63 range to replace the provisional codepoint described above.

IANA are about to make that new allocation, but that might not do good things for interoperability.

We're not changing the v2 version number and v2 *requires* the use of this transport parameter: https://quicwg.org/quic-v2/draft-ietf-quic-v2.html#section-4-2

Consequently, an implementation that uses the current transport parameter codepoint will not interoperate successfully with an implementation that uses any new transport parameter codepoint.

So, we either allocate a new codepoint for both, or we keep the existing ones.  Which do people prefer?

Or, am I wrong about this?