Responding to the DISCUSS point only: On Thu, Jan 7, 2021, at 08:45, Benjamin Kaduk via Datatracker wrote: > This is very much a "discuss discuss", and I am not strongly convinced > that there is a problem here, but if there is a problem it is a fairly big > one. > [... many words on version negotiation removed...] > > I'd love to hear more about how the WG decided to proceed > with the current formulation, especially with regard to what > consideration was given to non-standards-track new versions.
I think that this is the key ask here. I don't think that this is an appropriate use of DISCUSS, I believe that the working group consensus is clear and clearly documented, but I'll attempt to answer faithfully nonetheless. The working group came to the conclusion around half way though the design process that we did not have a firm understanding of what it meant to authenticate the choice of QUIC version. We had mechanisms proposed, but we found either operational issues or ways to circumvent the protections in those proposals. Given those discoveries, we made a decision to defer protections for version negotiation until after version 1 was deployed. This comes with risks, though I don't think that uncoordinated development of mechanisms is the primary one. The primary risk is that we never publish a workable design. It is a hard problem, after all. Other relevant points made in that discussion: * You don't need to rely on version negotiation to deploy a new version, in the extreme case where we fail to secure it. We have Alt-Svc, for instance, which is secure enough for HTTP (though I will concede that SVCB isn't good enough). Indeed, we want to avoid the performance hit of version negotiation for those applications anyway, so we're unlikely to be affected. * The problem only exists if you have both clients and servers willing to support two different versions and the least preferred (or worst) doesn't provide any downgrade protection. Non-standards track versions that have no intent of coexisting with version 1 are therefore not a downgrade risk. * Addressing version downgrade in QUIC doesn't address the problem of downgrade from QUIC to TCP (or vice versa if you prefer the other order). That said, we probably have to tolerate that sort of downgrade, at least for the moment. Ultimately, the working group is committed to solving the problem. There is adopted draft on defining a form of version negotiation. I've also recently updated draft-thomson-tls-snip which attempts to solve the problem more generally, including addressing the question of TCP/QUIC downgrade, which nothing this working group does will ever address. Not a lot of engagement on that, but I think what it reveals - in addition to this being HARD - is how the problem is not necessarily limited to QUIC. There has been a lot more discussion on this point than the above, and I have likely missed other key points, but I hope that this will suffice and we can get back to the YES position promptly. > The above notwithstanding, I support this protocol and I expect to > change my position to Yes once this point is resolved in some manner. Cheers, Martin
