Subject: Re: [quicwg/base-drafts] Version validation fields can't move or change (#498)

From: Victor Vasiliev <[email-masked]>
Date: Sun, 30 Jul 2017 23:23:31 -0700

vasilvv commented on this pull request.

> @@ -1131,6 +1131,13 @@ client MUST terminate with a QUIC_VERSION_NEGOTIATION_MISMATCH error code if
 version negotiation occurred but it would have selected a different version
 based on the value of the supported_versions list.
 
+The position and size of the version validation fields in the transport
+parameters MUST NOT change between different versions of QUIC.  If a version of
+QUIC needs to define a new format for transport parameters, it MUST define and
+use a new TLS extension rather than redefine the layout of the existing

I feel like it would be clearer if you expand on the attack you’re trying to mitigate.  Something like:
“When a peer accepts multiple versions of the handshake, it can potentially interpret the handshake as defined by any of the versions it supports.  Since the QUIC protocol relies on security of the handshake for authenticating the version, the position and the format of the version field in the handshake MUST be consistent across all QUIC versions supported by the client.”

-- 
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/pull/498#discussion_r130279032

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Jul 2017 23:58:05 -0700

Thanks to @vasilvv, I have some more text.  @ianswett, can you take another look?

-- 
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/pull/498#issuecomment-318984667

---

From: ianswett <[email-masked]>
Date: Mon, 31 Jul 2017 08:53:11 -0700

ianswett commented on this pull request.

> @@ -1232,6 +1232,15 @@ client MUST terminate with a VERSION_NEGOTIATION_ERROR error code if
 
+When an endpoint accepts multiple QUIC versions, it can potentially interpret
+transport parameters as they are defined by any of the QUIC versions it
+supports. Since the QUIC protocol relies on transport parameters for
+authenticating the version, the position and the format of the version fields in
+transport parameters MUST be consistent across all QUIC versions supported by
+the client. If a version of QUIC needs to define a new format for transport
+parameters, it MUST define and use a new TLS extension for transport parameters

One request: The rest of the section on transport parameters doesn't mention TLS.  Can we change this to "a new handshake extension" or something similar to avoid adding new references to it.

-- 
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/pull/498#pullrequestreview-53262256

---

From: Mike Bishop <[email-masked]>
Date: Mon, 31 Jul 2017 21:08:00 +0000 (UTC)

It took me a couple times through the issue and the PR to figure out the actual attack here, and I don't think the current text actually captures it.  What finally clicked for me was that, although the version number is explicitly given in the packet, an on-path attacker who tried to force a version negotiation mismatch could also undetectably modify the contents of the version field in the packet header.  (Because the integrity protection / encryption on the packets at this point is trivially recalculated by an attacker.)  It's the contents of the handshake that can't be modified without detection, but we have to guard against getting just the right set of transport parameters in the future that looks like the version confirmation one would expect from the current version.

So what we're actually saying is that, if the version validation fields are in a different location in a different version of QUIC, they MUST be unmistakably different from a valid confirmation of having selected the current version or any future version that uses this handshake and transport settings format.

-- 
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/pull/498#issuecomment-319196942