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
