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 <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/ <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 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 >> <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" 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? - alec — Alec Muffett Security Infrastructure Facebook Engineering London
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
