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

[Eric Rescorla <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> *On Behalf Of *Jana Iyengar
> *Sent:* Thursday, January 7, 2021 2:39 AM
> *To:* Martin Thomson <[e-mail]>
> *Cc:* WG Chairs <[e-mail]>; [e-mail];
> The IESG <[e-mail]>; Lars Eggert <[e-mail]>; QUIC WG <
> [e-mail]>; Benjamin Kaduk <[e-mail]>
> *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 <[e-mail]> 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.
>
>