On Mon, 16 Mar 2015, Jacob Appelbaum wrote:
Subject: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt
Is this meant to replace or augment draft-grothoff-iesg-special-use-p2p-names ?
- most importantly is the date October 1st. On that date we'll have a
death day for currently issued certifcates with .onion names. This
makes the onion name issue rather time sensitive and without further
action, some stuff will likely break.
How does the certificate "dead line" affect (non-)DNS for .onion?
I have reviewed the document and I'm not sure what is intended? I think
it is meant as advise to DNS implementors? I guess it is an attempt to
reduce .onion leaks if those happen to hit the DNS infrastructure? If
so, I would think a much shorter document could be written that only
talks about stub resolvers and caching resolvers, stating they should
never forward any of these queries but return something - and I'm not
sure if NXDOMAIN is the best answer if these resolvers cannot go out to
fetch the real DNSSEC proof needed to authoritatively say so. SERVFAIL
might be better.
Although, if draft-ietf-dnsop-qname-minimisation becomes an RFC, and I'm
pretty sure that it will, then actually processing the query would not
leak that much information anymore, as only the "onion." request will
go out (and get cached) and proper DNSSEC proof will come back denying
its existance, without leaking the fake FQDN onion address.
Htmlized: http://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-00
The Tor network [Dingledine2004] has the ability to host network
services using the ".onion" Top-Level Domain.
Well, it does not because there is no Top-Level Domain of ".onion" and
we have the cryptographic proof of that in the root zone.
Applications that do not implement the Tor protocol
SHOULD generate an error upon the use of .onion, and SHOULD NOT
perform a DNS lookup.
If an application does not implement tor, and is not tor aware, it
_will_ do a DNS lookup. You can't really go ask the world to stop
doing that. You need to deal with that fact.
Resolvers that implement the
Tor protocol MUST either respond to requests for .onion names by
resolving them (see [tor-rendezvous]) or by responding with
NXDOMAIN. Other resolvers SHOULD respond with NXDOMAIN.
Again, stating what software that is not TOR aware should do is a lost
cause. They will just think it is a real DNS query and process it that
way.
Resolvers that do support Tor and that for some "tor reason" are
returning NXDOMAIN are going to hit DNSSEC validation failures if
the application using that resolver is DNSSEC aware. The NXDOMAIN
has to come with some NSEC/NSEC3 proof. In a way, you are lucky
because there is such a the proof - because it _really_ does not exist.
But it means any resolver can return that proof for "legitimate" tor
domains as well, which I would guess is some kind of a security issue
for tor aware applications using a system or network bassed resolver?
4. Caching DNS Servers: Caching servers SHOULD NOT attempt to look
up records for .onion names. They SHOULD generate NXDOMAIN for
all such queries.
5. Authoritative DNS Servers: Authoritative servers SHOULD respond
to queries for .onion with NXDOMAIN.
Well, they already do? Because it does not exist!
Users must take special precautions to ensure that the .onion name
they are communicating with is correct, as attackers may be able to
find keys which produce service names that are visually or apparently
semantically similar to the desired service.
Also, users need be aware of the difference between a .onion name
used and accessed directly via Tor-capable software, versus .onion
subdomains of other TLDs and providers (e.g., the difference between
example.onion and example.onion.tld).
I don't think an RFC can tell enduers what to do or expect?
If client software attempts to resolve a .onion name, it can leak the
identity of the service that the user is attempting to access to DNS
resolvers, authoritative DNS servers, and observers on the
intervening network. This can be mitigated by following the
recommendations in Section 2
It could also be mitigated by actually configuring a .onion zone, but
your document states that's really unwanted. Why?
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
