Subject: [quicwg/base-drafts] Endpoints cannot verify padding (#4253)

From: Kazuho Oku <[email-masked]>
Date: Mon, 19 Oct 2020 18:24:28 -0700

In #4183, we added the following sentence, but I think it does not make sense.
> When a client receives an ack-eliciting Initial packet that is carried in a UDP datagram with a payload that is less than 1200 bytes, that client MAY close the connection by sending a CONNECTION_CLOSE frame.

Generally speaking, a receiver of a _datagram_ cannot verify if the sender sent a full-sized packet.

That is because a datagram as a whole is not authenticated. Instead, we authenticate each of the QUIC packets that constitute the datagram.

Therefore, if the sender sends a datagram consisting of multiple QUIC packet, it is (almost always) possible for a MITM to take one of the QUIC packets, coalesce that with a few octets, and forward that _datagram_. That forwarded _datagram_ would be smaller than the original datagram.

Note also that a sender can send coalesced packet after the handshake too; see [section 14.4.1 of the transport draft](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-pmtu-probes-containing-sour).

-- 
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/4253

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 19 Oct 2020 18:28:53 -0700

As a step forward, I think we should do the following:
* Regarding the sentence we added in #4183, we should either a) change the rule to "MAY discard UDP datagrams less than 1200 bytes that carry ACK-eliciting Initial apckets", or b) delete the sentence, and
* Considering the fact that there could be other occasions in which we might want to require padding, either within the base drafts, or in some of the extensions, add a note to [section 14](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-datagram-size) or somewhere that datagram size is not authenticated and cannot be enforced by the peer.

-- 
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/4253#issuecomment-712531288

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 19 Oct 2020 20:26:26 -0700

@kazuho: I hate to make more changes, but I think your point is a good one. If a receiver does the enforcement that we added in #4188, that makes us vulnerable to this MOTS attack.

The newly added text in #4188 hasn't shipped yet in a draft, so if we can get agreement, I'd like to take this in before we ship the next draft.

-- 
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/4253#issuecomment-712564429

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Oct 2020 23:45:18 -0700

A timely reminder that making changes always results in making more changes and no matter how careful or small, there are almost always problems.  This seems like a good proposed tweak, but this has to stop.

-- 
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/4253#issuecomment-712631735

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 20 Oct 2020 01:55:06 -0700

Let us discuss what purpose that "MAY discard" rule has and compare it to the issue. What is important for an endpoint is to ensure that its path to the peer is possible to forward packets and supporting at least minimal MTU to make QUIC work. I think that requirement lies on each endpoint to ensure that. Does the client need to enforce the server behavior for that verification? Is that a risk in itself that is greater, equal or less than the MOTS risk the enforcement has? 

-- 
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/4253#issuecomment-712700192

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 20 Oct 2020 03:48:35 -0700

@martinthomson @gloinul I totally agree that this has to stop. I'm sorry to have missed this point when working on #4188; I realized the problem when I was wondering about the MUST vs. SHOULD discussion in #4241.

That said, I do think that it would be a good idea to adopt the proposal in this issue.

Let me go through the facts first. They are:
* An encrypted transport has to discard unauthenticated signals to prevent MOTS attackers from disrupting the connection.
* The size of the datagram is an unauthenticated signal throughout the lifetime of the connection. As noted above, this is the case for 1-RTT packets after handshake confirmation too.

Due to these facts, "MUST NOT close, can discard" is a principle that we've always had. The reason we hadn't written it down is because we used to have only one requirement regarding datagram length, that correctly follow the principle, stating that "servers MUST discard non-full-sized datagrams containing Initial packets."

But now that we have emerging consensus that datagrams carrying PATH_CHALLENGE / PATH_RESPONSE MUST be padded to full size (#4241), we need to write down that the receiver cannot enforce that.

Realizing that, I started to wonder if the "MAY close" rule that we added in #4188 has been correct.

As @janaiyengar points out, #4188 is a change that has not shipped yet. It's a recent change due to an issue discovered during *this* IETF last call. I do not think we have official consensus yet.

Therefore, I tend to think there would be less confusion if the next draft would contain:
* servers MUST pad datagrams carrying ack-eleciting Initial packets (the basis of #4188)
* endpoints MUST pad datagrams carrying PATH_CHALLENGE / PATH_RESPONSE frames (#4241)
* endpoints MUST NOT close a connection when receiving datagrams with size requirements (#4254)

rather than having two different of rules for handling small-sized datagrams, of which one does not follow the principle.

-- 
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/4253#issuecomment-712764115

---

From: ianswett <[email-masked]>
Date: Tue, 20 Oct 2020 05:45:19 -0700

Given we explicitly allow coalesced packets for PathMTU, I agree that closing the connection seems like the wrong thing to do.  The PR looks sensible.

-- 
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/4253#issuecomment-712822419

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Oct 2020 07:34:39 -0700

Agree with Ian.  My plea for stopping was not about the fix (the fix here is good), but the original change.  We would not have had this problem if we were able to accept that the protocol wasn't absolutely perfect.

-- 
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/4253#issuecomment-712898555

---

From: Lars Eggert <[email-masked]>
Date: Tue, 20 Oct 2020 09:32:57 -0700

@kazuho has described a way forward on the mailing list for this issue - are we good with that? If so, let's merge, close and do the consensus establishment during IETF LC.

-- 
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/4253#issuecomment-712988499

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 20 Oct 2020 13:11:12 -0700

Closed #4253 via #4254.

-- 
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/4253#event-3900589751