commit 0e39d9e3b953a55e9ee57d454c8d8c1ae6bcf5bd Author: Nick Mathewson nickm@torproject.org Date: Fri Aug 2 11:55:19 2013 -0400
219-expanded-dns: Isolate the references to DNSSEC
This was originally a DNSSEC proposal, but the round trip issue makes it look as though this proposal is not sufficient to implement DNSSEC for practical use. --- proposals/219-expanded-dns.txt | 42 ++++++++++++++++++++++++++++++---------- 1 file changed, 32 insertions(+), 10 deletions(-)
diff --git a/proposals/219-expanded-dns.txt b/proposals/219-expanded-dns.txt index c291984..dd015a6 100644 --- a/proposals/219-expanded-dns.txt +++ b/proposals/219-expanded-dns.txt @@ -1,13 +1,13 @@ -Filename: xxx-dns-dnssec.txt +Filename: 219-expanded-dns.txt Title: Support for full DNS and DNSSEC resolution in Tor Authors: Ondrej Mikle Created: 4 February 2012 -Modified: 19 August 2012 +Modified: 2 August 2013 Status: Draft
0. Overview
- Adding support for any DNS query type to Tor, as well as DNSSEC support. + Adding support for any DNS query type to Tor.
0.1. Motivation
@@ -17,13 +17,23 @@ Status: Draft XMPP). TLS connections will benefit from planned TLSA record that provides certificate pinning to avoid another Diginotar-like fiasco.
- DNSSEC is part of the DNS protocol and the most appropriate place for DNSSEC - API would be probably in OS libraries (e.g. libc). However that will - probably take time until it becomes widespread. +0.2. What about DNSSEC?
- On the Tor's side (as opposed to application's side), DNSSEC will provide - protection against DNS cache-poisoning attacks (provided that exit is not - malicious itself, but still reduces attack surface). + Routine DNSSEC resolution is not practical with this proposal alone, + because of round-trip issues: a single name lookup can require + dozens of round trips across a circuit, rendering it very slow. (We + don't want to add minutes to every webpage load time!) + + For records like TLSA that need extra signing, this might not be an + unacceptable amount of overhead, but routine hostname lookup, it's + probably overkill. + + [Further, thanks to the changes of proposal 205, DNSSEC for routine + hostname lookup is less useful in Tor than it might have been back + when we cached IPv4 and IPv6 addresses and used them across multiple + circuits and exit nodes.] + + See section 8 below for more discussion of DNSSEC issues.
1. Design
@@ -162,7 +172,19 @@ Status: Draft - does not pose "ghost-cache-attack", since once RR is flushed from libunbound's cache, it must be fetched anew
-8. Round trips and serialization +8. DNSSEC notes + +8.1. Where to do the resolution? + + DNSSEC is part of the DNS protocol and the most appropriate place for DNSSEC + API would be probably in OS libraries (e.g. libc). However that will + probably take time until it becomes widespread. + + On the Tor's side (as opposed to application's side), DNSSEC will provide + protection against DNS cache-poisoning attacks (provided that exit is not + malicious itself, but still reduces attack surface). + +8.2. Round trips and serialization
Following are two examples of resolving two A records. The one for addons.mozila.org is an example of a "common" RR without CNAME/DNAME, the