Re: Quic: the Elephant in the Room

[Phillip Hallam-Baker <[e-mail]>]

On Tue, Apr 20, 2021 at 4:18 PM Eric Rescorla <[e-mail]> 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.