Re: Quic: the Elephant in the Room

[Michael Thomas <[e-mail]>]

On 4/20/21 10:20 AM, David Schinazi 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.

Signing your DNS zone is considered "ocean boiling" now? Really? And I 
didn't claim that it would "fully" reduce the number of packet, though 
that could be accomplished if TLSA records were stapled to the A/AAAA 
lookup. Half of this has already been done by Google when they 
implemented DANE for Chrome. All it would take is for them to dust off 
that code and sign their zone. Is Google really incapable of deploying a 
20 year old standard?

Mike

>
> David
>
> On Tue, Apr 20, 2021 at 10:15 AM Michael Thomas <[e-mail] 
> <mailto:[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]
>>     <mailto:[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
>>