Re: Quic: the Elephant in the Room

[Michael Thomas <[e-mail]>]

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