5 ms·

The purpose of Wireguard is to be simple. The purpose of QUIC is to be compatible with legacy web junk. You don't use the second one unless you need the second

The purpose of Wireguard is to be simple. The purpose of QUIC is to be compatible with legacy web junk. You don't use the second one unless you need the second one.

geoctl 1y ago
QUIC isn't really about the web, it's more of a TCP+TLS replacement on top of UDP. You can build your own custom L7 on top of QUIC.
- bb88 1y ago
  You can build a custom L7 on top of anything, really. I think my favorite was tcp/ip over printers and webcams. The question is what does QUIC get you that UDP alone does not? I don't know the answer to that. Is it because firewalls understand it better than native wireguard over UDP packets?
  - remexre 1y ago
    Encryption and reliable transport.
    - zamadatix 1y ago
      You really don't want reliable transport as a feature of the tunnel unless you are _intimately_ familiar with what all of the tunneled traffic is already doing for reliable transport. The net result of two reliable transports which are unaware of each other is awful.
    - bb88 1y ago
      I probably should have clarified that question. What does QUIC get you that TCP over Wireguard over UDP does not?
  - zamadatix 1y ago
    Mostly because WireGuard (intentionally) didn't bother with obfuscation https://www.wireguard.com/known-limitations/ https://www.wireguard.com/known-limitations/ > WireGuard does not focus on obfuscation. Obfuscation, rather, should happen at a layer above WireGuard, with WireGuard focused on providing solid crypto with a simple implementation. It is quite possible to plug in various forms of obfuscation, however. This comment https://news.ycombinator.com/item?id=45562302 https://news.ycombinator.com/item?id=45562302 goes into a practical example of QUIC being that "layer above WireGuard" which gets plugged in. Once you have that, one may naturally wonder "why not also have an alternative tunnelling protocol with <the additional things built into QUIC originally listed> without the need to also layer Wireguard under it?". Many design decisions are in direct opposition to Wireguard's design. E.g. Wireguard (intentionally) has no AES and no user selectable ciphers (both intentionally), QUIC does. Wireguard has no obfuscation built in, QUIC does (+ the happy fact when you obfuscate traffic by using it then it looks like standard web traffic). Wireguard doesn't support custom authentication schemes, QUIC does. Both are a reasonable tunneling protocol design, just with different goals.
    - bb88 1y ago
      I think maybe it's easier for an adversarial network admin to block QUIC altogether.
      - zamadatix 1y ago
        The hope with QUIC is encrypted tunnels that look and smell like standard web traffic are probably first in the list of any allowed traffic tunneling methods. It works (surprisingly) a lot more often than hoping an adversarial network/security admin doesn't block known VPN protocols (even when they are put on 443). It also doesn't hurt that "normal" users (unknowingly) try to generate this traffic, so opening a QUIC connection on 443 and getting a failure makes you look like "every other user with a browser" instead of "an interesting note in the log". I.e. the advantage here is any% + QUIC%, where QUIC% is the additional chances of getting through by looking and smelling like actual web traffic, not a promise of 100%.
        1y ago
- nine_k 1y ago
  Where is DNS on top of QUIC? Asking unironically.
  - jiveturkey 1y ago
    That's DoQ, RFC 9250.
  - geoctl 1y ago
    There is actually. A way more interesting re-implementation of a popular L7 is SSH over QUIC. SSH has to implement its own mutual authentication and transport embedded in the protocol implementation since it operates on top of plaintext TCP, but with QUIC you can just offload the authentication (e.g. JWT bearer tokens issued by IdPs verified at L7 or automatically via mTLS x509 certs) and transport parts to QUIC and therefore have a much more minimal implementation.
    - frumplestlatz 1y ago
      “Offloading” authentication onto complex web tech isn’t really a feature unless you already need to be operating in the web space for some other reason.
    - sigwinch 1y ago
      I feel like fans of `mosh` would run with this.
  - maxloh 1y ago
    It is already there. It is called DNS over HTTP/3 (DoH3).
