Re: Benjamin Kaduk's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT)

Jana Iyengar <> Thu, 07 January 2021 07:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58E6A3A03EF; Wed, 6 Jan 2021 23:39:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r7SxW19mGmFj; Wed, 6 Jan 2021 23:39:41 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 287263A09C1; Wed, 6 Jan 2021 23:39:21 -0800 (PST)
Received: by with SMTP id h205so12459711lfd.5; Wed, 06 Jan 2021 23:39:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mtDPUwBeE100g14YexuAaJpec3PbeoxZa7feQI3U66g=; b=XBv9uncvITRzABwyH5otinbWAEDiH+C6MM+DFutQ7LFP+xqTI1oz16sd3es63Y1k03 3dUMOez5bHR0cWAz98Dyuohb1hZBO0QkJpqKZKU+3ZF8ozmY6GlSmrsDcS3xqq6uxx2w yAWb9NlkOIZC9UCPQaDceLLbqS1v7rmkTxwuI37Izf0CAugguE/tQOvxCbFT66sPF3w/ PvHtOuqBpKtJqBWyWBBgfNzUB1qMfkMOF84utUl8Svsm7AC3lRCXk+JjpOdIXyGgtZ0e ISGs+T6egpXqktH3u4i4DMGwT64NA6qmWvXVkTAcHiXWqX/4vQCvjWV5RME5R4DUWiUf G0mA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mtDPUwBeE100g14YexuAaJpec3PbeoxZa7feQI3U66g=; b=ChasF/E1UZ0tv7IZk0aXqi6v/n9l9ugELSIqI/HWfPCJI5u+wzIm/zNmTEk3Cvyz1u wq5IfD9z2eyUTDVL+jPfdZYL6j49A78pb1FqFkvnz+HxXYVT2la0g/D/tOwVXUiLCWGy gR5g2uLBKMOT3Ft70BTlpmlLNgQz9DnOSNHxqaJN+09ZZxeU0qbOz+2mfUeXZ98lDlro n5d9oUT3ua7PkTiBqmgYFXiRtad2tuEPtxYJJ2YK+FdePF6TWdRICjd77Hcg2KxrDKPz FXetZUnjKNWwTl6u6RBTfkLk1TLKCtcksaXLu+yPJPj0OOLt8Ogwtgma0MvO+7p0AR0W lulA==
X-Google-Smtp-Source: ABdhPJwQxU9hbSrteLdFJVvvhhrYjznz3+C/9A38sQrv7tJE9lSxIMlKEN+Jbro9+yeFwCKWeRWcHWBEYftUHaVcXrI=
X-Received: by 2002:a2e:6c03:: with SMTP id h3mr3743181ljc.360.1610005159387; Wed, 06 Jan 2021 23:39:19 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Jana Iyengar <>
Date: Wed, 06 Jan 2021 23:39:08 -0800
Message-ID: <>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT)
To: Martin Thomson <>
Cc: Benjamin Kaduk <>, The IESG <>,, WG Chairs <>, QUIC WG <>, Lars Eggert <>
Content-Type: multipart/alternative; boundary="0000000000009cab6c05b84a89e3"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Jan 2021 07:39:47 -0000


The working group chose actively to make this decision. We had a broken
version negotiation in the spec, and after several long discussions, we
decided to remove the VN process out of the v1.

As it stands, in the worst case, if we find that we cannot do a safe
version negotiation within QUIC, we are stuck with a wasted version field
and a VN packet in the protocol. We can still build and deploy future
versions of QUIC, we just won't be able to negotiate their use within QUIC.

Given that we have a draft in progress, I don't believe that we'll end up
in that state, but even if we do, it's not an unsafe state. The working
group has consensus to move with v1 being incomplete in this regard,
because it's not unsafe.

To be clear, we aren't deferring safety of QUIC v1 (this document and this
protocol) to a future mechanism. We're deferring safety of the version
negotiation mechanism (which we don't have) to when we actually build that
mechanism. If we don't succeed, all we lose are the wasted bits in v1 and
we won't be able to negotiate a different version within QUIC.

If anyone else deploys a vN, the only way we are providing to use it is
through Alt-Svc. That is how major HTTP/3 deployments deploy multiple QUIC
versions today. That allows us to deploy multiple QUIC versions without
needing VN.

Am I helping, or is there a different point that I'm missing?

- jana

On Wed, Jan 6, 2021 at 11:21 PM Martin Thomson <> wrote:

> Excision performed in the service of brevity.
> On Thu, Jan 7, 2021, at 17:54, Benjamin Kaduk wrote:
> > Yes.  Do we have any reason to believe that non-standards-track versions
> > will or will not intend to coexist with v1?  I, at least, do not have any
> > data on that question either way.  I think this relates to my (3) above
> --
> > are we assuming that the problem of downgrade protection only becomes
> > relevant when there is specifically an IETF v2?
> We have no information, but that indicates more that we have time to work
> on a solution.
> > I agree that it's not necessarily limited to QUIC, though even having
> > something that only works within the QUIC ecosystem would be better than
> > nothing.  It would be surprising to define a protocol with verisons and a
> > Version Negotiation packet but end up with technical flaws that prevent
> > that packet from working properly, though.
> I am confident that we have enough of an escape valve that we will be able
> to define new versions securely.  As is the working group (who I am certain
> will speak up if they disagree).
> > I think it would be fruitful to try to drill a little more into
> > what assumptions we are making when we say (okay, I'm synthesizing a bit,
> > but I believe this is the sentiment) that "it is safe to defer
> availability
> > of this mechanism until a future version of the protocol exists".
> If only we hadn't already discussed this at length.
> > (I recognize that answering that last one may end up being nearly as
> hard to
> > answer as actually solving the problem.)
> I think that we know the answer in the general sense, just not in the
> specific sense of being able to define the bits and manage operational
> concerns and other protocol design constraints.
> > My main goal here is to have some reasonable level of confidence that we
> > are not putting ourselves in a position that will be hard or impossible
> to
> > get out of in the future.  Depending on what assumptions we are making,
> it
> > may be very easy or somewhat less easy to achieve such confidence, but
> > deferring entirely to future versions of the protocol without information
> > on how or when such version(s) will appear leaves me without much
> > confidence on that front.
> The working group reached that confidence.  I don't know how much effort
> I'm able to devote now to helping you reach that state.  Perhaps other
> participants would like to offer their help now.