Re: Quic: the Elephant in the Room

[Lucas Pardue <[e-mail]>]

I'm struggling to see what the problem statement that is unique to the QUIC
protocol is.

That certificates can be large is not new information, it was a prime
motivator for RFC 7924 [1] and RFC 8879 [2].

Operators can, of course, experiment with new optimal ways of doing things.
The broader IETF community is likely interested in the outcome of such
experiments. Since QUIC version 1 uses TLS, any changes that stand to
improve a QUIC handshake would likely be applicable to TLS too. So the
concept of replacing current TLS mechanisms with the DNS doesn't seem to be
something the QUIC WG should be leading. Should such work identify QUIC
protocol design evolution or extension, then it could be suitable for WG
consideration.

Cheers,
Lucas

[1] https://datatracker.ietf.org/doc/rfc7924/
[2] https://datatracker.ietf.org/doc/rfc8879/

On Mon, Apr 19, 2021 at 11:18 PM Michael Thomas <[e-mail]> wrote:

>
> 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
>
>