Subject: [quicwg/base-drafts] Why does stateless reset have to be checked after MAC failure (#2152)

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 11:41:28 -0800

```
An endpoint detects a potential stateless reset when a packet with a short
header either cannot be decrypted or is marked as a duplicate packet.  The
endpoint then compares the last 16 bytes of the packet with the Stateless Reset
Token provided by its peer, either in a NEW_CONNECTION_ID frame or the server's
transport parameters.  If these values are identical, the endpoint MUST enter
the draining period and not send any further packets on this connection.  If the
comparison fails, the packet can be discarded.
```

Why does the text mandate this order? You need a constant time comparison in any case.

-- 
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/issues/2152

---

From: Mike Bishop <[email-masked]>
Date: Thu, 13 Dec 2018 12:16:50 -0800

I'm not sure the order is (intended to be) normative.  An SR looks like a junk packet that you would otherwise drop, either because it doesn't match a known connection by CID, or because it happens to match a known CID (zero-length helps) but gives a whacko packet number compared to the connection state, or because the packet number looks reasonable but the MAC is bad.

In those situations, you then have to decide whether it's just junk or actually a SR.  So the order is what we expect a logical implementation would do, but not necessarily required.  Can you propose better explanatory text for that?

-- 
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/issues/2152#issuecomment-447106218

---

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 21:05:38 +0000 (UTC)

Sure, but I have to get my other issues from my read-through in first.

On Thu, Dec 13, 2018 at 12:16 PM Mike Bishop <[email-masked]>
wrote:

> I'm not sure the order is (intended to be) normative. An SR looks like a
> junk packet that you would otherwise drop, either because it doesn't match
> a known connection by CID, or because it happens to match a known CID
> (zero-length helps) but gives a whacko packet number compared to the
> connection state, or because the packet number looks reasonable but the MAC
> is bad.
>
> In those situations, you then have to decide whether it's just junk or
> actually a SR. So the order is what we expect a logical implementation
> would do, but not necessarily required. Can you propose better explanatory
> text for that?
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/2152#issuecomment-447106218>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABD1oc052jJJFKds92ObK9YEXS8-ZQ84ks5u4rWwgaJpZM4ZSSuW>
> .
>

-- 
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/issues/2152#issuecomment-447120346