-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/07/2015 12:38 AM, Andrew Sullivan wrote: > > Some of these proposals are in fact using names in domain name slots > as ways of indicating that the protocol itself ought to be > different. The hint a name below onion is giving is, "Not really the > protocol you think it is." It's a protocol-redirection trick. > *** Not exactly. As I understand it, Tor says: until you reach the exit node, the actual protocol is hidden from the intermediate participants and observers. At the exit node, HTTP is used if that is what you intended to use.
The case for using tor:// or onion:// (let's say it's tor:// to simplify), is to be able to indicate that the transport to destination should be the Tor network. In such case, you could use tor://example.com/ in your Web browser, and your Web browser would know that you intend to use HTTP(S?) to reach example.com via the Tor network, or you'd type: `ssh tor://example.net` to use SSH over Tor instead of `torsocks ssh example.net`, etc. Similarly, tor://facebookcorewwwi.onion/ would be redundant on a system running Tor only with https://facebookcorewwwi.onion/ but useful on a system running GNS and not Tor as the GNS resolver may know how to pass it on over the Tor network in the future. > In the other case, it's an indication that the _namespace_ is > different: that if you resolve that name on the Internet without > special enabled software, you aren't getting the service you desired, > regardless of the protocol you happen to be using. > *** This is true for all 6 pTLDs: special software is required to reach the desired service. Otherwise, NXDOMAIN is returned after hitting the DNS root. The problem resides in the fact that IANA may assign one of the 6 pTLDs to some registrar, and then conflicts start happening. Once IANA has assigned the pTLDs to P2P Systems, such conflict is known to be an error, or a malicious attempt, as the DNS cannot resolve such names without specific changes to implementations. > In theory, these kinds of applications actually ought to want > a new DNS class > *** A new DNS class would neither solve the privacy issue nor the censorship issue P2P systems want to address. > But they're different kinds of > problems, and so ought to be evaluated differently. > *** At least we shared that feeling, if not the scope of "kinds of problems" :) > Moreover, I wonder > whether using the special-names registry at the top level is justified > in every case, given that in principle we've already assumed that > top-level name space is managed by someone else. > *** The main issue I foresee with packing widely different name assignment and resolution strategies at levels below the top-level, e.g., under an .alt TLD, is one of complication. Who is managing name assignment and conflicts under .alt? Is that IETF via RFC 6761? Is that weird wild west? Now we're talking about 6 pTLDs, each one using its own strategy. They have in common to use innovative name assignment and resolution strategies independent from a centralized assignation authority. Why would such strategies appear lower than top-level, especially considering that they're even different strategies from each other? There might be others appearing but it's quite unlikely that they would flourish. On the other hand, opening .alt would give an incentive to rush for foo.alt and each new case would have to be treated separately by each application--without any way to know whether it fails because the target host name does not exist or because the domain name is not assigned. Imagine that we have .bit.alt. Applications start supporting .bit.alt, and it works, and everybody is happy. I can request a web page from example.bit.alt, and I retrieve it. I can request a web page from non-existent.bit.alt and receive an NXDOMAIN. Perfect. Now I mistype, or the person creating the QR code I used to connect mistyped: wrong.example.b1t.alt. Bee One Tee. Hardly visible. Still returns NXDOMAIN. Is that because the wrong.example.bit.alt does not exist, or because the b1t.alt does not exist, or is it not supported by my system? Things become complicated and confusing. 20 naming strategies later, implementors ask: was it .bit.alt or .but.alt that used the digital Arab telephone strategy? Or was it .bot.alt? Are you sure .bot.alt exists? Where can I verify what sub-domains of .alt exist? Who controls the list? Should Apple re-deploy .local under .local.alt? Why .invalid.? Six pTLDs in one RFC fosters clarity: these names are not assigned using regular DNS delegation to registrars; each has its own peer-to-peer way of assigning and/or resolving domains, outside the DNS tree ; they enable protection against arbitrary censorship. The message is both clear and simple. It becomes complicated when trying to eliminate the assignment/resolution specificity of P2P name systems. It becomes complicated if you have to look them up in various RFCs to figure out which P2P domains do not follow the regular DNS delegated registration rules. Regards, == hk -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUrNPQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9T4wQAKMTdlPmkQAEH6APZ2Ay/W2v OLhJlrPp6yPSJYMSdKq/yy+bpOt5AAvl3Zchf/VweZTNmx+PiI71+jtsaI0mqdTQ ZqvZZoLDb6qw66lvBeKneMJyQhEmZ4bPtuGMAZMxqXuNyFR2LMnx5N4+0fnrF6n+ uq3pnsZqKBRo3I3oeg9n5F6VlX+tpxyIoW9bcEu5N5tfNUBe27I5gfLwSo3GiVxO QiKrRC+pPoKwuTXGZFALENfywXAGGiJoNwyxX4IhU0nQKY0S35FjU74BsxejFebe PAEvPyqaUaOAEwjpVdxDww/pXTJMZgYQijpy0b0E8a/ehiCI36IZqdzfjfuOpatk JjDOJh/IBE6Pz8IyH22MitN73uX42cvdZxiD8uPalMJMBDMx16Mhn4QhOlpq3XjN 9mt1+GrQI5igtPHTHaXLYavrpTS0x6KanoNyyJlbrNxsxEPVI8CelkHwAGg5fGQR TsSL7dT/CBheAYkouC+sY/kHmbZREETF6iQ5XPqEOIWWPqCpnsebldwUt98T8+gv iNSHXgkffHt2Gdq5YFtgirFeMyY2OS0BmigXf1OeyTd/qleVpZBEebo5E87jrnw0 ihQtyLClfsqZLpryuVwJ6gPFj2szGexNxeDUzUcP/EflILVj2QFfQ8AGSJtrKbjB +R7Br0o6vKbRpPJ1rE3d =z5kQ -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
