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

Eric Rescorla <ekr@rtfm.com> Thu, 07 January 2021 16:57 UTC

Return-Path: <ekr@rtfm.com>
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 0E6E33A128E for <quic@ietfa.amsl.com>; Thu, 7 Jan 2021 08:57:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 l0wQh8esY7jb for <quic@ietfa.amsl.com>; Thu, 7 Jan 2021 08:57:13 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9902D3A1292 for <quic@ietf.org>; Thu, 7 Jan 2021 08:57:12 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id o13so16216990lfr.3 for <quic@ietf.org>; Thu, 07 Jan 2021 08:57:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; 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; d=1e100.net; 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: <160996950953.25754.14270013028683006869@ietfa.amsl.com> <39c24306-42dc-454a-8a60-cfbd86ab6c64@www.fastmail.com> <20210107065404.GH93151@kduck.mit.edu> <98093648-fed4-4da1-8e25-171c6770431e@www.fastmail.com> <CACpbDcdknN5T9a_TFAr2_0KAvnvQ6c1432wQJ3xwSbVQZwkc2g@mail.gmail.com> <CH2PR22MB2086CCC9463F86BB73BD109DDAAF0@CH2PR22MB2086.namprd22.prod.outlook.com>
In-Reply-To: <CH2PR22MB2086CCC9463F86BB73BD109DDAAF0@CH2PR22MB2086.namprd22.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 07 Jan 2021 08:56:34 -0800
Message-ID: <CABcZeBPU1G9SZWkBAw-d-n7GC99JE7QiJnmVN1xyrydy7kKpzQ@mail.gmail.com>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT)
To: Mike Bishop <mbishop@evequefou.be>
Cc: Jana Iyengar <jri.ietf@gmail.com>, Martin Thomson <mt@lowentropy.net>, WG Chairs <quic-chairs@ietf.org>, "draft-ietf-quic-transport@ietf.org" <draft-ietf-quic-transport@ietf.org>, The IESG <iesg@ietf.org>, Lars Eggert <lars@eggert.org>, QUIC WG <quic@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
Content-Type: multipart/alternative; boundary="000000000000a4372205b8525471"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/JHexfmjQzJh5VTYVllGwwmvyP9M>
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: 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).

-Ekr




On Thu, Jan 7, 2021 at 7:16 AM Mike Bishop <mbishop@evequefou.be> 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 <quic-bounces@ietf.org> *On Behalf Of *Jana Iyengar
> *Sent:* Thursday, January 7, 2021 2:39 AM
> *To:* Martin Thomson <mt@lowentropy.net>
> *Cc:* WG Chairs <quic-chairs@ietf.org>; draft-ietf-quic-transport@ietf.org;
> The IESG <iesg@ietf.org>; Lars Eggert <lars@eggert.org>; QUIC WG <
> quic@ietf.org>; Benjamin Kaduk <kaduk@mit.edu>
> *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 <mt@lowentropy.net> 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.
>
>