Ideally those incentives would be combined with disincentives for those organizations to continue breaking the web. A combination of the two seems more likely to be successful than either alone.
The corporate firewalls I'm talking about do often break UDP. Because chrome races QUIC/UDP with HTTP(S)/TCP, the big corps are often unaware it's broken. Chrome works around it.
People with corporate firewalls should also be limiting the unruly behavior of web browsers using group policy. For instance, in my environment, regardless of your browser of choice, QUIC is disabled. (As is DoH and various other recent/trendy things browsers are doing.) We also disable all but a small whitelist of approved browser extensions.
Well, they break TLS. That's almost as broad as breaking TCP.
And it's because they want levels of control on the least affordable place. They wouldn't need to break anything if they added the supervising software to the endpoints.
It's odd you refer to endpoints as being the "more affordable place". Because running monitoring software on 5,000 PCs plus management infrastructure and software updates is a lot more "expensive" than having a single purpose-built box on the border between the network and the wider Internet.
Now, I get that QUIC's developers live in a zero-trust/BeyondCorp model, and expect everyone else to too, and with COVID-19, a lot of businesses are suddenly having to look at thinking that way, it's far from how most companies work at present. And having a single box handle filtering and monitoring is actually the most affordable place to put it. ;)
> It's odd you refer to endpoints as being the "more affordable place".
The endpoints afford monitoring. The middle of the network does not afford it, so you are fighting the system and it is certain that you will break stuff.
The middle of the network has always afforded monitoring, until certain companies with a vested interest in interfering with said monitoring started pushing the Internet to not afford it.
Middleboxes are the system, and protocols that deliberately try to block inspection are fighting it and trying to break stuff.
Users have a vested interest in not having their connections MITMed. End-user security is not an "agenda" or a "vested interest". And portraying MITM attacks and similar security holes as "inspection" is spin.
See also RFC 7258 (https://tools.ietf.org/html/rfc7258), "Pervasive Monitoring is an Attack". Protocols that enable interception are broken and will be replaced with protocols that do not.
I disagree. Because when clients get phished or infected by malware that bypassed my inspection boxes, the end user was harmed. For me to buy that we shouldn't MITM for security reasons, you'd need to convince me that cloud providers on the other end were mildly successful at preventing malware, scams, and fraud.
And they're not. Google, Amazon, Microsoft, etc. have failed to keep the Internet safe. And when they fail they hide behind liability shields like Section 230. So it falls on IT staff, more often than not, to filter, block, and intercept where Big Tech has demonstrated inability to do so.
TLS is now pervasive. Certificate Transparency prevents CAs from aiding interception. http is now explicitly flagged as "insecure". Browser vendors have had a major part in those improvements to Internet security. (So have many other parties, such as Let's Encrypt for removing cost as an excuse for not using TLS.)
People trying to make protocols more secure don't need to convince you, they just need to make your job as hard as possible until most users reject what you're offering.
We need a dozen more ideas like Certificate Transparency. We need pervasive end-to-end DNS security, with unencrypted DNS flagged as insecure. We need a means of preventing DNS servers from altering the DNS records of sites they aren't authoritative for. We need browsers to all agree to explicitly flag connections as insecure when they chain to a locally installed certificate, in a way that can't be hidden without rebuilding from source.
And this isn't a purely technical problem, either. We also need legal support to review regulations in certain regulated industries and demonstrate well-supported ways to fulfill those regulations without breaking security (e.g. "if you do XYZ to log the time and endpoints of connections but don't actually MITM their traffic, it's reasonably well-established that you're fulfilling ABC regulation"). We need lobbyists to change regulations incompatible with secure protocols. We need designers to make security as usable as possible, because poor usability is a security problem.
Endpoint supervising isn't always an option. As more IoT devices start to use TLS connections to phone home, a network MITM may be the only way to see what they're reporting. Breaking TLS isn't just something that Big Brother would want to do.
(This is assuming they aren't using pinned certs baked into their firmware, anyhow. I don't have good data on which manufacturers/devices are doing this, but somebody else might know.)
If you want to reverse-engineer those devices, do that in a reverse-engineering lab; you may need to dissect the device to figure out what it's doing. Alternatively, run more open devices.
If you want to run those devices in production, put them in a separate network or VLAN where they can't see anything they don't need to see.
The problem is that as you advocate for encrypted communications with mysterious cloud endpoints, they just refuse to work unless they can talk to Google or other bad actors in secrer. Trust is unraveled by the unfortunate mistake of letting the PKI structure become the ultimate definition of trust in the world.
As it is, don't Chromecasts refuse to function if they can't reach 8.8.8.8? Add encrypted DNS to prevent inspection and transparency, and people are being asked to have potentially hostile devices in their network with no way to inspect them.
If you want to treat a company as a "bad actor", don't have a device they built and supply all the software for on your network or give it access to anything you don't want it to have.
(And the PKI infrastructure is the best thing we have; I'd certainly like to see it replaced with something even better.)
"Just don't use untrustworthy hardware and software" isn't really viable when Windows, MacOS, iOS, and Android (incl. Play Services) are all proprietary closed source operating systems, covering over 90% of all consumer computing devices. Before you include all of the IoT space, which also tend to be proprietary.
So creating a system where I, as a consumer, have no way to inspect the communication my devices undertake removes my rights and safety in deference to companies that really just want to make it harder to block ads.
I take issue with this entire model. The fact that PKI has had piles of issues with bad actors who are supposedly supposed to be bastions of trust doesn't give any example this is a system we should trust, much less have browsers force people to utilize and scare people off avoiding.
Do keep in mind that "want" isn't exactly accurate. No IT team wants to spend any time/effort maintaining that crap, the business doesn't want to shell out for it either since it's expensive, and the ops team doesn't want yet another thing mucking with traffic.
Yet we have one because it's required by law. Wanna take a guess at what companies make sure it stays required by law?
The laws (in the US, at least) are typically written such that some part of the administration is deputized to promulgate technical standards and rules, most of which delegate to the NIST, but sometimes to industry bodies. Laws like this include HIPAA, FERPA, FISMA, and GLB.
There are lots of industry standards you can reference (such as the Cloud Security Alliance Common Controls Matrix), but the government will generally look at things from the perspective of NIST publications, such as NIST 800-171, "Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations". So, basically, what the government thinks private enterprise should be doing to comply with legal requirements to protect sensitive information.
In that document, there are a number of "controls" an organization should have in place, in particular, it should audit any and all data transfers, and ensure such transfers can be traced back to a unique user.
Even within that framework, you aren't going to necessarily find a blanket "read everyone's mail!" edict. Instead, what you are going to do, is make an assessment, as an organization, about what you think you need to do in order to withstand any potential lawsuits that may arise from any kind of disclosure.
If we made software engineers individually liable for these things the way civil and mechanical engineers are, things would look very different.
Many organizations use "the web" as you refer only marginally. The MITM the Outside game works great if you consider the Outside untrusted and only whitelist what you need. Other traffic (both ways) gets inspected for viruses, phishing, information exfiltration, software/hardware call home and whatnot and denied unless proven innocent. This is easier on the users than blocking the outside outright while providing reasonable protection.
for one, not having hardware acceleration makes quic very slow compared to TCP. This is especially a problem on firewalls, as they need to tear apart and reassemble tcp packets at line speed.
In terms of BGP and quic as a transport.
As far as i know, quic is not backwards compatible with TCP, and having two different transport protocols for the routing protocols that ties the internet together would be problematic in terms of migration.
Im not entirely up to speed in terms of how quick would handle MSS size, but this could pose a problem in some situations.
I imagine it would be fairly simple to teach a BGP implementation to use either TCP or QUIC, configurable per-session.
Firewalls that dig deep into tcp packets sound like troublesome middleware with which good actors are in an arms, not something to go out of the way to support.
And why would QUIC not work for other streaming protocols? the only possible disadvantages I can see is that it is a bit more complex and that it requires encryption. It does not in any way require HTTP.
It is. The bare API of QUIC would now mostly look just like TCP/IP streams. You have bidirectional byte streams with flow-control.
The main difference from an API pointer of view is that there is an additional multiplexing layer. On TCP/IP the byte stream is directly on the connection. On QUIC a connection can contain multiple streams - which are openable by both sides. And each of those streams is a bidirectional or unidirectional byte streams.
QUIC doesn't care what protocol you run on top of those streams. HTTP/3 is just the only one which is specified at the moment.
Nothing prevents you from using QUIC as a replacement for TCP AFAIK - on the surface it seems like it would be potentially useful for more applications than HTTP. May even be a decent option for video games and other things that need somewhat lower latency and wish to avoid head-of-line blocking.
Seeing a BGP implementation running over QUIC would be the end game, right? There is so mug network hardware which will not be replaced for decades, so people would have to get started now if they wanted to completely make TCP redundant in the not so near future.
Sure. In fact most video games use some kind of networking middleware. But tbh, a lot of them are not so great because a lot of concerns get mixed together, and if you want a reliable connection with congestion control you likely will just open a TCP connection somewhere with a different protocol.
For the hobbyist world, this option as a low level transport is not so bad imo. Like as a replacement for ENet which does not have IPv6 support today seems reasonable.
lots of games use UDP, lots of games use TCP. I could easily see games using QUIC. If you include mobile games, I doubt most games have the budget to tune a UDP stack.
And emerging QUIC acceleration technology is likely to be stifled by intellectual property laws.
Intel has already filed (in 2019) for a European patent that seems to claim inventorship of the generic concept of hardware offloading (as it applies to QUIC)
How ironic. If you listened to HN, you'd think that Europe was so pro-consumer, unlike those silly Americans who keep granting Stupid Patents to Evil Bigcorps.
Bad, in my view. (Although I am not a lawyer, and would definitely appreciate input from one here!)
Hardware offload of a network protocol is an extremely generic concept and this patent seems to describe that concept (without any kind of novel mechanism or implementation details).
In estimates I've done, in its current un-accelerated state, it would at least triple the CPU cost per byte served on our CDN workload. We basically lose:
- sendfile
- ktls
- TSO
Its like stepping into a time machine and going back to the mid 90s. To send data with QUIC, we have to get byes from kernel into userspace, encrypt them in userspace, and then write them back to the kernel, where they travel down to the NIC an MTU at a time. Ugh.
One of the consequences of TCP being implemented in the Linux kernel is that companies were implicitly motivated to open source any performance or efficiency improvements to their TCP stack. Are any companies collaborating to improve QUIC efficiency issues in open source? The issues are well understood among at least the big cloud providers.
Quic is being standardized in the IETF there are a couple of companies involved:
- Cloudflare
- Facebook: They already use QUIC for some of their products, or at least it's a pretty sensitive piece of software on their architecture because they ask to report bugs to the bug bounty program[1]
- Microsoft
- Nginx
- Google
- NetApp
- Mozilla
- Traffic Server
- Litespeed
- Fastly
- F5
- Apple
Amazon is very quiet about all that, but they are probably looking into it. So, it is pretty backed up. If you take a look at their workgroup homepage (quicwg.org) you will see a couple of open source implementations, some from those same companies.
Adoption of HTTP/2 also limits the appeal of QUIC. HTTP/2 delivers many (not all) of benefits QUIC offers and is both widely implemented and adopted now.
Just the title itself shows author has no idea what the hell he is talking about TCP/IP != TCP
TCP/IP refers to the entire stack that Internet is build on, the UDP is actually part of TCP/IP (it was added later for use cases where low latency was important, like telephony). He probably meant just TCP, but that's still "no".
I see two main ways to look at this question: will QUIC replace TCP as a go to protocol for developing atop of? The other interpretation is, will QUIC replace all TCP ever written? No, indeed, likely not.
I've been told in the recent past that there is so much old internet infrastructure equipment that only knows UDP and TCP that any other protocol will fail to meaningfully catch on. This equipment will drop anything that isn't TCP or UDP and until it's replaced you will have a lot of trouble.
Yes, though this is arguably a big reason why SCTP didn't take off, which is similar to QUIC in a lot of ways (there is SCTP over UDP, but it was a second class citizen until WebRTC.)
I see no problems in Google continuing to replace basic protocols. In fact, why not get rid of the open Internet altogether and just use all Google products all the time? It'll be like the good old days of AOL.
The fact that it originated in Google doesn't make it some kind of proprietary protocol. It's subject to the usual IETF process, just like others, and is a public draft: https://tools.ietf.org/html/draft-ietf-quic-transport-22
My concern with Google engaging standards bodies is that if Google is the monopoly on all sides, the standards body has little choice but to eventually accept it: Google didn't wait for an IETF standard to implement it in both their monopoly-scale browser and their monopoly-scale services and then declare that a large portion of Internet traffic was now already using QUIC. I am aware there have been some revisions between gQUIC and QUIC as being prepared for standardization, but it seems unlikely the IETF has the ability to say, discourage shifting a huge portion of Internet traffic to a Google-based protocol.
Under these sorts of arrangements, standards bodies have little choice but to rubber stamp the company's interests or face irrelevance. On the HTML/JS side, we often see the same problem with the W3C.
The web's baseline protocols are slowly being replaced by protocols designed to favor the interests of a single company without enough meaningful checks on that. I do not really think it's an IETF/W3C problem though, so much as a economic power one.
On the other hand, a protocol that has been battle-tested and proven to work in the real world makes it much easier for a standards body to accept: there is less risk of making a standard that nobody uses.
The important point is not to make proprietary deviations to the standard. Of course, Google is guilty here (Chrome-only web service, mostly) but when it comes to network protocols they haven't behaved badly, especially when others were pushing for HTTP/2 without TLS and other harmful ideas...
How does the protocol Google chooses to use on its private intranet at all put pressure on the IETF to accept that protocol as a standard?
The chrome argument at least sort of makes sense, but I really don't get how the network transport that literally no one but Google can see threatens IETF irrelevance.
I think you misunderstood what I was saying here. Google's control of both Chrome (client side monopoly) and Search, Gmail, etc. (server side monopoly) together under one entity is what enables Google to define Internet protocols on a broad scale regardless of what a standards body thinks.
I agree with you that how Google servers talk amongst themselves has no relevance in Internet standards.
The IETF has shown it's self less prone to rubber stamping. W3C is a whole other case. Problem is unlike IETF which anyone can chime in on a standard. W3C is members only and most the members are companies. Most these companies use googles web browser so they just kinda go along with it.
The W3C was conceived from the outset for corporations. It even has the word consortium in its name. Personal membership was added much later.
It's actual normal for Standards Organizations to look like this. If anything by their standards the W3C is very liberal. ISO's members are UN member states for example. Want a delegation to ISO to disagree with how an ISO standard works? Create a sovereign entity, seize control over an appreciable amount of the world and force other sovereign entities to accept you as an equal or you can't. The SI units are controlled by Conférence Générale des Poids et Mesures which only has countries as members - some countries don't even get full membership. Don't like the kilogram? Unless you are literally a country too bad.
The IETF is the far outlier, it might even question whether it is indeed a Standards Organization at all. After all it doesn't have any members, (the Internet Society has members but the IETF does not) and so perhaps its "standards" are only "standard" the way English is standard: a bunch of loose conventions, some honoured more consistently than others. Nobody pretends there's a "Standards Organization" for English after all.
> I am aware there have been some revisions between gQUIC and QUIC as being prepared for standardization
I mean... are you though? Because this feels like if somebody told me they are aware there are "some changes" between "Nothing Lasts Forever" and "Die Hard". I mean, yeah, "some" -- like the "hero" cop is actually a hero because Bruce Willis didn't want to play a washed-up alcoholic nutjob whose paranoid fantasies come true... Wait that's a pretty different story isn't it?
Google was welcome to not use IETF protocols before (and sometimes they didn't) and it'll be welcome to not use IETF protocols afterwards (and likely sometimes they won't).
The IETF has no enforcement arm, it exists so that people can agree on things they all want to do. Or, they don't agree on what to do and then they do whatever they want. Lots of people want a better TCP with encryption, enhanced privacy, a way to avoid head-of-line blocking and a fold-away double bed and the QUIC working group has, starting with Google's experiment over two dozen drafts ago, been trying to build one. Some of its participant are from Google (which is great, they have some really smart guys) and of course most are not. You can and should contribute.
I think it might actually succeed to replace TCP. There are a bunch of benefits. There is a great video here about it that you should also watch before passing summary judgement: https://www.youtube.com/watch?v=idViw4anA6E
On the flip side there are no multi path implementation for QUIC while Multi Path TCP is being merged since Linux 5.6[1], just for this I think it's won't be simple as your comment may lead to think.
> Maybe the marketing department needs to hire someone who knows the fundamentals to write the headlines?
What's that quote about throwing stones while living in glass houses?
The headline says nothing about replacing IP. It's talking about replacing "TCP/IP", which is neither "TCP or IP" nor "TCP and IP".
In this case, it's asking whether TCP/IP will be replaced with a protocol (QUIC) that is built on UDP/IP.
IP is definitely still involved.
As with the classic XKCD reference for this situation (https://xkcd.com/927/), I find it very unlikely that it will "replace" TCP/IP in the sense of TCP/IP disappearing altogether, but it certainly stands a chance of replacing TCP/IP in many specific applications that test it and find it beneficial.
TCP/IP is a name for the Internet Protocol Suite[1], which UDP ironically is part of.
If someone talks about one protocol replacing another they should be aware of this distinction, and this title makes me believe the author doesn't know what he is talking about.
That's not the singular definition of TCP/IP, as you're seemingly so intent on believing.
TCP and IP are separable[1], so it logically makes sense to have "TCP/IP" mean that you're using them together, rather than meaning some arbitrary suite of protocols that may have nothing to do with TCP specifically.
Cloudflare, which is obviously a major industry player, defines TCP/IP the same way that the webinar authors and I both normally define it.[2] Cloudflare also (logically) refers to UDP/IP as a concept,[3][4] which further supports the notion that TCP/IP is not singularly referring to the whole internet protocol suite.
I understand that people do sometimes use TCP/IP to refer to the internet protocol suite as a whole, including UDP. I've seen it before. That doesn't make it the only (or most logical) definition of the term. It's certainly not the definition the authors of this webinar intended you to use when reading the title.
In the tech world, many terms are overloaded with multiple definitions. This isn’t an uncommon situation by any means.
> this title makes me believe the author doesn't know what he is talking about
Because the authors are choosing to use a different common definition of TCP/IP, you think they're the ignorant ones because you don't know that common definition? Or because you're only willing to read the title in the way that makes it seem the most nonsensical?
I left my first reply because the author of that comment was being so unnecessarily insulting to the authors, and now you're following up with similar snark, and posting it in multiple places on this topic, when there is no evidence to support that your use of the term is the only valid use of the term.
I don't think your cloudflare link supports your position. CF talks about "The TCP/IP relationship..." - in context they are clearly referring to tcp and ip as two separate nouns, not as a single noun to refer to the internet suite. Context can modify word meaning-using that as an example really doesn't say anything about the term "tcp/ip" in general.
If it was clear, after reading the headline I would not have assumed that QUIC was proposed to replace the internet protocol (IP) for the internet.
The title "QUIC -- Will it replace TCP?" would be accurate and correct and contains everything both necessary and sufficient to describe the article. Adding in unrelated extras, like QUIC replacing IP, conveys additional and incorrect information. It muddies what the article is about.
Calling out unclear and misleading communications is not being pedantic. Clarity is the most fundamental aspect of good and effective communications. The headline writer does not need an apologist, they need to expand their knowledge of the subject they are writing about.
No, TCP/IP is just a name of the suite, there's no such thing as UDP/IP, just because person who wrote the cloudflare glossary invented it doesn't mean it is an accepted term.
Frankly UDP over any other protocol than IP makes very little sense, UDP header literally are just 4 fields:
- source port
- destination port
- length of the datagram
- checksum
that's it, and just ports by themselves are not really useful for anything.
The name TCP/IP comes because TCP and IP protocols were created together and closely coupled. Soon they were separated and other protocols were added (UDP, ICMP, IGMP, ARP and many others), but the name stayed.
The TCP/IP name stands for the protocol suite, and things like UDP/IP were invented by people who didn't understand its meaning.
1. Not everything needs encryption, so QUIC's built-in TLS doesn't always make sense.
2. Not everything that needs encryption needs TLS specifically. TLS is not a one-size-fits-all solution.
These reflect the fact that QUIC is a transport protocol for the WWW more than a TCP replacement.
By the way, does anyone know why QUIC specifically put NewReno as its official congestion control [0]? Different environments benefit from different algorithms so I don't see why.
1) Not everything needs encryption, but crucially, nothing is worse off if it is encrypted. Encryption is either useless or better, so why not put it everywhere by default ?
2) QUIC explicitely doesn't use TLS but something different, so indeed, not everything needs TLS
The thing is, if you run Istio there’s a standard setting for getting it to do the TLS for you. Indeed, half the features of istio wouldn’t work if you did the TLS yourself. So you kind of need plaintext protocols even if you’re only running them internally within a single (logical) machine.
You're right, but it would provide a permanent use for regular old TCP connections (which means the answer to the article's question would still be no).
QUIC nicely abstracts the crypto from the transport protocol so you could easily plug in different crypto implementations. For example, someone already did a QUIC with Noise implementation.
"nothing is worse off if it is encrypted" is a pretty big oversimplification. Layer 7 proxies and firewalls frequently use packet data to make more intelligent decisions about where to route packets, whether to drop packets, whether to modify packets, etc.
I don't see how this refutes the argument. These proxies and firewalls could just have a copy of the decryption key, no? (And if whoever is setting them up doesn't have access to the key, then they probably shouldn't be inspecting the packets anyway)
I'd say that the bigger argument against "nothing is worse off if it is encrypted" is that this takes precious time.
not to mention, that while encryption is cheaper than it was, it still isn't free. And managing certificates and CRLs, while much easier than it used to be is still not trivial, especially on an internal network or localhost.
If everything on the Internet ends up encrypted, I will call you to troubleshoot the problematic SIP calls. ;)
eta: Or at least the ones where one end is a $30 phone someone bought off of Amazon that has no vendor support and the device has no CLI or debug tools available.
This is one of the examples of what not to do from "End-to-End Arguments in System Design" (Saltzer, 1984) [1]:
The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible.
Applications vary in what needs encryption and how that encryption is implemented, so it is better to leave this to them to implement; otherwise, all applications may suffer the cost of your protocol's encryption implementation without getting the actual encryption that they need.
QUIC does use TLS, but since TLS sits on top of TCP and QUIC replaces TCP entirely they wire TLS directly into their protocol rather than it resting on top as it does with TCP.
Technically this was fairly complicated to do, but cryptographically nothing much really changes, except that now more things are encrypted.
Now, if your TLS implementation just presents as a shim layer between a TCP port and your socket code then this may mean a significant rewrite, but again that's not about cryptography it's just an engineering problem.
In many cases you don't want the traffic to be encrypted, so you can audit what's happening. This is common in corporate environments (banks, etc.) It's good to know what e.g. stock traders are talking about so you can monitor for insider trading and market manipulation.
If they use the encrypted Googleprotocol using the Googlebrowser to connect to the Googleweb, you can't do that.
I get that it's important for Google to encrypt what happens between their browser and their servers, but the rest of the world has different requirements.
> By the way, does anyone know why QUIC specifically put NewReno as its official congestion control [0]? Different environments benefit from different algorithms so I don't see why.
It's a "reasonable default", in the sense that it normally works quite well, and is easy to implement. The dangerous thing about congestion control is that it's really easy to get it wrong and not notice (as noticing requires performance testing and monitoring).
Google QUIC uses BBR on the server side. I wrote the initial version of said BBR implementation, and it took a lot of effort to get it to a production-ready state, so I would not generally recommend writing BBR from scratch. CUBIC is much simpler than BBR, but is also prone to subtle bugs like [0].
> 2. Not everything that needs encryption needs TLS specifically. TLS is not a one-size-fits-all solution.
I'm actually curious what use cases you have in mind. TLS definitely does not cover 100% of all possible cases, but I've seen a surprising number of cases where people rolled their own thing when using (D)TLS would have just worked.
You can do TLS with shared keys. The rest of this comment describes the situation in TLS 1.3 since earlier versions are not used in QUIC and future versions don't exist yet.
If you want Forward Secrecy you still need to do the DH steps so that you'll get unique session keys, but you don't need a certificate since your mutual knowledge of the shared key is sufficient.
If you don't need Forward Secrecy (pro tip: You actually do, but I can't stop you) then you can skip DH and just go straight to the main course.
Thanks for the information; your link was an interesting read.
> I'm actually curious what use cases you have in mind.
TLS certs can be a hassle for peer-to-peer type stuff. I'm currently working on a project that does encrypted file transfer between two people and uses a PAKE instead, because I can encode 32 bits of random data in 3 words and that's plenty versus having to deal with public-key infrastructure or dealing with cert files/large blocks of base64. I don't want to run a CA for this and a self-signed cert doesn't verify identity. I certainly don't want to trust some other CA. SSH sort of solves this problem by keeping a known_hosts file with which IP has which key. Unfortunately, that's only good after first contact. People's IPs also change whereas those of servers usually don't. Finally, I share Colin Percival's concerns about the quagmire of backwards compatibility that TLS has become: https://news.ycombinator.com/item?id=16751358
Edit: What's app also moved from TLS to a protocol based on Noise. I believe the rationale was that it's a much cleaner, ground-up implementation rather than being an evolution of something from the '90s. It's analogous to C++: you can do just about anything with it because it has so many features, but they were bolted-on piecemeal. This also means there are a half-dozen ways to do any given thing and even more ways to do something wrong, so there are stylistic inconsistencies on teams beyond "tabs vs. spaces".
TLS is designed to let you replace the provided peer authentication, people have looked at drafts to hook a PAKE into TLS 1.3 in the past but those drafts have expired. There has more recently been interest in trying again. You can even (though it's discouraged) just make the right noises to get appropriate enumerated values reserved for your mechanism, and ship it, without the hassle (valuable as it would be for actual security) of peers offering their opinions and maybe not doing things how you prefer.
I don't see how certificates are relevant at all? You clearly don't want a certificate if you intend a PAKE to provide mutual assurance of identity.
I think Colin grossly overestimates the chances of some bozo getting an RSA (of all things) transport protocol to work securely. My guess is that most attempts will end without it working at all (frustrating but safe) but a potentially very scary number would work in the sense that they seem to function as intended while not delivering the expected security through a combination of ignorance and inadequate testing. I particularly don't buy that a bozo who actually does get all that right can't instead write code against OpenSSL without ripping a hole in the universe. I don't like OpenSSL, but even I can see that it gets enough hard things right to be a useful contribution.
There is already an older PAKE in TLS, TLS-SRP. It doesn't apear to be well-loved [0] and I don't know enough about the IP situation to use it confidently, so I've been looking through the CFRG reviews on PAKE candidates [1] to get more info.
I mentioned certs because they're a pain to manage and are generally how people do TLS, though there are a few PSK options [2].
Your right that implementing a secure RSA protocol by one's self is difficult. That's the idea of things like Noise, to make messing up your own protocol implementation harder (albeit not impossible). The other option is building on something like libsodium that has a good, well-documented API and is hard(er) to screw up.
TLS certainly works for a lot of things, it just doesn't work for everything. For that reason, something that bakes it in probably won't replace TCP.
You can't use the stuff you linked with TLS 1.3, and of course you can't use an older TLS version in QUIC. It's possible you knew those things, but I want to make sure.
My recent experience with the password manager that was linked on HN shows me that even an abuse-resistant API like Sodium cannot stop people being idiots. (The author believs some random passwords aren't "unique enough" so they have written a bunch of code on top of Sodium to avoid passwords like '4K2m_chmJ$gD' which they feel wouldn't be suitable because it has the letter 'm' more than once...)
I hadn't checked compatibility and wasn't aware they no longer included SRP. It's not the best PAKE, but to my knowledge, not cryptographically broken (Apple uses it for a bunch of stuff, IIRC). Thanks for letting me know.
And you're right, that's pretty dopey with the password manager. I understand the point of password security measures, but just do something like pam cracklib. There's no such thing as an idiot-proof library. Honestly, that looks like the developer was being kind of lazy, using a constant size for things like max password length.
My only point here is that there are libraries that are well-tested, secure, and at least as idiot-proof as openssl. The increased ability to do the protocol wrong with something like libsodium is balanced by the increased ability to do the crypto wrong with something like openssl.
They didn't explicitly deprecate TLS-SRP, it simply can't work in TLS 1.3 because although it superficially looks like a minor revision, and indeed (to defeat middlebox ossification) on the wire it appears to say it is only TLS 1.2 in reality it's a fairly radical change.
TLS-SRP bolts over the traditional TLS key exchange mechanism, which made sense, but in TLS 1.3 that entire mechanism is gone, keys are either pre-shared or they're always agreed in the first protocol burst using an (elliptic curve) Diffie Hellman method. So by the time you'd have a natural opportunity to do SRP the protocol has already agreed keys anyway.
> TLS certs can be a hassle for peer-to-peer type stuff.
From my perspective that's very generous. All the flags and extensions in x509 certs seem to have one use: provide a way for the companies who run the PKI infrastructure to extract more money. I am perhaps to being a little harsh here, as some like the ability to sign sub-certs are absolutely necessary to PKI.
However, outside of PKI, almost none of it adds any security. But they do add enormous amounts of complexity. To take but one example from StrongSwan:
> In addition to serverAuth the 'IP Security IKE Intermediate' EKU with OID 1.3.6.1.5.5.8.2.2 does not hurt either and will allow you to use the certificate with older Mac OS X releases too.
How much does 1.3.6.1.5.5.8.2.2 or indeed any of the extensions add to IPSec security: none. Yet woe betide you if you miss it and someone attempt to use your IPSec implementation from an older OSx. But if you try to work around that by providing every extension under the sun, Windows will reject it. So you end up walking this tightrope of trying to find the magic combination that works with everything.
The option to use TLS without the x509 baggage would be a breath of fresh air.
Which is pretty much the entire point of QUIC, since updating gazillions of network appliances to support newer versions of TCP is rather hard and will take decades, if not longer. With QUIC, that's no longer needed.
After all the equipment investment and adding support to all the software, people are going to say "just forget it" and go back to v4-only and piling CGNAT style hacks on top of each other in an endless tower of babel? Possible, but would be quite a dystopia.
IPv6 transition mechanisms were designed for a long coexistence of both v4 & v6, not that different from QUIC vs HTTP :)
They're specifically doing QUIC as a way to move TCP to up into the application space so they can iterate more quickly. Ideally, a lot of these concepts could be adopted into TCP stacks eventually.
Historically, some of the big problems of running UDP-based services over the internet are related to source spoofing, used in reflection/amplification attacks etc (looking at you, DNS/NTP), which is possible as very few providers carry out source address validation on egress.
142 comments
[ 0.27 ms ] story [ 236 ms ] threadAlso, most firewall don't break TCP, they break HTTP(S) because they want levels of control.
And it's because they want levels of control on the least affordable place. They wouldn't need to break anything if they added the supervising software to the endpoints.
Now, I get that QUIC's developers live in a zero-trust/BeyondCorp model, and expect everyone else to too, and with COVID-19, a lot of businesses are suddenly having to look at thinking that way, it's far from how most companies work at present. And having a single box handle filtering and monitoring is actually the most affordable place to put it. ;)
The endpoints afford monitoring. The middle of the network does not afford it, so you are fighting the system and it is certain that you will break stuff.
Middleboxes are the system, and protocols that deliberately try to block inspection are fighting it and trying to break stuff.
See also RFC 7258 (https://tools.ietf.org/html/rfc7258), "Pervasive Monitoring is an Attack". Protocols that enable interception are broken and will be replaced with protocols that do not.
And they're not. Google, Amazon, Microsoft, etc. have failed to keep the Internet safe. And when they fail they hide behind liability shields like Section 230. So it falls on IT staff, more often than not, to filter, block, and intercept where Big Tech has demonstrated inability to do so.
People trying to make protocols more secure don't need to convince you, they just need to make your job as hard as possible until most users reject what you're offering.
We need a dozen more ideas like Certificate Transparency. We need pervasive end-to-end DNS security, with unencrypted DNS flagged as insecure. We need a means of preventing DNS servers from altering the DNS records of sites they aren't authoritative for. We need browsers to all agree to explicitly flag connections as insecure when they chain to a locally installed certificate, in a way that can't be hidden without rebuilding from source.
And this isn't a purely technical problem, either. We also need legal support to review regulations in certain regulated industries and demonstrate well-supported ways to fulfill those regulations without breaking security (e.g. "if you do XYZ to log the time and endpoints of connections but don't actually MITM their traffic, it's reasonably well-established that you're fulfilling ABC regulation"). We need lobbyists to change regulations incompatible with secure protocols. We need designers to make security as usable as possible, because poor usability is a security problem.
(This is assuming they aren't using pinned certs baked into their firmware, anyhow. I don't have good data on which manufacturers/devices are doing this, but somebody else might know.)
If you want to run those devices in production, put them in a separate network or VLAN where they can't see anything they don't need to see.
As it is, don't Chromecasts refuse to function if they can't reach 8.8.8.8? Add encrypted DNS to prevent inspection and transparency, and people are being asked to have potentially hostile devices in their network with no way to inspect them.
(And the PKI infrastructure is the best thing we have; I'd certainly like to see it replaced with something even better.)
So creating a system where I, as a consumer, have no way to inspect the communication my devices undertake removes my rights and safety in deference to companies that really just want to make it harder to block ads.
I take issue with this entire model. The fact that PKI has had piles of issues with bad actors who are supposedly supposed to be bastions of trust doesn't give any example this is a system we should trust, much less have browsers force people to utilize and scare people off avoiding.
Yet we have one because it's required by law. Wanna take a guess at what companies make sure it stays required by law?
The laws (in the US, at least) are typically written such that some part of the administration is deputized to promulgate technical standards and rules, most of which delegate to the NIST, but sometimes to industry bodies. Laws like this include HIPAA, FERPA, FISMA, and GLB.
There are lots of industry standards you can reference (such as the Cloud Security Alliance Common Controls Matrix), but the government will generally look at things from the perspective of NIST publications, such as NIST 800-171, "Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations". So, basically, what the government thinks private enterprise should be doing to comply with legal requirements to protect sensitive information.
In that document, there are a number of "controls" an organization should have in place, in particular, it should audit any and all data transfers, and ensure such transfers can be traced back to a unique user.
Even within that framework, you aren't going to necessarily find a blanket "read everyone's mail!" edict. Instead, what you are going to do, is make an assessment, as an organization, about what you think you need to do in order to withstand any potential lawsuits that may arise from any kind of disclosure.
If we made software engineers individually liable for these things the way civil and mechanical engineers are, things would look very different.
[Ed: misspelled FERPA]
Many people here seem to not realize that TCP is used for much more then just http/https.
Quick might be nice for web traffic, but i see little reason to use it as an underlay for BGP for instance.
In terms of BGP and quic as a transport.
As far as i know, quic is not backwards compatible with TCP, and having two different transport protocols for the routing protocols that ties the internet together would be problematic in terms of migration.
Im not entirely up to speed in terms of how quick would handle MSS size, but this could pose a problem in some situations.
Theoretically? Depends on the transport and it's characteristics. There could be a theoretical gain to using something else.
Firewalls that dig deep into tcp packets sound like troublesome middleware with which good actors are in an arms, not something to go out of the way to support.
I'll have to look into potential MSS issues.
The main difference from an API pointer of view is that there is an additional multiplexing layer. On TCP/IP the byte stream is directly on the connection. On QUIC a connection can contain multiple streams - which are openable by both sides. And each of those streams is a bidirectional or unidirectional byte streams.
QUIC doesn't care what protocol you run on top of those streams. HTTP/3 is just the only one which is specified at the moment.
Most video games already use UDP
For the hobbyist world, this option as a low level transport is not so bad imo. Like as a replacement for ENet which does not have IPv6 support today seems reasonable.
We're having difficulty getting IPv6 up and going, and that's 100% supported by everyone.
QUIC deployed worldwide might cost us a power station or two...
Intel has already filed (in 2019) for a European patent that seems to claim inventorship of the generic concept of hardware offloading (as it applies to QUIC)
https://data.epo.org/publication-server/pdf-document?pn=3541...
Hardware offload of a network protocol is an extremely generic concept and this patent seems to describe that concept (without any kind of novel mechanism or implementation details).
- sendfile
- ktls
- TSO
Its like stepping into a time machine and going back to the mid 90s. To send data with QUIC, we have to get byes from kernel into userspace, encrypt them in userspace, and then write them back to the kernel, where they travel down to the NIC an MTU at a time. Ugh.
- Cloudflare
- Facebook: They already use QUIC for some of their products, or at least it's a pretty sensitive piece of software on their architecture because they ask to report bugs to the bug bounty program[1]
- Microsoft
- Nginx
- Google
- NetApp
- Mozilla
- Traffic Server
- Litespeed
- Fastly
- F5
- Apple
Amazon is very quiet about all that, but they are probably looking into it. So, it is pretty backed up. If you take a look at their workgroup homepage (quicwg.org) you will see a couple of open source implementations, some from those same companies.
[1]: https://github.com/facebookincubator/mvfst/blob/master/READM...
No.
This as been another episode of "simple answers to stupid questions".
TCP/IP refers to the entire stack that Internet is build on, the UDP is actually part of TCP/IP (it was added later for use cases where low latency was important, like telephony). He probably meant just TCP, but that's still "no".
My guess is that just saying "IP" is too short.
(And ambiguous - tee hee)
Quite probably!
I see two main ways to look at this question: will QUIC replace TCP as a go to protocol for developing atop of? The other interpretation is, will QUIC replace all TCP ever written? No, indeed, likely not.
Under these sorts of arrangements, standards bodies have little choice but to rubber stamp the company's interests or face irrelevance. On the HTML/JS side, we often see the same problem with the W3C.
The web's baseline protocols are slowly being replaced by protocols designed to favor the interests of a single company without enough meaningful checks on that. I do not really think it's an IETF/W3C problem though, so much as a economic power one.
The important point is not to make proprietary deviations to the standard. Of course, Google is guilty here (Chrome-only web service, mostly) but when it comes to network protocols they haven't behaved badly, especially when others were pushing for HTTP/2 without TLS and other harmful ideas...
The chrome argument at least sort of makes sense, but I really don't get how the network transport that literally no one but Google can see threatens IETF irrelevance.
I agree with you that how Google servers talk amongst themselves has no relevance in Internet standards.
It's actual normal for Standards Organizations to look like this. If anything by their standards the W3C is very liberal. ISO's members are UN member states for example. Want a delegation to ISO to disagree with how an ISO standard works? Create a sovereign entity, seize control over an appreciable amount of the world and force other sovereign entities to accept you as an equal or you can't. The SI units are controlled by Conférence Générale des Poids et Mesures which only has countries as members - some countries don't even get full membership. Don't like the kilogram? Unless you are literally a country too bad.
The IETF is the far outlier, it might even question whether it is indeed a Standards Organization at all. After all it doesn't have any members, (the Internet Society has members but the IETF does not) and so perhaps its "standards" are only "standard" the way English is standard: a bunch of loose conventions, some honoured more consistently than others. Nobody pretends there's a "Standards Organization" for English after all.
I mean... are you though? Because this feels like if somebody told me they are aware there are "some changes" between "Nothing Lasts Forever" and "Die Hard". I mean, yeah, "some" -- like the "hero" cop is actually a hero because Bruce Willis didn't want to play a washed-up alcoholic nutjob whose paranoid fantasies come true... Wait that's a pretty different story isn't it?
Google was welcome to not use IETF protocols before (and sometimes they didn't) and it'll be welcome to not use IETF protocols afterwards (and likely sometimes they won't).
The IETF has no enforcement arm, it exists so that people can agree on things they all want to do. Or, they don't agree on what to do and then they do whatever they want. Lots of people want a better TCP with encryption, enhanced privacy, a way to avoid head-of-line blocking and a fold-away double bed and the QUIC working group has, starting with Google's experiment over two dozen drafts ago, been trying to build one. Some of its participant are from Google (which is great, they have some really smart guys) and of course most are not. You can and should contribute.
No, it won't replace TCP/IP
[1]: https://www.phoronix.com/scan.php?page=news_item&px=Linux-5....
Maybe the marketing department needs to hire someone who knows the fundamentals to write the headlines?
What's that quote about throwing stones while living in glass houses?
The headline says nothing about replacing IP. It's talking about replacing "TCP/IP", which is neither "TCP or IP" nor "TCP and IP".
In this case, it's asking whether TCP/IP will be replaced with a protocol (QUIC) that is built on UDP/IP.
IP is definitely still involved.
As with the classic XKCD reference for this situation (https://xkcd.com/927/), I find it very unlikely that it will "replace" TCP/IP in the sense of TCP/IP disappearing altogether, but it certainly stands a chance of replacing TCP/IP in many specific applications that test it and find it beneficial.
TCP/IP is a name for the Internet Protocol Suite[1], which UDP ironically is part of.
If someone talks about one protocol replacing another they should be aware of this distinction, and this title makes me believe the author doesn't know what he is talking about.
[1] https://en.wikipedia.org/wiki/Internet_protocol_suite
TCP and IP are separable[1], so it logically makes sense to have "TCP/IP" mean that you're using them together, rather than meaning some arbitrary suite of protocols that may have nothing to do with TCP specifically.
Cloudflare, which is obviously a major industry player, defines TCP/IP the same way that the webinar authors and I both normally define it.[2] Cloudflare also (logically) refers to UDP/IP as a concept,[3][4] which further supports the notion that TCP/IP is not singularly referring to the whole internet protocol suite.
I understand that people do sometimes use TCP/IP to refer to the internet protocol suite as a whole, including UDP. I've seen it before. That doesn't make it the only (or most logical) definition of the term. It's certainly not the definition the authors of this webinar intended you to use when reading the title.
In the tech world, many terms are overloaded with multiple definitions. This isn’t an uncommon situation by any means.
> this title makes me believe the author doesn't know what he is talking about
Because the authors are choosing to use a different common definition of TCP/IP, you think they're the ignorant ones because you don't know that common definition? Or because you're only willing to read the title in the way that makes it seem the most nonsensical?
I left my first reply because the author of that comment was being so unnecessarily insulting to the authors, and now you're following up with similar snark, and posting it in multiple places on this topic, when there is no evidence to support that your use of the term is the only valid use of the term.
[1]: https://superuser.com/questions/449703/must-tcp-use-ip
[2]: https://www.cloudflare.com/learning/ddos/glossary/tcp-ip/
[3]: https://www.cloudflare.com/learning/ddos/glossary/user-datag...
[4]: https://www.cloudflare.com/learning/ddos/glossary/internet-p...
Fwiw Wikipedia also thinks tcp/ip means the protocol suite https://en.wikipedia.org/wiki/Internet_protocol_suite (edit: i guess other person already said that, i didnt notice)
Edit2: otoh, i think this whole argument is pedantic and its clear what the original article meant.
The title "QUIC -- Will it replace TCP?" would be accurate and correct and contains everything both necessary and sufficient to describe the article. Adding in unrelated extras, like QUIC replacing IP, conveys additional and incorrect information. It muddies what the article is about.
Calling out unclear and misleading communications is not being pedantic. Clarity is the most fundamental aspect of good and effective communications. The headline writer does not need an apologist, they need to expand their knowledge of the subject they are writing about.
Frankly UDP over any other protocol than IP makes very little sense, UDP header literally are just 4 fields:
that's it, and just ports by themselves are not really useful for anything.The name TCP/IP comes because TCP and IP protocols were created together and closely coupled. Soon they were separated and other protocols were added (UDP, ICMP, IGMP, ARP and many others), but the name stayed.
The TCP/IP name stands for the protocol suite, and things like UDP/IP were invented by people who didn't understand its meaning.
Here are definitions from ICANN: https://icannwiki.org/TCP/IP
Many other authoritative places:
Bunch of RFCs (this one is from 90s): https://tools.ietf.org/html/rfc1180
https://computerhistory.org/profile/vint-cerf/
This term was used essentially from the beginning of the Internet: http://www.columbia.edu/~rh120/other/tcpdigest_paper.txt
1. Not everything needs encryption, so QUIC's built-in TLS doesn't always make sense.
2. Not everything that needs encryption needs TLS specifically. TLS is not a one-size-fits-all solution.
These reflect the fact that QUIC is a transport protocol for the WWW more than a TCP replacement.
By the way, does anyone know why QUIC specifically put NewReno as its official congestion control [0]? Different environments benefit from different algorithms so I don't see why.
[0]: https://tools.ietf.org/html/draft-ietf-quic-recovery-12#sect...
2) QUIC explicitely doesn't use TLS but something different, so indeed, not everything needs TLS
Performance and power consumption of low-end devices.
I'd say that the bigger argument against "nothing is worse off if it is encrypted" is that this takes precious time.
eta: Or at least the ones where one end is a $30 phone someone bought off of Amazon that has no vendor support and the device has no CLI or debug tools available.
The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible.
Applications vary in what needs encryption and how that encryption is implemented, so it is better to leave this to them to implement; otherwise, all applications may suffer the cost of your protocol's encryption implementation without getting the actual encryption that they need.
[1] http://pages.cs.wisc.edu/~bart/739/papers/end-to-end.pdf
Technically this was fairly complicated to do, but cryptographically nothing much really changes, except that now more things are encrypted.
Now, if your TLS implementation just presents as a shim layer between a TCP port and your socket code then this may mean a significant rewrite, but again that's not about cryptography it's just an engineering problem.
If they use the encrypted Googleprotocol using the Googlebrowser to connect to the Googleweb, you can't do that.
I get that it's important for Google to encrypt what happens between their browser and their servers, but the rest of the world has different requirements.
What is using TCP that wouldn't work with QUIC?
It's a "reasonable default", in the sense that it normally works quite well, and is easy to implement. The dangerous thing about congestion control is that it's really easy to get it wrong and not notice (as noticing requires performance testing and monitoring).
Google QUIC uses BBR on the server side. I wrote the initial version of said BBR implementation, and it took a lot of effort to get it to a production-ready state, so I would not generally recommend writing BBR from scratch. CUBIC is much simpler than BBR, but is also prone to subtle bugs like [0].
> 2. Not everything that needs encryption needs TLS specifically. TLS is not a one-size-fits-all solution.
I'm actually curious what use cases you have in mind. TLS definitely does not cover 100% of all possible cases, but I've seen a surprising number of cases where people rolled their own thing when using (D)TLS would have just worked.
[0] http://bitsup.blogspot.com/2015/09/thanks-google-tcp-team-fo...
If you want Forward Secrecy you still need to do the DH steps so that you'll get unique session keys, but you don't need a certificate since your mutual knowledge of the shared key is sufficient.
If you don't need Forward Secrecy (pro tip: You actually do, but I can't stop you) then you can skip DH and just go straight to the main course.
How would you do that? The API's I've seen for TLS all require the use of certificates.
> I'm actually curious what use cases you have in mind.
TLS certs can be a hassle for peer-to-peer type stuff. I'm currently working on a project that does encrypted file transfer between two people and uses a PAKE instead, because I can encode 32 bits of random data in 3 words and that's plenty versus having to deal with public-key infrastructure or dealing with cert files/large blocks of base64. I don't want to run a CA for this and a self-signed cert doesn't verify identity. I certainly don't want to trust some other CA. SSH sort of solves this problem by keeping a known_hosts file with which IP has which key. Unfortunately, that's only good after first contact. People's IPs also change whereas those of servers usually don't. Finally, I share Colin Percival's concerns about the quagmire of backwards compatibility that TLS has become: https://news.ycombinator.com/item?id=16751358
Edit: What's app also moved from TLS to a protocol based on Noise. I believe the rationale was that it's a much cleaner, ground-up implementation rather than being an evolution of something from the '90s. It's analogous to C++: you can do just about anything with it because it has so many features, but they were bolted-on piecemeal. This also means there are a half-dozen ways to do any given thing and even more ways to do something wrong, so there are stylistic inconsistencies on teams beyond "tabs vs. spaces".
I don't see how certificates are relevant at all? You clearly don't want a certificate if you intend a PAKE to provide mutual assurance of identity.
I think Colin grossly overestimates the chances of some bozo getting an RSA (of all things) transport protocol to work securely. My guess is that most attempts will end without it working at all (frustrating but safe) but a potentially very scary number would work in the sense that they seem to function as intended while not delivering the expected security through a combination of ignorance and inadequate testing. I particularly don't buy that a bozo who actually does get all that right can't instead write code against OpenSSL without ripping a hole in the universe. I don't like OpenSSL, but even I can see that it gets enough hard things right to be a useful contribution.
I mentioned certs because they're a pain to manage and are generally how people do TLS, though there are a few PSK options [2].
Your right that implementing a secure RSA protocol by one's self is difficult. That's the idea of things like Noise, to make messing up your own protocol implementation harder (albeit not impossible). The other option is building on something like libsodium that has a good, well-documented API and is hard(er) to screw up.
TLS certainly works for a lot of things, it just doesn't work for everything. For that reason, something that bakes it in probably won't replace TCP.
[0]: https://blog.cryptographyengineering.com/should-you-use-srp/
[1]: https://github.com/cfrg/pake-selection
[2]: https://tools.ietf.org/html/rfc4279
My recent experience with the password manager that was linked on HN shows me that even an abuse-resistant API like Sodium cannot stop people being idiots. (The author believs some random passwords aren't "unique enough" so they have written a bunch of code on top of Sodium to avoid passwords like '4K2m_chmJ$gD' which they feel wouldn't be suitable because it has the letter 'm' more than once...)
And you're right, that's pretty dopey with the password manager. I understand the point of password security measures, but just do something like pam cracklib. There's no such thing as an idiot-proof library. Honestly, that looks like the developer was being kind of lazy, using a constant size for things like max password length.
My only point here is that there are libraries that are well-tested, secure, and at least as idiot-proof as openssl. The increased ability to do the protocol wrong with something like libsodium is balanced by the increased ability to do the crypto wrong with something like openssl.
TLS-SRP bolts over the traditional TLS key exchange mechanism, which made sense, but in TLS 1.3 that entire mechanism is gone, keys are either pre-shared or they're always agreed in the first protocol burst using an (elliptic curve) Diffie Hellman method. So by the time you'd have a natural opportunity to do SRP the protocol has already agreed keys anyway.
From my perspective that's very generous. All the flags and extensions in x509 certs seem to have one use: provide a way for the companies who run the PKI infrastructure to extract more money. I am perhaps to being a little harsh here, as some like the ability to sign sub-certs are absolutely necessary to PKI.
However, outside of PKI, almost none of it adds any security. But they do add enormous amounts of complexity. To take but one example from StrongSwan:
> In addition to serverAuth the 'IP Security IKE Intermediate' EKU with OID 1.3.6.1.5.5.8.2.2 does not hurt either and will allow you to use the certificate with older Mac OS X releases too.
How much does 1.3.6.1.5.5.8.2.2 or indeed any of the extensions add to IPSec security: none. Yet woe betide you if you miss it and someone attempt to use your IPSec implementation from an older OSx. But if you try to work around that by providing every extension under the sun, Windows will reject it. So you end up walking this tightrope of trying to find the magic combination that works with everything.
The option to use TLS without the x509 baggage would be a breath of fresh air.
IPv6 transition mechanisms were designed for a long coexistence of both v4 & v6, not that different from QUIC vs HTTP :)
But even if it does, the replacement won't be QUIC.
Will it replace HTTPS over TCP? Maybe. Mostly. Eventually. (Hopefully?)
Will it replace TCP for other purposes? Of course not.
However, I don't see it replacing TCP, and if anything it's just an other tool to use.
Looks like QUIC has a nice solution to this, making the impact of source spoofing similar to that of TCP, give or take a few CPU cycles: https://jacobianengineering.com/blog/2016/11/1543/