On 01/30/2012 06:07 PM, Ondrej Mikle wrote:
On 01/30/2012 11:18 AM, Jacob Appelbaum wrote:
On 01/30/2012 01:09 AM, Christian Grothoff wrote:
In summary, I think begin_dns is a good idea, but I'm not sure you need to then talk TCP to the nameserver -- UDP ought to suffice.
I think begin_dns is a good idea as well.
Seconded, I also find it as a good idea.
Glad to hear it.
It seems to me that there are a few ways to do it:
send the query and the type send a raw packet that is then forwarded send a variable query and a fixed type (what we do now)
I think that even if DNSSEC dies tomorrow, we'd be silly to stick with the way we do things now. I also think that sending a raw packet is a bit sketchy as it basically means that you're sending client side crafted data - this usually isn't good news from an anonymity perspective.
I'd suggest that client sends query string, RR type and class in the cell. The class is almost always INTERNET, but CHAOS can be useful for debugging which server of anycast cluster are you actually talking to. You'll almost never need the class CHAOS, but when you do, it will come in handy (see TXT "hostname.bind" and "version.bind").
I think that almost any record type is fine.
DNSSEC: it will become very useful once DANE protocol is standardized (see https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/). DANE is a certificate-pinning protocol, saying which site should have which TLS certificate or which CA should have issued it (maybe Sovereign Keys or Auditable CAs will catch on first, but there's no way of knowing yet).
Agreed. DANE is an important nail in the CA Racket's coffin. :)
If begin_dns worked by sending the query and the type, we'd remove almost all possibilities of client side DNS fingerprinting but we'd add attack surface to the exit nodes...
I agree. How do we evaluate exit nodes' attack surface? (I suggested fuzzing libunbound/ldns as one method). How could we hide the CHAOS queries?
Well - first off, we'd want to determine the places where new code is added - if we don't change current things and only add a cell type, I think that's quite easy to do. Secondly, I'd imagine that we'd want to audit the underlying library quite extensively.
However, I imagine that if we wanted, we could add a new flag 'dns' that would allow various exit nodes to declare themselves open for begin_dns cells. When a user opens the DNSPort, they could select nodes flagged with 'dns' to query directly. If none existed or the query was of a generic CNAME, PTR or A record type, we could use any normally available node.
With current code of relays, CNAME, A and PTR for in-addr.arpa would work. These three RR types have an advantage that they can be easily checked for resolution of private adresses (like Tor does now; though banning resolution of ".local" FQDNs might be added, it's a damn special case).
Right. We could certainly enable inspection at DNSPort time - it can check for RFC1918 addresses. I personally want a way to know what a server replied with - even if it might be harmful, I want a true, verifiable answer. I also want a way to ensure that it doesn't shoot people in the foot. So, perhaps we can do both?
I'd add NS, DNAME and AAAA to the default-allowed set (DNAME is quite rare, nevertheless used, there's also BNAME RFC draft that seems expired).
I'd like to see - TXT, SSHFP, CHAOS, NS, DNAME, AAAA, A, PTR, CNAME, DS, DNSKEY, RRSIG, NSEC, NSEC3, CERT, IPSECKEY, KEY, SOA, MX, SRV, SPF
It's becoming very difficult to use Tor without native SRV record for say, Jabber and the same is true for MX and other types.
Basically, the entire list: http://en.wikipedia.org/wiki/List_of_DNS_record_types
If we want to support DNSSEC, then DS, DNSKEY, RRSIG, NSEC, NSEC3 should be allowed as well.
Agreed.
On the 'dns' flagged exit nodes, a client could begin_dns and then we'd parse the query and the type, generate the DNS query and then ask the our locally configured name server. In an ideal world, we'd use something like unbound to do the parsing and perhaps even to do caching.
I think it's reasonable to separate it into two tasks - 'dns' flagged exits would require supporting begin_dns - caching is something we should probably have but a full unbound cache is something perhaps huge to put into the same process.
libunbound as well as unbound do caching. ldns can do parsing (libunbound uses ldns).
I think that seems OK. I think the first step is a proposal, the second step is likely to implement whatever "begin_dir" means, a third step is another proposal where we add the "dns" flag to the Tor spec; likely we'd find that the second step requires a cache...
Thanks for hacking on this!
All the best, Jacob