Re: Quic: the Elephant in the Room

[Matt Joras <[e-mail]>]

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 <[e-mail]> 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
>