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 <[email protected]> On Behalf Of Jana Iyengar Sent: Thursday, January 7, 2021 2:39 AM To: Martin Thomson <[email protected]> Cc: WG Chairs <[email protected]>; [email protected]; The IESG <[email protected]>; Lars Eggert <[email protected]>; QUIC WG <[email protected]>; Benjamin Kaduk <[email protected]> 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 <[email protected] <mailto:[email protected]> > 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.
smime.p7s
Description: S/MIME cryptographic signature
