3 ms·

The market is perfectly content to sit back and add workarounds on top of workarounds until everything starts to collapse. It's culminated in DNS Flag Day: http

The market is perfectly content to sit back and add workarounds on top of workarounds until everything starts to collapse. It's culminated in DNS Flag Day: https://dnsflagday.net/ https://dnsflagday.net/. I suppose it's fine to forklift upgrade if it's to resolve the tech debt the market tacitly accepted, but not so if it means securing a small but meaningful part of internet infrastructure. I don't want or need DNSSEC as currently designed to be accepted everywhere, but saying that a workaround is preferable because the real fix is costly ignores the long-term ramifications.

tptacek 8y ago
I understand your argument, but try for a second to see it from my perspective: the end-to-end argument pretty strongly implies, to me at least, that to get meaningful security, you want to provide it in higher-layer protocols, closer to the endpoints. What's wrong with taking a layered design like TCP/IP and simply drawing a line, below which we don't try to provide cryptographic security? We've been doing that for ~30 years now; it is the only means of providing cryptographic security on the Internet that has ever actually worked. You're calling this approach "workarounds", which, sure, they're workarounds, in the same sense as TCP is a workaround for IP's native lack of congestion avoidance.
- wahern 8y ago
  Because making a TLS stack mandatory for doing DNS is both ridiculous and also a non-starter. Ridiculous because if you think adding DNSSEC verification to a DNS library is hard, try adding a TLS stack. The hard part isn't recursive queries. All DNS libraries, even stub resolves, already need to handle recursive resolution to follow CNAME chains as caching servers don't normally return resolved chains unless they're (a) in-bailiwick or (b) the chain can be resolved from cache. The ugly part is attaching such a complex dependency to all the various third-party resolvers out there. A non-starter because I've written DNS servers and clients that saw widespread deployment and by far the biggest headache was networks that blocked TCP on port 53. DNS over TLS uses port 853. LOL Like that's gonna work better. Same analysis applies to DNS over HTTP, except now you're adding a whole HTTP stack to your DNS library. For heaven's sake.... Why not just get the slow, painful death of the open internet over with and move everything to AWS. We can have AWS terminals using opaque, bespoke protocols for everything. We can merge the AWS and Blink/Chrome teams and we can delegate the development of all new novel network services to them.
  - tptacek 8y ago
    Nerds have been saying this about the HTTP-ization of protocols literally for decades, but HTTP's gradual assimilation of all other protocols has continued basically unimpeded. Also: your primary objection to DoTLS is that networks block 53/tcp, and you say "same analysis applies to DNS over HTTP", except that, obviously, it does not: the whole reason DoH exists is to address that problem. Finally, even though I believe over the long term that DoH will be successful and will eventually become the primary mechanism with which browsers look up hostnames, it doesn't have to be for DoH to solve, entirely, the real problems DNSSEC tried to solve.
    - JdeBP 8y ago
      M. Ahern was, I suspect, referring to the analysis of the first paragraph with "same". In other words: > if you think adding DNSSEC verification to a DNS library is hard, try adding a HTTP or a HTTP+TLS stack
      - tptacek 8y ago
        That doesn't make much sense as an argument. Adding DNSSEC verification to a library is probably harder.
- peterwwillis 8y ago
  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.

tptacek 8y ago

I understand your argument, but try for a second to see it from my perspective: the end-to-end argument pretty strongly implies, to me at least, that to get meaningful security, you want to provide it in higher-layer protocols, closer to the endpoints. What's wrong with taking a layered design like TCP/IP and simply drawing a line, below which we don't try to provide cryptographic security? We've been doing that for ~30 years now; it is the only means of providing cryptographic security on the Internet that has ever actually worked. You're calling this approach "workarounds", which, sure, they're workarounds, in the same sense as TCP is a workaround for IP's native lack of congestion avoidance.

wahern 8y ago
Because making a TLS stack mandatory for doing DNS is both ridiculous and also a non-starter. Ridiculous because if you think adding DNSSEC verification to a DNS library is hard, try adding a TLS stack. The hard part isn't recursive queries. All DNS libraries, even stub resolves, already need to handle recursive resolution to follow CNAME chains as caching servers don't normally return resolved chains unless they're (a) in-bailiwick or (b) the chain can be resolved from cache. The ugly part is attaching such a complex dependency to all the various third-party resolvers out there. A non-starter because I've written DNS servers and clients that saw widespread deployment and by far the biggest headache was networks that blocked TCP on port 53. DNS over TLS uses port 853. LOL Like that's gonna work better. Same analysis applies to DNS over HTTP, except now you're adding a whole HTTP stack to your DNS library. For heaven's sake.... Why not just get the slow, painful death of the open internet over with and move everything to AWS. We can have AWS terminals using opaque, bespoke protocols for everything. We can merge the AWS and Blink/Chrome teams and we can delegate the development of all new novel network services to them.
- tptacek 8y ago
  Nerds have been saying this about the HTTP-ization of protocols literally for decades, but HTTP's gradual assimilation of all other protocols has continued basically unimpeded. Also: your primary objection to DoTLS is that networks block 53/tcp, and you say "same analysis applies to DNS over HTTP", except that, obviously, it does not: the whole reason DoH exists is to address that problem. Finally, even though I believe over the long term that DoH will be successful and will eventually become the primary mechanism with which browsers look up hostnames, it doesn't have to be for DoH to solve, entirely, the real problems DNSSEC tried to solve.
  - JdeBP 8y ago
    M. Ahern was, I suspect, referring to the analysis of the first paragraph with "same". In other words: > if you think adding DNSSEC verification to a DNS library is hard, try adding a HTTP or a HTTP+TLS stack
    - tptacek 8y ago
      That doesn't make much sense as an argument. Adding DNSSEC verification to a library is probably harder.
peterwwillis 8y ago
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.