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.
>
> 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.
>
Well, the overall point of my post was that it would be interesting to 
run an experiment and that Google, MS and Apple would be in a good 
position to do that. Out of  all of this I found out that Google doesn't 
DNS sign their zone which is a little shocking. But it's sort of hard to 
call DNS "out of band" since it's needed for A/AAAA records and as my 
flow showed the TLSA record could be requested at the same time as the 
A/AAAA lookup which would on average not stall the handshake (and of 
course, RR's are cached). If you wanted to be really clever, the TLSA RR 
could be stapled to the name lookup too.

When I was looking this over with Wireshark it sure seemed like it was 
mostly doing a 5 message handshake, but it was hard to make a lot of 
sense because... encrypted.

Mike, i'll check out TLS resume though