Re: QUIC changes "early_data" extension semantics (Re: Benjamin Kaduk's Discuss on draft-ietf-quic-tls-33: (with DISCUSS and COMMENT))

[Mikkel Fahnøe Jørgensen <[e-mail]>]

> On 7 Jan 2021, at 07.26, Benjamin Kaduk <[e-mail]> wrote:
> 
> It seems like only QUIC internals would have to change, not TLS internals?
> 
> My expectation is roughly that, if we were to compare the work needed to go
> from (has TLS 1.3 implementation) to (has QUIC implementation that uses
> quic_early_data instead of early_data) with the work needed to go from (has
> TLS 1.3 implementation) to (has QUIC implementation as currently
> specified), there would not be much difference.  Obviously if you are
> starting from (has QUIC implementation as currently specified), things are
> different, especially if you want to be able to support both draft QUIC and
> RFC QUIC in the same codebase.  I still think that things are cleaner with
> a separate extension and won't involve trying to smush together two things
> that are mostly, but not entirely, the same, but I'm not going to hold a
> Discuss over it.

The concern is also the QUIC v1 uses TLS 1.3 but QUIC as a concept is not heavily tied to a specific crypto paradigm. TLS 1.3 provides the handshake and the transport keys, but QUIC handles all of its own session encryption with or without help from a TLS library. On a practical level this can also helps performance optimizations in software and in hardware.

From a TLS perspective it may seem reasonable to use the designed feature set, but from a QUIC perspective, QUIC does not necessarily benefit from a tight coupling as long as it can get the keys that it needs. This separation makes it simpler to evolve new versions of QUIC with different crypto designs.

For example, a given TLS library might not support many-core optimizations and this also isn’t critical for obtaining traffic keys, but a large volume of early data could be processed on 24 separate cores in parallel. Getting that to work with any run of the mill TLS library could be a challenge.

Mikkel