Time to start from scratch, and start a large-scale redesign of the Internet and its protocols, to try and better secure users from surveillance/attacks?
In my view the most dire issue facing the network right now is handful of content companies owning majority of network traffic. People have to run their own servers and get involved with the network again. There is no meaningful technological solution for aggregation of power in the hands of a few media companies caused by laziness and lack of engagement. Those with the skills need to work to make it more accessible to those without the time or inclination to learn.
Tor and other fringe security protocols/networks won't cut it, and getting people to use very-user-unfriendly encryption tools won't happen - nothing short of a mammoth redesign
The structure of the current net at IP layer and below is architecturally about right as far as I'm concerned. 100% untrusted, 100% untrustworthy. All the network needs to do is forward packets with some degree of assurance they will be delivered.. the rest is up to us users.
far surpassing the resources/scale of the IPv6 changeover, is going to come anywhere close to repairing the damage.
I think if we're smart about it IPv6 becomes a huge part of the solution. Whatever the future of the net and accompanying protocol soup look like maintaining a network of peers where any one can talk to anyone else is the most powerful tool we have to avoid oppressive tendencies of various less than perfect governments.
There's no going back now - it's already too late to salvage what we have, because it has already been completely and irrecoverably 'owned' - the NSA broke the Internet.
If you were talking specifically SMTP or SSL CA's I would agree with you. More generally all is not lost and all does not need to be replaced.
Because consoles aren't something most people use 24/7. I probably use my 360 about 2-3 hours per week. It's not at all challenging to see the opportunity for increased efficiency. Why should everyone have a full powered machine that only is used 2-3% of the time. 2-3% usage is the perfect situation for usage based rentals.
Its very simple - power savings, and cheaper thin consoles for end users.
What power savings? Power is being consumed somewhere else where as a customer YOU are paying for that too. Lets not forget about additional power requirements required to push insane number of real-time bits for trivial reasons over the Internet.
This would not work too well for multiplayer because of the latency between user-server-user, but would be great for single player.
Since everyone would experience input latency and there is no network latency for the multi-player link latency would be about the same persistent problem whether it were single or multiplayer game. The only lag assuming lack of operator incompetence would be in the form of input delay with very limited opportunities to compensate with prediction algorithms. Nobody who plays on anything approaching a competitive basis would touch this thing.
It's basically a way to keep the price of consoles at a point where people will still buy them, while being able to offer the level of processing power that would be too expensive.
Current consoles are well beyond the point of diminishing returns with regards to graphics power while cost of replicating existing capabilities keep getting cheaper year after year.
I don't know if it's vendor lock-in, but atleast this is a way to offer paying customers a better experience than pirates instead of the other way around with current DRM.
On what planet does high latency translate into a better experience?
Either the government will send people over to force the issue, or I could do it myself. If you are doing something that I want stopped and you won't stop, my only two options are to pay the government (via taxes) to force the issue, or to force it myself.
You could try searching for another way to settle conflicts such as invocation of the sacred art of letting others have your way.
Such one dimensional thinking... assumption that force is necessary to effect change when it is rarely so, practical or produces favorable outcomes.
After you have called the government on your neighbor you still have to live with them as your neighbor.
Those of you defending this specific EPA ban on the *abstract* basis of limits of a persons right to pollute how does your position square with the following hypothetical?
House A has a 500sq ft home with a family of four.
House B has a 3000sq ft home with just one person living there.
Both homes use wood stoves exclusively for heat. House A spews 15 micrograms per cubic meter of air.
House B spews 10 micrograms per cubic meter of air.
Who is the bigger polluter?
Efficiency and sustainability is ultimately best achieved when there is market pressure behind them - preferably by consumer deriving value from lower operating cost.
In case of wood stoves cleaner air translates into less wood consumed and less gunk to clean out of the system. It should be something buyers are naturally looking for when purchasing a stove and a point of market differentiation for manufacturers.
If energy efficient stoves must be more expensive then offer a subsidy to help people of limited means make the better choice. It is clearly in everyone's interest to get the more efficient model.
While there are problems which can't be solved without government threat of violence to "internalize externalities" did anyone even try before invoking EPAs blunt instrument?
TCP is, however, a bottleneck, and not optimal for all uses.
I think this is obvious to everyone. Hammers are not optimal for all uses. TCP provides an ordered reliable byte stream. Not all applications require or benefit from these properties. Using the right tool for the right job tends to provide the best results.
TCP has all kinds of cool, well-thought-out machinery which simply isn't exposed to the application in a useful way.
.. more general statements where specifics would be most helpful..
As an example, when SPDY or HTTP2 is layered on TCP, when there is a single packet lost near the beginning of the TCP connection, it will block delivery of all other successfully received packets
What are you referring to specifically? Is this before or after established state? Are you talking about some kind of SYN cross where data sent in the same round as SYN where SYN is lost but not subsequent data? What is the missing packet at issue and why do you believe the current behavior is wrong or not optimal? What is the role of congestion avoidance in your decision?
I think there are huge amounts of room for improvement in TCP. At the very top of my list is TFO and ICW hysteresis. If adopted more generally they would offer significant additional value. Drafts and code for the most part are already out there. TFO has been available as a socket option in Linux for a year or so already.
even when that lost packet would affect only one resource and would not affect the framing of the application-layer protocol.
HOL is always solved by multiple concurrent streams. With TCP TFO for example concurrent requests go out on the wire without having to pay out a single RTT in advance for connection setup of of subsequent streams. Does not get much cheaper than free.
It's in-effect correct because there are lots of UDP protocols designed before the general concept of "do not amplify unauthenticated solicitations with a larger reply" finally sunk in. (Or at least, sunk in among more serious protocol designers/implementers.)
The parent was making a point against QUIC because it used UDP. It is a false statement. QUIC has appropriate mechanisms to prevent unsolicited mischief.
What DNS, SNMP, NTP and god knows what else did way back then have nothing at all to do with the topic at hand.
If the QUIC exercise is successful, then the IETF should consider extending TCP to support the relevant features. For example, their point about multiple steams is a good one. Perhaps TCP should define an option to open N simultaneous connections with a single 3-way handshake. Existing implementations would ignore the new option bytes in the header so nothing would break.
While TCP is ancient there has been continuous work to improve it over the years. I think most people throwing stones here have not taken the time to look around and understand the current landscape. Indeed many ideas in QUIC are good ones yet not a single one of them are something new or something that had not been implemented or discussed in various WGs.
Regarding multiple streams what effectively is the difference between this and fast open? I send a message the message arrives and is processed immediately without a round trip... with a scenario like that what is even the point of something labeled "multi-stream"?
You make a good point about poor congestion control causing wide-scale harm, but that problem exists today. Anyone can create any protocol they want, as long as it is built on TCP or UDP.
TCP congestion is normally implemented within the operating system where user space does not have access or visibility into scheduling of transmission.
UDP mostly used for low bandwidth exchanges or inherently rate limited realtime communications. Most of these applications sport non-existent or insufficient congestion coverage. For example a bit torrent client without built in queue management or where you have neglected to set rate limits will easily saturate any network link to the point of being unusable. UDP congestion is a problem it just is not that big of a bandwidth consumer to have a large scale impact where it can be a threat to the network.
To be clear I don't think Google is at risk of bring about a congestive apocalypse. The potential risk I see takes the form of excessive aggression for competitive advantage.
The slides refer to a feature called "pacing" where it doesn't send packets as fast as it can, but spaces them out. Can someone explain why this would help? If the sliding window is full, and an acknowledgement for N packets comes in, why would it help to send the next N packets with a delay, rather than send them as fast as possible?
I wonder if this is really "buffer bloat compensation" where some router along the line is accepting packets even though it will never send them. By spacing the packets out, you avoid getting into that router's bloated buffer.
Yes essentially it is a hedge against future probability of packet loss. I don't know about QUIC but with TCP statistically more packet loss tends to present toward the end of a window than start therefore normally more expensive to correct.
The back off mechanism is one of the problems they're trying to fix. Internet protocols need some way to control bandwidth usage, but there are a lot of limitations with the existing options in TCP.
Like? Please be specific. This thread is getting old quick with people saying "TCP sucks" going on and on about how it just sucks without ever citing any technical justifications why that is so.
The current problem with UDP is that many border routers do not check whether outgoing udp packages are from within their network. This is the base for DNS based ddos attacks. They are very difficult to mitigate on server level without creating openings for Joe job attacks instead... Standardizing on udp for other protocols will emphasize this problem
This is incorrect. Ingress filtering is a global IP layer problem.
TCP handles the problem with SYN packets and SYN cookie extensions to prevent local resource exhaustion by one sided SYNs from an attacker.
A well designed UDP protocol would be no more vulnerable to this form of attack than TCP using the same proven mechanisms of TCP and other better designed UDP protocols (DTLS).
DNS can also be fixed the same way using cookies but seems people are content to make the problem worse by implementing DNSSEC and ignoring the underlying issue.
May I be so bold as to suggest graphs citing only x performance improvement for protocol y are insufficient, harmful and useless measures of usable efficiency. We know how to make faster protocols.. the challenge is faster while preserving generally meaningful congestion avoidance. This part is what makes the problem space non-trivial.
Look at TFA and connectify links it is all performance talk with total silence on addressing or simulating congestion characteristics of the protocol.
Having sat in on a few tcpm meetings it is always the same with google... they show data supporting by doing x there will be y improvement but never as much enthusiasm for consideration of secondary repercussions of the proposed increased network aggression.
My personal view RTT reductions can be achieved thru extension mechanisms to existing protocols without wholesale replacement. TCP fast open and TLS extensions enabling 0 RTT requests thru the layered stack...experimental things for which "code" exists today can provide the same round trip benefits as QUIC.
What google is doing here is taking ownership of the network stack and congestion algorithms away from the current chorous of stakeholders and granting themselves the power to do whatever they please. No need to have a difficult technical discussion or get anyones opinions or signoff before droping in a new profit enhancing congestion algorithm which could very well be tuned to prefer google traffic globally at the expense of everyone elses... they control the clients and the servers...done deal.
There are two fundamental improvements I would like to see regarding TCP.
1. Session establishment in the face of in band adversaries adding noise to the channel. Currently TCP connections can be trivially reset by an in-band attacker. I think resilience to this necessarily binding security to the network channel can be a marginally useful property in some environments yet is mostly worthless in the real world as in-band adversaries have plenty of other tools to make life difficult.
2. Efficient Multi-stream/message passing. Something with the capabilities of ZeroMQ as an IP layer protocol would be incredibly awesome.
Question: Do you believe that tobacco users should pay more for health insurance due to their choices, or would you require that all policies be priced the same regardless of personal choices?
My previous comment is applicable to structures where health care is "free" and everyone pays indirectly by virtue of being a taxpayer.
Competition only works if all feet are held to the fire. This applies to consumers, producers and middlemen alike.
If an insurance company wants to charge Smokey the bear more for lighting up or for eating shit far be it for me to complain about that.
Problem with most health care regimes as I see it insurance fails or at some point is captured and then fails to become an effective proxy for competition. As long as the hospitals feet are not at risk of burning health care costs will continue to be grossly detached from reality.
Thankfully my phone has no Google Apps, in fact, no apps at all and most certainly no GPS in it. Look after those old phones. No GPS == No Big Brother Tracking
Nice to hear you using the words cell phone and no big brother tracking in the same sentence as if NSA had not been wholesale collecting cellsite data of every cell user in the US.
Do you really not see a difference between an experimental, opt-in location system and an international, clandestine spy program?
Does the average person who has "opted-in" know what they are getting into or is this fine print inserted to make the lawyers happy and subsequently buried by professional marketing turd polishers?
Yes, but the problem with that is if you make crappy food choices, then we all have to pay for your health care. If you're ok to go die in a ditch because you ate a dozen Krispy Kream donuts every day, then fine, have at it, but if you want to join the health care system, then we all should get some say in what you can and cannot eat.
It does affect the overall cost to all of us, so it isn't just "personal choice".
I would gladly pay more for the freedom of others to make poor personal choices. Freedom isn't free.
It's not enough that we tell people what they eat may be bad for them, now we enforce it. How long before meat is banned? Sugar? Fat? Salt?
I tend to agree with this in principal yet as it stands consumers are denied the ability to know how much trans fat is in the shit their eating due to the infamous 0.5g/serving threshold loophole.
Either change labeling laws or get rid of the shit. Changing labeling laws would essentially have the same effect anyway I suspect.
So now all the attacker has to do is steal your password list, plus that single encryption key and they've just saved themselves week/months of work of brute-forcing and dictionary attacks against the list.
Unless you are willing to properly weigh risks throughout the threat tree this all an attacker has to do game is not worth playing. Everyone is always one hop away from an "all an attacker has to do" disaster scenario regardless of what they do.
All an attacker has to do is compromise system generating user accounts or accepting password changes and they can collect millions of plaintexts at their leisure.
Nobody said anything about a "single encryption key"... that was something you made up. Proper key management includes mitigation of risk.
If you only use hashing then, yes, you are open to Rainbow Table attacks because common passwords can be immediately exposed.
But hashing is not salted hashing. Best practice uses salted hashing with a unique salt for each user, thus making Rainbow Table attacks useless - you have to generate a whole new set of Rainbow Tables for each known salt which is a whole lot more work for an attacker.
Who cares if you use a salt or not? If entropy of the underlying password is shit as most passwords are the password will still be compromised. When you are working with a space of 2.9 million passwords there are plenty of easy pickings to make your botnet army's computer time well worth the trouble.
Cost of compromise goes down as technology advances while human capacity/willingness to manage large passwords remains constant.
No, I explained why when I talked about establishing proof of password knowledge.
Entering your password into a site which falsely claims to be twitter or facebook or google or whatever should NOT result in compromise of your password. It should instead result in detection of a scam (e.g. failure to connect to site)
Entering passwords into plaintext web forms on SSL sites obviously does NOT accomplish this.
Being trained to entering passwords only into browser based login dialogue which mutually authenticates using appropriate zero knowledge proof does.
All mutual authentication requires guarding of source of trust. You can hash a password and store the hash but this only shifts the burden from protecting the password to protecting the hash. If the hash is compromised trust is also compromised (e.g. "passing the hash"). There is fundamentally no way around it other than to maintain the current ridiculous status quot.
I couldn't disagree more with this so called "best practice".
Hashes can be brute forced as a function of strength of users password (universally very poor) and size of password pool (2.9m..hiccup). The situation gets worse and only goes downhill as technology improves. Selecting the latest and greatest hashing algorithm does nothing to change this basic truth. Nor does amplifying weak passwords by a multiplication factor of redundant rounds do anything much useful to fix a problem in which only exponents provide actual security.
Encrypted passwords on the other hand are useless to an attacker unless they possess the decryption key. On a well designed system storage is completely separate from decryption key and as such breaches have no consequence.
Further this industry is universally doing it wrong while knowing better. Accepting passwords in the clear over SSL as virtually everyone does is **NOT** acceptable or secure. The phishers love each and every one of us for not insisting on real security. Doing it the right way requires either server side decryption of the password or possession of the hashed version as proof of knowledge in which case the hashed version of the password is fundamentally no different than the plaintext.
When we are storing things resembling SRP verifiers on the server protected by encryption keys and entering passwords into special browser provided fields rather than ad-hoc fields on web forms them come back to me.. Until then OWASP and everyone else parroting back this "best practice" without thinking are making things worse for everyone.
If you want to be amused by people with no understanding of the proper use of hash algorithms in a security standard check out PCI DSS 3.4 "One-way hashes based on strong cryptography"
Lets do the math here. When you strip away the first >6 digits representing a few hundred issuers and subtract the check digit it leaves a search space in billions to trillions making it trivial for anyone to reverse regardless of hash algorithm. Being a "secure" hash algorithm does nothing to protect you from insane misuse of said algorithm.
Slashdot Mirror
Time to start from scratch, and start a large-scale redesign of the Internet and its protocols, to try and better secure users from surveillance/attacks?
In my view the most dire issue facing the network right now is handful of content companies owning majority of network traffic. People have to run their own servers and get involved with the network again. There is no meaningful technological solution for aggregation of power in the hands of a few media companies caused by laziness and lack of engagement. Those with the skills need to work to make it more accessible to those without the time or inclination to learn.
Tor and other fringe security protocols/networks won't cut it, and getting people to use very-user-unfriendly encryption tools won't happen - nothing short of a mammoth redesign
The structure of the current net at IP layer and below is architecturally about right as far as I'm concerned. 100% untrusted, 100% untrustworthy. All the network needs to do is forward packets with some degree of assurance they will be delivered.. the rest is up to us users.
far surpassing the resources/scale of the IPv6 changeover, is going to come anywhere close to repairing the damage.
I think if we're smart about it IPv6 becomes a huge part of the solution. Whatever the future of the net and accompanying protocol soup look like maintaining a network of peers where any one can talk to anyone else is the most powerful tool we have to avoid oppressive tendencies of various less than perfect governments.
There's no going back now - it's already too late to salvage what we have, because it has already been completely and irrecoverably 'owned' - the NSA broke the Internet.
If you were talking specifically SMTP or SSL CA's I would agree with you. More generally all is not lost and all does not need to be replaced.
Because consoles aren't something most people use 24/7. I probably use my 360 about 2-3 hours per week. It's not at all challenging to see the opportunity for increased efficiency. Why should everyone have a full powered machine that only is used 2-3% of the time. 2-3% usage is the perfect situation for usage based rentals.
Good luck improving on the power button.
Its very simple - power savings, and cheaper thin consoles for end users.
What power savings? Power is being consumed somewhere else where as a customer YOU are paying for that too. Lets not forget about additional power requirements required to push insane number of real-time bits for trivial reasons over the Internet.
This would not work too well for multiplayer because of the latency between user-server-user, but would be great for single player.
Since everyone would experience input latency and there is no network latency for the multi-player link latency would be about the same persistent problem whether it were single or multiplayer game. The only lag assuming lack of operator incompetence would be in the form of input delay with very limited opportunities to compensate with prediction algorithms. Nobody who plays on anything approaching a competitive basis would touch this thing.
It's basically a way to keep the price of consoles at a point where people will still buy them, while being able to offer the level of processing power that would be too expensive.
Current consoles are well beyond the point of diminishing returns with regards to graphics power while cost of replicating existing capabilities keep getting cheaper year after year.
I don't know if it's vendor lock-in, but atleast this is a way to offer paying customers a better experience than pirates instead of the other way around with current DRM.
On what planet does high latency translate into a better experience?
This reminds me of a certain coffee stand I drive by each day on my way to work.
Every few months it closes down, sold to a new owner who improves it and re-opens only to close down a few months later.
In the last few years I can count on one hand times drive thru was something other than completely empty.
Sometimes people just can't take a hint.
Either the government will send people over to force the issue, or I could do it myself.
If you are doing something that I want stopped and you won't stop, my only two options are to pay the government (via taxes) to force the issue, or to force it myself.
You could try searching for another way to settle conflicts such as invocation of the sacred art of letting others have your way.
Such one dimensional thinking... assumption that force is necessary to effect change when it is rarely so, practical or produces favorable outcomes.
After you have called the government on your neighbor you still have to live with them as your neighbor.
Those of you defending this specific EPA ban on the *abstract* basis of limits of a persons right to pollute how does your position square with the following hypothetical?
House A has a 500sq ft home with a family of four.
House B has a 3000sq ft home with just one person living there.
Both homes use wood stoves exclusively for heat. House A spews 15 micrograms per cubic meter of air.
House B spews 10 micrograms per cubic meter of air.
Who is the bigger polluter?
Efficiency and sustainability is ultimately best achieved when there is market pressure behind them - preferably by consumer deriving value from lower operating cost.
In case of wood stoves cleaner air translates into less wood consumed and less gunk to clean out of the system. It should be something buyers are naturally looking for when purchasing a stove and a point of market differentiation for manufacturers.
If energy efficient stoves must be more expensive then offer a subsidy to help people of limited means make the better choice. It is clearly in everyone's interest to get the more efficient model.
While there are problems which can't be solved without government threat of violence to "internalize externalities" did anyone even try before invoking EPAs blunt instrument?
TCP is, however, a bottleneck, and not optimal for all uses.
I think this is obvious to everyone. Hammers are not optimal for all uses. TCP provides an ordered reliable byte stream. Not all applications require or benefit from these properties. Using the right tool for the right job tends to provide the best results.
TCP has all kinds of cool, well-thought-out machinery which simply isn't exposed to the application in a useful way.
As an example, when SPDY or HTTP2 is layered on TCP, when there is a single packet lost near the beginning of the TCP connection, it will block delivery of all other successfully received packets
What are you referring to specifically? Is this before or after established state? Are you talking about some kind of SYN cross where data sent in the same round as SYN where SYN is lost but not subsequent data? What is the missing packet at issue and why do you believe the current behavior is wrong or not optimal? What is the role of congestion avoidance in your decision?
I think there are huge amounts of room for improvement in TCP. At the very top of my list is TFO and ICW hysteresis. If adopted more generally they would offer significant additional value. Drafts and code for the most part are already out there. TFO has been available as a socket option in Linux for a year or so already.
even when that lost packet would affect only one resource and would not affect the framing of the application-layer protocol.
HOL is always solved by multiple concurrent streams. With TCP TFO for example concurrent requests go out on the wire without having to pay out a single RTT in advance for connection setup of of subsequent streams. Does not get much cheaper than free.
It's in-effect correct because there are lots of UDP protocols designed before the general concept of "do not amplify unauthenticated solicitations with a larger reply" finally sunk in. (Or at least, sunk in among more serious protocol designers/implementers.)
The parent was making a point against QUIC because it used UDP. It is a false statement. QUIC has appropriate mechanisms to prevent unsolicited mischief.
What DNS, SNMP, NTP and god knows what else did way back then have nothing at all to do with the topic at hand.
If the QUIC exercise is successful, then the IETF should consider extending TCP to support the relevant features. For example, their point about multiple steams is a good one. Perhaps TCP should define an option to open N simultaneous connections with a single 3-way handshake. Existing implementations would ignore the new option bytes in the header so nothing would break.
While TCP is ancient there has been continuous work to improve it over the years. I think most people throwing stones here have not taken the time to look around and understand the current landscape. Indeed many ideas in QUIC are good ones yet not a single one of them are something new or something that had not been implemented or discussed in various WGs.
Regarding multiple streams what effectively is the difference between this and fast open? I send a message the message arrives and is processed immediately without a round trip... with a scenario like that what is even the point of something labeled "multi-stream"?
You make a good point about poor congestion control causing wide-scale harm, but that problem exists today. Anyone can create any protocol they want, as long as it is built on TCP or UDP.
TCP congestion is normally implemented within the operating system where user space does not have access or visibility into scheduling of transmission.
UDP mostly used for low bandwidth exchanges or inherently rate limited realtime communications. Most of these applications sport non-existent or insufficient congestion coverage. For example a bit torrent client without built in queue management or where you have neglected to set rate limits will easily saturate any network link to the point of being unusable. UDP congestion is a problem it just is not that big of a bandwidth consumer to have a large scale impact where it can be a threat to the network.
To be clear I don't think Google is at risk of bring about a congestive apocalypse. The potential risk I see takes the form of excessive aggression for competitive advantage.
The slides refer to a feature called "pacing" where it doesn't send packets as fast as it can, but spaces them out. Can someone explain why this would help? If the sliding window is full, and an acknowledgement for N packets comes in, why would it help to send the next N packets with a delay, rather than send them as fast as possible?
I wonder if this is really "buffer bloat compensation" where some router along the line is accepting packets even though it will never send them. By spacing the packets out, you avoid getting into that router's bloated buffer.
Yes essentially it is a hedge against future probability of packet loss. I don't know about QUIC but with TCP statistically more packet loss tends to present toward the end of a window than start therefore normally more expensive to correct.
The back off mechanism is one of the problems they're trying to fix. Internet protocols need some way to control bandwidth usage, but there are a lot of limitations with the existing options in TCP.
Like? Please be specific. This thread is getting old quick with people saying "TCP sucks" going on and on about how it just sucks without ever citing any technical justifications why that is so.
There are tons of congestion algorithms
http://en.wikipedia.org/wiki/TCP_congestion-avoidance_algorithm
and extensions
http://en.wikipedia.org/wiki/TCP_tuning
for TCP.
The current problem with UDP is that many border routers do not check whether outgoing udp packages are from within their network. This is the base for DNS based ddos attacks. They are very difficult to mitigate on server level without creating openings for Joe job attacks instead... Standardizing on udp for other protocols will emphasize this problem
This is incorrect. Ingress filtering is a global IP layer problem.
TCP handles the problem with SYN packets and SYN cookie extensions to prevent local resource exhaustion by one sided SYNs from an attacker.
A well designed UDP protocol would be no more vulnerable to this form of attack than TCP using the same proven mechanisms of TCP and other better designed UDP protocols (DTLS).
DNS can also be fixed the same way using cookies but seems people are content to make the problem worse by implementing DNSSEC and ignoring the underlying issue.
May I be so bold as to suggest graphs citing only x performance improvement for protocol y are insufficient, harmful and useless measures of usable efficiency. We know how to make faster protocols.. the challenge is faster while preserving generally meaningful congestion avoidance. This part is what makes the problem space non-trivial.
Look at TFA and connectify links it is all performance talk with total silence on addressing or simulating congestion characteristics of the protocol.
Having sat in on a few tcpm meetings it is always the same with google... they show data supporting by doing x there will be y improvement but never as much enthusiasm for consideration of secondary repercussions of the proposed increased network aggression.
My personal view RTT reductions can be achieved thru extension mechanisms to existing protocols without wholesale replacement. TCP fast open and TLS extensions enabling 0 RTT requests thru the layered stack...experimental things for which "code" exists today can provide the same round trip benefits as QUIC.
What google is doing here is taking ownership of the network stack and congestion algorithms away from the current chorous of stakeholders and granting themselves the power to do whatever they please. No need to have a difficult technical discussion or get anyones opinions or signoff before droping in a new profit enhancing congestion algorithm which could very well be tuned to prefer google traffic globally at the expense of everyone elses ... they control the clients and the servers...done deal.
There are two fundamental improvements I would like to see regarding TCP.
1. Session establishment in the face of in band adversaries adding noise to the channel. Currently TCP connections can be trivially reset by an in-band attacker. I think resilience to this necessarily binding security to the network channel can be a marginally useful property in some environments yet is mostly worthless in the real world as in-band adversaries have plenty of other tools to make life difficult.
2. Efficient Multi-stream/message passing. Something with the capabilities of ZeroMQ as an IP layer protocol would be incredibly awesome.
Question: Do you believe that tobacco users should pay more for health insurance due to their choices, or would you require that all policies be priced the same regardless of personal choices?
My previous comment is applicable to structures where health care is "free" and everyone pays indirectly by virtue of being a taxpayer.
Competition only works if all feet are held to the fire. This applies to consumers, producers and middlemen alike.
If an insurance company wants to charge Smokey the bear more for lighting up or for eating shit far be it for me to complain about that.
Problem with most health care regimes as I see it insurance fails or at some point is captured and then fails to become an effective proxy for competition. As long as the hospitals feet are not at risk of burning health care costs will continue to be grossly detached from reality.
Thankfully my phone has no Google Apps, in fact, no apps at all and most certainly no GPS in it. Look after those old phones. No GPS == No Big Brother Tracking
Nice to hear you using the words cell phone and no big brother tracking in the same sentence as if NSA had not been wholesale collecting cellsite data of every cell user in the US.
Do you really not see a difference between an experimental, opt-in location system and an international, clandestine spy program?
Does the average person who has "opted-in" know what they are getting into or is this fine print inserted to make the lawyers happy and subsequently buried by professional marketing turd polishers?
Yes, but the problem with that is if you make crappy food choices, then we all have to pay for your health care.
If you're ok to go die in a ditch because you ate a dozen Krispy Kream donuts every day, then fine, have at it, but if you want to join the health care system, then we all should get some say in what you can and cannot eat.
It does affect the overall cost to all of us, so it isn't just "personal choice".
I would gladly pay more for the freedom of others to make poor personal choices. Freedom isn't free.
.5/g per serving of Trans-fats will not hurt you. Silly point.
There is no basis for such conclusions without first knowing how many "servings" would normally be consumed.
Serving size is completely arbitrary some have been intentionally reduced to avoid having to put a number other than 0 in the trans fat column.
This has the effect of the consumer being lied to about the nutrition of the shit their eating.
It's not enough that we tell people what they eat may be bad for them, now we enforce it. How long before meat is banned? Sugar? Fat? Salt?
I tend to agree with this in principal yet as it stands consumers are denied the ability to know how much trans fat is in the shit their eating due to the infamous 0.5g/serving threshold loophole.
Either change labeling laws or get rid of the shit. Changing labeling laws would essentially have the same effect anyway I suspect.
I would spend the time hacking away at my car while it is driving.
So now all the attacker has to do is steal your password list, plus that single encryption key and they've just saved themselves week/months of work of brute-forcing and dictionary attacks against the list.
Unless you are willing to properly weigh risks throughout the threat tree this all an attacker has to do game is not worth playing. Everyone is always one hop away from an "all an attacker has to do" disaster scenario regardless of what they do.
All an attacker has to do is compromise system generating user accounts or accepting password changes and they can collect millions of plaintexts at their leisure.
Nobody said anything about a "single encryption key" ... that was something you made up. Proper key management includes mitigation of risk.
If you only use hashing then, yes, you are open to Rainbow Table attacks because common passwords can be immediately exposed.
But hashing is not salted hashing. Best practice uses salted hashing with a unique salt for each user, thus making Rainbow Table attacks useless - you have to generate a whole new set of Rainbow Tables for each known salt which is a whole lot more work for an attacker.
Who cares if you use a salt or not? If entropy of the underlying password is shit as most passwords are the password will still be compromised. When you are working with a space of 2.9 million passwords there are plenty of easy pickings to make your botnet army's computer time well worth the trouble.
Cost of compromise goes down as technology advances while human capacity/willingness to manage large passwords remains constant.
You could do both: Hash and encrypt.
No, I explained why when I talked about establishing proof of password knowledge.
Entering your password into a site which falsely claims to be twitter or facebook or google or whatever should NOT result in compromise of your password. It should instead result in detection of a scam (e.g. failure to connect to site)
Entering passwords into plaintext web forms on SSL sites obviously does NOT accomplish this.
Being trained to entering passwords only into browser based login dialogue which mutually authenticates using appropriate zero knowledge proof does.
All mutual authentication requires guarding of source of trust. You can hash a password and store the hash but this only shifts the burden from protecting the password to protecting the hash. If the hash is compromised trust is also compromised (e.g. "passing the hash"). There is fundamentally no way around it other than to maintain the current ridiculous status quot.
I couldn't disagree more with this so called "best practice".
Hashes can be brute forced as a function of strength of users password (universally very poor) and size of password pool (2.9m..hiccup). The situation gets worse and only goes downhill as technology improves. Selecting the latest and greatest hashing algorithm does nothing to change this basic truth. Nor does amplifying weak passwords by a multiplication factor of redundant rounds do anything much useful to fix a problem in which only exponents provide actual security.
Encrypted passwords on the other hand are useless to an attacker unless they possess the decryption key. On a well designed system storage is completely separate from decryption key and as such breaches have no consequence.
Further this industry is universally doing it wrong while knowing better. Accepting passwords in the clear over SSL as virtually everyone does is **NOT** acceptable or secure. The phishers love each and every one of us for not insisting on real security. Doing it the right way requires either server side decryption of the password or possession of the hashed version as proof of knowledge in which case the hashed version of the password is fundamentally no different than the plaintext.
When we are storing things resembling SRP verifiers on the server protected by encryption keys and entering passwords into special browser provided fields rather than ad-hoc fields on web forms them come back to me.. Until then OWASP and everyone else parroting back this "best practice" without thinking are making things worse for everyone.
If you want to be amused by people with no understanding of the proper use of hash algorithms in a security standard check out PCI DSS 3.4 "One-way hashes based on strong cryptography"
Lets do the math here. When you strip away the first >6 digits representing a few hundred issuers and subtract the check digit it leaves a search space in billions to trillions making it trivial for anyone to reverse regardless of hash algorithm. Being a "secure" hash algorithm does nothing to protect you from insane misuse of said algorithm.