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.)
How do you stop a denial of service attack if both sides aren't required to maintain the overhead of the connection? TCP uses the overhead caused by ACK packets as a rate limiter on clients.
There are obviously high-bandwidth frameworks where you're already putting a strain on systems just by using them, where low-latency is also critical, and UDP is appropriate; video chat comes to mind, but outside of that very limited purview, what use could encrypting UDP actually do?
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 see no indication of a security audit. Given that SPDY initially had a major security hole (chosen plain text attack based on the compression+encryption combination), I will wait for some expert review of this.
That said, this sounds like a great idea, and I'm looking forward to see how this develops. It appears to be a lower latency faster to connect encrypted network protocol. I'd love to see all network traffic encrypted, and I suspect this would have a disproportionately large improvement for multi-hop encrypted streams, like TOR. If this works out, it will be great for privacy and security.
On the other hand, it might have horrible security holes all over. We need to be careful, but this does look promising. I'll give it a good read through, but I don't consider myself qualified to say much about its security.
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.
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.
While I appreciate the sentiment, I think you are missing an important point - the specification itself could be deliberately flawed. Crypto is hard, and not just the math itself but all the infrastructure details. The number of people able to recognize a weak design (deliberate or not) is quite small. Probably a couple of orders smaller than the number of people able to re-implement a network protocol from specs.
When information is power, privacy is freedom.
They are not doing their own crypto.... they are using TLS. Again, please read the actual documents.
The point of this is to improve performance for tiny HTTP transactions. The need for all those tiny transactions comes from ads and tracking data and their associated tiny bits of Javascript and CSS. The useful content is usually one big TCP send.
Blocking of all known tracking systems is a simpler solution.
It is bad enough that they rush the TCP start with no regard for the effects of the initial packet flood. If they are going to give up throughput control altogether, network operators will justifiably throttle flows to prevent unfair monopolization of the bandwidth through flooding. Web traffic is not real-time traffic. UDP creates an impression of urgency that isn't true. That kind of traffic will be a bad neighbor on your network.
What do we get from this that we don't already get from TCP? Not to be as conspiratorial as some other posters here; but remember the good ol' days when Microsoft angered you by playing around with HTTP? Now Google wants to muck around at a much lower layer. Whatever.
So... we're probably going to see new connection flood DOS attacks like the ones that prompted SYN cookies a couple of decades ago. Application stacks will need to handle their own congestion control, and applications that do so poorly will negatively impact carrier networks. And, yay, a new variant of TLS when there are already several versions that aren't widely implemented, let alone deployed.
Oh, and in the application so that each of those problems can be addressed over and over. Yay!
Everyone has seen this work before, nothing new here except the who, and the why. Without protocols like this, VDI is next to impossible to give anything like a normal experience over the web. If Google rolls out cloud desktops to go with their apps, I think certain people may take notice. Vmware recently added HTML5 access into the mix, though its still kind of spartan in the current version, its hopefully going to mature in the next. I don't really pay attention to citrix that much, so I don't know where the state of HDX is right now.
And yet there always seems to be somebody out there that's capable of finding the flaws that exist.
Yes, there are a relatively small number of people able to find those flaws, but it's still a large enough number of people that the flaws will be found at some point. And at any rate, the crypto has already been done, they're reusing TLS for the crypto.
Here we are again.
After VP8, protocol buffer, Google is a it again providing some free replacement of some existing standard (DTLS here http://www.rfc-editor.org/rfc/rfc4347.txt)
But of course, Google's people know better and have more money. And the list can go on. Dart as a replacement of javascript. Protocol buffer as replacement of ASN.1, SPDY to replace HTTP. With Jingle google tried to replace SIP protocol as well but at least the extended an existing standard but they dropped the support when stopping Google talk. For couse everyting is free, open source and Not Evil. So why bother?
Well as an aging network engineer, I am starting to be fed up with such "innovations". More consensus building would be refreshing.
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)
I don't know how you expect to keep things in sequence and accommodate dropped packets without implementing a sequencing and transmission protocol. With that in mind, you've just recreated TCP.
What's more likely is Google will create a TCP protocol (you must accept the EULA) which forwards a copy of everyone's session to Google. When you make a request to, say weather.com, Google will then serve you cached results from previous cached sessions to make things faster by eliminating network hops to weather.com. Muhahahahaha...
Join the Slashcott! Feb 10 thru Feb 17!
Are you a cryptography expert? Because there are a _lot_ of ways to attack cryptography schemes. Length of transferred data can often be inferred very easily, for instance. As another example, sophisticated replay attacks can often significantly weaken encryption strength; perhaps in some yet unknown way. A layperson's "actual read" of the documents cannot and should not provide any reassurance to anyone. It is their availability to the cryptography community, as a whole, who will then inspect them which will ultimately lead to confidence in the who stack. Only over time, as the protocol is employed and studied, should it be trusted.
You should not be so glib regarding security and especially cryptography. It is an extremely subtle field, which you clearly do not understand very deeply.
in case people aren't familiar with my non-drunken-but-close-enough debate style- scratch the tcp/ from the first sentence. And obviously I was just flailing against webrtc and this quic thing which smells like it is also trying to address the more general problem space of - "well, since we don't really have an open ipv6 internet that works for everyone, lets waste our lives engineering this big mess over here..."
Wow, we hit another low point for /. A 2 line 'article' gets to front page because it contains a bunch of TLA's and a FLA (Three-Letter-Abbreviation and Four-Letter-Abbreviation).
It would be really nice if someone would actually explain in any 'article' what the f*ck they are talking about to all the people reading it who don't know what a TLS is. Or even an UDP for that matter.
Is it that difficult to simple put some brackets and the full name after the TLA?
Sorry all, but I can't figure out why this is even 'news' !!!
I think you might be the one that needs to do some reading. Their info page says that they're using something "similar to TLS" and then, in the docs, mention "the analog of" when referring to features of TLS. It doesn't sound like they're using stock TLS or DTLS, so there would be ample opportunity to make small mistakes (whether intentional or not.)
> 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.
Funny, but I think the worry is that people will adapt QUIC for communications, websites, and programs that don't involve Google. Then if the protocol has security flaws, it's an engineered backdoor Google and the NSA can use.
Yes, I am not going to lose sleep over communicating with GMail via QUIC. I already assume anything I store there is in NSA vaults.
Reducing RTT for connection setup and encryption is a nobel goal yet I'm not clear on why technically this can't be solved without the reinvention of TCP over UDP.
TCP fast open coupled with TLS session tickets/snap start offers essentially the same possibility for actual transmission of an encrypted request before completion of first round trip.
Multiple concurrent TCP streams normally end up having much the same properties as multiplexed UDP in the aggregate so I don't buy head of line koolaid either.
What I think is really going on here they want an excuse to bring congestion control algorithms into user space where they can program whatever congestion algorithms they want into their browser and bypass having to deal with the OS vendors.
The design of congestion algorithms is a black art... I worry about algorithms designed using data from google networks not generally applicable to the Internet or otherwise too aggressive which could ultimatly give browser vendors and sites an unfair advantage or prove to be detremental to the larger Internet.
Even in their text they talk about "speculative" double posting of packets just to mitigate against the *possibility* of incurring delays due to dropped packets. There must some kind of real pain felt when packet loss occurs otherwise things turn to shit. Google is always blabing away about "tail loss" and avoiding the dreaded RTO but they never seem to care about the repercussions.
They are not doing their own crypto.... they are using TLS. Again, please read the actual documents.
Come on man that is barely relevant to what I said. I can't believe you got +5 informative for that glib drivel. There is more to the infrastructure than just TLS. If TLS was all there is to it then they wouldn't be doing anything new, would they?
When information is power, privacy is freedom.
http://www.cs.utexas.edu/users/sustik/QUIC
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.
For all those that say "the spec is open" so is the spec for MSFT Open Doc, don't actually work IRL does it? for a spec to mean shit 1.- it has to be 100% what they are actually using (the "can you trust the compiler" problem) and 2.- You have to have somebody with enough skill (as you pointed out) to spot any flaws in the crypto that would give any bad guys or bad govs a backdoor.
I urge all those who think just having the spec alone is enough to look up "The Obfuscated C contest" and please download the source and see for yourself. in that contest you KNOW there is a backdoor, you KNOW what that backdoor does and its STILL pretty damned hard to spot where the backdoor is. there are several of those i showed to long time programmers and without telling them what flaw they should be looking for they couldn't find it.
Now THINK for a second, if amateurs trying to win a stupid contest that really doesn't offer more than bragging rights can cook up backdoors that are THAT well hidden, what could somebody like Google cook up with a blank check from the NSA? doesn't Google brag they hire the best programmers on the planet?
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.
QUIC sounds like mTLS which Microsoft already made, use, and openly documented the protocol. Seems like Google is copying an earlier concept and getting all the kudos.
You already understand you can't change the mind of fanboys. But you and the other poster seem to miss the idea that you can make yourselves look like trolls and/or idiots to people who are neither fanboys nor the other extreme. It is just a protocol, and in terms of things Google can screw up and is a threat to your data, this is pretty far down the list. Considering there is enough crap from Google that is a legit threat to complain about, spewing so much over this issue is at best comical.
But this is SUPPOSED to be a geek site, do we REALLY need to fricking spell out how simply saying "there is a spec' isn't magic fairy dust to insure it doesn't have a backdoor already? I mean are we REALLY gonna have to paste a page and a half explaining the basics, how complex crypto is, how having something "similar to" something currently being used doesn't mean it won't have serious holes, or the whole "what you get from the spec isn't always what the final product is" ala MSFT OpenDoc?
I mean good lord if the only way to shut up the fanbois is to paste a couple of paragraphs of explanation, after we've had nothing but back to fricking back NSA headlines for a year? I'll happily clean out the plasma conduits, get me outta here!
ACs don't waste your time replying, your posts are never seen by me.
Thank you, and what is so wrong with not trusting a new protocol from a company that has not had the greatest record when it comes to user privacy and security, until some guys that know their stuff and are NOT on the payroll have had a chance to tear it apart and look for obvious flaws?
Now once Bruce Schneier and a few of the other heavyweight crypto guys have had a look at it, if they say its good? THEN I'll be happy to try it. To all these fanbois, would you be saying the same thing if it were MSFT or Apple? Then why does Google deserve a free pass?
ACs don't waste your time replying, your posts are never seen by me.
What I don't understand is why over UDP? They are building a transport protocol, which logically should be another alternative to TCP, UDP, SCTP, etc. Wouldn't this be both more efficient and architecturally cleaner?
What's with the naming convention? With Google releasing SPDY, Snappy and QUIC, I'm guessing they will run out of synonyms for 'fast' sooner than Apple will run out of cats...
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.
IMO It's not just direct financial costs.
Google is now into mobile in a pretty big way. A "GSM based" smartphone would typically move between.
GRPS: encryption exists but it's an old design and has security flaws that can't really be fixed due to compaitbility with legacy equipment. Fortunately the equipment needed to exploit things is expensive enough to keep most people out.
3G: better encryption systems but they can be subverted by forcing the phone to drop back to GRPS.
Public wifi networks: Either no encryption or encryption with a fairly well known shared key. Trivially easy for an attacker to set themselves up as a man in the middle.
Owners: home wifi, usually wpa encrypted nowadays but older installs may be either unencrypted or encyrpted with a broken encryption system and some people may use an insecure key to make it easier to remember.
As well as security problems some of these networks are likely to be high latency (i've seen latencies in the seconds on GRPS). So every round trip added reduces the quality of the user experiance. Getting the number of round trip times to set up a secure connection reduces the user experiance impact of increasing security which makes it an easier sell to do it.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I mean good lord if the only way to shut up the fanbois
Half the point of labeling someone as a fanboy is that they are beyond reason. You don't try to shut them up unless you have some vindictive need that is going to be borderline fanboy-ish itself. And since when has a geek site been free of fanboys, it comes with the territory.
to paste a couple of paragraphs of explanation
Speaking of a couple paragraphs, the actual specification if only a couple pages for the relevant section. If there is was a "geek site", should we aspire for people to actually look at the damn thing before running their mouth off? It is no where near anything like OpenDoc, and the crypto part is pretty straight forward and standard with a different hand shaking mechanism.
But instead you seem to think it is more important to balance Google fanboy-ism with anti-Google fanboy-ism. Instead of investigating at all, or applying any thought to it, you do what amounts to the same as warming people not to use free Google pens at a trade show because the pens might be secretly violating the privacy of what you write with them, without even looking to see they are simple mechanical pens, regardless of how good or crappy they are.
I don't think you understand what a protocol is. If Hitler were to design a useful protocol, the world would be stupid not to use it; what would be stupid is using binaries provided by Hitler.
Have you paid any attention at all to the academic security community? (spoiler: no, you haven't.) The majority of researchers work for universities (and promote Tor!). They aren't on anyone's payroll.
GPRS, 3G, Owners
Securing anything but the peer is always a waste of time and treasure. Security properties of an access technology is moot when the entire Internet is and always has been untrustworthy and insecure.
As well as security problems some of these networks are likely to be high latency (i've seen latencies in the seconds on GRPS). So every round trip added reduces the quality of the user experiance. Getting the number of round trip times to set up a secure connection reduces the user experiance impact of increasing security which makes it an easier sell to do it.
As others have mentioned you can beat down round trips to same extent as QUIC using TCP and TLS extensions without reinventing TCP.
It is hard to trust the data mining giant. Every Android app is required to send any data they collect to google. Their whole business is about data.