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

Eric Rescorla <> Thu, 07 January 2021 16:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E6E33A128E for <>; Thu, 7 Jan 2021 08:57:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l0wQh8esY7jb for <>; Thu, 7 Jan 2021 08:57:13 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9902D3A1292 for <>; Thu, 7 Jan 2021 08:57:12 -0800 (PST)
Received: by with SMTP id o13so16216990lfr.3 for <>; Thu, 07 Jan 2021 08:57:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6Cu0A9GnceJ44N2y6I1bHSEOg1/rNuyGR2maNxYTVtc=; b=zt4LmSCBATdqhQDDUeSkLxzIVrezQgmkjboaAKURVFSA9Tyk+ZKofS/pD6nAHcoXDI CFPDPpnMWHxtadMTQsf1hry5btJd1T8PuwwsVhnjvnoRzgLzfotz3MRkuBmJVdJPWRT5 bkbyR/uU3aEDdAMM80WlHVuJA1BqSJbXosKiygJ2kJgnr35W15Ao/KtTwkYPA+1PKk8/ wbM0teezrtvrwVm6AC+VAR9bI/duaQSBKRERf58u66nTsTDkLBVrp5AAY/Du00kP8nIw xt36PLMjW8M9TghSTFpP4TQsnIpr8Lvn7NgmuQJkkPzi5Spkx+pexixUAacMKx6ojoYw LyHA==
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=6Cu0A9GnceJ44N2y6I1bHSEOg1/rNuyGR2maNxYTVtc=; b=DKpj2Fr1ESHQNnva0PJNIQdXjkTMwvVa5u2OJbGLlPsT4KAe33Q5La73VlzL8ZI29q B7nUT2gbMYn6TCGrcAcsBITB8AJS2IlxdFdboSJIMjSXk2eJ+z/aLLyD2p8uSDUrsvce Vk7VdjAHXsBtj+8eZisMSlECdcUI8Z0AVRKwdo/sScZ/jnVqIZ+Gnub29dFfOTyoMcJM elDSSsbMbmt6kWDLFLJRzWlRdwBncZ/S77OMXA+lSh4XAFr+GIM32hA82FQmz2/gffry huytBtugueXX1j/rRP4ZjTuxD9aTT0ZXpzua1EswQpONXztGCABwGuwr4unBJUW8m5uL /g7g==
X-Gm-Message-State: AOAM533NmdRpLVqgk6mRuMGQksdaSjBaZeHTX2ZaXkrsrR2K+Cw1IjSj z+zhRiaWHkRSeO2ikLgj0YMdZbgpfRP4byc8GCAaWg==
X-Google-Smtp-Source: ABdhPJyrEMGUgAtt4356CyZrgFMyPBfX9jEx7A5knFj81Sp+cYAH9LyU6fC1PJsjW8vffczARgIbQgSho4pjkDL3roU=
X-Received: by 2002:a2e:9f53:: with SMTP id v19mr4348483ljk.109.1610038630424; Thu, 07 Jan 2021 08:57:10 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Thu, 07 Jan 2021 08:56:34 -0800
Message-ID: <>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT)
To: Mike Bishop <>
Cc: Jana Iyengar <>, Martin Thomson <>, WG Chairs <>, "" <>, The IESG <>, Lars Eggert <>, QUIC WG <>, Benjamin Kaduk <>
Content-Type: multipart/alternative; boundary="000000000000a4372205b8525471"
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 16:57:16 -0000

I mostly agree with what others have said here.

For the record, my view was that the WG should define what
draft-ietf-quic-version-negotiation calls "compatible" version negotiation
(i.e., where the Initial was valid for both version N and N+1) but not
"incompatible" negotiation. However, the WG consensus was to negotiate
neither. I believe it is possible to add version negotiation safely to QUIC
after v1 is published, as evidenced by the fact that a design for this
already exists in draft-ietf-quic-version-negotiation. ISTM that this falls
into the category of "informed WG decisions".

To clarify one point, Jana writes:
"If anyone else deploys a vN, the only way we are providing to use it is
through Alt-Svc." This is true, but as noted above, the mechanism defined
in the current draft the WG is working on would allow a version N+1/version
N client to safely offer version N+1 to servers even without an alt-svc
hint, which I believe is the right VN target (this is what, for instance,
TLS allows).


On Thu, Jan 7, 2021 at 7:16 AM Mike Bishop <> wrote:

> To expand on the Alt-Svc case slightly; we removed the “version hint” ALPN
> extension from HTTP/3, but later made a decision that an ALPN token can
> imply a QUIC version, so offering a set of ALPNs implies the set of
> supported QUIC versions.
> *From:* QUIC <> *On Behalf Of *Jana Iyengar
> *Sent:* Thursday, January 7, 2021 2:39 AM
> *To:* Martin Thomson <>
> *Cc:* WG Chairs <>;;
> The IESG <>; Lars Eggert <>; QUIC WG <
>>; Benjamin Kaduk <>
> *Subject:* Re: Benjamin Kaduk's Discuss on draft-ietf-quic-transport-33:
> (with DISCUSS and COMMENT)
> Ben,
> 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.