Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

QUIC is now RFC 9000

fastly.com

Post reply on HN
Print view View original

191–200 of 246 posts

Re: QUIC is now RFC 9000

#191

Post by throwawaaarrgh »

KirillPanov wrote: post #189
cormacrelf wrote: post #64

Earlier quoted context omitted.

The “ossification” that QUIC deals with is primarily about internet routers who decide to dig into their IP packets. https://http3-explained.haxx.se/en/why-quic/why-ossification Many have optimisations around TCP and long-standing TCP characteristics, which they are able to do because the TCP headers are unencrypted. This led to TCP being difficult to improve, because of all the implementations out there making assum…

Are deep packet inspection and modification boxes really that prevalent outside of the Great Firewall of China and its imitators (Russia has something similar now)? If QUIC gets in the way of these countries they will simply set up a decrypt-and-recrypt TLS proxy and block connections that don't honor its certificate. Lots of banks and trading firms already do this to their employees for regulatory purposes; there is…

> there is no technical hurdle

As someone who has been forced to use ZScaler, there is a slew of technical challenges. 80% of the traffic can be handled "easily" with a custom CA cert, and the rest have varying issues ranging from client problems to server problems to problems in the proxy itself. Just trying to clone a GitHub repo over HTTPS breaks with ZScaler.

Re: QUIC is now RFC 9000

#192

Post by Matthias247 »

ninepoints wrote: post #69

I wish the QUIC design was datagram-first... so many client/server implementations don't implement the datagram extension properly because it's... well an extension, and for most applications, reliable sequencing should be eschewed in favor of client-side reassembly. IMO QUIC was far too influenced by the legacy of how HTTP works when there was an opportunity to leapfrog a generation of bad decisions.

> IMO QUIC was far too influenced by the legacy of how HTTP works when there was an opportunity to leapfrog a generation of bad decisions.

I don't think this is fair. IETF QUIC doesn't have any references to HTTP anymore. It mostly provides bidirectional flow-controlled data streams - just like TCP. From an application point of view QUIC is pretty much TCP with the ability to have multiple concurrent streams after the connection was established. And reliable streams empower most higher layer networking protocols - not just HTTP. Implementing reliable flow controlled streams is not an easy task, therefore I think it was the right call to standardize this.

Regarding the datagram extension: It's very easy to implement cocmpared to streams. If you have a need for it, consider contributing it to the QUIC implementation of your choice.

For the datagram extension: If you have

Re: QUIC is now RFC 9000

#193

Post by xxpor »

wmf wrote: post #46
jiggawatts wrote: post #42

Earlier quoted context omitted.

I would argue that with 200 Gbps NICs starting to become mainstream, the era of stateful firewalls in general is over...

No see, the NIC now includes a stateful firewall so you can implement it at each server at line rate.

Exactly. But every flow still uses memory, and with TCP you know when the connection has ended and can reuse it immediately. With general UDP (and QUIC because they intentionally put this in the encrypted part) the only way to do it is with timers. So you have both problems of state sticking around for a lot longer than needed if the timer is too long, as well as the state going away too early and breaking flows that wouldn't be broken otherwise because the timer's too short.

I get why they made it hard for middleboxes to modify the connections, but they didn't have to make it hard to observe the state of the connection in order to do that.

Re: QUIC is now RFC 9000

#194

Post by [deleted] »

fouric wrote: post #177
throwawaaarrgh wrote: post #164

Earlier quoted context omitted.

NAT is literally the only thing stopping every single personal device in the world from being hacked. It may be a kludge, but it's the best kludge in all of technology. And what do you have against QoS? Would it be better if your VoIP calls stuttered every time you loaded a fat web page?

> NAT is literally the only thing stopping every single personal device in the world from being hacked. This is so wrong that it must be satire. NAT provides the very most basic protection possible, easily replicated (and surpassed) by every firewall that comes stock with every modern OS, and is completely insufficient (and not even necessary) to prevent personal devices being hacked.

[deleted]

Re: QUIC is now RFC 9000

#195

Post by brundolf »

Let's say I wanted to add HTTP3 support to my web service - perhaps a NodeJS one, for example. What's that look like right now, practically speaking?

Is it supported at all yet in stable web servers? Is it as simple as flipping a config property in my web framework of choice? Does it only work on Linux, or all major OSes? Or none of them yet out of the box? Does it perform as well or better on all axes, or are we waiting on hardware support or library refinement? How much of a problem will ISP infrastructure be? If I get it working, will it significantly benefit users right now?

Not expecting comprehensive answers, just trying to get a feel for the current state of things

Re: QUIC is now RFC 9000

#196

Post by tialaramex »

throwawaaarrgh wrote: post #163
cormacrelf wrote: post #64

Earlier quoted context omitted.

The “ossification” that QUIC deals with is primarily about internet routers who decide to dig into their IP packets. https://http3-explained.haxx.se/en/why-quic/why-ossification Many have optimisations around TCP and long-standing TCP characteristics, which they are able to do because the TCP headers are unencrypted. This led to TCP being difficult to improve, because of all the implementations out there making assum…

Ah, the old middleboxes excuse. Changing TCP would break the middleboxes, so instead we'll invent a brand new protocol which is (theoretically) ignored by the middleboxes. The idea being if you slip something in via UDP, nobody will notice, and then you encrypt it so the middleboxes give up on it. This assumes that lack of transparency is the only way forward. I'd argue that IP and TCP ossified not because of transpa…

You're arguing for the "smart network" approach. This approach already failed. Some HN readers might not even have been born when that happened. The dumb network won. Perhaps the smart network can be pulled off successfully, but it won't be by humans, and I don't see anybody else around here trying.

