4 ms·

> An other view of the history of Internet network security is largely the history of plain text protocols getting encryption and authentication. Telnet was re

by zrm 8y ago

> An other view of the history of Internet network security is largely the history of plain text protocols getting encryption and authentication. Telnet was replaced by ssh, but they're both connection-oriented protocols that create a session between two endpoints. The same is true of the transition from X to X-over-TLS for the various values of X. DNS isn't really a connection-oriented protocol to begin with and DNSSEC isn't really a protocol at all, it's a collection of DNS records for use in signature verification. Moreover, it's not encryption, only signatures. It doesn't provide privacy protection. The DNS equivalent to the transition to ssh or TLS would be something like DNSCurve, which is a transport protocol and does encrypt the data.

tptacek 8y ago
Note that we actually got what DNSCurve was offering, in the form of DoTLS and DoH.
- zrm 8y ago
  Not entirely. The promise of DNSCurve is that the authoritative servers can use it too. If they do, it can secure the queries between the recursive resolvers and the authoritative servers as well, and inherently provides secure delegation between administrative boundaries when the parent and child domain both use it. DNS over TLS/HTTPS typically only secures the link between the client and the resolver, and does so at the complexity cost of bringing in all of TLS and its problematic CA system, and HTTP on top of that for DoH. And the proposals to make it work to the authoritative nameservers have it using DANE (i.e. DNSSEC).
  - zaarn 8y ago
    There is no reason that the authorative DNS Server couldn't use DNS over TLS/HTTPS as well.
    - zrm 8y ago
      TLS could be used in much the same way that a mining truck could be used by a letter courier service. You can, doesn't mean you should. With DNSCurve, when you have a delegation from one authoritative server to another, the parent domain provides the name of the child domain's nameserver, which encodes its public key. Then you use the public key to communicate with the child nameserver. The key distribution is part of the protocol. To use TLS, you would either have to rely on the CA system with all its problems (any malicious CA can forge any name and many are operated by potential adversaries), or DANE, and then we're creating a dependency on DNSSEC rather than replacing it. Worse, you have to choose one or the other for everyone or else support both as options and have the worst of both worlds in combined complexity and lowest common denominator security. The overhead of DoT/DoH is also worse in the recursive case. Between the client and the recursive DNS server, creating a TLS session is expensive but at least then you can keep it active and use it for all your queries. In the recursive case the queries go to/from many different authoritative servers, each with low probability of reusing the connection such that keeping it active long is counterproductive. So you're moving from a single UDP request and reply to a full TCP handshake + TLS handshake for as little as a single query. This adds both computation and latency. Moreover, the one redeeming quality of DNS over TLS/HTTPS is avoiding interference by middleboxes, which exists almost entirely in the context of client devices on restrictive networks rather than the links between recursive and authoritative DNS servers.
belorn 8y ago
DNS is just as much a connection-oriented protocol as http. It just happens that DNS uses caches a bit more than the web because of "reasons", so we got all those caches called recursive resolves being the default. An early argument against HTTPS was that you could not use web proxies any more. Today we don't normally talk about that, in part because the caching was moved away from the middle and into the server end. The discussion around how useful DNSSEC misses the point that what history has shown is that authentication without encryption is like encryption without authentication. We need both and preferable done yesterday.
- _red 8y ago
  >DNS is just as much a connection-oriented protocol as http DNS (UDP) is a strictly connection-less protocol. There is no state, there is no transport guarantees, its total fire-and-forget. https://en.wikipedia.org/wiki/Connectionless_communication https://en.wikipedia.org/wiki/Connectionless_communication
  - tptacek 8y ago
    DNS runs just fine over TCP.

by zrm 8y ago

tptacek 8y ago

Note that we actually got what DNSCurve was offering, in the form of DoTLS and DoH.

zrm 8y ago
Not entirely. The promise of DNSCurve is that the authoritative servers can use it too. If they do, it can secure the queries between the recursive resolvers and the authoritative servers as well, and inherently provides secure delegation between administrative boundaries when the parent and child domain both use it. DNS over TLS/HTTPS typically only secures the link between the client and the resolver, and does so at the complexity cost of bringing in all of TLS and its problematic CA system, and HTTP on top of that for DoH. And the proposals to make it work to the authoritative nameservers have it using DANE (i.e. DNSSEC).
- zaarn 8y ago
  There is no reason that the authorative DNS Server couldn't use DNS over TLS/HTTPS as well.
  - zrm 8y ago
    TLS could be used in much the same way that a mining truck could be used by a letter courier service. You can, doesn't mean you should. With DNSCurve, when you have a delegation from one authoritative server to another, the parent domain provides the name of the child domain's nameserver, which encodes its public key. Then you use the public key to communicate with the child nameserver. The key distribution is part of the protocol. To use TLS, you would either have to rely on the CA system with all its problems (any malicious CA can forge any name and many are operated by potential adversaries), or DANE, and then we're creating a dependency on DNSSEC rather than replacing it. Worse, you have to choose one or the other for everyone or else support both as options and have the worst of both worlds in combined complexity and lowest common denominator security. The overhead of DoT/DoH is also worse in the recursive case. Between the client and the recursive DNS server, creating a TLS session is expensive but at least then you can keep it active and use it for all your queries. In the recursive case the queries go to/from many different authoritative servers, each with low probability of reusing the connection such that keeping it active long is counterproductive. So you're moving from a single UDP request and reply to a full TCP handshake + TLS handshake for as little as a single query. This adds both computation and latency. Moreover, the one redeeming quality of DNS over TLS/HTTPS is avoiding interference by middleboxes, which exists almost entirely in the context of client devices on restrictive networks rather than the links between recursive and authoritative DNS servers.

belorn 8y ago

DNS is just as much a connection-oriented protocol as http. It just happens that DNS uses caches a bit more than the web because of "reasons", so we got all those caches called recursive resolves being the default. An early argument against HTTPS was that you could not use web proxies any more. Today we don't normally talk about that, in part because the caching was moved away from the middle and into the server end. The discussion around how useful DNSSEC misses the point that what history has shown is that authentication without encryption is like encryption without authentication. We need both and preferable done yesterday.

_red 8y ago
>DNS is just as much a connection-oriented protocol as http DNS (UDP) is a strictly connection-less protocol. There is no state, there is no transport guarantees, its total fire-and-forget. https://en.wikipedia.org/wiki/Connectionless_communication https://en.wikipedia.org/wiki/Connectionless_communication
- tptacek 8y ago
  DNS runs just fine over TCP.