Subject: [quicwg/base-drafts] Version numbers (#113)

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Jan 2017 20:44:13 -0800

This defines what a version number is and carves out space for us.

I've added a section on what can change between versions.  Right now, I've identified what I believe to be the absolute minimum that has to stay constant.  This is made easier because it only relates to packets that are exchanged before a connection is setup.  Closes #55.

I've aligned the version negotiation section with the recent changes to -tls.  That includes the client including a version in all packets prior to the commencement of packet protection.

I'm laying some groundwork for later changes here.  I'll build on this when I define the transport parameters, stealing from #99.

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

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

-- Commit Summary --

  * Big endian
  * Define version negotiation more thoroughly
  * Reserve space
  * not off

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/113.patch
https://github.com/quicwg/base-drafts/pull/113.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/113

---

From: Mike Bishop <[email-masked]>
Date: Wed, 04 Jan 2017 11:07:09 -0800

MikeBishop approved this pull request.

Looks good, with a few nits.

> -values specified in this document are in little-endian format and all field
-sizes are in bits.
+referenced in subsequent mechanisms.
+
+All values specified in this document are in big-endian format and all field
+sizes are in bits.  When discussing individual bits of fields, the least
+significant bit is referred to as bit 0.  Hexadecimal notation is used for
+describing the value of fields.
+
+
+## Versions
+
+QUIC versions are identified using a 32-bit value.
+
+The version 0x00000000 is reserved to represent an invalid version.  This
+version of the specification is identified by the number 0x00000001.

I note, not as an objection, that I'll need to substantially change my Alt-Svc v= encoding to accommodate this format.  Thanks.  ;-)

> +version of the specification is identified by the number 0x00000001.
+
+Versions with the most significant 16 bits of the version number cleared are
+reserved for use in future IETF consensus documents.
+
+\[\[RFC editor: please remove the remainder of this section before
+publication.]]
+
+The version number for the final version of this specification (0x00000001), is
+reserved for the version of the protocol that is published as an RFC.
+
+Version numbers used to identify IETF drafts are created by adding the draft
+number to 0xff000000.  For example, draft-ietf-quic-transport-13 would be
+identified as 0xff00000D.
+
+Versions of QUIC that are used for experimentation are coordinated on the

Should we reserve a range for experimentation as well as suggesting where to coordinate?

-* If the client's version is not acceptable to the server, the server MUST send
-  a Version Negotiation packet to the client.  This packet will have the VERSION
-  flag set and will include the server's set of supported versions.  On
-  subsequently received packets for the same connection ID with the unacceptable
-  version, the server MUST continue responding with a Version Negotiation
-  packet.
+If the packet contains a version that is acceptable to the server, the server
+proceeds with the handshake ({{handshake}}).  All subsequent packets sent by the
+server MUST have the VERSION flag unset.  This commits the server to the version
+that the client selected.

This seems somewhat contradictory to the text about server triggering Version Negotiation if the ALPN token and the selected version don't line up.  The QUIC version may be acceptable, but the server and client have no mutual application protocols that allow it, for example.

The "verify that you would have sent that version list if offered this initial version" requirement gets into that, too.

-- 
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/113#pullrequestreview-15174988

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Jan 2017 16:45:00 -0800

martinthomson commented on this pull request.

+

The thought was that the remainder of the space is for experimentation.  See also RFC 6648.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Jan 2017 16:49:03 -0800

Yeah, I have a separate change that removes the text on triggering version negotiation based on the ALPN token.  This is simpler: negotiate a quic version, then negotiate an application protocol based on what is permitted within QUIC.

I haven't done a thorough analysis of what effect that has on the downgrade situation though.  So there might be some potential avenues of attack on the unauthenticated part of the negotiation.  My hope is that the version fields we've got in the transport parameters will detect those sorts of attack, but I'm not sure yet.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Jan 2017 16:59:13 -0800

-sizes are in bits.

Oh, I see, you have chosen to represent the version as a string rather than a number.  I was just copying what Jana had in his proposal, I didn't think to check what you had in your example.  I have a slight preference for the simplicity of numbers here, but there are some aesthetic advantages of what you have.  I've put some more comments over there.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Jan 2017 13:58:10 -0800

@martinthomson pushed 1 commit.

abf7dcf  Move version section to the top level

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/113/files/3b5d3d4d9c6eed41ceb85f13c5d9a1e443c69917..abf7dcf5b794dbf33055f2178f265ee4fac14efb

---

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Jan 2017 14:33:57 -0800

Merged #113.

-- 
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/113#event-916691980

---

From: martinduke <[email-masked]>
Date: Tue, 10 Jan 2017 11:40:20 -0800

martinduke commented on this pull request.

I believe this addresses the concerns I had. I assume the "length of the flags" field leaves open the possibility that a MORE_FLAGS bit might indicate two or more flag bytes at the front of the packet, if that's the way we decide to go.

Potentially splitting a > 64 bit conn id is a little strange, but I can deal with it for packets with the version flag.

Nice work.

-- 
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/113#pullrequestreview-15995817

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Jan 2017 13:39:29 -0800

This does prevent MORE_FLAGS from being used when version negotiation is present unless the flags appear after the version field.

-- 
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/113#issuecomment-271706200

---

From: martinduke <[email-masked]>
Date: Tue, 10 Jan 2017 15:53:23 -0800

As a semantic matter, I believe saying "the location and size of the Flags field" can't change defers to whatever we end up putting in the flags field description for the initial version. 

Although I mildly disagree with your preference, given the wording perhaps this is something to argue out when someone specifies the MORE_FLAGS bit.

-- 
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/113#issuecomment-271735848