The supposed "chilling effects" don't work out in practice. You will sometimes see people saying oh, China blocks TLS 1.3. Nope, many of the services you use now have TLS 1.3 and yet still work fine in China. "They just push people to a fallback". Nope, Downgrade Protection means that's exactly the same as just dropping all TLS connections.

TLS 1.3 doesn't change the correct way to interpose, it just makes yet more of the bad ideas that shouldn't work actually not work. If you were doing any of those and they broke, that's not TLS 1.3, that's because you were doing something that we already warned you shouldn't work. Stop doing things that can't work.

And it's true, such people keep demanding "transparency". I think they'd probably avoid some of their problems by just admitting that what they want is at best eavesdropping and that this isn't what other people think "transparency" means. There was a whole thread about this on the TLS working group list earlier in May. We get it, you would like to eavesdrop on people, but you don't like to admit this and you'd prefer if there was some way to pretend everything is fine, while, on the other hand, actually eavesdropping.

What's funniest is that the big players in this game want to play both sides so badly they can't even stop contradicting themselves long enough to write a document. The last version of draft-camwinget-opsec-ns-impact that I reviewed has such an obvious contradiction which I called out, it wants everybody else to use RSA key exchange, so that it can snoop all their TLS traffic, but of course implementers of the draft must forbid RSA key exchange, so that nobody snoops them.

Re: QUIC is now RFC 9000

#197

Post by throwawaaarrgh »

ikiris wrote: post #166
throwawaaarrgh wrote: post #164

Earlier quoted context omitted.

NAT is literally the only thing stopping every single personal device in the world from being hacked. It may be a kludge, but it's the best kludge in all of technology. And what do you have against QoS? Would it be better if your VoIP calls stuttered every time you loaded a fat web page?

No it isn't, that's basic stateful firewalling. NAT in no way provides security. At all.

The fact that a kid with a port scanner can't remotely connect to and exploit your printer is due to NAT not being able to route the traffic, whether you have a stateful firewall or not. The majority of internet-addressable devices in the world do not have firewalls. Hence, NAT keeps most devices safe from drive-by RCE. There are plenty of attacks to get around that, but by default, nothing else protects random devices like NAT does.

Re: QUIC is now RFC 9000

#198

Post by adrianmonk »

MertsA wrote: post #72
ivan4th wrote: post #11

Wake me up when multipath support is included... Till then I prefer TCP b/c I can use MPTCP to utilize all of my rural LTE bandwidth for each single flow (e.g. downloading a file)

I just really wish Google would have built QUIC on top of SCTP. They had the clout, and opportunity to push for real end-to-end SCTP support across the internet. Tunnel it over UDP for IPv4 and userspace implementations but use native SCTP where possible like over IPv6 before middleboxes abound that only support TCP, UDP, and ICMP. There's too many NAT implementations, firewalls, etc that don't support SCTP on IPv4 b…

> It's got built in multihoming for seamless handoff in mobile environments to keep a persistent connection across e.g. WiFi and cellular.

From what I can tell from the QUIC RFC, it also supports this. See section 9, "Connection Migration" (https://www.rfc-editor.org/rfc/rfc9000.html#name-connection-...).

When your phone or whatever switches network, it can initiate a connection migration. Assuming it's the client, which would be the common case.

Re: QUIC is now RFC 9000

#199

Post by tialaramex »

cbsmith wrote: post #186
bcoates wrote: post #183

Earlier quoted context omitted.

Nah, middleboxes are garbage. The security features they claim to offer are all snakeoil checkbox-ware, businesses and government agencies/state-controlled telcos use them because they have a nominal compliance obligation to do a thing so they buy a middlebox that they can wave their arms at when the auditor/commissar comes around. Generalized "optimizer" middleboxes don't actually work in real world performance test…

I'll give you that a lot of the middlebox problems are because they are garbage, however... Dismissing the security features they are ostensibly delivering snakeoil is more than a bit unfair. There is a legit security context where absolute transparency & auditability is the right design objective, rather than absolute privacy. I'd argue the greatest failing we've seen with the evolution of TLS was the failure to rec…

For TLS if you build a middlebox which obeys the protocol invariants (e.g. see RFC 8446 section 9.3) then you're golden. This isn't so hard, it's almost embarrassing that anybody needed these writing down, but evidently they did.

This is true for QUIC too. Obey the invariants. You don't need to read all these complicated documents, just the invariants.

Now of course there are obstacles. First doing this is expensive. Doing things that don't obey the invariants (many of which also destroy your security) was cheaper. Too bad. If your supposed "legit security context" is so valuable you'll afford this.

Second doing this in effect requires confessing to the people you were "legitimately" giving "transparency & auditability" that you are snooping on them. Too bad, if your supposed "legit security context" really was what you pretend this conversation will be easy for you.

Re: QUIC is now RFC 9000

#200

Post by dnautics »

throwawaaarrgh wrote: post #197
ikiris wrote: post #166

Earlier quoted context omitted.

No it isn't, that's basic stateful firewalling. NAT in no way provides security. At all.

The fact that a kid with a port scanner can't remotely connect to and exploit your printer is due to NAT not being able to route the traffic, whether you have a stateful firewall or not. The majority of internet-addressable devices in the world do not have firewalls. Hence, NAT keeps most devices safe from drive-by RCE. There are plenty of attacks to get around that, but by default , nothing else protects random devi…

Yes I agree with this but do note that in your gp you stated "every single personal device", not "half of all personal devices"
Post reply on HN