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

[Alec Muffett <alecm@xxxxxx>]

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 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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail