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
