[quicwg/base-drafts] Improve Large Server Certificate Scenario (#3784)

[Nick Banks <[e-mail]>]

### Problem

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.

### Proposed Solution

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. [This blog post](https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study) 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.

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