So... Alec and I did a bit of wordsmithing and what I propose is a slight clarification on the existing text, based on this exchange, and here it is:
Like Top-Level Domain Names, .onion addresses can have an arbitrary number of subdomain components. Only the first first label to the left of ".onion" is significant to the layer 3 Tor protocol, while application layers above have access to the full name. For example... And then an HTTP example would be inserted (or otherwise "For example..." taken out). Eliot On 7/20/15 12:58 PM, Alec Muffett wrote: >> >> Yes, there is an HTTP Host header. Yes, responses vary by the >> *value* but not by the *structure*. As far as Apache is concerned, >> for instance, I would imagine it's doing a string compare without >> counting or considering dots. By discussing an arbitrary number of >> components, that paragraph implies that HTTP cares about the >> *structure* of the name, when it does not (although some >> implementations might kludge this with www.domain = domain). >> >> And I'll just hasten to add that now between you and Richard there >> are two interpretations of what the text in the document means. All >> I am suggesting is a bit of clarity, please. > > Hi Eliot, > > I am one of the authors of this draft, and I would like to spell out > the concern which was raised to us, and which we sought, with this > paragraph to try and address. > > Onion addresses 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 addresses 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 address 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 > <http://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" address. > > In pursuit of "clarity", having had this explained, I would welcome a > better and more succinct phrasing, if you can offer one and yet not > bury the reader in unnecessary detail, or in technical detail which > might become inaccurate as implementations improve whilst the outline > remains largely unchanged. > > > -a > > -- > Alec Muffett > Security Infrastructure > Facebook Engineering > London >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
