5 ms·

> By the way, does anyone know why QUIC specifically put NewReno as its official congestion control [0]? Different environments benefit from different algorithm

> 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-for-open-source.html http://bitsup.blogspot.com/2015/09/thanks-google-tcp-team-fo...

thayne 6y ago
If you are in a situation where you can have a shared key, TLS, with it's asymmetric handshake is probably overkill.
- tialaramex 6y ago
  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.
  - thayne 6y ago
    > 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.
mmm_grayons 6y ago
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 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".
- tialaramex 6y ago
  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.

thayne 6y ago

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

tialaramex 6y ago
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.
- thayne 6y ago
  > 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.

mmm_grayons 6y ago

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

tialaramex 6y ago
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.