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. Cheers, Lucas [1] https://datatracker.ietf.org/doc/rfc7924/ [2] https://datatracker.ietf.org/doc/rfc8879/ On Mon, Apr 19, 2021 at 11:18 PM Michael Thomas <[email protected]> wrote: > > On 4/19/21 1:45 PM, Matt Joras wrote: > > Hi, > > > > Note that there is a TLS feature which reduces the crypto (TLS) data > > needed to be sent during the handshake considerably, resumption. The > > vast majority of QUIC connections in our deployment (and TCP + TLS for > > that matter) are resumed. In a typical resumed connection the total > > crypto data transferred is around 500 bytes in both directions. > > Resumption is also less CPU intensive on the server than a fresh > > handshake. > > > Ok, I just looked up TLS Restore and it has the problem that it needs to > keep fairly hard state in the typical case where there are a lot of > servers listening. A Cloudflare blog post said that they use memcached > which implies that they have to do a out of band lookup for the > session-id. To my mind, it sort of begs the question of why you'd ever > kill the transport session in the first place, but that's the browser's > choice to make. > > That's in contrast to the DANE or client cert caching solutions which > cache on the client side and would be fairly rarely be waiting for the > TLSA RR, and no state of any kind is required at all in the backend. So > I don't think this is exactly a slam dunk. That Cloudflare even wrote a > blog post about it shows that Restore introduces operational complexity > at the very least. > > Mike > >
