> On 7 Jan 2021, at 07.26, Benjamin Kaduk <[email protected]> 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
