Not being on DNSOP, I may be missing context here, but this exchange jumped out at me as especially wrong:
> 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. > The entire point of the special use domains registry is to tell general clients how to behave with regard to special-use names. It exists precisely to tell the world the DNS names for which they should not do lookups, because they require different handling. --Richard I understand your point, and reality is a good check; by analogy though, > most (?) programmers are aware not to try looking up “192.168.1.1” in a > the “.1” top-level domain, and I hope this “should not” phrasing will > grow, with the establishment of “.onion” as a TLD, to reflect similar sane > practice. > > > > > 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. > > > Quite. That is, indeed, how it currently works. > > When we launched the Facebook Tor Onion we were concerned that malicious > people would seek to attack users by setting up local DNS resolvers to > point a DNS address of “facebookcorewwwi.onion” to a malicious IP address, > and then persuade users with non-Tor-capable browsers to access it. > > This concern was fortunately mitigated by our broad use of SSL; but this > threat model understores the importance of proper SSL certification and > putting “.onion” on a proper footing as a TLD and within DNS. > > With the aid of CA/B Forum Ballot 144, the first portion of that risk has > been addressed - it should become astonishingly hard to generate an > acceptable SSL certificate for an "onion address” for use on the IP-based > network space. > > [deletia, apologies, I am going to skip some stuff and seek to revisit it > later, due to time constraints.] > > > > > 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? > > > Actually, I feel that an RFC can tell users what to do and/or expect. > > That’s what “documentation” is *meant* to be for. :-) > > But, again, I think I take your point. Do you feel the wording is perhaps > too aggressive? > > - alec > > > -- > Alec Muffett > Security Infrastructure > Facebook Engineering > London > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
