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

From: Jana Iyengar <[email-masked]>
Date: Tue, 08 Oct 2019 15:41:11 -0700

@ekr is right that the PR doesn't resolve the original issue about the ordering. @martinthomson : is there a reason for the ordering?

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 09 Oct 2019 16:54:54 -0700

Oh, I completely missed the question about ordering in there.  Reading comprehension fail on my part.  I've tweaked the proposed fix to account for this.  Specifically:

> This comparison can be performed for every inbound datagram.  Endpoints MAY skip this check if packets from a datagram are successfully processed.  However, the comparison MUST be performed when the first packet in an incoming datagram either cannot be associated with a connection, cannot be decrypted, or is identified as a duplicate.

Note that I've switched this to datagram rather than packet, so match the sending and to allow for variations in how packets are assembled into datagrams.

I think that fixes it, but I'll wait for input on the new changes before reattaching `proposal-ready`.

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

---

From: Christian Huitema <[email-masked]>
Date: Sat, 12 Oct 2019 20:26:10 -0700

Can someone explain to a dumb guy like me why this is important? We have three paths:

1) Good packet: decrypt, validate, and then process the data in the packet.

2) Stateless reset: attempt to decrypt, fail, find a match for a registered reject token, kill connection.

3) Garbage: attempt to decrypt, fail, do not find a match, do nothing.

I content that (1) and (2) are observable no matter what. If the connection goes on as in (1), further packets can be observed. If the connection stops, absence of further packets can be observed. The behavior after (3) depends on the state -- if the connection is up, further data will come out as in (1). If the connection is down, nothing will happen.

What exactly is the concern?

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Oct 2019 10:40:46 -0700

Christian, the original text required that we only evaluate 2 after failing to match on 1 (i.e., fail to decrypt).  The new text allows any order of operations.

The secondary thing is that 2 needs to be constant time for each stateless reset token.

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

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 15 Oct 2019 10:48:09 -0700

Thanks for the updated PR, @martinthomson. I think this resolves @ekr's concern.

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

---

From: Lars Eggert <[email-masked]>
Date: Wed, 16 Oct 2019 14:15:40 -0700

Discussed in Cupertino. #2993 to be merged following consensus call.

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Oct 2019 22:29:37 -0700

Closed #2152 via #2993.

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