Re: QUIC Version Negotiation Extension

"Martin Thomson" <mt@lowentropy.net> Mon, 04 November 2019 23:16 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 DF96A12091B for <quic@ietfa.amsl.com>; Mon, 4 Nov 2019 15:16:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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=lszGOL3j; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ayxo47gY
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 TjWAiugwoxiH for <quic@ietfa.amsl.com>; Mon, 4 Nov 2019 15:16:22 -0800 (PST)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94641207FB for <quic@ietf.org>; Mon, 4 Nov 2019 15:16:21 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 2904B694 for <quic@ietf.org>; Mon, 4 Nov 2019 18:16:21 -0500 (EST)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 04 Nov 2019 18:16:21 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=+bhOz8rm85LOwn+ADF7csGfxFSrDiE9 pnFvffYgvftE=; b=lszGOL3jhPGbJVMdegZ+TZ75TZJpy++B11Kaf6BkEPa+aMh owwYalVzfychowGRsJvwy4VGMz11mHCRqjMwMFABYmqMBDfpea16cirnJnh9KLs4 1pt498yV7/BLpqVS09Ct1brJHu2F80RSw78Ccw2sU55ziAm48DDIdilNKXOLz9pT tpJLrxx27f9JKE+f0ghUdB1jzEEXAKWZj6Fck8IRrNIdUK8ByWeWgp2R5pxP70Df O7sC6NVrsnZKCliKp5A/XY3crVAU+rVAWwk+ormudTkwC+F5GxkJ0Q9myXV7fziW i+/BIJvJpLd57vagGBSq00PatLen5Vhs8EK2+vw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=+bhOz8 rm85LOwn+ADF7csGfxFSrDiE9pnFvffYgvftE=; b=Ayxo47gY0LH1Wmbp1p8WnW RJrT5CGHVCWjwdyqR6HTzCFwc9G8VWGb95Y/iQpFUJzb6XTextkDcgS/hXTxNl8q I2P9lmoISlJdRp4YedGtH1jbYG/xt0elPbb4swWnrAVL5ewviRmCVPt1bb5d3M4l Yunts1R0LTKpoMGYGLr/ekmtSLFFSJnDUk1/8Sv9h9kOSnocyZgmKNX8MX4axumx 5Y4Z4RwVnCWsYYifXxwbgsUsYcaZ7vdEuraQRCF47c/m5hKHYBfDt0ZZB+2Z6PaQ ZdPK2xuY3hS0kT4YcBcm5tABtbW1zDIgZxPhjcywhSQIuoeO8NqEN+LkrRA1UdPw ==
X-ME-Sender: <xms:RLHAXfi23gVwdauc63HqIoGeoqQa29r0q-fusZ2u2B_QgmKxJzm26g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddugedgtdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd
X-ME-Proxy: <xmx:RLHAXbMH9EC1y74tuIcESuwe93gwTXd97nI9KGTNieQcmSN5xvBlBA> <xmx:RLHAXVR2SLoEZWDlesTLk_HGeW1IDkByje93aC_k7tZ8gmO9x2mMzw> <xmx:RLHAXdwjTxIM5V_zNiD2BHuWoiN0PBTY1LmN-i5mFCyPRYwlpnBOFA> <xmx:RLHAXQdWfiaZ2_EeAPZnvMLkglV6Y43Yps2cl06kJExrOShG7wumaA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 18A8BE00A3; Mon, 4 Nov 2019 18:16:20 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1
Mime-Version: 1.0
Message-Id: <6ee87e10-ef61-46be-b29d-3d6c0aef39b7@www.fastmail.com>
In-Reply-To: <CAPDSy+4wrhqejh9k8=G7W267EgcT5Z2sDK7ZBGKtNn5kkbXGfg@mail.gmail.com>
References: <CAPDSy+4wrhqejh9k8=G7W267EgcT5Z2sDK7ZBGKtNn5kkbXGfg@mail.gmail.com>
Date: Tue, 05 Nov 2019 10:16:01 +1100
From: "Martin Thomson" <mt@lowentropy.net>
To: quic@ietf.org
Subject: Re: QUIC Version Negotiation Extension
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/x-P5DpFQovPTHi_pkaLVsiC8j10>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 04 Nov 2019 23:16:24 -0000

Hi David,

I think that this is broadly the right mechanism.  It would be good to validate it more thoroughly.  

The model and framing could use a little work.

I struggled a little with the framing here because the split between incompatible and compatible versions is very important, but also unclear.  The definition of "compatible" is left for Section 7, but it seems like it should be right up front.

The framing I would choose puts the model up front.  The model that you have have two layers that are applied progressively:

1. incompatible version negotiation, where the server sends a Version Negotiation packet in response to a version it does not understand.

2. compatible version negotiation, where the server can generate interpret a version X Initial packet and continue with version Y.

Regarding the model, the definition of "compatible" needs work.

I observe that you only need a mapping from "Initial"-equivalent packets in X to the same in Y - and maybe the ability to generate a Retry in version X (more below) - in order for this to work.  That's where there is a clear functional mapping from a version X packets that initiate the connection to something that fills the same purpose in version Y.  

But the definition you have for "compatible" implies that the mapping is bijective, which I don't think is necessary.  As the draft says, version Y might define (and allow) new frame types in its Initial-equivalent packet(s), but as long as those are either optional or can be synthesized from X, that's OK.  It isn't necessary that every Y have a functional representation in X.  We might not want to define a way to negotiate an older version from a newer one (or at least not for every case).

The ability to generate a Retry stretches this definition a little.  Can you explain why you can't generate a version Y Retry?  I have an inkling, but it's not fully formed.  It complicates the model more than I'd like to have it this way around.

On Tue, Nov 5, 2019, at 07:29, David Schinazi wrote:
> Hi everyone,
> 
> From the recent discussion on multiple PRs, it appears that there might 
> be a need for downgrade-safe QUIC version negotiation, earlier than we 
> expected.
> 
> EKR and I updated our extension to hopefully suit these needs:
> https://tools.ietf.org/html/draft-schinazi-quic-version-negotiation-02
> 
> Comments welcome here or on the GitHub (link in draft).
> 
> Thanks,
> David