Re: Benjamin Kaduk's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Thu, 07 January 2021 23:18 UTC
Return-Path: <kaduk@mit.edu>
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 1550D3A0CED; Thu, 7 Jan 2021 15:18:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 pfgjTVq2pdpj; Thu, 7 Jan 2021 15:18:32 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C7C3A0AD8; Thu, 7 Jan 2021 15:18:31 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 107NIJ7Q002283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 7 Jan 2021 18:18:24 -0500
Date: Thu, 07 Jan 2021 15:18:19 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>, lars@eggert.org, quic@ietf.org, draft-ietf-quic-transport@ietf.org, quic-chairs@ietf.org
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT)
Message-ID: <20210107231819.GO93151@kduck.mit.edu>
References: <160996950953.25754.14270013028683006869@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <160996950953.25754.14270013028683006869@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/7opR8mC265cswneJNkAAx1v8Alk>
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 23:18:39 -0000
Thanks everyone for the productive discussion. It's clear that there's a lot of background available to those who participated in the previous WG discussions but (understandably!) did not make it into the document itself, and I appreciate the effort that was put in to help share that with me. Just to state it clearly, at no point has my position been that QUIC v1 needs to be delayed until a complete version negotiation story exists. As this was a "discuss discuss", my goal was to obtain more information about the actual situation in order to confirm that there are no significant issues, since my interpretation of the text in the document itself left that possibility open. Attempting to summarize salient points: - the IETF is only currently defining bindings for HTTP over QUIC, though other entities are free to define their own protocol over QUIC at any time. - the only way currently defined to discover a QUIC endpoint to use as server for a given HTTP service is the Alt-Svc header field, which uses an ALPN value to indicate the protocol to use; it is perhaps not fully nailed down that the ALPN value will be specific to a particular version of QUIC but the ALPN vlaue probably will be specific to a particular version of QUIC. - (SVCB is in the works, too, but may not be able to meet all the needs for this purpose.) - Anyone doing non-HTTP or non-Alt-Svc is presumed to be configuring it out of band and thus can provision the QUIC version to use along with other provisioned information; in-band version negotiation is not needed in that case. If needed (e.g., we cannot build a secure downgrade protection mechanism), this or similar techniques could be used generically. - A downgrade protection mechanism solely in-band at the QUIC layer will not be a complete solution for existing protocols that may also fall back to a TCP binding (or new protocols that need to traverse networks like the Internet that don't reliably pass UDP in the ways QUIC needs). New protocols over QUIC that are berift of such legacy would have a complete solution, though. - There seems to be a desire to have only zero or one functional downgrade prortection/version negotiation mechanism, globally. - (There is a corresponding desire to have zero non-functional downgrade protection/version negotiation mechanisms.) - In accordance with the previous two points, it's expected that a downgrade protection/version negotiation scheme, when specified, will be in an IETF standards-track protocol specification. (This document does not necessarily have to be a new QUIC version, as I understand it, though is not a blocking dependency until there is such a new version.) - In particular, we do *not* expect non-IETF QUIC versions to define their own downgrade protection scheme. They are expected to either pick up the IETF one (when it exists) or just only use a single version at a time, possibly with out of band configuration. I've attempted to update the text in the document to reflect my understanding of the current WG expectations (as summarized above), in a PR at https://github.com/quicwg/base-drafts/pull/4697 . Obviously, if my summary above is incorrect, that PR is not expected to be useful. In particular, since we do *not* expect or want non-IETF QUIC versions to be attempting to specify a downgrade protection scheme, the scope of the problem space seems sufficiently restricted that we have ample time to come up with something good and not find ourselves reacting to events out of our control. The phrasing in the -33 suggests, at least to me, that *any* future version of QUIC, including one developed outside the IETF, might update version negotiation handling, which is where my perception of risk arose. I've tried to refrain from expounding on topics that are not actually relevant, but since I'm prone to doing so I may have let some sneak in anyway... Thanks again, Ben
- 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