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. > >
- Benjamin Kaduk's Discuss on draft-ietf-quic-trans… Benjamin Kaduk via Datatracker
- Re: Benjamin Kaduk's Discuss on draft-ietf-quic-t… Lucas Pardue
- Re: Benjamin Kaduk's Discuss on draft-ietf-quic-t… Martin Thomson
- Re: Benjamin Kaduk's Discuss on draft-ietf-quic-t… Benjamin Kaduk
- Re: Benjamin Kaduk's Discuss on draft-ietf-quic-t… Martin Thomson
- Re: Benjamin Kaduk's Discuss on draft-ietf-quic-t… Jana Iyengar
- Re: Benjamin Kaduk's Discuss on draft-ietf-quic-t… Mikkel Fahnøe Jørgensen
- RE: Benjamin Kaduk's Discuss on draft-ietf-quic-t… Mike Bishop
- Re: Benjamin Kaduk's Discuss on draft-ietf-quic-t… Eric Rescorla
- Re: Benjamin Kaduk's Discuss on draft-ietf-quic-t… Benjamin Kaduk
- Re: Benjamin Kaduk's Discuss on draft-ietf-quic-t… Eric Rescorla
- Re: Benjamin Kaduk's Discuss on draft-ietf-quic-t… Spencer Dawkins at IETF
- Re: Benjamin Kaduk's Discuss on draft-ietf-quic-t… Martin Duke