On Thu, Jan 07, 2021 at 03:52:00PM +1100, Martin Thomson wrote: > 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.
By way of clarification, allow me to phrase a related (if not identical) concern in a way that closely adheres to the RFC 2026 requirements for a Proposed Standard specification: 1) is this an unresolved design choice? 2) did the WG resolve a design choice by concluding that it is safe to defer creation of a version downgrade protection mechanism? 3) if yes, what assumptions were used to make that choice? 4) are those assumptions valid? Most of the discourse in my ballot position involved inferences and assumptions as to the answers to (2) and (3), leaving uncertainty about (4). Thank you for continuing on an attempting to answer; I would prefer if we do not spend too much energy on the "appropriate use of DISCUSS" topic and attempt to conclude the technical discussion quickly instead. > 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. 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? > * 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. 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. > 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. This helps some, and I'm happy to hear that the WG is committed to solving the problem. 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". This might touch on things like: - is the only "future version" we care about IETF v2? - what role will non-standards-track versions play in the global ecosystem? - what does "safe" mean in that statement? - what properties are needed for a version downgrade mechanism to be called "secure"? (I recognize that answering that last one may end up being nearly as hard to answer as actually solving the problem.) 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. Thanks, Ben
