Re: [DNSOP] Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion S

> 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 
> <https://urldefense.proofpoint.com/v1/url?u=http://www.domain&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=PKCvk5ihsZdnlobuFIuhTw%3D%3D%0A&m=A9kJsJTtp7y9FT7avJ3dH%2Biv4nQfZ6morew9jupKe6c%3D%0A&s=6e63e914f40b2ad82dba84208b2004762b55c9e266dc4e941a3b09a015a55c02>
>  = 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/ <http://www.192.168.0.1/>  (versus 
http://eliot.blogs.192.168.0.1/ <http://eliot.blogs.192.168.0.1/>)

...whereas the following *is* viable:

https://www.facebookcorewwwi.onion/ <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: Message signed with OpenPGP using GPGMail