On Thu, Jan 25, 2024 at 1: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. > > 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. > > Quic for IoT is interesting. I wonder why Quic extensions (down or up layer like Radius over Quic) can not be offloaded from Quic WG and discussed/ done elsewhere? Behcet > 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 > >
