Re: Quic: the Elephant in the Room

[Eric Rescorla <[e-mail]>]

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.

-Ekr

P.S.  Mike writes "TLS could be extended to allow clients to cache server
certificates." This already exists (https://tools.ietf.org/html/rfc7924)
but in terms of applicability it has a lot of overlap with resumption.
[0] By contrast for TLS over TCP, the server has already confirmed the
client's IP and so it can use a larger initial window.
[1]
https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study


On Tue, Apr 20, 2021 at 10:20 AM David Schinazi <[e-mail]>
wrote:

> Cutting down the number of packets was never a goal for QUIC.
> The goal was to save round trips in connection establishment,
> as that significantly impacts user-visible latency. The number of
> packets only slightly increases the probability of loss during the
> handshake which can be correlated to user-visible latency, but
> much less.
>
> I'm not saying that a 3-packet handshake would be bad, I'm saying
> that it's not worth boiling the ocean to remove 2 packets. I'll also
> note that your proposal doesn't fully reduce the number of packets
> because you still need a DNS TLSA request and response, and loss
> of those is much worse as DNS retransmissions are less optimized.
>
> David
>
> On Tue, Apr 20, 2021 at 10:15 AM Michael Thomas <[e-mail]> wrote:
>
>>
>> On 4/20/21 10:07 AM, David Schinazi wrote:
>>
>> Hi Mike,
>>
>> I read your blog post, and I failed to find what problem you're trying to
>> solve.
>> The fact that some handshakes spend a couple packets on certificates?
>> We can actually quantify the user-visible impact of the handshake size,
>> and
>> from everything I've seen this particular topic isn't impactful enough to
>> solve,
>> apart from ensuring support for RFC 8879. It's even less realistic if the
>> solution involves the minor task of switching PKIs and roots of trust.
>> Speaking as one of the QUIC tech leads at a "Google-like company", I can
>> ensure you that we don't spend time on experiments that don't benefit
>> users.
>> It seems that you have a solution in search of a problem here.
>>
>> I thought the entire point of QUIC (aside from HoL blocking) was to cut
>> down the number of packets needed to start a connection. From what I can
>> tell, it takes it from an 8 packet exchange to a 5 packet exchange. If you
>> were to use a DANE-like solution that would be a 3 packet exchange most of
>> the time. Why is a 5 packet exchange good but a 3 packet exchange not?
>>
>> Mike
>>
>>
>>
>> David
>>
>> On Mon, Apr 19, 2021 at 3:39 PM Michael Thomas <[e-mail]> wrote:
>>
>>>
>>> On 4/19/21 3:33 PM, Lucas Pardue wrote:
>>> > I'm struggling to see what the problem statement that is unique to the
>>> > QUIC protocol is.
>>> >
>>> > That certificates can be large is not new information, it was a prime
>>> > motivator for RFC 7924 [1] and RFC 8879 [2].
>>> >
>>> > Operators can, of course, experiment with new optimal ways of doing
>>> > things. The broader IETF community is likely interested in the outcome
>>> > of such experiments. Since QUIC version 1 uses TLS, any changes that
>>> > stand to improve a QUIC handshake would likely be applicable to TLS
>>> > too. So the concept of replacing current TLS mechanisms with the DNS
>>> > doesn't seem to be something the QUIC WG should be leading. Should
>>> > such work identify QUIC protocol design evolution or extension, then
>>> > it could be suitable for WG consideration.
>>> >
>>> I'm not asking this working group to do anything. Just socializing
>>> something that generated a lot of discussion on the IETF list that might
>>> be of interest to the Quic community.
>>>
>>> Mike
>>>
>>>