Dropsafe

by Alec Muffett

A question for you all: Tor, DNS, URIs, generic TLDs, and a return to flat namespaces?

Here’s an example URL:

scheme://host.domain.tld/path/file.ext

This matches most of the URLs that you will ever encounter on the Web; don’t nitpick it too much – there can be hanging directories, portnumbers, user:password@host... additions and even full-blown URIs, but overall it’s a pretty good example.

But there’s an open problem – the URL syntax does a very good job of abstracting and separating the scheme, the host/location and the path/resource – but it assumes a unified name lookup service. A URI assumes that there is essentially only one host.domain.tld, and that it is resolvable in the DNS – except this is not exactly correct, and is likely soon to be very wrong.

Examples:

Examples of the above:

– are not like content-addressable Magnet Links because (obviously) we are not talking about content-based addressing; instead the magic cryptobabble represents a real machine to which a real connection is made, and over which real HTTP is spoken; so this challenge is not addressable by futzing with the scheme (tor-http://...)

The tactic so far has been to create fake top-level-domains like .onion – which is great, and even has historical precedent, but even though the recent approval of the .XXX top level domain is causing a ruckus, it seems pretty likely that more and financially-attractive-to-ICANN top level domains will arise.

This would flatten-out the DNS in a manner akin to UUCP or BITNET – where intra-domain hierarchies represent some clan-like hierarchical granularity, but between domains anything would be possible; I could call dibs on www.alec.muffett and have my nameserver at ns0.alec.muffett, and my cousin could have www.duncan.muffett – but anyone with the surname “onion” cannot do this because they’ll clash with Tor.

Hence the Fake TLD is probably a bad mechanism. Maybe someone farsighted at the IETF would be interested in:

scheme://resolutionamespace::host.domain.tld/path/file.ext

…instead? Or ideally something ideally better than that grotesqueness?

⊞

Comments

9 responses to “A question for you all: Tor, DNS, URIs, generic TLDs, and a return to flat namespaces?”

  1. alecm

    related:
    http://blogs.computerworlduk.com/unscrewing-security/2010/12/why-should-there-be-only-one-dns/index.htm

    Reply
  2. Peter da Silva

    Just create an arbitrary domain dedicated to the namespace, and have scheme: recognize it. Eg: tor://dsjdaskdjlsa.onion.magicword.xx/

    You could make the actual magicword.xx domain return an explanation for all pages.

    Reply
    1. alecm

      @Peter: your example means ensuring that

      1) all HTML is relative-linked (which is almost fair)

      2) all browsers understand the “tor:” scheme (unfair, if Tor access is being implemented by a sitewide proxy that otherwise hides all the magic)

      3) that “.magicword.xx” is proof against domainjacking by ICANN and/or is guaranteed to be processed first in name-resolution, before a recursive resolver punts the request elsewhere and returns either “Unknown Host” or (worse) a trojan site.

      Reply
  3. Daniel

    Cool, but what would resolutionnamespace look like? Isn’t it moving the problem around?

    Reply
    1. alecm

      @daniel: i don;’t think it is moving the problem around, because the idea is a notation outside the scope of a hostname within a URL.

      so http://dns::www.crypticide.com:8080/index.html and http://p2p::alecmuffett:8080/index.html might be equivalent.

      anything lacking the :: syntax would default to dns::

      i’ll be the first to admit that it’s not elegant, since it’s actually trying to control both name resolution and to some extent the means of establishing a connection, in both cases running HTTP over the resulting socket; but I think the idea advances the concept a little…

      Reply
      1. Alec Muffett

        2015 UPDATE:

        I see that I was kinda wrong (as are people proposing similar) given the underlying assumptions and the approach of the URI schema.

        It’s easiest to explain by a thought experiment:

        The URI is meant to be a UNIVERSAL Resource Indicator, right? So let’s imagine that you point a browser at:

        http://tor::something.onion/path/file.txt

        The way that browser work (and parse URIs) is to assume that everything which is not explicitly cited in a relative URI, stays invariant; so if you stumble across a legitimate hyperlink in a document that links to:

        //www.google.com/foo/bar/

        …then it should stay within the Tor namespace and abort, because “www.google.com” is not valid within the tor namespace; but the corpus of extant HTML and code (which, combined, is a bigger boatanchor than DNS) is such that this situation (hardcoded hostnames in code, lacking a namespace qualification) is a very likely scenario.

        …*OR ALTERNATIVELY*…

        Instead, let’s break that rule of invariance and have DNS be a default namespace anywhere that a “namespace::” is not specified.

        Therefore, all tor URIs will have to be written and linked-to as “tor::something.onion”, even internal to the Tor network, because lack of a “tor::” namespace prefix will cause use of the DNS namespace instead.

        At this point, one is merely dicking with whether there should be a namespace prefix (“tor::”) or just a recognised namespace suffix (“.onion”) – ie: semantics. It’s not a technical call, it’s a political one.

        This could have all been addressed in 1993 by TBL doing things differently, but that’s not going to change now; what is essentially being argued about is whether DNS can ever provide a universal namespace, beyond the (e.g.:) centralised addressing systems that DNS currently provides.

        I’d like to have that argument.

        In a sense IPv6 does similar, that you can have and be using an address which is divorced from the “subnet” which you are currently supposed to be attached to.

        “ZOMG THIS BREAKS ALL THE RULES OF ROUTING AS WE KNOW IT” – but the world hasn’t collapsed yet. Technologies change, network addresses in the future will be decentralised and self-declared, get over it, etc, etc…

        Reply
  4. Dogsbody

    We we need is some sort of ID mechanism of all objects and beings. Fully flat with no hierarchy… some sort of mandatory ID card….. 😉

    Reply
  5. Daniel

    Regardless of elegance, it generally sounds good because it is going towards decentralisation.

    But from the point of view of the ‘Fake TLD’ problem, in a world where we have shared namespaces, I’m not sure how the namespace notation of the URI would fix it. Who would define these namespaces and make sure there are no clashes? This is what I meant by moving the problem around. What am I missing?

    Reply
    1. alecm

      I don’t think you’re missing anything; I just believe these issues generally sort themselves out, a-la crowdsourcing, and then the IETF eventually standardises it or ICANN comes up with a solution…

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts