5 ms·

> working connection migration on IP changes MPTCP is available in iOS and recent linux kernels. So you don't need QUIC for that. > decoupling protocol upgrad

> working connection migration on IP changes MPTCP is available in iOS and recent linux kernels. So you don't need QUIC for that. > decoupling protocol upgrades from OS upgrades This is as much a downside as it is an upside. Now you have to potentially juggle hundreds of applications each shipping their own transport protocol implementation. And maybe their own DNS client too.

infogulch 6y ago
Dynamic linking has lost. Static linking fully self-contained binaries / containers etc combined with robust, deterministic build automation is the future.
- simias 6y ago
  I do think that in many situations dynamic linking doesn't make a whole lot of sense these days (like, say, a JPEG decoding library for instance). But having a central point where you can configure, test and administer networking makes a lot of sense to me. The idea of every application coming up with its own DNS implementation for instance annoys me greatly. I can already anticipate the amount of time I'm going to lose hunting down the way application X handles DNS because it won't apply my system-wide settings. I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest. Moving stuff to higher layers is, IMO, mainly because Google wants to become the new Microsoft/Apple and moving that stuff up is a way to take the control away from Windows/Mac OS. The browser is the OS. You use web apps instead of apps. You turn every device out there into a glorified ChromeBook.
  - skissane 6y ago
    > I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest. IBM z/OS actually does this with a feature called AT-TLS (Application Transparent TLS) [0]. You don't even need to call setsockopt (actually z/OS uses ioctl instead of setsockopt for this, but same idea). You can turn a non-TLS service into a TLS service simply by modifying the OS configuration. [0] https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.halx001/transtls.htm https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/...
    - tialaramex 6y ago
      People have built (more than once even) the same functionality for the Linux and NT kernels. https://www.kernel.org/doc/html/latest/networking/tls.html https://www.kernel.org/doc/html/latest/networking/tls.html https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-13-and-go/ https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-1... https://docs.microsoft.com/en-us/windows/win32/http/kernel-mode-ssl https://docs.microsoft.com/en-us/windows/win32/http/kernel-m...
      - skissane 6y ago
        That isn't the same functionality. - Linux kernel TLS doesn't provide a full implementation of TLS in the Linux kernel, only the symmetric encryption part. The handshake still has to be performed by the application in user space, and the application then needs to call setsockopt() in order to inject the keys into the kernel. By contrast, z/OS AT-TLS implements all of TLS (including the handshake), so the application doesn't have to do anything. As far as the application is concerned, a TLS socket looks exactly the same as a plain one (unless the application starts calling the AT-TLS ioctl, which will tell it whether a socket is plain or TLS) - The Windows "kernel mode SSL" is only for the built-in HTTP server. It doesn't apply to clients, or to other protocols than HTTP. By contrast, z/OS AT-TLS works for any protocol, not just HTTP, and supports both clients and servers So nobody has built the same functionality as z/OS AT-TLS in Linux or Windows. People have built some small subsets of z/OS AT-TLS's functionality, but not the generality that AT-TLS provides.
        tialaramex 6y ago
        Fair, although I think 99.9% of the value is in the trick Linux is doing here. The handshake is at once the most complicated part (which means you don't really want it in Ring Zero) and the part you're most likely to want to customise (e.g. OCSP stapling is in the handshake, certificate compression is in the handshake, SNI handling is in the handshake, and so on) which means that's the part an application author is least likely to be satisfied with being done on their behalf. Notice that in Linux because sockets "are" file descriptors you actually can put all connection and handshake work into a separate processes altogether, and just pass the socket (now TLS encrypted) to a process that pumps data back and forth, without it needing to be aware of TLS at all.
- saagarjha 6y ago
  Not to bring up the usual debate again, but anyone trying to sell you one side of the static/dynamic debate without acknowledging that this is not a cut-and-dry issue is doing you a disservice and it is probably in your best interest to not listen to them.

infogulch 6y ago

Dynamic linking has lost. Static linking fully self-contained binaries / containers etc combined with robust, deterministic build automation is the future.

simias 6y ago
I do think that in many situations dynamic linking doesn't make a whole lot of sense these days (like, say, a JPEG decoding library for instance). But having a central point where you can configure, test and administer networking makes a lot of sense to me. The idea of every application coming up with its own DNS implementation for instance annoys me greatly. I can already anticipate the amount of time I'm going to lose hunting down the way application X handles DNS because it won't apply my system-wide settings. I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest. Moving stuff to higher layers is, IMO, mainly because Google wants to become the new Microsoft/Apple and moving that stuff up is a way to take the control away from Windows/Mac OS. The browser is the OS. You use web apps instead of apps. You turn every device out there into a glorified ChromeBook.
- skissane 6y ago
  > I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest. IBM z/OS actually does this with a feature called AT-TLS (Application Transparent TLS) [0]. You don't even need to call setsockopt (actually z/OS uses ioctl instead of setsockopt for this, but same idea). You can turn a non-TLS service into a TLS service simply by modifying the OS configuration. [0] https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.halx001/transtls.htm https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/...
  - tialaramex 6y ago
    People have built (more than once even) the same functionality for the Linux and NT kernels. https://www.kernel.org/doc/html/latest/networking/tls.html https://www.kernel.org/doc/html/latest/networking/tls.html https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-13-and-go/ https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-1... https://docs.microsoft.com/en-us/windows/win32/http/kernel-mode-ssl https://docs.microsoft.com/en-us/windows/win32/http/kernel-m...
    - skissane 6y ago
      That isn't the same functionality. - Linux kernel TLS doesn't provide a full implementation of TLS in the Linux kernel, only the symmetric encryption part. The handshake still has to be performed by the application in user space, and the application then needs to call setsockopt() in order to inject the keys into the kernel. By contrast, z/OS AT-TLS implements all of TLS (including the handshake), so the application doesn't have to do anything. As far as the application is concerned, a TLS socket looks exactly the same as a plain one (unless the application starts calling the AT-TLS ioctl, which will tell it whether a socket is plain or TLS) - The Windows "kernel mode SSL" is only for the built-in HTTP server. It doesn't apply to clients, or to other protocols than HTTP. By contrast, z/OS AT-TLS works for any protocol, not just HTTP, and supports both clients and servers So nobody has built the same functionality as z/OS AT-TLS in Linux or Windows. People have built some small subsets of z/OS AT-TLS's functionality, but not the generality that AT-TLS provides.
      - tialaramex 6y ago
        Fair, although I think 99.9% of the value is in the trick Linux is doing here. The handshake is at once the most complicated part (which means you don't really want it in Ring Zero) and the part you're most likely to want to customise (e.g. OCSP stapling is in the handshake, certificate compression is in the handshake, SNI handling is in the handshake, and so on) which means that's the part an application author is least likely to be satisfied with being done on their behalf. Notice that in Linux because sockets "are" file descriptors you actually can put all connection and handshake work into a separate processes altogether, and just pass the socket (now TLS encrypted) to a process that pumps data back and forth, without it needing to be aware of TLS at all.
saagarjha 6y ago
Not to bring up the usual debate again, but anyone trying to sell you one side of the static/dynamic debate without acknowledging that this is not a cut-and-dry issue is doing you a disservice and it is probably in your best interest to not listen to them.