- AnthonyMouse 1y ago
  QUIC uses Web PKI and TLS. TLS is not a simple protocol and the main reason to use it over something simpler is if you need it to be compatible with something else that already uses it, like HTTPS.
  - johncolanduoni 1y ago
    The main reason to use TLS is that you can get a bunch of off-the-shelf implementations that are (post-Heartbleed) the most heavily scrutinized public cryptographic implementations in existence. Plus if anyone finds a practical exploit of TLS (or a major implementation), they’re more likely to go steal credit card numbers being typed into Amazon than to attack your particular use of it. Noise is cool but if you don’t need the same flexibility that Wireguard does (or have the expertise to implement a concrete protocol on top of it correctly), something built on TLS 1.3 is a better bet.
    - AnthonyMouse 1y ago
      I'm not even convinced that a random TLS library would get non-trivially more scrutiny than Wireguard does, and on top of that it would need more scrutiny because it's significantly more complicated which is a synonym for attack surface. And the "more valuable targets" argument is self-defeating because if there aren't as many high value targets using something then there aren't as many attackers looking for vulnerabilities in it either. Moreover, if someone finds one in TLS (or anything) then they can launch exploits against multiple targets simultaneously rather than waiting to move on to the second target until after the first investigates the attack and publishes a patch for everyone else to use.
      - johncolanduoni 1y ago
        Sure, they’ll get every credit card typed into Walmart’s website too. Cisco’s IKE implementation has had vulnerabilities (definitely still more widely deployed than Wireguard unfortunately), but almost nobody has heard about those. I don’t think they even had a cutesy name! My point isn’t that Wireguard should’ve used TLS/QUIC. Is that if you want a connection oriented transport encryption, you should almost certainly use TLS 1.3 in some fashion even if web compatibility isn’t a concern.
johncolanduoni 1y ago
What legacy junk is QUIC compatible with? It doesn’t include anything HTTP-related at all. It’s just an encrypted transport layer.
- mlhpdx 1y ago
  It’s multi stream, reliable connections. WireGuard’s encryption over UDP is none of those things. WireGuard encryption is simpler and far more flexible, but also less capable.
  - johncolanduoni 1y ago
    I’m not advocating WireGuard’s transport be replaced with QUIC (they’re solutions for very different problems), but that doesn’t mean QUIC is saddled with legacy junk. Most applications want protocols that are connection-based and optionally offer retransmit - that’s not legacy junk, that’s just what is called for in most cases. L3 encryption is an unusual application in that it doesn’t call for these properties.

The purpose of Wireguard is to be simple. The purpose of QUIC is to be compatible with legacy web junk. You don't use the second one unless you need the second one.

geoctl 1y ago

QUIC isn't really about the web, it's more of a TCP+TLS replacement on top of UDP. You can build your own custom L7 on top of QUIC.

bb88 1y ago
You can build a custom L7 on top of anything, really. I think my favorite was tcp/ip over printers and webcams. The question is what does QUIC get you that UDP alone does not? I don't know the answer to that. Is it because firewalls understand it better than native wireguard over UDP packets?
- remexre 1y ago
  Encryption and reliable transport.
  - zamadatix 1y ago
    You really don't want reliable transport as a feature of the tunnel unless you are _intimately_ familiar with what all of the tunneled traffic is already doing for reliable transport. The net result of two reliable transports which are unaware of each other is awful.
  - bb88 1y ago
    I probably should have clarified that question. What does QUIC get you that TCP over Wireguard over UDP does not?
- zamadatix 1y ago
  Mostly because WireGuard (intentionally) didn't bother with obfuscation https://www.wireguard.com/known-limitations/ https://www.wireguard.com/known-limitations/ > WireGuard does not focus on obfuscation. Obfuscation, rather, should happen at a layer above WireGuard, with WireGuard focused on providing solid crypto with a simple implementation. It is quite possible to plug in various forms of obfuscation, however. This comment https://news.ycombinator.com/item?id=45562302 https://news.ycombinator.com/item?id=45562302 goes into a practical example of QUIC being that "layer above WireGuard" which gets plugged in. Once you have that, one may naturally wonder "why not also have an alternative tunnelling protocol with <the additional things built into QUIC originally listed> without the need to also layer Wireguard under it?". Many design decisions are in direct opposition to Wireguard's design. E.g. Wireguard (intentionally) has no AES and no user selectable ciphers (both intentionally), QUIC does. Wireguard has no obfuscation built in, QUIC does (+ the happy fact when you obfuscate traffic by using it then it looks like standard web traffic). Wireguard doesn't support custom authentication schemes, QUIC does. Both are a reasonable tunneling protocol design, just with different goals.
  - bb88 1y ago
    I think maybe it's easier for an adversarial network admin to block QUIC altogether.
    - zamadatix 1y ago
      The hope with QUIC is encrypted tunnels that look and smell like standard web traffic are probably first in the list of any allowed traffic tunneling methods. It works (surprisingly) a lot more often than hoping an adversarial network/security admin doesn't block known VPN protocols (even when they are put on 443). It also doesn't hurt that "normal" users (unknowingly) try to generate this traffic, so opening a QUIC connection on 443 and getting a failure makes you look like "every other user with a browser" instead of "an interesting note in the log". I.e. the advantage here is any% + QUIC%, where QUIC% is the additional chances of getting through by looking and smelling like actual web traffic, not a promise of 100%.
      - 1y ago
