6 ms·

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

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]? Different environments benefit from different algorithms so I don't see why. [0]: https://tools.ietf.org/html/draft-ietf-quic-recovery-12#section-4 https://tools.ietf.org/html/draft-ietf-quic-recovery-12#sect...

rakoo 7y ago
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
- dragontamer 7y ago
  > nothing is worse off if it is encrypted Performance and power consumption of low-end devices.
  - Wowfunhappy 7y ago
    And particularly embedded devices. Just because we can make very fast cpu's nowadays doesn't mean that every cpu is that fast.
    - stingraycharles 7y ago
      Yup I work with a lot of industrial IoT companies. QUIC will not replace TCP/IP there any time soon.
- moomin 7y ago
  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.
  - jupp0r 7y ago
    Istio would not only do TLS, but would also do QUIC for you in the scenario you describe.
    - moomin 7y ago
      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).
      - jupp0r 7y ago
        Good point!
- nickthemagicman 7y ago
  I like how tcp/ip operates below the encryption layer so encryption schemes can be easily changed.
  - dochtman 7y ago
    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.
- deleted 7y ago
  [deleted]
- pawalt 7y ago
  "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.
  - falcor84 7y ago
    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.
  - thayne 7y ago
    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.
  - kevin_thibedeau 7y ago
    These are the same agents that prevented SCTP from being usable outside of private networks. We need to stop catering for them.
- Kuinox 7y ago
  Why not ? Because it require a lot of CPU power... A lot.
- hackmiester 7y ago
  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.
  - falcor84 7y ago
    Please sign me up for this future where every phone has to support end-to-end encryption in order to connect to the network :)
- bobbiechen 7y ago
  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 http://pages.cs.wisc.edu/~bart/739/papers/end-to-end.pdf
- tialaramex 7y ago
  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.
- pnako 7y ago
  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.
fart_ratty 7y ago
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?
ajrw 7y ago
The spec still says NewReno, but I believe Google are mainly using BBR, if not BBR v2.
vasilvv 7y ago
> 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 7y ago
  If you are in a situation where you can have a shared key, TLS, with it's asymmetric handshake is probably overkill.
  - tialaramex 7y 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 7y 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.
Ericson2314 7y ago
QUIC is itself layered post Google, so 1 and 2 don't apply.

rakoo 7y ago

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

dragontamer 7y ago
> nothing is worse off if it is encrypted Performance and power consumption of low-end devices.
- Wowfunhappy 7y ago
  And particularly embedded devices. Just because we can make very fast cpu's nowadays doesn't mean that every cpu is that fast.
  - stingraycharles 7y ago
    Yup I work with a lot of industrial IoT companies. QUIC will not replace TCP/IP there any time soon.
moomin 7y ago
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.
- jupp0r 7y ago
  Istio would not only do TLS, but would also do QUIC for you in the scenario you describe.
  - moomin 7y ago
    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).
    - jupp0r 7y ago
      Good point!
nickthemagicman 7y ago
I like how tcp/ip operates below the encryption layer so encryption schemes can be easily changed.
- dochtman 7y ago
  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.
deleted 7y ago
[deleted]
pawalt 7y ago
"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.
- falcor84 7y ago
  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.
- thayne 7y ago
  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.
- kevin_thibedeau 7y ago
  These are the same agents that prevented SCTP from being usable outside of private networks. We need to stop catering for them.
Kuinox 7y ago
Why not ? Because it require a lot of CPU power... A lot.
hackmiester 7y ago
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.
- falcor84 7y ago
  Please sign me up for this future where every phone has to support end-to-end encryption in order to connect to the network :)
bobbiechen 7y ago
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 http://pages.cs.wisc.edu/~bart/739/papers/end-to-end.pdf
tialaramex 7y ago
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.
pnako 7y ago
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.

fart_ratty 7y ago

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?

ajrw 7y ago

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

vasilvv 7y ago

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

Ericson2314 7y ago

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