Hi, Ben, Top-posting here - I think one other point that is worth remembering, is that the QUIC working group also has https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/, which seems like a fine place for recommendations about deployment of specific versions and withdrawal of other versions.
In my mind, there are two cases. Either - QUICv1 is "secure enough", so using it is OK even if QUICv2 would be better, or - QUIVv1 is not "secure enough", so downgrading will be a problem. People can deploy QUIC using a variety of implementation strategies, but given that the QUIC implementation is likely at least a library, and may be a library bound to a specific application, it would be reasonable to say "QUICv1 is not secure enough, so stop using QUICv1 as soon as possible", and let implementers and deployers put out versions of applications that aren't bound to QUICv1 at all. (This discussion is slightly weird to me, because the last time I asked about "QUICv2", the answer I got was that we're more likely to run for some time with QUIv1 + extensions, but even then, my intention when QUIC was chartered, was that deploying new versions should be orders of magnitude than the universal deployment of a new version of TCP, for instance, and withdrawing QUICv1 should be a lot easier than withdrawing TCPv4). I'm sure everyone will Do The Right Thing, of course. Best, Spencer On Thu, Jan 7, 2021 at 5:18 PM Benjamin Kaduk <[email protected]> wrote: > 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 > >
