5 ms·

The layered approach gives benefits when the lower-layer protocols provide features to the upper-layer ones. We should have some security at a lower level so th

The layered approach gives benefits when the lower-layer protocols provide features to the upper-layer ones. We should have some security at a lower level so the upper levels can relax. But encryption was bolted onto everything after the fact, so it's a special case that doesn't translate to layering until you get into network tunnels. DNS is also weird because it's used by all these other protocols not as a layer, but as an external resource. It's like if an HTTPS server needed records from an SQL server, and rather than secure the SQL connection, you put the SQL inside HTTPS. I mean... sure, I can run an HTTPS server on the SQL server, add some extensions to the protocol, and request records that way. But that's layer-7-in-layer-7. That's not layering, that's... weird smooshing and stacking and munging. It's not the kind of layering the internet was designed for. I think we should've widely adopted layer 4 secure transport protocols a long time ago. You wouldn't need to do anything other than add or change some arguments to your existing IPC syscalls. Decentralized protocols are more complicated, but could be adapted without much trouble.

tptacek 8y ago
Your first argument begs the question. "We should have security at a lower level so upper protocols can relax". Ok, at what layer? The overwhelming majority of "protocols" are instantiated at a layer higher than TLS. Make the case that we need security at a lower layer than TLS. DNS is "weird" in the sense that you say, but it's important to understand that it's not the only thing that's weird in the exact same way. We don't have secure ARP, or secure BGP, or secure OSPF, or really even secure SNMP. TLS is a secure transport protocol. That's literally what the name means.
- peterwwillis 8y ago
  > Make the case that we need security at a lower layer than TLS I am. The first line of my last paragraph says it. "I think we should've widely adopted layer 4 secure transport protocols" (I meant OSI L4, not TCP/IP L4). As in, make TCP TLS connections natively adopted as ubiquitously as tcp and udp, built into operating systems and routers, and made as easy to use as opening a socket. That would help these other protocols that we don't secure, like SNMP. Obviously SNMP would still have those crap "community strings", but every protocol built on top of tcp could have been secure if tcp had security by default. SSH might never have been invented if Telnet and Rsh could have used an operating system's native TLS connections. Forcing applications to bring their own TLS implementation doesn't make sense to me.
  - deleted 8y ago
    [deleted]
  - pvg 8y ago
    "I think we should have widely adopted" and "it doesn't make sense to me" is not really "making the case" against the stated end-to-end principle argument, it's just describing a bare preference. The end-to-end principle isn't some immutable axiom but it's been particularly effective and applicable in secure network communications. So the bar for "making the case" is a lot higher than what you have so far.

tptacek 8y ago

Your first argument begs the question. "We should have security at a lower level so upper protocols can relax". Ok, at what layer? The overwhelming majority of "protocols" are instantiated at a layer higher than TLS. Make the case that we need security at a lower layer than TLS. DNS is "weird" in the sense that you say, but it's important to understand that it's not the only thing that's weird in the exact same way. We don't have secure ARP, or secure BGP, or secure OSPF, or really even secure SNMP. TLS is a secure transport protocol. That's literally what the name means.

peterwwillis 8y ago
> Make the case that we need security at a lower layer than TLS I am. The first line of my last paragraph says it. "I think we should've widely adopted layer 4 secure transport protocols" (I meant OSI L4, not TCP/IP L4). As in, make TCP TLS connections natively adopted as ubiquitously as tcp and udp, built into operating systems and routers, and made as easy to use as opening a socket. That would help these other protocols that we don't secure, like SNMP. Obviously SNMP would still have those crap "community strings", but every protocol built on top of tcp could have been secure if tcp had security by default. SSH might never have been invented if Telnet and Rsh could have used an operating system's native TLS connections. Forcing applications to bring their own TLS implementation doesn't make sense to me.
- deleted 8y ago
  [deleted]
- pvg 8y ago
  "I think we should have widely adopted" and "it doesn't make sense to me" is not really "making the case" against the stated end-to-end principle argument, it's just describing a bare preference. The end-to-end principle isn't some immutable axiom but it's been particularly effective and applicable in secure network communications. So the bar for "making the case" is a lot higher than what you have so far.