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.
David On Mon, Apr 19, 2021 at 3:39 PM Michael Thomas <[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 > >
