Hi, Alec, On Thu, Sep 3, 2015 at 6:31 AM, Alec Muffett <al...@fb.com> wrote:
> Hello Spencer! > > I do have one observation that I haven't seen anyone else touch on: > > I thought .onion was tied closely to the TOR protocol, so I have no idea > why the second sentence in this paragraph is here, or what it means, and > neither the string "TOR" nor the string "onion" appear in RFC 7230, so > chasing that reference didn't help. > > Like Top-Level Domain Names, .onion addresses can have an arbitrary > number of subdomain components. This information is not meaningful > to the Tor protocol, but can be used in application protocols like > HTTP [RFC7230]. > > Am I just being dense the night before a telechat, and everyone else > understands what this means and why it needs to be included in this > document? > > > > This matter has been discussed extensively elsewhere, and in response to > feedback from that experience, this paragraph will be mildly amended to > address matters of DNS syntax conformance: > > Like Top-Level Domain Names, .onion names can have an arbitrary > number of subdomain components. This information is not meaningful > to the Tor protocol, but can be used in application protocols like > HTTP [RFC7230]. Note that such names must conform to DNS name syntax > (as defined in Section 3.5 of [RFC1034] and Section 2.1 of > [RFC1123]), as they will still be exposed to DNS implementations. > > > What the first half of paragraph is attempting to express is outlined in > my e-mail to the IETF Discuss list (and DNSOP) > > https://www.ietf.org/mail-archive/web/dnsop/current/msg15084.html > > > …where I write, at perhaps excessive length (and mildly edited for > clarity): > > Onion names are much closed to (say) dotted quads (or other layer-3 > addresses) than to domain names, albeit that to denote them there is the > label ".onion" affixed in the place where one would expect to find a TLD. > > Where the analogy between onion names and IP addresses breaks down is that > the following is illegal (or, at least, has never been functionally viable): > > http://www.192.168.0.1/ (versus http://eliot.blogs.192.168.0.1/) > > ...whereas the following *is* viable: > > https://www.facebookcorewwwi.onion/ > > In some hypothetical alternate universe where we were all using IP > addresses rather than DNS to connect to endpoints, it might be cute to > support <subdomain>.<ipaddress> and let the "Host" header (and/or the HTTPS > SNI) disambiguate the intent, though doubtless this would also lead to some > kind of disaster. > > In the Onion world, the canonical representation of an onion name is: > > *sixteencharlabel.onion* (compare representations: *192.168.1.1*, *[::1]*, > etc) > > ...and in the outline we sketched of how Onions work, we sought to > describe them properly in their role as layer-3 analogues, mechanically > generated hashes of a randomly generated certificate, beyond human choice > except for brute-force mining. > > *However*, the Tor software has a party trick, that (as Richard has > explained) given an "onion" label for surety, it's happy to parse-out the > "sixteencharlabel" label and use that for connection establishment, > ignoring any other labels leftwards of that, if any. > > Of course using (say) "ssh" to connect to www.sixteencharlabel.onion will > not be beneficial, because SSH supports neither "Host" header nor SNI; but > a web browser using HTTP/S will pass a Host header, and thus we may effect > virtual hosting over a single ".onion" names. > > > The really short summary of this is: Onion names are layer-3 analogues, > but they look like domain names and may have trivial “subdomains” where the > transport protocol would be happy to recognise, honour and differentiate > subdomains via metadata transfer. > > Does that help, please? > It does(*), as does Christian's explanation. I wonder whether there's a sentence or two that would capture the salient points (which sound like "Tor routers ignore leftward labels", and "Onion names can include leftward labels that aren't used by Tor routers, but might be used to accomplish techniques like virtual hosting" to me, at least so far). Could you two talk, and see if that could happen? My question is at the non-blocking Comment level, but it's also at the "is the document clear enough on its own?" level. So you can ignore it, if the answer is "yes, it's clear enough" :-) Spencer (*) and I saw your note on the IETF discussion list - thanks for sending it there.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
