Slashdot Mirror
QUIC: Google's New Secure UDP-Based Protocol
New submitter jshurst1 writes "Google has announced QUIC, a stream multiplexing protocol running over a new variation of TLS, as well as UDP. The new protocol offers connectivity with a reduced number of round trips, strong security, and pluggable congestion control. QUIC is in experiment now for Chrome dev and canary users connecting to Google websites."
I have serious doubts in ANY new network tech not having backdoors of some sort.
Oh, come on. This is a network protocol. Sure, protocols *can* have flaws, but it's a very long stretch from being forced to run an unknown binary. Just implement it on your own if you're paranoid enough.
Ezekiel 23:20
What exactly can be hidden in an open protocol specification that will compromise your personally sensitive data? By design, a protocol has to be something that people can actually implement to be useful - the payloads you send via that protocol are up to you (based on your choices of which pieces of software to use, etc.)
Maybe if you would RTFA instead of pontificating, you would have found that the reference QUIC implementation is already open source, the specification is open, the wire specification is open, the whole thing is open. If you don't trust Google's implementation then roll your own.
I have no objection to protocol experiments that are 100% Open Source implementations. I wouldn't trust one that was not, and an Open Standard is just instructions for people who make implementations.
But it seems that a lot of this might belong in a system facility rather than the browser and server. I don't know if it makes sense to put all of TLS in the kernel, but at least it could go in its own process. Using UDP is fine for an experiment, but having 200 different ad-hoc network stacks each tied into their own application and all of them using UDP is not.
Bruce Perens.
They are not doing their own crypto.... they are using TLS. Again, please read the actual documents.
How do you stop a denial of service attack if both sides aren't required to maintain the overhead of the connection
How do you stop it if someone does not bother to respect the rate limiter? You are assuming that someone doing something bad is going to play by the rules.
QUIC uses an equivalent of SYN cookies to prevent some kinds of DoS. It also uses packet reception proofs to prevent some ACK spoofing attacks that TCP is vulnerable to. Overall it looks even better than TCP.
As for encryption, Google gives two reasons. They intend to run HTTP over QUIC and Google services are encrypted by default; it's more efficient for QUIC itself to implement encryption than to layer HTTP over TLS over QUIC. The other reason is that middleboxes do so much packet mangling that encryption is the only way to avoid/detect it.
QUIC has congestion control. (I suppose your brain would explode if you saw uTP, which runs over UDP yet is even less aggressive than TCP.)
You should open up the perf tab of your browser and look at this page to see if it supports your conclusions.
I have serious doubts in ANY new network tech not having backdoors of some sort.
Oh, come on. This is a network protocol. Sure, protocols *can* have flaws, but it's a very long stretch from being forced to run an unknown binary. Just implement it on your own if you're paranoid enough.
The problem with trying to implement a new protocol over tcp/ip (the internet) like Tim Berners-Lee did with the web, is that the mythical 'Open Internet' has been degraded. QUIC and webRTC reek to me of some orwellian attempt to make the lies about home servers being less worthy of net-neutrality protections than skype's servers make sense. I.e. allowing 'client to client' file transfers and video chats. All this is because of the conspiracy to deprive residential internet users the power to serve. Now, don't get me wrong, the things webRTC, and I'm guessing QUIC work around (legacy nat traversal when no simple 'open internet' directly routable path is available) are useful. But it is disingenous to look at QUIC without also looking at the fact that when Google entered the residential ISP business, they actually pushed the server persecution further, with a blanket 'prohibited from hosting any kind of server' terms of service language.
Earlier this week the FCC finally after 9 months 'served' my NetNeutrality (2000F) complaint against Google, along with the longer 53 page manifesto that now reached google via the FCC via the Kansas Attorney General('s office). Yesterday after pinging schneier@schneier.com for any insight to prepare for google's July 29th compelled response, he (or someone spoofing him) replied- "Thanks.\n\nGood Luck.".
http://cloudsession.com/dawg/downloads/misc/mcclendon_notice_of_informal_complaint.pdf
http://cloudsession.com/dawg/downloads/misc/kag-draft-2k121024.pdf
http://slashdot.org/comments.pl?sid=3643919&cid=43438341 (score 5 comment about the situation, with further links)
TCP has some major issues with congestion control that isn't playing well with buffer-bloat. The Internet is bursty in nature. TCP takes too long to ramp-up. It is acutally easier on infrastructure to burst 10MB over one second than to stream it over 10 seconds.
There are a lot of write-ups on issues with TCP, but one of the big issues that is starting to become a problem as speeds increase but latency is staying fixed, is the congestion control. Because TCP starts off slow and ramps up, it tends not to make use of available bandwidth. Un-used bandwidth is bad. The other issue is current TCP uses packet-loss to decide when to back off. The issue this creates is packet-loss tends to affect a lot of connections at the same time. You get this synchronization where lots of computers experiencing packet-loss all at the same time, so they all back-off at the same time. Suddenly the route is under-utilized. All of the connections start building up again until the route is over-utilized, then they all back-off at the same time.
This issue alone could possible cause large portions of the Internet to fail. It has happened in the past and the variables are getting to be similar again. Essentially you're left with a large portion of the Internet routes in a constant violent swing between over-utilized and under-utilized.
You get this issue where the average utilization is low, but packet-loss and jitter is high. Relatively speaking.
There is a lot of theory on how to fight these issues, but the only real way to figure this out is to actually test these theories on the large scale. A protocol that rides on top of UDP and runs in the application is the perfect place to test this. If something goes wrong, you just disable it. You can't do that with most OSs TCP stacks.
> Please, if you can't use SSL+TCP for text chat and keep it real time
They could have, but QUIC is "better" for their use cases. In many ways, it's like an improved version of TCP. It runs on top of UDP simply
because routers, firewalls, etc. often only speak TCP and UDP. From the FAQ:
> it is unlikely to see significant adoption of client-side TCP changes in less than 5-15 years. QUIC allows us to test and experiment with new ideas,
> and to get results sooner. We are hopeful that QUIC features will migrate into TCP and TLS if they prove effective.
> You can outright lose data. Your packets can arrive out of order. It's okay with video data where a hiccup only makes a few missing pixels,
> but with text, that's a terrible idea.
Unless of course the protocol you're running over UDP handles that stuff, just like TCP handles that stuff.
Normally, it's a bad idea to use UDP to run a protocol that has in-order packets, guaranteed delivery, etc. because TCP already gives you that.
Why re-invent TCP? Unless you're going to spend a few million dollars on R&D to make your UDP-based protocol actually be better than TCP,
you should just use TCP.
That "unless you're going to spend a few million dollars on R&D" is the key here. Google DID make the investment, so the protocol actually does
work better for the particular use than TCP does.
Give it up friend, you can give 'em a page of citations but anything to do with Google or Apple gets a "doubleplus good" by default here, free thought isn't allowed.
I have to think these companies must laugh their asses off at board meetings, just looking at how many peasants will rush to defend them. Fuck that noise, i want somebody OTHER than a researcher on the payroll to tear this thing apart with a fine tooth comb before i trust jack shit from ANY of these major corps. I mean for fucks sake, hasn't ANYBODY been reading the headlines here for the past year? How many whistleblowers does it take before you figure out these corps like government green just as much as yours and will be happy to sell your asses out if the check is right?
For God's sake you'd think these people were stockholders by the way they rush to crush anything that doesn't read "Gee Bill, isn't (insert corp) great? Why it sure is Bob, why I heard they cured AGW and hunger in just an afternoon! How anybody could ever doubt (insert corp) is beyond me, they are so sweet and kind!"...If the future is corp ass kissing and flag waving, can i get a lift out of here please? i promise i have my towel ready.
ACs don't waste your time replying, your posts are never seen by me.
It's "like" TLS, as in "its none dairy but it tastes just like milk".
Google's reason for doing this is to lower their costs associated with better security. This creates a 3 way instead of a 5 way exchange for the security protocol setup. Fewer connections less load on their stuff and less stuff they have to buy.
The security landscape is littered with security implementations which tried improve existing protocols. Just type in the terms WAP and security for a story on how to take a secure starting point SSL and bugger it.
Another is Microsoft's introduction of PKINIT for keberos, kerberos is a proveably security protocol which is limitied by the entropy in a users password, MS "fixed" this with PKINIT however they initroduced replay attach vectors precisely because they wanted fewer exchanges. BTW google seems to have done a better job in this regard +1 for google, -1 for MS.
UDP provides a mechanism (source ports) for multiple client applications on the same host to coexist. Furthermore through the mangling of source ports NATs can allow multiple hosts running UDP applications to coexist and communicate with the same servers from behind one public IP.
If you created a new IP protocol then you'd have to implement your own mechanism for multiple client applications on the same host to exist. Furthermore your system would likely break if two users behind the same NAT tried to access the same server with it because unless the NAT specifically supported your new protocol* it would have no way to differentiate between the traffic to different clients.
The overhead of building on top of UDP is pretty minimal, a source and destination port which as i've mentioned above are useful for allowing applications to coexist and a checksum which may or may not be redundant with checksums in your new protocol.
* Which will likely happen sometime arround when hell freezes over.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register