111–120 of 142 posts
Nah, I think it won't. 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]? Diffe…
Nah, I think it won't. 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]? Diffe…
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
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.
Earlier quoted context omitted.
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 be…
Earlier quoted context omitted.
> 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…
If you are in a situation where you can have a shared key, TLS, with it's asymmetric handshake is probably overkill.
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.
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
[1]: https://www.phoronix.com/scan.php?page=news_item&px=Linux-5....
Earlier quoted context omitted.
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 migh…
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.
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.
Earlier quoted context omitted.
> 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…
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 deal…
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.
Earlier quoted context omitted.
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…
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.
- 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
- 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...
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/
Earlier quoted context omitted.
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 deal…
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 act…
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/