On Tue, Apr 20, 2021 at 4:18 PM Eric Rescorla <[email protected]> wrote: > To follow up on what David Schinazi says, the primary determinant of > handshake latency for a protocol like TLS or QUIC is not the total number > of packets but rather the number of round trips. Of course these are not > unconnected because you don't have infinite congestion control window. This > is especially true for QUIC because the server is limited to 3x the > client's initial flight as an anti-amplification defense [0]. However, in > practice, most server certificate chains will fit within a single QUIC > flight, as documented in this post by Patrick McManus from Fastly [1]. And > if you use RFC 8879 certificate compression you should capture almost all > of the rest. For this reason, it seems unlikely that the TLSA approach you > propose would significantly decrease setup latency. > > This is not to say that there is no room for improving latency via keying > material in the DNS, but the purpose of that would be to allow the client > to send data in its first flight (aka "zero-RTT priming"), not to reduce > the size of the server's first flight >
If you win at Pinball, you get to play again. I decided not to engage in QUIC fairly early on. Not because I didn't have any relevant ideas but because the scope was already large and my ideas would tend to make it larger when was needed was to make it narrower. As the work continued, I realized that QUIC is very different from TLS and TCP: We don't have to try to make one size fits all. We can have separate transports optimized for Browsing, RTC and transactional services. There are now several people who have various prototypes of non-QUIC UDP transports. Rather than discuss them here in QUIC, it would make more sense to discuss them elsewhere, such as in an IRTF group. Some parts of QUIC are probably re-usable, I plan to reuse the recovery scheme albeit with changes to allow for my rather different approach to encryption. Changing the PKI to save a few packets seems like the wrong move to me. We should be bolder. If paying $30/yr for a certificate was an unacceptable outrage, we should treat $10/yr for a domain name in like manner. $0.10 with no renewal fee ever seems fairer to me. If you build out a naming scheme and a PKI at the same time, you don't need validation.
