On Sun, Apr 13, 2014 at 8:45 AM, Rubens Kuhl <[email protected]> wrote: >> Which is one of the reasons why I have been rather suspicious of the >> 'just use DTLS' approach. Building on DTLS means importing all the >> current and future complexity of TLS. >> >> That seems rather a lot of overhead when all we need to do at the DNS >> layer is to take a message M, encrypt it under a key and plonk a MAC >> code on the end. >> > > What about “Just use QUIC” ? It might have a better future with DNS than DTLS.
QUIC is a replacement for TCP and it has a lot of merit for applications where requests can be larger than a packet. If the request will fit into one packet and the number of response packets is small enough, the simplest approach is one UDP request packet and multiple response packets. That means servers are completely stateless and we can use anycast etc. What might be rather surprising is that we can fit a complex DNS transaction into one request packet, for example, to resolve http://www.example.com/ we might want to do the following lookups: www.example.com ? A www.example.com ? AAAA _http._tcp.www.example.com ? SRV _http._tcp.www.example.com ? POLICY Although the DNS protocol allows for multiple queries per request, this doesn't quite work because there is no way to specify which response code matches which query. So the simplest approach turns out to be to encode these as four separate DNS queries. But even with that overhead, we can fit all four queries above plus a MAC and a key identifier into one 1400 byte request packet. The nice thing about this is that it means support for the secure DNS actually reduces the load on the server. Instead of making at least two separate queries (A, AAAA) there is a single query. Since the crypto overhead is negligible (its all symmetric key), this is almost certainly a net win as most servers are I/O and transaction bound rather than CPU bound. >> I know that the counter argument is that 'TLS is a known quantity, 20 >> years have gone into development'. But like the argument that 'open >> source is better because anyone can review' we are seeing that its not >> necessarily true. Code can get worse over time as well as better. > > > Open source is still better because anyone can review. But code get worse > with time, either closed or open source, unlike wine. These arguments are only problematic when people think 'A allows B' means 'A therefore B'. -- Website: http://hallambaker.com/ _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