nine_k 1y ago
Where is DNS on top of QUIC? Asking unironically.
- jiveturkey 1y ago
  That's DoQ, RFC 9250.
- geoctl 1y ago
  There is actually. A way more interesting re-implementation of a popular L7 is SSH over QUIC. SSH has to implement its own mutual authentication and transport embedded in the protocol implementation since it operates on top of plaintext TCP, but with QUIC you can just offload the authentication (e.g. JWT bearer tokens issued by IdPs verified at L7 or automatically via mTLS x509 certs) and transport parts to QUIC and therefore have a much more minimal implementation.
  - frumplestlatz 1y ago
    “Offloading” authentication onto complex web tech isn’t really a feature unless you already need to be operating in the web space for some other reason.
  - sigwinch 1y ago
    I feel like fans of `mosh` would run with this.
- maxloh 1y ago
  It is already there. It is called DNS over HTTP/3 (DoH3).
AnthonyMouse 1y ago
QUIC uses Web PKI and TLS. TLS is not a simple protocol and the main reason to use it over something simpler is if you need it to be compatible with something else that already uses it, like HTTPS.
- johncolanduoni 1y ago
  The main reason to use TLS is that you can get a bunch of off-the-shelf implementations that are (post-Heartbleed) the most heavily scrutinized public cryptographic implementations in existence. Plus if anyone finds a practical exploit of TLS (or a major implementation), they’re more likely to go steal credit card numbers being typed into Amazon than to attack your particular use of it. Noise is cool but if you don’t need the same flexibility that Wireguard does (or have the expertise to implement a concrete protocol on top of it correctly), something built on TLS 1.3 is a better bet.
  - AnthonyMouse 1y ago
    I'm not even convinced that a random TLS library would get non-trivially more scrutiny than Wireguard does, and on top of that it would need more scrutiny because it's significantly more complicated which is a synonym for attack surface. And the "more valuable targets" argument is self-defeating because if there aren't as many high value targets using something then there aren't as many attackers looking for vulnerabilities in it either. Moreover, if someone finds one in TLS (or anything) then they can launch exploits against multiple targets simultaneously rather than waiting to move on to the second target until after the first investigates the attack and publishes a patch for everyone else to use.
    - johncolanduoni 1y ago
      Sure, they’ll get every credit card typed into Walmart’s website too. Cisco’s IKE implementation has had vulnerabilities (definitely still more widely deployed than Wireguard unfortunately), but almost nobody has heard about those. I don’t think they even had a cutesy name! My point isn’t that Wireguard should’ve used TLS/QUIC. Is that if you want a connection oriented transport encryption, you should almost certainly use TLS 1.3 in some fashion even if web compatibility isn’t a concern.

johncolanduoni 1y ago

What legacy junk is QUIC compatible with? It doesn’t include anything HTTP-related at all. It’s just an encrypted transport layer.

mlhpdx 1y ago
It’s multi stream, reliable connections. WireGuard’s encryption over UDP is none of those things. WireGuard encryption is simpler and far more flexible, but also less capable.
- johncolanduoni 1y ago
  I’m not advocating WireGuard’s transport be replaced with QUIC (they’re solutions for very different problems), but that doesn’t mean QUIC is saddled with legacy junk. Most applications want protocols that are connection-based and optionally offer retransmit - that’s not legacy junk, that’s just what is called for in most cases. L3 encryption is an unusual application in that it doesn’t call for these properties.