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
