Re: Quic: the Elephant in the Room

[Michael Thomas <[e-mail]>]

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
>