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

From: ianswett <[email-masked]>
Date: Tue, 01 Aug 2017 19:17:51 +0000 (UTC)

Thank you Mike for elegantly summarizing my previous confusion.

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

---

From: janaiyengar <[email-masked]>
Date: Tue, 01 Aug 2017 17:14:58 -0700

janaiyengar commented on this pull request.

> @@ -1232,6 +1232,15 @@ client MUST terminate with a VERSION_NEGOTIATION_ERROR error code if
 version negotiation occurred but it would have selected a different version
 based on the value of the supported_versions list.
 
+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

This isn't defined as a TLS extension in this document, but the format is specified as the layout for in the TransportParameters field in the quic_transport_parameters TLS extension (se line 1076 above.) I think this text probably belongs there, along with the description of the wire layout, instead of here with version negotiation. I think the text is fine, but I would move it up there.

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 02 Aug 2017 19:21:01 -0700

martinthomson commented on this pull request.

This is still the right place for the text, because it is talking specifically about version downgrade and how those are detected. Ian's comment is easy to address.

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 02 Aug 2017 19:30:17 -0700

@martinthomson pushed 1 commit.

7b05603  Attempt to address feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/498/files/c48030d34993cda46314e5daaaeaa2896b16432b..7b05603055fbe32047714a8b92cf0839761c6afc

---

From: ianswett <[email-masked]>
Date: Thu, 03 Aug 2017 15:38:07 +0000 (UTC)

ianswett approved this pull request.

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

---

From: janaiyengar <[email-masked]>
Date: Thu, 10 Aug 2017 00:34:26 +0000 (UTC)

janaiyengar approved this pull request.

LGTM, modulo readability nits.

+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.  The version field in the QUIC packet header are only authenticated

nit: are -> is
also, "is only authenticated using" -> "is authenticated using"

+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.  The version field in the QUIC packet header are only authenticated
+using the transport parameters.  The position and the format of the version
+fields in transport parameters MUST either be identical across different QUIC
+versions, or be unambiguously different in a way that ensures that there is no
+possibility for confusion about their interpretation.  One way that a new format

suggested rephrase: "be unambiguously different in a way that ensures that there is no possibility for confusion about their interpretation" --> "be unambiguously different to ensure no confusion about their interpretation"

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 09 Aug 2017 17:50:46 -0700

Merged #498.

-- 
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#event-1200105149