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

[Eric Rescorla <[e-mail]>]

On Thu, Jan 7, 2021 at 3:18 PM Benjamin Kaduk <[e-mail]> 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.
>

I don't believe this is correct. You can simply try to connect with QUICv1.



> - 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.
>

Hmm.... Well, it obviously can't be at the QUIC layer, because you won't be
using QUIC at all, but it can be at the TLS layer.


- 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.
>

Maybe? I'm not sure there is a consensus one way or the other on this.

-Ekr