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

From: Nick Banks <[email-masked]>
Date: Tue, 23 Jun 2020 17:48:11 -0700

### 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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Jun 2020 18:35:08 -0700

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.

-- 
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#issuecomment-648530057

---

From: Nick Banks <[email-masked]>
Date: Wed, 24 Jun 2020 10:32:46 -0700

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.

-- 
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#issuecomment-648960579

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 25 Jun 2020 18:19:27 -0700

(I'll invoke the @mcmanus 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?

-- 
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#issuecomment-649895802

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Jun 2020 20:33:41 -0700

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.

-- 
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#issuecomment-649938850