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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
