Live data from Hacker News

Some notes about HTTP/3

blog.erratasec.com

41–50 of 181 posts

Re: Some notes about HTTP/3

#41
post #38

Earlier quoted context omitted.

It compares in the way that there's not a single SCTP web server implementation compared to QUIC. People here say that we should use HTTP/2 over SCTP, no protocol will be adopted if there's no good implementations of it.

A WebRTC "RTCDataChannel" is an SCTP-over-DTLS-over-UDP stack, and webservers exist to stream to these. They're just mostly proprietary, existing as part of vertically-integrated stacks like that of Google Hangouts (i.e. its "app sharing" feature.)

I wish there was a open source verison king like PyCharm

Re: Some notes about HTTP/3

#42

Earlier quoted context omitted.

I'm curious, how does SCTP tunneled over UDP compare to QUIC? https://tools.ietf.org/html/rfc6951

It compares in the way that there's not a single SCTP web server implementation compared to QUIC. People here say that we should use HTTP/2 over SCTP, no protocol will be adopted if there's no good implementations of it.

Perhaps a better question would be why did Google decided to experiment with QUIC in Chrome instead of HTTP/2 over TLS over SCTP over UDP in Chrome. And the answer is probably because TLS over SCTP would require more RTTs.

Re: Some notes about HTTP/3

#43

Earlier quoted context omitted.

Not unless you want to get through firewalls seamlessly. UDP "state" tracking is a thing, and if my firewall sees a UDP packet destined for it without knowing the remote IP address it's going to drop it.

Which is yet another reason to migrate to IPv6, which doesn’t require stateful NAT.

Although stateful connection tracking is still a best practice for IPv6 firewalls and home routers.

Re: Some notes about HTTP/3

#44
post #35
post #14

Earlier quoted context omitted.

Those do not affect TCP state machine parameters like RTO(min), ATO, and TLP timeout. These are internal to the kernel and are either static, or can only be set systemwide. For example the minimum delayed ack timeout in Linux is just 40ms and can't be changed except by recompiling the kernel. 40ms is a totally inappropriate number for ATO in a datacenter or other low-latency setting. Other numbers like RTO(min) are s…

Again, as someone who does not completely grok QUIC I am not dismissing it. I was hoping if some parameters were not exposed work would be put toward making these available through existing interfaces.

Linux network maintainers have repeatedly rejected attempts by Eric Dumazet and others to expose delack_min and other parameters to userspace. This is the kernel tyranny to which I refer.

Notably many of the people whose proposals have been shot down by linux netdev are currently working on QUIC.

Re: Some notes about HTTP/3

#45

Most of the deadliest DDoS attacks happen over UDP. Spoofing, reflection and amplification just to name a few. Many businesses just deny UDP to protect themself against the on going DDoS threats. I feel this move won't make internet a better and safer place, but let's see.

Or let's actually read about QUIC before quickly commenting on it.

QUIC uses two mechanism to make sure you cannot do such attacks:

* it requires a proof of IP ownership (exactly like TCP sequence numbers) to setup a connection ID (pretty much, you're able to receive the server's response to finalize the connection) [1]

* it requires the client's first message (client hello) to be padded to at least the size of the server's response. Which implies that an attacker would require as much bandwidth as is spent by the server performing the attack, making the attack as practical as the attack without QUIC. [2]

[1]: https://tools.ietf.org/html/draft-ietf-quic-transport-16#sec...

[2]: https://tools.ietf.org/html/draft-ietf-quic-tls-16#section-9...

Re: Some notes about HTTP/3

#47

I feel like the adoption of HTTP/3 is going to be much much slower than HTTP/2... Besides Google Cloud do any of the major cloud providers have UDP load balancers?

HTTP/2 works well, so adoption speed isn't that important.

On the other hand, HTTP/3 is way, way faster. So there are strong incentives for big players to adopt it as fast as possible :)

Re: Some notes about HTTP/3

#48
The discussion of standards seems like it unhelpfully conflates the reality of standardisation by bodies like the IETF that have no discernible authority and don't want it even if it were possible - with "de facto" standards which it says are just whatever people do in practice. Not so.

The IETF is not a conventional SDO, nor indeed a conventional organisation of any sort, since it has no members, and it operates on "rough consensus" rather than having some specific formal process that invariably (see Microsoft's interaction with ECMA and ISO) would be gamed by scumbags.

But nevertheless those are de jure standards that come out the far end, the result of "getting all major stakeholders in a room" albeit that room is most often a mailing list since only a hardcore few can attend every IETF physical meeting. The IETF even explicitly marks standards track RFCs distinctly from non-standards track ones. If you contribute documentation for a complete working system, rather than (as Google did with QUIC) a proposal based on such a system that needs further refinement, it'll just get published as an Informational RFC. Such RFCs are how a bunch of Microsoft network protocols are documented, by Microsoft. Whereas months of arguing and back-and-forth technical discussion have shaped the IETF's QUIC and will continue to do so, the documentation for MSCHAPv2 (commonly used in corporate WiFi deployments) is an informational RFC so a Microsoft employee just dumped it as written, no chance for anyone to say "Er, this protocol is stupid, change it not to shove zero bytes into this key labelled C or else anybody can crack user passwords after spoofing the AP". So they didn't, and you can.

[Edited: wording tweaks near start, sorry]

Post reply on HN