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

[Benjamin Kaduk <[e-mail]>]

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