For what it's worth, On Thu, Jan 7, 2021 at 9:15 AM Mikkel Fahnøe Jørgensen <mikke...@gmail.com> 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. > I asked about how closely QUIC would be tied to TLS 1.3 during charter discussions, and the answer I got then was that most of what would keep QUIC tied to TLS 1.3 was that the security people who replied weren't expecting any replacement for TLS 1.3 anytime soon. So this was a case of QUIC using the only handshake that made sense, not the only handshake that could work. So I'm agreeing with Mikkel here. Best, Spencer
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
