2 ms·

It is interesting that people have such negative reaction to the idea of end-to-end encryption in dns. I can think of very few other technical areas where havin

by belorn 6y ago

It is interesting that people have such negative reaction to the idea of end-to-end encryption in dns. I can think of very few other technical areas where having secure communication between the client and server without the involvement of third parties is seen as something bad and who ever suggest it should be shunned. Given how that is, I wonder how people would react to the idea of using even stronger security like off-the-Record Messaging.

tptacek 6y ago
I didn't downvote your comment, because I couldn't even understand it. You advocated for DoT (and extensions to it). I pointed out that DoT and DoH are the same thing. You came back with a non-sequitur about end-to-end encryption.
- belorn 6y ago
  I am advocating for aDoT, which is not DoT. The "a" letter in the beginning is an important distinction and stands for (a)uthoritative and aDoT is an early rfc draft about communication between a resolver and an authoritative server. To explain the terminology I use I can source the definitions from RFC 1034. We have "stub", "recursive", and "authoritative" resolvers. A stub resolver sits at clients because in 1987 not every computer had enough computer resources to run a recursive resolver themselves, and stub resolver talks exclusively to recursive resolvers. Recursive resolvers iterative talks to authoritative servers in order to resolve a domain name into a resource record (ip addresses, text, alias and so on), and the recursive resolver return the results to the stub resolver or the computer that host it. As the RFC specify, there was original two reasons why a machine may want to have a stub resolver and use someone else recursive resolver. One is the above reason that stub resolvers can be used on machines that do not have the computer resources to run a resolver. The second is in order to "centralize the cache for a whole local network or organization.". The preferred way as specified by the RFC is to do the recursive resolving on all machines, but if you want a centralized cache or have machines that do not have enough in terms of 1987 computer resources then there is a option to use a stub resolver. DoH and DoT is technology to encrypt the traffic between the stub resolver and the recursive resolver. Neither can be used if one follow the recommendation and operate the recursive resolver yourself. DNS between recursive resolving and the authoritative server is in plain text. aDoT fixes this, allowing for encrypted traffic between the recursive resolving and authoritative server. When a client who runs its own recursive resolver can create a encrypted channel between it and the authoritative server, what we have is end-to-end encryption. If there is a technical concept here you don't under just let me know and I can try to explain it further.
  - tptacek 6y ago
    I'm familiar. Obviously, over the long term, DoH is going to make its way to authority services, and subsume the legacy plaintext service. Maybe, because nobody has a strong interest in anti-censorship in recursor-to-authority communications, it'll even be DoT between cache and authority servers; I don't care (though it will be silly to have two different transports for the same fundamental transaction).

by belorn 6y ago

tptacek 6y ago

I didn't downvote your comment, because I couldn't even understand it. You advocated for DoT (and extensions to it). I pointed out that DoT and DoH are the same thing. You came back with a non-sequitur about end-to-end encryption.

belorn 6y ago
I am advocating for aDoT, which is not DoT. The "a" letter in the beginning is an important distinction and stands for (a)uthoritative and aDoT is an early rfc draft about communication between a resolver and an authoritative server. To explain the terminology I use I can source the definitions from RFC 1034. We have "stub", "recursive", and "authoritative" resolvers. A stub resolver sits at clients because in 1987 not every computer had enough computer resources to run a recursive resolver themselves, and stub resolver talks exclusively to recursive resolvers. Recursive resolvers iterative talks to authoritative servers in order to resolve a domain name into a resource record (ip addresses, text, alias and so on), and the recursive resolver return the results to the stub resolver or the computer that host it. As the RFC specify, there was original two reasons why a machine may want to have a stub resolver and use someone else recursive resolver. One is the above reason that stub resolvers can be used on machines that do not have the computer resources to run a resolver. The second is in order to "centralize the cache for a whole local network or organization.". The preferred way as specified by the RFC is to do the recursive resolving on all machines, but if you want a centralized cache or have machines that do not have enough in terms of 1987 computer resources then there is a option to use a stub resolver. DoH and DoT is technology to encrypt the traffic between the stub resolver and the recursive resolver. Neither can be used if one follow the recommendation and operate the recursive resolver yourself. DNS between recursive resolving and the authoritative server is in plain text. aDoT fixes this, allowing for encrypted traffic between the recursive resolving and authoritative server. When a client who runs its own recursive resolver can create a encrypted channel between it and the authoritative server, what we have is end-to-end encryption. If there is a technical concept here you don't under just let me know and I can try to explain it further.
- tptacek 6y ago
  I'm familiar. Obviously, over the long term, DoH is going to make its way to authority services, and subsume the legacy plaintext service. Maybe, because nobody has a strong interest in anti-censorship in recursor-to-authority communications, it'll even be DoT between cache and authority servers; I don't care (though it will be silly to have two different transports for the same fundamental transaction).