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

[Benjamin Kaduk <[e-mail]>]

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