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 _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
