IETF Logo Mail Archive

Re: QUIC ossification

Martin Thomson <mt@lowentropy.net> Wed, 13 February 2019 23:47 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 4ED9B130E57 for <quic@ietfa.amsl.com>; Wed, 13 Feb 2019 15:47:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=hXMxmENR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Vyy0EvIL
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 99Xe97jfFgv7 for <quic@ietfa.amsl.com>; Wed, 13 Feb 2019 15:47:00 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 824AF128B01 for <quic@ietf.org>; Wed, 13 Feb 2019 15:47:00 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B419E21E97 for <quic@ietf.org>; Wed, 13 Feb 2019 18:46:59 -0500 (EST)
Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Wed, 13 Feb 2019 18:46:59 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:references:date:in-reply-to:subject; s=fm1; bh=mO1 iwfAZ8dCUB4TVC8qoGZJSRlhU/BS2fm296Sw6P50=; b=hXMxmENRZ43C5ZJlt6O QiYsZ9HSEQZZuMU5qLsUJjO8yJU0iTm5QZdAicgnoVUDkWPP+o90N+zPYfZpCncq hQkgswfBtuZAWxM/yBEaSdEuxNmkmyEM1gn4WldjfKuYSqOigQ6CNC95K/RrCTaL kpEuKHP/mqalmW4sWt07Grd8GDCBP5USEM9cp7rPG5n25A9R/L4kNe/RAS5ajLod FxCxZb5G1eRDUclpLDw32Bn1H+PhMfhsbWFoEfzmkPf2qS9cifH8NuFRgLNJbXj0 /i4BfteQeUQylkds8r9WT25d5H+E4fKnRmbKZIYOcFiwLBrpwWyfLCLNRqnAfHlo onA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=fm2; bh=mO1iwfAZ8dCUB4TVC8qoGZJSRlhU/BS2fm296Sw6P 50=; b=Vyy0EvILW4jAhFy3qPd5ZBuuDBVn/gOfR6oVMhS+CL8ULYTpXg3Aks6Dl 4btisIffZxPQxigkqzMA9HYa9r1uo/xvnCt7CZIPZbvxB6dMn0H/3wLubIbjEewt JfYWzkCW2HCDg++O1CM86iqYvdYIdW9kHNOjemOujSu9URJ0OhhfuFVmQHHTXYKr kDzO/Hjc3o+e0fDC4foMuiFnFhj8hgYHd/cZUvH6U80brexjaU+VEF53M/p75ask 6JWeYmPy/QA2JqCRmFlEUCy+gRxXfZ/6eNpYySUbKQHmbunGIBYhVvp3h2T2tBP2 EOJrmxCjkkyl/J3qEmatw8CqJuX3A==
X-ME-Sender: <xms:c6xkXP6eeQ5cPJ0Bd9YoieQ5O22eRa3qIX1Dc1TRlstSnKDeN7Cgfw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtgedgudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurhepkffhvfgggfgtofhfffgjufesthhqredtredtjeenucfhrhhomh epofgrrhhtihhnucfvhhhomhhsohhnuceomhhtsehlohifvghnthhrohhphidrnhgvtheq necurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtne cuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:c6xkXOMXJzYm_G6z7NwVsJi0-_aYJWjcX38zNclM8Svh40_-vZJU4w> <xmx:c6xkXOeGMFerhF33DxMFCSPDSYdtDwiubBkUxp-YkAUXoMqTkxGQyw> <xmx:c6xkXJ1Z4KtuoWAKRdotq_GdcI9MkqdtWYs_jMNaqpcTl-ApOlVfeA> <xmx:c6xkXMx_q1gqZ0otjT0vvEPH6lGaaa-4Q8gV6psAfF294NRoPeVa9Q>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0D4809E54B; Wed, 13 Feb 2019 18:46:59 -0500 (EST)
Message-Id: <1550101618.3002483.1657568864.062669F6@webmail.messagingengine.com>
From: Martin Thomson <mt@lowentropy.net>
To: quic@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-e97eb308
References: <CAM4esxTm0GiXnow4Vyv0UX6kFW4U3zJgVrN_JzD31Sm6sxoYGg@mail.gmail.com> <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <CAPDSy+5LikoojquLhaW58DbJ3VrGXUViaD0aHcTkxBJGzFjgQA@mail.gmail.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <CAM4esxThzPJUxU7R5-CY-ZcgmqhYdPFMoM5Fg17vN-Hsk_pJ8A@mail.gmail.com> <CAKcm_gMmxeHHN3dtH9kby_En96oPwTqrfHE=wpqy5Z0YbX4png@mail.gmail.com> <CAN1APdegy8n3+8J-pkgB6f-SNxHtju9p1Hiyct2tHWQ0KyeiGg@mail.gmail.com> <CA+9kkMC95TnFatowKU6121g+1DPy1hMNbKPagveMfKCXtpFSUQ@mail.gmail.com>
Date: Thu, 14 Feb 2019 10:46:58 +1100
In-Reply-To: <CA+9kkMC95TnFatowKU6121g+1DPy1hMNbKPagveMfKCXtpFSUQ@mail.gmail.com>
Subject: Re: QUIC ossification
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/JGn56y2MURuoT90jXai3z2SC680>
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: Wed, 13 Feb 2019 23:47:02 -0000

On Thu, Feb 14, 2019, at 04:17, Ted Hardie wrote:
> On Wed, Feb 13, 2019 at 9:14 AM Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
> wrote:
> 
> > There is the risk that middle boxes learn that versions mean nothing, and
> > that they are all the same, akin to crying wolf.
> 
> I tend to agree with this. Version numbers should shift when the
> interoperability among parties to the protocol shifts.  While you can
> artificially create that shift in closed system, teaching the ecosystem
> that the shifts are meaningless doesn't seem to advance the general goal.

If I understand David's proposal, these versions would have meaningful changes, or at least changes that go beyond the version number.  In TLS he has suggested a similar technique, with changes that are not compatible, but relatively easy to implement.  For instance, changing the salt for the Initial keys would be trivial to implement and make the protocol indecipherable.  Switching to ChaCha20-Poly1305 instead of AES-128-GCM would be another.  He also suggested that we reorder key fields, switch endianness of various encodings, rot13 extension codepoints, ... plus whatever you can imagine.  As long as it is easier to respond correctly to new versions than it is to build specific handling for every new permutation, the protocol designers win.

Now, I'm not sure if that is as good as having a good reason to deploy a new version, but there you are.

v2.23.0 | Report a Bug | By Email