Draft: draft-ietf-quic-tls

Commentary: 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 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 is n'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 is n't to say that compression is n't worthwhile , but I do n't think that it is as critical as  's study might suggest . 
 Is the resolution here what 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 .
Paragraph (version B):
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.