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.
There is always an opportunity for using DNS features in a clever way to improve things. I would say though that the complexity, especially since it introduces out-of-band dependencies, makes it a hard sell for someone to implement and explore without a really compelling reason (i.e. data showing that there is a huge opportunity). Resumption makes this particular concern a non-issue for most real world connections and has other positive benefits. Matt Joras On Mon, Apr 19, 2021 at 11:34 AM Michael Thomas <[email protected]> wrote: > > Hi all, > > I wrote a blog post called Quic: the Elephant in the Room and posted it > to the ietf list which generated a lot of comments, so maybe it's > worthwhile for this list to consider as well. The jist is getting the > Quic startup exchange back down to a 3 way handshake and very analogous > to the original TCP handshake. It can be implemented using a DANE-like > approach, or could be TLS could be extended to allow clients to cache > server certificates. > > My main purpose for writing it is because a Google-like company could > actually implement it just like they did with Quic itself to see how it > behaves in real life. > > https://rip-van-webble.blogspot.com/2021/04/quic-elephant-in-room.html > > Mike >
