Re: [DNSOP] Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard

[Eliot Lear <[e-mail]>]

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
>