Subject: [quicwg/base-drafts] Stateless Reset Cleanup (#1328)

From: martinduke <[email-masked]>
Date: Wed, 25 Apr 2018 15:29:16 -0700

The Stateless Reset is just a bunch of random bytes except the first one and the token, so I simplified the spec to reflect that.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Stateless Reset Cleanup

-- File Changes --

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

-- Patch Links --

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

---

From: martinduke <[email-masked]>
Date: Wed, 25 Apr 2018 22:35:56 +0000 (UTC)

@martinduke pushed 1 commit.

23a4113  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1328/files/ac31d5927fbac3a34a2750f533fb344b1c8af515..23a4113a59d06254e759ca8d595f04e950d51328

---

From: martinduke <[email-masked]>
Date: Wed, 25 Apr 2018 15:37:41 -0700

The spec is clear that the CID is random, so it's all just random bytes between the short header byte and the token.

However, an alternate way to improve this section is to leave it pretty much the same, except to say that if the stateless reset is in response to a long header, servers should use the SCID instead.

Either is fine with me.

-- 
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/1328#issuecomment-384455866

---

From: Mike Bishop <[email-masked]>
Date: Thu, 26 Apr 2018 09:21:54 -0700

MikeBishop commented on this pull request.

Not unreasonable.

> @@ -2015,9 +2011,27 @@ following layout:
 This design ensures that a stateless reset packet is - to the extent possible -
 indistinguishable from a regular packet with a short header.
 
-A server generates a random 18-octet Destination Connection ID field.  For a
-client that depends on the server including a connection ID, this will mean that
-this value differs from previous packets.  Ths results in two problems:
+The message consists of a packet header, followed by random octets of arbitrary
+length, followed by a Stateless Reset Token.
+
+The server SHOULD send a packet with a short header and a packet number length
+of 1 octet. Using the hortest possible packet number encoding minimizes the

shortest

> -this value differs from previous packets.  Ths results in two problems:
+The message consists of a packet header, followed by random octets of arbitrary
+length, followed by a Stateless Reset Token.
+
+The server SHOULD send a packet with a short header and a packet number length
+of 1 octet. Using the hortest possible packet number encoding minimizes the
+perceived gap between the last packet that the server sent and this packet.  A
+server MAY indicate a different packet number length, but a longer packet number
+encoding might allow this message to be identified as a stateless reset more
+easily using heuristics.
+
+The random octets MUST be of a length equal to at least 18 octets plus the
+packet number length implied by the type field. A packet of this length
+simulates a packet with a short header, the maximum-length destination
+connection ID, a packet number of the appropriate length and (with the
+Stateless Reset Token) an authentication trailer, with no packet payload.

Are fully-empty packets permitted?  If not, perhaps we should mandate that this be slightly longer, so it appears there's a payload.

> +
+The server SHOULD send a packet with a short header and a packet number length
+of 1 octet. Using the hortest possible packet number encoding minimizes the
+perceived gap between the last packet that the server sent and this packet.  A
+server MAY indicate a different packet number length, but a longer packet number
+encoding might allow this message to be identified as a stateless reset more
+easily using heuristics.
+
+The random octets MUST be of a length equal to at least 18 octets plus the
+packet number length implied by the type field. A packet of this length
+simulates a packet with a short header, the maximum-length destination
+connection ID, a packet number of the appropriate length and (with the
+Stateless Reset Token) an authentication trailer, with no packet payload.
+
+In response to a packet with a short header, the server has no means of
+determining the source connection ID and is effectively using a random one

It might be worth being precise about source in which direction.  Maybe "The server has no means of determining a short packet's source connection ID, and therefore uses a random destination ID in the Stateless Reset packet."

-- 
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/1328#pullrequestreview-115649270

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Apr 2018 04:40:31 +0000 (UTC)

martinthomson approved this pull request.

This is a fine change, though I have a few comments.  (If @martinduke doesn't get around to these, I will do so once I've finished my post-break triage.)

Yes, let's not leak that.  The simple fix here is s/18/19/

Reasonable, though make sure to state "destination connection ID"

-- 
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/1328#pullrequestreview-116195942