It's redundant, client certificates have been widely deployed for decades, achieve the same result, are standardized and cheaper (both in terms of software and hardware solutions).
What is most wrong with it is that USB is used instead of a dedicated interface such as a smartcard reader. USB is a massive attack vector. For it to be required for basic authentication in my view is irresponsible at best. Someone replaces your USB key when you are not looking and when you plug it in next it's a HID that executes shell commands to install a RAT or it's a class device that takes advantage of driver vulnerability to root your system. Attack surface of USB is gargantuan.
Security sensitive environments explicitly restrict USB for a reason. Turning around and requiring it for access is brain-dead stupid.
Passwordless, asymmetric authentication is absolutely the future and the right thing to do Are you so blinded by Microsoft hate that you are unable to see this?
I don't view your assertions as valid on their face.
The selection of any single factor (know, have, are) or chaining of one or more for authentication each have their strengths and weaknesses. It's generally a good thing that more methods are made available so people and organizations can chose options that best fits their needs based on careful consideration of requirements and tradeoffs.
There is no panacea. There is no one solution. The idea the "future" is necessarily dominated by what you have or considered "the right thing to do" is not apparent to me at all.
that "trust" requires an expensive cert and a third computer in the loop (the server which is inexplicable presumed to be trustworthy even thought there is no cert for it being verified by some other (fourth?) server, which would of course need a cert verified by some (fifth?) server, etc.
In fact, who said that this current scheme/scam provides ANY true confidence and security?
The old line "who died and made YOU king?" comes to mind.
What I actually said is encryption without trust is meaningless doublespeak. This is a basic fact of reality not open for debate any more than the outcome of 1 + 1 is open for debate.
The rest is you yourself attacking a strawman created exclusively from your own imagination insinuating things neither stated or implied. My response is exclusively in the context of "encryption" without "trust" advocated by OP.
Saying a specific source of trust is no good or other sources can be used instead is NOT the argument of OP: "we need an encryption scheme that is on be default on any web server and that does not require certificates - just the encryption"
What's required is a new scheme that ditches all this fake confidence. The new scheme should allow users to "sneakernet" certs and keys too... so a private business concern or members of an extended family, for example, could exchange digital certs in-person or via snail mail (like on USB keys) which would then be used on each end of the digital communications without the use of some 3rd party server.
I've been advocating trust off-ramps by limiting scope of global trust anchors exclusively to role of initial service discovery for many many years.
I've advocated for adoption of specific readily available and accessible technological solutions (standalone secure authentication) denied from being rolled into browsers for purely selfish political reasons. More importantly I've implemented these solutions in the software I develop.
The author makes a great point about the near impossibility of perfect, error-free quantum computation. But this has been realized a few years back by most quantum algorithm developers, too.
Many recent algorithms assume that the quantum computation will be partially faulty. And they work around it.
Yes, that makes these algorithms harder to design and they are less efficient compared to the ones assuming no errors, but they still seem to provide a way forward. I would definitely not write off quantum computing yet.
If whatever augmentation you can dream up doesn't follow an exponential growth curve (NONE OF THEM DO) then it's not worth thinking about on these scales.
Lets say your able to do quantum error correcting using fan-outs of supporting qubits. None of the imagined schemes to achieve this come close to exponential scaling.
Likewise no kind of oversampling or related scheme anyone has been able to dream up to account for noise allows exponential scaling.
There becomes a decidedly non-exponential curve after which you've fallen so deep into the noise floor your totally screwed no matter how clever you are.
Please don't get me wrong these things are useful and worth doing. I have no doubt QC will be useful for solving problems in the future. It's just that none of it means jack shit in the context of a scalable quantum computer.
I thought that the whole point of quantum computers was that there's no need to describe or process all possible states. And that the difficulty of practical quantum computers is that the qubits need to "work together": you can't just make 1 cubit, then make 1023 more and build yourself a 1024 cubit computer.
The guy obviously knows way more about quantum computers than I do. But I've never seen the difficulties of quantum computing described in this manner.
I think it's important to express measures in this way because it keeps everyone honest. People are cheating at least in marketing jargon. Simply belching out number of qubits in something is like belching out the number of transistors in a flash drive and using that to draw conclusions about it's processing performance relative to other components.
Given we have people building "topological" computers with a whole lot of qubits that don't map to anything resembling exponential performance curve I think it makes the most sense to describe performance in this way and only in this way. Qubit counts are meaningless.
And so long as you always get to cherry pick what conditions to frame the situation you put "everyone" in... you might as well declare unencrypted HTTP hitler, because thats about as much honesty and sense you are making.
SSL was invented by Netscape specifically to address needs of ecommerce.
To this day one of the most common scenarios where general public cares most about security on the Internet has to do with monetary transactions conducted via Internet. For most this means buying shit from ecommerce sites and some form of online banking. It's in this context they are most exposed to and familiar with the concepts of security and encryption.
So again... you havent said shit... you havent made a point.. you are just waving your hands
I don't believe referencing common activity conducted by the general public where security has the highest profile exposure in their lives is cherry picking.
When the public thinks "secure" they dont think the same thing that you do about what that means, so your point is less than nothing.
I disagree. Everyone knows what secure means. When someone buys something from an ecommerce site or logs into their bank account there is no confusion in anyone's mind as to what secure means in the context of what they are doing.
Alex is a security dude at Mozilla. Yes the very same company whose browser is so insecure it's not even on the menu of hacking competitions because exploits are too easy to come by.
A security dude who believes "If we make that change and that investment we can make a dramatic improvement to computer security for all users, and make HeartBleed, WannaCry, and million dollar iPhone bugs far less common."
I was very much looking forward to seeing Mozilla lead by example and port the whole browser to Rust or whatever without cheating by ever using any of the unsafe methods the Rust language provides yet it seems this isn't even on the roadmap. Apparently continuing to add new features and improving "performance" is more important to Mozilla than security of their users. They can improve security of their browser right now by compiling it with compile time guards and using any number of third party tools that protect against these things with existing codebase yet Mozilla is consciously choosing not to even though it's security record is among the worst of major browsers.
It is scary yet unsurprising a security guy would believe false nonsense eliminating software bugs would bring about a "dramatic improvement to computer security". The fact is well over 90% of breaches exploit people not weaknesses in computer code. If you snapped your fingers and magically removed all vulnerabilities from all software and hardware tomorrow globally nothing would change. For someone in his position not to understand this basic reality is extremely disconcerting. It means he's trying to saw off the visible portion of an iceberg above water to keep from damaging ships in its path.
A bigger issue is that when developers sit down to choose a programming language for a new project, they're generally making their decision based on what languages their team knows, performance, and ecosystem of libraries that can be leveraged. Security is almost never a core consideration. This means languages which emphasize security, at the cost of ease of use, are at a disadvantage.
Major languages supposed to be immune to low level memory issues are way easier to use.
With QUIC on the way and HTTP3 on the horizon, we need an encryption scheme that is on be default on any web server and that does not require certificates - just the encryption.
Encryption without trust is not just meaningless doublespeak it's actually dangerous.
The public hears "encrypted" and thinks it means "secure".
Even if all of the matter inside a fusion reactor were to fuse simultaneously -- a physical impossibility -- the worst that would happen is significant damage to the reactor building. There simply isn't enough matter inside the reactor at any time to do worse.
Fusion reactors are still generating neutrons.. activation is still a problem. There must be at least some radioactive crap that can leak out and make the evening news.
I'm afraid that all deuteriam and tritium based fusion reactors rely on fuel that is in extremely limited supply, especially tritium. Since the main source of tritium on Earth is nuclear decay from fission reactors, if there are enough fission reactors to generate enough of the very inefficiently used fusion fuel to generate significant, they can generate many times more energy from the fission reactors without having to engage in dangerous refinement of the tritium.
The plan is for tritium to be bred from fusion reactors when they are actually working in a commercially useful manner.
And out of the actual billion people in the world lots of people will require hardware upgrades. Anyway pat yourself on the back. It's only taken you 15+ years to get I tend to agree with the conclusions but not the supporting detail about I woke up one day and my web server supported TLS or QUIC or whatever.
Except you're missing the obvious difference between a software update and a hardware upgrade, and yes I deliberately used two different verbs to describe what was going on. Comparing the two is assinine. You can literally have all the capabilities in QUIC while you sleep.
The point I'm making doesn't rely on verb use or differences between hardware and software. In fact it doesn't rely on any specific information of any kind.
The entirety of my point is an attempt to convey fruitless nature of engaging in baseless cherry picking.
I didn't lift a finger for a new car appeared in my garage. I didn't lift a finger for TLS 1.2 to appear on my web server. I didn't lift a finger for QUIC to appear on my web server. I didn't lift a finger for IPv6 to appear on my network. I didn't lift a finger and a basket of goodies appeared on my doorstep.
*ALL* of the above statements fail spectacularly to speak objectively to the underlying issues in any meaningful way.
They say nothing of the costs involved, who pays or is otherwise negatively impacted.
They speak little to nothing of value and who benefits.
My comparison was intended exclusively as a device to illuminate the worthless baseless nature of the original statement I quoted: "Anecdote: One day in 2015 I woke up to find my webserver supported TLS 1.2"
Nothing more. I was not staking an opinion on or give a fuck about individual perspectives on comparative cost benefit analysis of IPv6 vs QUIC deployment.
Maybe its time for BGP (the protocol that is used by all these networks to talk to each other) to get some security so that people can't advertise routes for IP blocks they dont actually own.
Great idea, you should totally do that.
Tell all of the tier 1 networks not to advertise routes to your 'blocks' because they don't own them.
There is no such thing as HTTP 3.0. This is HTTP/3 being discussed, which is HTTP (some version) over QUIC. It is not a change to the HTTP protocol.
This is not true. This is not just a simple layering of an existing transport agnostic application protocol on top of a new stream transport.
It is perfectly possible to achieve this outcome via QUIC but it's not what's being specified in the draft and is not what is actually being deployed.
The HTTP protocol has in fact been modified:
"An HTTP message (request or response) consists of:
1. the message header (see [RFC7230], Section 3.2), sent as a single
HEADERS frame (see Section 4.2.2),
2. the payload body (see [RFC7230], Section 3.3), sent as a series
of DATA frames (see Section 4.2.1),
3. optionally, one HEADERS frame containing the trailer-part, if
present (see [RFC7230], Section 4.1.2)."
While the HTTP layer from a higher layer perspective of server applications and clients is mostly unchanged this is not just a simple layering of a transport agnostic application protocol.
Not at all. They may wake up one day to hear about this IPv6 thing only to find that their modem doesn't support it, their switches doesn't support it and even if it did, their ISP doesn't provide them with a publically routable IP address.
Everything I said is factually correct and has in fact already happened to countless millions of customers on eyeball networks across the world.
For years modems and routers sold that don't support IPv6 today are an endangered species. Only managed switches which most consumers don't have in the first place need to "support" IPv6. I'm unaware of any ISP handing out non-routable IPv6 prefixes. I'm sure someone somewhere is doing it yet the behavior is quite rare and counterproductive. The entire reason you as an ISP deploy IPv6 is routing is cheaper and better user experience than CGN.
Comparing IPv6 to what is being proposed here is idiotic to the highest order and serves only to show an incredible lack of critical thinking skills.
This is actually my point. I was pointing out the absurdity of the supporting evidence with a factually correct counter-argument for IPv6.
I tend to agree with the conclusions but not the supporting detail about I woke up one day and my web server supported TLS or QUIC or whatever. While it may be factually true it's cherry picking that fails entirely to speak objectively to the underlying issues.
Anecdote: One day in 2015 I woke up to find my webserver supported TLS 1.2
I did need to restart the running instances, but yes updating EVERY running web server is simpler.
This often happens to Internet users. They wake up one day and all their computers have IPv6 addresses and more than half of their traffic is IPv6. Not only did they not do anything to make it happen they don't even know what IPv6 is.
Originally HTTP ran over plaintext, unencrypted TCP. There was a TCP session. Then there was the option to tunnel an SSL session over the TCP connection, so you had a session within a session. You'd first establish a TCP connection, doing the whole handshake dance, then start the handshake dance over again for SSL. That's just as slow and inefficient as it sounds.
By definition a tunnel is a transport protocol within a transport protocol. SSL is NOT a transport protocol. SSL is a security layer. SSL is transport agnostic requiring an ordered reliable stream over which to operate. TCP is but one of many protocols SSL operates over.
The reality is only advantage QUIC has over TFO + tickets is one additional RTT on initial connection. From there new HTTPS requests can be 0-RTT over TCP just like their QUIC counterparts.
The idea you are selling layering is bad and necessarily inefficient is not true.
Now that we're moving to TLS on all web connections, setting up a TCP session just to then set up a TLS connection is wasteful and silly.
Not that it matters WRT topic at hand but not everyone wants to use TLS.
Many protocols designed for encrypted connections, such as ipsec and openvpn, work better by just setting up the connection once. They just do one handshake, which sets up the encrypted connection, over UDP.
That's what QUIC does - the handshake sets up an encrypted TLS connection, over UDP. That's faster and more efficient. That's why openvpn, ipsec, quic, and most protocols originally designed for encrypted connections skip setting up two sessions, an unencrypted TCP session and then an encrypted session riding it. Just set up one encrypted session.
The reason VPN transport avoid the use of TCP has nothing to do with inefficient evils of layering. It has everything to do with the fact VPNs are tunneling PACKETS not STREAMS.
SCTP is available now, is well understood, HTTP(S) already runs on it. Is more resilient than TCP, does not have Head-of-Line issues...
The primary driver for change is round trip reduction. You can achieve QUIC parity in that regard using TCP TFO in conjunction with TLS features (session tickets). This is really nice because you can resume a "session" with no round trips before transmitting request to a server without requiring server side state be maintained.
With these two used in conjunction HTTP 1.0 works just as well as HTTP 3.0 given you can send any number of requests any time you want without any inter-request HOL with no RTT overhead.
SCTP kind of sucks in this regard and the resilient thing with connecting to multiple hosts and active heartbeats is dumb/worthless/counterproductive.
You can only use one path at a time and you eat something like a RTO on switchover. It's better simply to connect to a couple hosts at once or stagger connection by a few hundred MS and go with whatever answers first.
What's not to like?
What's not to like from Google's perspective is not having full control over the transport protocol from user space. They don't get to fuck with congestion algorithms throwing caution and prudence to the wind for selfish undeserved advantage over responsible traffic.
Not really sure why smartphone vendors feel they need to take it upon themselves to dream up innovative new ways to poke, annoy and piss off their customers while at the same time raising prices to ridiculous new heights and failing in spectacular manner to deliver compelling new value.
Not really surprising nobody's upgrading anymore given industry behavior.
I'll upgrade tomorrow if any vendor can deliver the following.
1. Removable battery 2. Physical keyboard (e.g. BB KEY2) 3. Not ridiculously thin 4. Not ridiculously large 5. No infinity edge 6. No notches 7. No headphone "courage" 8. No AMOLED (IPS please) 9. No (front) cameras 10. No biometric unlock 11. No locked bootloaders 12. SD Card 13. Configurable RGB indicator light for notification 14. IR transmitter 15. Real GPS 16. SDR AM/FM... LF-UHF preferred
Regular guys believe and are very sure that they know the difference, just like they are sure about many other things they have no clue about. It's called ignorance and yes, this is a common feature of the so-called regular guy.
All you are doing is making a bigoted blanket statement about "regular guys" exposing your own biases.
Some degree of ignorance is useful and necessary in order for people to function in the real world and get anything at all accomplished.
Some assume too much for their own good while others are too careful and indecisive for their own good. If you feel compelled to judge try doing so on an individual basis using something resembling objective criteria.
so thank you to all the fucking 'cord cutters' that raised the rates for everybody else.
You're quite welcome.
so $30 more for less, and 15x4 + 10x2 + 5 + 20 = $105 for what we gave up = $135 + 110 = $245 to get what we had. that's well over 100% increase since 2005 when we had to start downgrading services.
You're welcome to join us and become a cord cutter too. We have cookies.
Slashdot Mirror
What is so wrong with the FIDO spec?
It's redundant, client certificates have been widely deployed for decades, achieve the same result, are standardized and cheaper (both in terms of software and hardware solutions).
What is most wrong with it is that USB is used instead of a dedicated interface such as a smartcard reader. USB is a massive attack vector. For it to be required for basic authentication in my view is irresponsible at best. Someone replaces your USB key when you are not looking and when you plug it in next it's a HID that executes shell commands to install a RAT or it's a class device that takes advantage of driver vulnerability to root your system. Attack surface of USB is gargantuan.
Security sensitive environments explicitly restrict USB for a reason. Turning around and requiring it for access is brain-dead stupid.
Passwordless, asymmetric authentication is absolutely the future and the right thing to do Are you so blinded by Microsoft hate that you are unable to see this?
I don't view your assertions as valid on their face.
The selection of any single factor (know, have, are) or chaining of one or more for authentication each have their strengths and weaknesses. It's generally a good thing that more methods are made available so people and organizations can chose options that best fits their needs based on careful consideration of requirements and tradeoffs.
There is no panacea. There is no one solution. The idea the "future" is necessarily dominated by what you have or considered "the right thing to do" is not apparent to me at all.
that "trust" requires an expensive cert and a third computer in the loop (the server which is inexplicable presumed to be trustworthy even thought there is no cert for it being verified by some other (fourth?) server, which would of course need a cert verified by some (fifth?) server, etc.
In fact, who said that this current scheme/scam provides ANY true confidence and security?
The old line "who died and made YOU king?" comes to mind.
What I actually said is encryption without trust is meaningless doublespeak. This is a basic fact of reality not open for debate any more than the outcome of 1 + 1 is open for debate.
The rest is you yourself attacking a strawman created exclusively from your own imagination insinuating things neither stated or implied. My response is exclusively in the context of "encryption" without "trust" advocated by OP.
Saying a specific source of trust is no good or other sources can be used instead is NOT the argument of OP: "we need an encryption scheme that is on be default on any web server and that does not require certificates - just the encryption"
What's required is a new scheme that ditches all this fake confidence. The new scheme should allow users to "sneakernet" certs and keys too... so a private business concern or members of an extended family, for example, could exchange digital certs in-person or via snail mail (like on USB keys) which would then be used on each end of the digital communications without the use of some 3rd party server.
I've been advocating trust off-ramps by limiting scope of global trust anchors exclusively to role of initial service discovery for many many years.
I've advocated for adoption of specific readily available and accessible technological solutions (standalone secure authentication) denied from being rolled into browsers for purely selfish political reasons. More importantly I've implemented these solutions in the software I develop.
The author makes a great point about the near impossibility of perfect, error-free quantum computation. But this has been realized a few years back by most quantum algorithm developers, too.
Many recent algorithms assume that the quantum computation will be partially faulty. And they work around it.
Yes, that makes these algorithms harder to design and they are less efficient compared to the ones assuming no errors, but they still seem to provide a way forward. I would definitely not write off quantum computing yet.
If whatever augmentation you can dream up doesn't follow an exponential growth curve (NONE OF THEM DO) then it's not worth thinking about on these scales.
Lets say your able to do quantum error correcting using fan-outs of supporting qubits. None of the imagined schemes to achieve this come close to exponential scaling.
Likewise no kind of oversampling or related scheme anyone has been able to dream up to account for noise allows exponential scaling.
There becomes a decidedly non-exponential curve after which you've fallen so deep into the noise floor your totally screwed no matter how clever you are.
Please don't get me wrong these things are useful and worth doing. I have no doubt QC will be useful for solving problems in the future. It's just that none of it means jack shit in the context of a scalable quantum computer.
I thought that the whole point of quantum computers was that there's no need to describe or process all possible states. And that the difficulty of practical quantum computers is that the qubits need to "work together": you can't just make 1 cubit, then make 1023 more and build yourself a 1024 cubit computer.
The guy obviously knows way more about quantum computers than I do. But I've never seen the difficulties of quantum computing described in this manner.
I think it's important to express measures in this way because it keeps everyone honest. People are cheating at least in marketing jargon. Simply belching out number of qubits in something is like belching out the number of transistors in a flash drive and using that to draw conclusions about it's processing performance relative to other components.
Given we have people building "topological" computers with a whole lot of qubits that don't map to anything resembling exponential performance curve I think it makes the most sense to describe performance in this way and only in this way. Qubit counts are meaningless.
And so long as you always get to cherry pick what conditions to frame the situation you put "everyone" in ... you might as well declare unencrypted HTTP hitler, because thats about as much honesty and sense you are making.
SSL was invented by Netscape specifically to address needs of ecommerce.
To this day one of the most common scenarios where general public cares most about security on the Internet has to do with monetary transactions conducted via Internet. For most this means buying shit from ecommerce sites and some form of online banking. It's in this context they are most exposed to and familiar with the concepts of security and encryption.
So again... you havent said shit... you havent made a point.. you are just waving your hands
I don't believe referencing common activity conducted by the general public where security has the highest profile exposure in their lives is cherry picking.
When the public thinks "secure" they dont think the same thing that you do about what that means, so your point is less than nothing.
I disagree. Everyone knows what secure means. When someone buys something from an ecommerce site or logs into their bank account there is no confusion in anyone's mind as to what secure means in the context of what they are doing.
Alex is a security dude at Mozilla. Yes the very same company whose browser is so insecure it's not even on the menu of hacking competitions because exploits are too easy to come by.
A security dude who believes "If we make that change and that investment we can make a dramatic improvement to computer security for all users, and make HeartBleed, WannaCry, and million dollar iPhone bugs far less common."
I was very much looking forward to seeing Mozilla lead by example and port the whole browser to Rust or whatever without cheating by ever using any of the unsafe methods the Rust language provides yet it seems this isn't even on the roadmap. Apparently continuing to add new features and improving "performance" is more important to Mozilla than security of their users. They can improve security of their browser right now by compiling it with compile time guards and using any number of third party tools that protect against these things with existing codebase yet Mozilla is consciously choosing not to even though it's security record is among the worst of major browsers.
It is scary yet unsurprising a security guy would believe false nonsense eliminating software bugs would bring about a "dramatic improvement to computer security". The fact is well over 90% of breaches exploit people not weaknesses in computer code. If you snapped your fingers and magically removed all vulnerabilities from all software and hardware tomorrow globally nothing would change. For someone in his position not to understand this basic reality is extremely disconcerting. It means he's trying to saw off the visible portion of an iceberg above water to keep from damaging ships in its path.
A bigger issue is that when developers sit down to choose a programming language for a new project, they're generally making their decision based on what languages their team knows, performance, and ecosystem of libraries that can be leveraged. Security is almost never a core consideration. This means languages which emphasize security, at the cost of ease of use, are at a disadvantage.
Major languages supposed to be immune to low level memory issues are way easier to use.
With QUIC on the way and HTTP3 on the horizon, we need an encryption scheme that is on be default on any web server and that does not require certificates - just the encryption.
Encryption without trust is not just meaningless doublespeak it's actually dangerous.
The public hears "encrypted" and thinks it means "secure".
Even if all of the matter inside a fusion reactor were to fuse simultaneously -- a physical impossibility -- the worst that would happen is significant damage to the reactor building. There simply isn't enough matter inside the reactor at any time to do worse.
Fusion reactors are still generating neutrons.. activation is still a problem. There must be at least some radioactive crap that can leak out and make the evening news.
I'm afraid that all deuteriam and tritium based fusion reactors rely on fuel that is in extremely limited supply, especially tritium. Since the main source of tritium on Earth is nuclear decay from fission reactors, if there are enough fission reactors to generate enough of the very inefficiently used fusion fuel to generate significant, they can generate many times more energy from the fission reactors without having to engage in dangerous refinement of the tritium.
The plan is for tritium to be bred from fusion reactors when they are actually working in a commercially useful manner.
And out of the actual billion people in the world lots of people will require hardware upgrades. Anyway pat yourself on the back. It's only taken you 15+ years to get I tend to agree with the conclusions but not the supporting detail about I woke up one day and my web server supported TLS or QUIC or whatever.
Except you're missing the obvious difference between a software update and a hardware upgrade, and yes I deliberately used two different verbs to describe what was going on. Comparing the two is assinine. You can literally have all the capabilities in QUIC while you sleep.
The point I'm making doesn't rely on verb use or differences between hardware and software. In fact it doesn't rely on any specific information of any kind.
The entirety of my point is an attempt to convey fruitless nature of engaging in baseless cherry picking.
I didn't lift a finger for a new car appeared in my garage.
I didn't lift a finger for TLS 1.2 to appear on my web server.
I didn't lift a finger for QUIC to appear on my web server.
I didn't lift a finger for IPv6 to appear on my network.
I didn't lift a finger and a basket of goodies appeared on my doorstep.
*ALL* of the above statements fail spectacularly to speak objectively to the underlying issues in any meaningful way.
They say nothing of the costs involved, who pays or is otherwise negatively impacted.
They speak little to nothing of value and who benefits.
My comparison was intended exclusively as a device to illuminate the worthless baseless nature of the original statement I quoted: "Anecdote: One day in 2015 I woke up to find my webserver supported TLS 1.2"
Nothing more. I was not staking an opinion on or give a fuck about individual perspectives on comparative cost benefit analysis of IPv6 vs QUIC deployment.
Maybe its time for BGP (the protocol that is used by all these networks to talk to each other) to get some security so that people can't advertise routes for IP blocks they dont actually own.
Great idea, you should totally do that.
Tell all of the tier 1 networks not to advertise routes to your 'blocks' because they don't own them.
We really need to figure out a way to secure BGP announcements.
From whom?
There is no such thing as HTTP 3.0. This is HTTP/3 being discussed, which is HTTP (some version) over QUIC. It is not a change to the HTTP protocol.
This is not true. This is not just a simple layering of an existing transport agnostic application protocol on top of a new stream transport.
It is perfectly possible to achieve this outcome via QUIC but it's not what's being specified in the draft and is not what is actually being deployed.
The HTTP protocol has in fact been modified:
While the HTTP layer from a higher layer perspective of server applications and clients is mostly unchanged this is not just a simple layering of a transport agnostic application protocol.
Not at all. They may wake up one day to hear about this IPv6 thing only to find that their modem doesn't support it, their switches doesn't support it and even if it did, their ISP doesn't provide them with a publically routable IP address.
Everything I said is factually correct and has in fact already happened to countless millions of customers on eyeball networks across the world.
For years modems and routers sold that don't support IPv6 today are an endangered species. Only managed switches which most consumers don't have in the first place need to "support" IPv6. I'm unaware of any ISP handing out non-routable IPv6 prefixes. I'm sure someone somewhere is doing it yet the behavior is quite rare and counterproductive. The entire reason you as an ISP deploy IPv6 is routing is cheaper and better user experience than CGN.
Comparing IPv6 to what is being proposed here is idiotic to the highest order and serves only to show an incredible lack of critical thinking skills.
This is actually my point. I was pointing out the absurdity of the supporting evidence with a factually correct counter-argument for IPv6.
I tend to agree with the conclusions but not the supporting detail about I woke up one day and my web server supported TLS or QUIC or whatever. While it may be factually true it's cherry picking that fails entirely to speak objectively to the underlying issues.
Anecdote: One day in 2015 I woke up to find my webserver supported TLS 1.2
I did need to restart the running instances, but yes updating EVERY running web server is simpler.
This often happens to Internet users. They wake up one day and all their computers have IPv6 addresses and more than half of their traffic is IPv6. Not only did they not do anything to make it happen they don't even know what IPv6 is.
Originally HTTP ran over plaintext, unencrypted TCP. There was a TCP session.
Then there was the option to tunnel an SSL session over the TCP connection, so you had a session within a session. You'd first establish a TCP connection, doing the whole handshake dance, then start the handshake dance over again for SSL. That's just as slow and inefficient as it sounds.
By definition a tunnel is a transport protocol within a transport protocol. SSL is NOT a transport protocol. SSL is a security layer. SSL is transport agnostic requiring an ordered reliable stream over which to operate. TCP is but one of many protocols SSL operates over.
The reality is only advantage QUIC has over TFO + tickets is one additional RTT on initial connection. From there new HTTPS requests can be 0-RTT over TCP just like their QUIC counterparts.
The idea you are selling layering is bad and necessarily inefficient is not true.
Now that we're moving to TLS on all web connections, setting up a TCP session just to then set up a TLS connection is wasteful and silly.
Not that it matters WRT topic at hand but not everyone wants to use TLS.
Many protocols designed for encrypted connections, such as ipsec and openvpn, work better by just setting up the connection once. They just do one handshake, which sets up the encrypted connection, over UDP.
That's what QUIC does - the handshake sets up an encrypted TLS connection, over UDP. That's faster and more efficient. That's why openvpn, ipsec, quic, and most protocols originally designed for encrypted connections skip setting up two sessions, an unencrypted TCP session and then an encrypted session riding it. Just set up one encrypted session.
The reason VPN transport avoid the use of TCP has nothing to do with inefficient evils of layering. It has everything to do with the fact VPNs are tunneling PACKETS not STREAMS.
SCTP is available now, is well understood, HTTP(S) already runs on it. Is more resilient than TCP, does not have Head-of-Line issues...
The primary driver for change is round trip reduction. You can achieve QUIC parity in that regard using TCP TFO in conjunction with TLS features (session tickets). This is really nice because you can resume a "session" with no round trips before transmitting request to a server without requiring server side state be maintained.
With these two used in conjunction HTTP 1.0 works just as well as HTTP 3.0 given you can send any number of requests any time you want without any inter-request HOL with no RTT overhead.
SCTP kind of sucks in this regard and the resilient thing with connecting to multiple hosts and active heartbeats is dumb/worthless/counterproductive.
You can only use one path at a time and you eat something like a RTO on switchover. It's better simply to connect to a couple hosts at once or stagger connection by a few hundred MS and go with whatever answers first.
What's not to like?
What's not to like from Google's perspective is not having full control over the transport protocol from user space. They don't get to fuck with congestion algorithms throwing caution and prudence to the wind for selfish undeserved advantage over responsible traffic.
Having used both Oracle and MS-SQL: Microsoft thinks their product competes with Oracle. It's not anywhere in the same league
Why? Years ago the answer was lack of MVCC. What is it today?
Windows 10 is like a window company that doesn't sell but only rents windows to home owners.
A window company that embeds non-removable cameras in the frames to monitor the window and what's inside.
Not really sure why smartphone vendors feel they need to take it upon themselves to dream up innovative new ways to poke, annoy and piss off their customers while at the same time raising prices to ridiculous new heights and failing in spectacular manner to deliver compelling new value.
Not really surprising nobody's upgrading anymore given industry behavior.
I'll upgrade tomorrow if any vendor can deliver the following.
1. Removable battery ... LF-UHF preferred
2. Physical keyboard (e.g. BB KEY2)
3. Not ridiculously thin
4. Not ridiculously large
5. No infinity edge
6. No notches
7. No headphone "courage"
8. No AMOLED (IPS please)
9. No (front) cameras
10. No biometric unlock
11. No locked bootloaders
12. SD Card
13. Configurable RGB indicator light for notification
14. IR transmitter
15. Real GPS
16. SDR AM/FM
There are many ways this differs...
I suspect if this were actually true you would have actually bothered to specifically list them.
Instead you elected to go with the old disagreement with my conclusions means there is something wrong with you play.
but it boils down to this: Linusâ(TM) words focused on the code, not the coder.
Narrative: Torvolds is unhinged and mean to everyone.
Evidence: I went back 20 years and found a handful of examples that tend to support my narrative.
Narrative: Torvolds is no longer unhinged and mean to everyone.
Evidence: A single post where he neglected to blow up proves it.
He didn't swear and didn't get personal. No all caps even. Quite a change from before.
You are simply cherry picking data which agrees with a pre-ordained narrative.
Regular guys believe and are very sure that they know the difference, just like
they are sure about many other things they have no clue about. It's called ignorance and yes, this is a common feature of the so-called regular guy.
All you are doing is making a bigoted blanket statement about "regular guys" exposing your own biases.
Some degree of ignorance is useful and necessary in order for people to function in the real world and get anything at all accomplished.
Some assume too much for their own good while others are too careful and indecisive for their own good. If you feel compelled to judge try doing so on an individual basis using something resembling objective criteria.
so thank you to all the fucking 'cord cutters' that raised the rates for everybody else.
You're quite welcome.
so $30 more for less, and 15x4 + 10x2 + 5 + 20 = $105 for what we gave up = $135 + 110 = $245 to get what we had. that's well over 100% increase since 2005 when we had to start downgrading services.
You're welcome to join us and become a cord cutter too. We have cookies.