On 3/17/15, 21:53, "Richard Barnes" <r...@ipv.sx> wrote: >The only nit I would pick with the above is that it's perfectly possible >to *specify* what should be done, but of course one should not expect >that to instantly change everyone's behavior.
A preamble - I don't think what is "perfectly possible" matters. In an environment that has an unbounded population it's a waste of time to document a rule saying "this is how you must/should/ought to behave if only because enforcement (testing) is impractical. What you can do, in such an environment, is focus on individual reactions to the stimuli - like - when you get asked a question, reply like this. If you are writing to a bounded population of actors, you can spell out rules that define membership and what it means to be a member. Nevertheless, you have to account for the unbounded population of non-members knowingly or unwittingly getting in the way. Sometimes the underlying concept is perfectly reasonable but the way it is described has flaws and sometimes the recipe contains poor assumptions. >From the draft (https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-00) 1. Users: human users are expected to recognize .onion names as having different security properties, and also being only available through software that is aware of onion addresses. I don't know what to make of that. It's fine, but, to me an onion is something I buy at the supermarket so if asked about an onion address, I'd guess a farm. (Take this lightly, I'm not sure what would be an appropriate answer - and I couldn't resist.) 2. Application Software: Applications that implement the Tor protocol MUST recognize .onion names as special by either accessing them directly, or using a proxy (e.g., SOCKS [RFC1928 <https://tools.ietf.org/html/rfc1928>]) to do so. Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion, and SHOULD NOT perform a DNS lookup. The first part of the answer is spot-on. The latter is wrong - for example, my mail client allowed be to type in .onion and it didn't and shouldn't complain. (I turned off spell checking too.) Trying to specify what non-Tor-protocol elements will do is kind of useless. 3. Name Resolution APIs and Libraries: 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. This is tricky. Again, Tor-protocol elements are fair game. Other resolvers will fall into two camps, one that would always return NXDOMAIN so long as .onion is not delegated in the root zone. It's possible I stand up a test DNS with .onion, .tomato, .lettuce for testing in my private lab and that should be okay (until I connect the lab with the outside world - which I have seen happen). 4. Caching DNS Servers: Caching servers SHOULD NOT attempt to look up records for .onion names. They SHOULD generate NXDOMAIN for all such queries. Same comment as for #3. 5. Authoritative DNS Servers: Authoritative servers SHOULD respond to queries for .onion with NXDOMAIN. Same comment as for #3 and #4. 6. DNS Server Operators: Operators SHOULD NOT configure an authoritative DNS server to answer queries for .onion. If they do so, client software is likely to ignore any results (see above). I would drop the latter sentence, the first is a reasonable "suggested practice" for operators. I worked at an operator that would let you configure any domain you wanted, so long as it didn't conflict with others in its own system. This had the same pitfalls as certificate authorities issuing certificates for resources whose responsibility was impossible to trace, with actually less consequences. (I'll avoid the temptation to justify that here.) 7. DNS Registries/Registrars: Registrars MUST NOT register .onion names; all such requests MUST be denied. This goes along with my responses to #3, #4, #5 - as far as there never being a .onion in the root zone. (Somewhere in this writing, I remind myself that the Special-Use Domain Name registry is a little bit of an unknown to me, mentioned in another email earlier today.) Elsewhere in the draft is this: "The Tor network is designed to not be subject to any central controlling authorities with regards to routing and service publication, so .onion names cannot be registered, assigned, transferred or revoked. "Ownership" of a .onion name is derived solely from control of a public/private key pair which corresponds to the algorithmic derivation of the name. 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." And to me that clearly distinguished these names from the DNS. "Special precautions" to me includes the Tor elements protecting themselves from non-tor-elements either knowingly or unwittingly interfering. The notion of a tor name not being subject to an authority hierarchy distinguishes these identifiers from the DNS model. It's probably possible to have two names clash (if I read correctly how the names are derived) which runs up against the uniqueness principle in DNS, something enforced in IDNA too, if I believe correctly. I use believe here on purpose because I'm usually wrong whenever I make any statement about IDNA. In summary, the draft really ought to address this, and prehaps by reference - how Tor protocol elements are to behave with the names, what is requested of external systems to help the Tor protocol, and how the elements of the protocol protect themselves from non-(compliant-)elements interfering.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
