Subject: Re: [quicwg/base-drafts] Allow Smaller Stateless Resets (#2927)

From: martinduke <[email-masked]>
Date: Tue, 03 Sep 2019 09:50:43 -0700

I don't understand what this is trying to specify. The stateless reset sender has no idea what CID length the peer has chosen (except for the 20 bytes limit), so I don't see how to guarantee that the Reset exceeds minimum size without allowing for the full 20 bytes.

Unless this PR is trying to say that it's OK to go smaller if you're willing to risk 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/2927#issuecomment-527543789

---

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Sep 2019 17:42:02 -0700

It's pretty much "it's OK to go smaller if you are willing to risk stateless reset messages being identifiable", but a little stronger than that.  The sender of a stateless reset is now no longer bound by the upper limit on connection ID size.  That allows for a smaller packet to be sent and still have it get a stateless reset in response.

However, the onus for ensuring that the resulting stateless reset is indistinguishable from regular packets moves to the endpoint that would receive the stateless reset.  It has to ensure that it never sends a packet small enough that a stateless reset packet would be too small to appear as valid.

For instance, take the case where a client needs at least 8 bytes of connection ID, but the server had no connection ID.  Though the client has no real need to send larger packets toward the server, it has to pad outbound packets so that the server, should it be forced to send a stateless reset, wouldn't end up sending a packet that appears to have a 7 byte connection ID (which, assuming an observer knows about the client's constraints, would be easy to identify as a stateless reset).

-- 
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/2927#issuecomment-527692685

---

From: martinduke <[email-masked]>
Date: Thu, 05 Sep 2019 08:17:41 -0700

I find this text to be really unclear. Furthermore, if implementers don't pick up the SHOULD we're going to have detectable stateless resets all over the place.

And given the final version of extended connection IDs, we're talking about 2 additional bytes over the draft-20 status quo?

I don't find this change to be necessary, though I wouldn't raise a huge stink about it. However, I'd like to consider changing SHOULD to MUST. This seems like a potential security vulnerability.

At an absolute minimum, I'll propose an editorial rewrite to make these considerations 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/2927#issuecomment-528419864

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Sep 2019 17:11:26 -0700

In coming back to this, I can agree with Martin.  This is very unclear.

-- 
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/2927#issuecomment-528654658