Change:
There are a few ways that this can be managed, but it's worth pointing out why, and some things that might help.
Amplification protection (send no more than 3x of receive) on the server side ends up adding an extra round trip in many scenarios than use a large server certificate. Send more in the initial client flight. We already require client Initial packets to be padded to at least 1200 bytes to force them to "pay to play" so to speak, but that's not enough if the server's certificate is larger than ~3K. does a good job of outlining the problem and proposes certificate compression as a possible solution. A simpler solution (IMO) is to recommend clients send more in their initial flight; perhaps two fully padded copies of their Client Hello. This effectively doubles the size of certificate that would fit in the server's first flight. Doubling the number of initial packets may increase congestion at the start of the handshake, but QUIC has already made the decision to send 2 probe packets for recovery, compared to TCP's 1.
How much of this requires specification, as opposed to clients just doing stuff? And how much would relieving this pressure just remove an incentive on servers to have smaller certificates? I mean, if you have a giant certificate, then you get TCP-level performance, maybe that's OK.
According to the data in the blog post, we're talking about ~43% of the handshakes sampled (assuming 1200 byte initial packets). If you make the assumption that operators of these websites do the minimal effort possible when updating to HTTP/3 and continue to have the same certificates, that's 43% of handshakes that get no benefit (during the handshake) for using QUIC. Personally, I think it's something the spec should address with a recommendation.
(I'll invoke the NAME for his thoughts, since he wrote that article.) At a high level, we should be working on reducing the handshake size, for two reasons: reduced packet loss, and reduced network load. Fewer packets in the handshake is generally good. Compression is aligned with this outcome, and it is not a steep hill. Simply inflating the client's hello goes in exactly the opposite direction. I would suggest that simply moving to QUIC without cert compression was not expected to reduce handshake latency. It was always a critical part of gQUIC, and was always considered a part of the equation for realizing QUIC's potential. That is how I read the article -- that to realize QUIC's promise, cert compression is necessary. Perhaps it might be useful to mention this somewhere in the TLS draft?
The thing about the dataset there is that certificate sizes are driven more by the requirements of the current environment. That is, where address validation has already occurred and you are only bound by congestion control limits. There are obviously factors that push people to take advantage of the space available, that primarily being the inclusion of more names. But in the presence of new pressures and new possibilities will create a new incentive structure. ECDSA isn't exactly new, but it leads to much smaller certificate sizes. People deploying QUIC will be able to use ECDSA and to request that their CA do the same for intermediates. That isn't to say that compression isn't worthwhile, but I don't think that it is as critical as Patrick's study might suggest.
Is the resolution here what NAME suggests above, i.e., an editorial addition to -tls
That seems overspecific based on one datapoint and one resolution. A different take on this is to make the observation that within the mechanisms described for QUIC, increasing certificate size can reduce the chances of achieving minimal-possible round-trips. Implementations can use methods to minimize the size of certificates such as ECDSA or compression.
Fair point. But it looks like an editorial change saying "moar handshake data = bad" is what would address the issue?
That seems like a good summary.

Discussion:
included in a certificate and that the certificate is issued by a trusted entity (see for example RFC2818). <ins> Where servers provide certificates for authentication, the size of the certificate chain can consume a large number of bytes. Controlling the size of certificate chains is critical to performance in QUIC as servers are limited to sending 3 bytes for every byte received prior to validating the client address; see Section 8.1 of QUIC-TRANSPORT.  The size of a certificate chain can be managed by limiting the number of names or extensions; using keys with small public key representations, like ECDSA; or by using certificate compression COMPRESS. </ins> A server MAY request that the client authenticate during the handshake.  A server MAY refuse a connection if the client is unable to authenticate when requested.  The requirements for client