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

From: Martin Thomson <[email-masked]>
Date: Wed, 03 May 2017 21:04:16 -0700

Closes #121.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/498

-- Commit Summary --

  * Version validation fields can't move or change

-- File Changes --

    M draft-ietf-quic-transport.md (7)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/498.patch
https://github.com/quicwg/base-drafts/pull/498.diff

-- 
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

---

From: ianswett <[email-masked]>
Date: Sun, 14 May 2017 18:31:48 -0700

ianswett 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

This is a bizarre solution to this problem.  Why not say that it must define a version that indicates a change of format and base new formats on that?  Or something of that sort?

At the point we're doing version negotiation, TLS hasn't come into play, so I don't think this works.

-- 
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-38015314

---

From: Martin Thomson <[email-masked]>
Date: Wed, 17 May 2017 07:11:17 -0700

martinthomson commented on this pull request.

@ianswett, I've read this suggestion several times and I'm sorry, but I don't understand what you are trying to say.  Can you explain your alternative design in more detail?

-- 
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_r117011750

---

From: ianswett <[email-masked]>
Date: Wed, 17 May 2017 08:30:28 -0700

I misunderstood what this text was attempting to accomplish, I was thinking of transport parameters as connection ID/packet number/etc.

That being said, I'm not clear on why the transport parameter format can't be tied to QUIC version.  Can you explain more about how this attack works?

-- 
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_r117035145

---

From: MikkelFJ <[email-masked]>
Date: Wed, 17 May 2017 08:45:47 -0700

mikkelfj commented on this pull request.

If a QUIC version is defined that does not rely on TLS, how would it define transport parameters?

-- 
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_r117039469

---

From: Martin Thomson <[email-masked]>
Date: Thu, 18 May 2017 07:40:45 -0700

@ianswett, let's say that we don't change the format of the transport parameters for version 1.  We also have a server that supports version 1 and some hypothetical version 4.

With the current format, a server that selects version 1 will send advertise transport parameters starting with the bytes 0x0008, 0x00000004, 0x00000001 (a length, followed by version 4 and version 1).  After that, it will have some lengths and TLVs for parameters.

However, if version 4 decides to change the transport parameters, then the client that is subject to spoofing of a version negotiation packet might find that they interpret transport parameters differently.  If version 4 is sufficiently similar to version 1 in other ways, you could even end up in a situation where the client and server disagree on what version they are speaking.

For instance, the above value could be interpreted as being valid against a different schema.

-- 
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_r117266544

---

From: ianswett <[email-masked]>
Date: Mon, 22 May 2017 12:00:09 -0700

I believe I now understand what you're saying.  I keep thinking the entire packet is protected, but it's not.

The current wording is still a bit confusing to me, I think Victor had some suggestions on how to make it clearer.

-- 
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_r117821041