Hi Mikkel, I suspect I'm misunderstanding something, because it sounds to me like you are supporting a dedicated "quic_early_data" extension to help decouple QUIC from TLS. More inline...
On Thu, Jan 07, 2021 at 04:14:05PM +0100, Mikkel Fahnøe Jørgensen wrote: > > > > On 7 Jan 2021, at 07.26, Benjamin Kaduk <ka...@mit.edu> 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. Yes. This is what I mean by QUIC 0-RTT and TLS 0-RTT being different -- TLS provides keys, but the actual data handling is done by QUIC. Using the TLS mechanism to negotiate TLS early data as an indication that QUIC early data should be used seems to needlessly couple TLS and QUIC for little gain. > 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. This just seems to be reconfirming that TLS only provides keys to QUIC but doesn't do any of the bulk-data-handling work. So a flag that tells TLS "give me QUIC 0-RTT keys" would work just fine, and there's no reason to make it be the same flag that says "do TLS 0-RTT". -Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
