Original text:
(IPv4), the DF bit MUST be set if possible, to prevent fragmentation on the path.  14.1. A client MUST expand the payload of all UDP datagrams carrying datagram with a payload that is smaller than the smallest allowed maximum datagram size of 1200 bytes.  A server MAY also immediately close the connection by sending a CONNECTION_CLOSE frame with an <del> error code of PROTOCOL_VIOLATION; see immediate-close-hs.  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. </del>  The server MUST also limit the number of bytes it sends before validating the address of the client; see address-validation.

Reviewer comments:
by adding generic "MUST NOT close, MAY discard packets" rule.
?
NAME NAME Merging this, since the plan is to do consensus as part of LC.
In , we added the following sentence, but I think it does not make sense. Generally speaking, a receiver of a datagram cannot verify if the sender sent a full-sized datagram. 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 packets, it is (almost always) possible for a MOTS 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 .
As a step forward, I think we should do the following: Regarding the sentence we added in , 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 or somewhere that datagram size is not authenticated and cannot be enforced by the peer.
NAME 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 -- of enforcing the datagram size -- that makes us vulnerable to this MOTS attack. The newly added text in 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.
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.
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?
NAME NAME I totally agree that this has to stop. I'm sorry to have missed this point when working on ; I realized the problem when I was wondering about the MUST vs. SHOULD discussion in . 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 PATHCHALLENGE / PATHRESPONSE MUST be padded to full size (), 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 has been correct. As NAME points out, 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 ) endpoints MUST pad datagrams carrying PATHCHALLENGE / PATHRESPONSE frames () endpoints MUST NOT close a connection when receiving datagrams with size requirements () rather than having two different of rules for handling small-sized datagrams, of which one does not follow the principle.
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.
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.
NAME 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.
This seems sensible.

Revised text:
(IPv4), the DF bit MUST be set if possible, to prevent fragmentation on the path. <ins> Datagrams are required to be of a minimum size under some conditions. However, the size of the datagram is not authenticated.  Therefore, an endpoint MUST NOT close a connection when it receives a datagram that does not meet size constraints, though the endpoint MAY discard such datagrams. </ins> 14.1. A client MUST expand the payload of all UDP datagrams carrying datagram with a payload that is smaller than the smallest allowed maximum datagram size of 1200 bytes.  A server MAY also immediately close the connection by sending a CONNECTION_CLOSE frame with an  <ins> error code of PROTOCOL_VIOLATION; see immediate-close-hs. </ins> The server MUST also limit the number of bytes it sends before validating the address of the client; see address-validation.