On Thu, Jan 25, 2024 at 7:58 AM Mikkel Fahnøe Jørgensen <[email protected]> wrote:
> As to why TLS 1.3 specifically, I recall early on asking for schemes that > were more IoT friendly. > > You may recall that Google QUIC did not use TLS. If memory serves me correctly that was partly because Google wanted 0-RTT resumption and a few other capabilities that TLS did not provide at the time. When those facilities were added to TLS in TLS 1.3, it made sense to re-use TLS rather than maintain a separate crypto stack. I no longer work for Google, so I don't have access to my notes on this; you may want to confirm with Ian Swett or one of the folks who was both there at the time and is still a Googler. regards, Ted > The consensus at the time was that encryption is important for > ossification prevention and non-encryption was a deal breaker, as has been > explained in this thread. However, there was nothing preventing other > encryption schemes than TLS and this could be added in other later QUIC > versions separately, but for QUIC 1.0, IoT would not be a priority in part > to get something out of the door to finalize 1.0, and in part because TLS > 1.3 allows for negotiation in case some encryption turns out weak. > > As to network transparency for troubleshooting, various tooling has been > mentioned but there are header bits explicitly exposed to measure pacing > and roundtrip of encrypted packets modulating a signal that can be > observed, which was deemed sufficient after some testing, although there > was a push for more insight operator side of things. > > QUIC load balancing protocol was also discussed, partly in order to avoid > early TLS termination. LBs requires access to some confidential information > in order to route packets correctly. I have not studied this closely, but I > guess one could introduce a load balancer to gain more insights? > > Mikkel > >
