Subject: Re: [quicwg/base-drafts] Let server abort on post-Retry packet number reset (#3990)

From: Lucas Pardue <[email-masked]>
Date: Tue, 01 Sep 2020 15:08:43 -0700

@LPardue commented on this pull request.

> @@ -4807,6 +4807,8 @@ responding to a Retry packet. However, the data sent in these packets could be
 different than what was sent earlier. Sending these new packets with the same
 packet number is likely to compromise the packet protection for those packets
 because the same key and nonce could be used to protect different content.
+A server MAY abort the connection if it detects that the client reset the

> Given that we don't have such a rule at the moment, I would be happy to take this text in and evaluate this with other MAYs in the general sense if there's enough interest to do it. Would you mind filing a separate issue for this?

I like Jana's suggestion. Can we take this PR and create another issue?

-- 
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/3990#discussion_r481459379

---

From: Marten Seemann <[email-masked]>
Date: Tue, 01 Sep 2020 19:54:04 -0700

@marten-seemann commented on this pull request.

> My argument for why here is because this PN reuse can be a security issue.

I disagree with this statement. There's only a security issue if the client resets the 0-RTT packet number space, but the server wouldn't be able to detect that, since it wouldn't even bother to unprotect 0-RTT packets. So the only violation that can be detected here is the reuse of packet numbers in the Initial packet number space. Since the Initial keys are publicly known anyway, this can't be a security issue.

-- 
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/3990#discussion_r481581803

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 01 Sep 2020 20:11:03 -0700

@kazuho commented on this pull request.

Generally speaking, detecting MUST violations is fine for Handshake and ApplicationData packets, after decrypting them, is fine because it will always be about a misbehaving peer, and because we do not (yet) have existing implementations that do not follow the MUSTs.

However, using information that is not protected by AEAD is going to be dangerous, as it is a potential attack vector. For unprotected data (incl. Initial packets), a reader should not assume that a MUST on the sender side implies a "MAY detect" on the receiver side. As can be seen on the issue, we discussed if we might or might not want to have a MAY here, knowing that we have a MUST on the sender side.

To summarize, I tend to believe that having an explicit MAY here makes sense.

-- 
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/3990#discussion_r481592574

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 02 Sep 2020 21:06:31 -0700

Merged #3990 into master.

-- 
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/3990#event-3722780508