Subject: [quicwg/base-drafts] Ben Kaduk's Transport Discuss 1 (#4607)

From: Lucas Pardue <[email-masked]>
Date: Wed, 06 Jan 2021 16:49:20 -0800

@kaduk said:

> This document defers creation of a downgrade protection mechanism for
> version negotiation; after all, if there is only one version in
> existence, there is nothing to negotiate.  However, an effective
> downgrade protection mechanism requires support from all potentially
> affected parties in order to be reliable, so some careful thought is in
> order.  If we limit ourselves to a mindset where QUIC versions are
> infrequent undertakings brought about by standards action (i.e., we
> don't have to worry until a "v2" exists), then deferring seems to be
> okay (but part of the Discuss is to confirm that my reasoning is valid).
> The main goal of downgrade protection is to be able to distinguish a node
> that only supports v1 (or in general, any single version, or set of
> versions that only has one overlapping version with the peer) from one
> that supports a different shared version but was tricked by an attacker
> into using v1 when it otherwise would have used a different version.
> I'll call that different version v2 for clarity.  However, if the peer
> only supports v1, there's nothing to distinguish and nothing to
> negotiate; it suffices to ensure that all nodes that are capable of v2
> support the downgrade protection scheme.  That is, an attacker can only
> change the negotiated protocol version (as opposed to just causing
> connection failure, which can be done in many other ways) if there is
> some shared version other than v1 that would have been negotiated in the
> absence of the attacker.  So, if v2 is definitly going to be
> defined+implemented before other versions, and all nodes that support v2
> support downgrade protection, we are guaranteed that in any case where
> two peers would negotiate v2 in the absence of an attack, both peers
> support the downgrade protection mechanism and thus that mechanism will
> be effective in the face of an attack.  Peers that don't support the
> mechanism only do v1 and so there is no downgrade possible when they are
> participating in the connection.  (We would, of course, still need to be
> confident that we could define such a downgrade protection scheme in a
> backwards-compatible manner, though this seems like a fairly low bar
> given the extensibility provided by transport parameters and frame
> types.)
> 
> However, it's not clear to me that this assumption holds that v2 is
> going to be the next version and that every node that implements v1 and
> some other version will definitely implement v2.  In particular, we
> currently have a very open registration policy for new versions, and
> there may be a desire to have some custom version of QUIC, perhaps that
> only has a small difference from v1, and furthermore a desire to use
> that custom version when available but be able to use v1 when not
> available.  There might be multiple such new versions in development in
> parallel, with no clear "first new version" tasked with the
> responsibility to develop a downgrade protection mechanism for global
> use.  The interaction between multiple competing downgrade-protection
> mechanisms seems likely to become quite messy quite quickly, so I am
> inclined to see "make each non-standards-track version specify their own
> downgrade protection" as a non-starter.
> 
> I think that the lack of a secure downgrade protection mechanism is
> fundamentally incompatible with an open procedure for creating new
> versions while claiming that the protocol is a secure protocol.  While it
> would not be a pleasant choice, I think we might be forced to require
> standards action for new QUIC versions until we have a single global
> downgrade protection mechanism defined.  Or perhaps I misunderstand the
> ecosystem that we are trying to produce, or am making erroneous
> assumptions.  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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4607

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Jan 2021 17:07:11 -0800

Responded via email.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4607#issuecomment-755818398

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Jan 2021 19:22:26 -0800

My mistake; I haven't responded to this DISCUSS yet.  I will do so shortly.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4607#issuecomment-755857418

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 08 Jan 2021 09:33:21 -0800

Martin did so (shortly): see https://mailarchive.ietf.org/arch/msg/quic/_JWqxGPDm5TcLkeb5T6cODfFH_Q/

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4607#issuecomment-756896869

---

From: Martin Thomson <[email-masked]>
Date: Sun, 10 Jan 2021 18:56:21 -0800

Closed #4607 via a3039ffb8d483125c765449ef7d215131e258e2c.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4607#event-4188768425