> 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.

[0] http://bitsup.blogspot.com/2015/09/thanks-google-tcp-team-fo...

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 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.

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.

[0]: https://blog.cryptographyengineering.com/should-you-use-srp/

[1]: https://github.com/cfrg/pake-selection

[2]: https://tools.ietf.org/html/rfc4279

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.

If you are in a situation where you can have a shared key, TLS, with it's asymmetric handshake is probably overkill.

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.

> you don't need a certificate since your mutual knowledge of the shared key is sufficient

How would you do that? The API's I've seen for TLS all require the use of certificates.

The spec still says NewReno, but I believe Google are mainly using BBR, if not BBR v2.

Other than captive portals, what would be harmed by adding encryption. It might not provide benefit but is there any downside?

What is using TCP that wouldn't work with QUIC?

QUIC is itself layered post Google, so 1 and 2 don't apply.

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

"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.

These are the same agents that prevented SCTP from being usable outside of private networks. We need to stop catering for them.

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.

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.

> nothing is worse off if it is encrypted

Performance and power consumption of low-end devices.

And particularly embedded devices. Just because we can make very fast cpu's nowadays doesn't mean that every cpu is that fast.

Yup I work with a lot of industrial IoT companies. QUIC will not replace TCP/IP there any time soon.

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.

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.

Please sign me up for this future where every phone has to support end-to-end encryption in order to connect to the network :)

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.

[1] http://pages.cs.wisc.edu/~bart/739/papers/end-to-end.pdf

I like how tcp/ip operates below the encryption layer so encryption schemes can be easily changed.

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.

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.

Istio would not only do TLS, but would also do QUIC for you in the scenario you describe.

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).

Good point!

Why not ? Because it require a lot of CPU power... A lot.