Hacker News Reader

Comment by altairprime | Hacker News Reader

The performance gap is shown to be due to hardware offloading, not due to congestion control, in the arxiv paper above.

And because Quic is encrypted at a fundamental level, offload likely means needing to share keys with the network card which is a trust concern.

This is already how TLS offload is implemented for NICs that support it. The handshake isn't offloaded, only the data path. So essentially, the application performs the handshake, then it calls setsockopt to convert the TCP socket to a kTLS socket, then it passes the shared key, IV, etc. to the kTLS socket, and the OS's network stack passes those parameters to the NIC. From there, the NIC only handles the bulk encryption/decryption and record encapsulation/decapsulation. This approach keeps the drivers' offload implementations simple, while still allowing the application/OS to manage the session state.

Sure, similar mechanisms are available but for TCP ack offloading and TLS encryption/decryption offloading are distinct features. With QUIC there’s no separation which changes the threat model. Of course the root architectural problem is that this kind of stuff is part of the NIC instead of an “encryption accelerator” that can be requested to operate with a key ID on a RAM region and then the kernel only needs to give the keys to the SE (and potentially that’s where they even originate instead of ever living anywhere else)

Your NIC can already access arbitrary RAM via DMA. It can read your keys already.

That is often incorrect for Apple computers, whether x64+T2 or aarch64: https://support.apple.com/fr-tn/guide/security/seca4960c2b5/...

And it’s often incorrect on x64 PCs when IOMMU access is appropriately segmented. See also e.g. Thunderclap: https://www.ndss-symposium.org/wp-content/uploads/ndss2019_0...

It may still be true in some cases, but it shouldn’t be taken for granted that it’s always true.

Nope. https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_ma...

Kernels enable IOMMU of the CPU, which limits the memory areas of the NIC can access to only to the memory it needs to access. This is also why it should be safe to attach pcie over thunderbolt devices.

Although I think for Intel CPUs the mmunuded to be disabled for years because their iGPU driver could not work with it. I hope things have improved with the Xe GPUs.

Reply on news.ycombinator.com