On 4/20/21 5:43 PM, Phillip Hallam-Baker wrote:
On Tue, Apr 20, 2021 at 4:18 PM Eric Rescorla <[email protected]
<mailto:[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.
This is a picture perfect example of the power hungry working group
chairs executing the infidels that have been the subject of many recent
talks on the IETF list. this is exactly why nobody wants to work with
the IETF. I predicated this on the IETF list with Keith Moore and turned
out exactly as I expected. And it took less than 24 hours. Thanks for
making my point Lucas Purdue. You are part of the problem, not part of
the solution.
Mike
