Change:
Handshake packet from the client, it can consider the client address to have been validated. <ins> Additionally, a server MAY consider the client address valididated if the client uses a connection ID chosen by the server and the connection ID contains at least 64 bits of entropy. </ins> Prior to validating the client address, servers MUST NOT send more than three times as many bytes as the number of bytes they have received.  This limits the magnitude of any amplification attack that

Discussion:
I'm not sure this changes anything in practice, since the client can't rely on it and the server could already do this, but explicitly saying it seems preferable.
LGTM
Suppose you have a large SH, for instance due to PQ crypto, in which case it will have to span multiple packets. If it exceeds three packets, then it will not be able to fit into a single flight. Ideally this would look something like this: However, as I read the text, the server is actually only permitted to send three packets in response to the ACK. The good news is that because the client is required to send fully padded packets, so you at least get to send 3600 octets or so per RT, but if the SH is >7K this is pretty annoying. I believe that there is a straightforward compatible change that would allow relaxing this restriction: if the server uses a reasonably long SCID, then when the client responds with an initial with DCID set to that SCID (which it is supposed to do anyway by my reading of S 7.2), then it is implicitly a proof of reachability, and the server could ignore the amplification limit.
This would be conditional on the server choosing a connection ID that has enough entropy (we seem to have decided that 64 bits is the benchmark). NAME has made the same comment on occasion.
Yes, agreed.
How would a client know how what algorithm the server used to generate the connection ID? As this seems to be a design issue anyway, here's another proposal: The server could send a token in the Initial packet, and the client would then use this token on subsequent Initial packets (replacing the token it might have used on the packet containing the ClientHello). This way, we'd be using a field that's intended to carry a high-entropy value, and not rely on a field that the server might not even have control over.
The client doesn't need to know, because it's the server's amplification limit that is at hand. And right now, the handshake would complete if the client doesn't do anything, it's just not optimal. I agree that this would work, but it seems like a significantly more invasive change, especially given the somewhat edge-casey nature of the issue.
We could also allow PATH_CHALLENGE in Initial packets, but that too has more disruptive effects on the design.

Of course, this is almost something that implementations could do without permission. But if we want that, then it is better to capture it.
Yah, that was my thinking.
That's probably easier than using the Token field. The only change required for this would be to allow those two frames in Initial packets.
I agree that the change makes sense. The picoquic server already does that: if the client responds with the proper CID, then the connection is validated. The protocol police has not caught me yet, and that makes sense because the specifics of amplification response are pretty much a server implementation choice -- and yes, sticking a path challenge in the server's Initial packet would be another valid choice. The main problem is not on the server side, but rather on the client side. The last interop issue I saw came when a client was coalescing an Initial ACK with an Handshake ACK. The exchange went something like: For DCID I'm sending you an Initial ACK + Handshake but picoquic is rejecting it as too short (error code 408). My reading of the spec is this is legal, as it's a coalesced packet Answer: The text log says that the Initial packet was accepted, but after that you are sending an initial packet that is just 95 bytes long, and then an handshake packet. ... discussion showing that the coalesced datagram was just 95 bytes long, when the spec says that all initial packets should be padded to 1200 bytes. So basically the question is, should clients be authorized to NOT pad an Initial packet to 1200 bytes if the DCID of the Initial packet is set to the SCID received by the server? I would love to say that, but I am concerned about making disruptive changes during WGLC. And so my reluctant advice is to not do anything about this issue now. Developers of servers can make their own decisions, using either long CID or path challenges.
Yes, the Initial padding was discussed, and I think that as it depends on the client making an assessment of the entropy present in the connection ID, it is a non-starter.
The server could also inject entropy by selecting a large sequence number for the Initial packet. In theory nothing would break if the server picked a random 61 bit number for the first Initial packet instead of zero.

If the client acks that and repeats the proper CID, then the server can legitimately assume that the client's address is validated.
You can only get 32 bits of entropy in the packet number, and you might limit your ability to send more packets if you picked a number that is too large, but yeah, there are options.
Is there a reason we would want to prohibit PATHCHALLENGE/PATHRESPONSE in Initial packets? That seems like a straightforward way to use existing mechanisms, if we want to take this design change.
I'm a bit surprised we're having this conversation at this stage in the process, but I'll throw my 2 cents in. I'm not particularly opposed to allowing PATHCHALLENGE/PATHRESPONSE, but it seems more invasive than explicitly saying something like "Servers MAY treat the receipt of a server generated connection ID with at least 64 bits of entropy as address validation."
This is my take as well. What's the disadvantage of the text Ian proposes
I like Ian's proposal and I dislike the idea of allowing the Path Challenge in Initial packets. I think allowing Path Challenge would just make things more complicated, while providing very little advantage over the Retry process. We might have debated that longer 2 years ago, but now is not the time -- better leave the spec as is.
Ian's suggestion seems fine. It's an addition to the spec, and I'm not really hearing any strong dissensions.
This is sounding like a design change, is that accurate?
Yes, this is a design change being proposed.
Is there a proposed resolution here?
NAME there is now.
Thanks, NAME Do folks agree with the proposed resolution?
NAME -- the PR needs some work, but I've only heard agreement on the resolution itself.
NAME : I think this is as well.
I see this concern, but consider a use case where it is expensive to send a large initial packet but the client has an a-priory key to generate trusted initial CIDs. In that case the client knows that entropy is sufficient and the server can validate the DCID. This can be done, for example, and deployment dependent, by using a blake-2b hash. For battery powered low-power radio devices, sending large initials can be prohibitive.
In most cases, the only reason a client will need to send another large Initial is if there is loss.

In low-power conditions, coalescing of Initial and Handshake by the server can be used, at which point the client never has to send an Initial again. Unless there is loss, the client in this case only ever sends one 1200 byte packet. (And it probably never ever has to receive a packet that big ever again, assuming that the server doesn't decide to drop a 10k certificate on it.)
I can see that you might want to forego an a-priory key and pay 1200 bytes once to get a 0-RTT token. But the 1200 initial bytes still holds for 0-RTT, no? A low power device will frequently go to sleep, and might exceed to the idle timeout of the server (although the server might want to reconsider its timeout in that case). I could also see a client generating its own 0-RTT token based on a-priory keys and this way get around the 1200 bytes if 0-RTT permitted that.
QUIC still requires that the datagram be 1200 bytes, but most of that 1200 can be 0-RTT payload (after you include a token, session ticket, TLS key share, transport parameters, etc..). A new protocol specialized to this can define a different minimum packet size. That can be QUIC-compatible if it wants to be. For such a constrained deployment, that might be a good choice.
LGTM. My weak preference goes to adding a word or a phrase that indicates that this is an alternative to the strategy being described in the previous sentence (like below).I think this is a useful improvement.Thanks, NAME !