On Mon, Nov 13, 2023 at 03:01:15PM +0000, Alec Muffett wrote: > Hi! I'm one of the authors of RFC 7686. > > Although myself and Appelbaum[1] are cited on it, the document is the > result of a huge amount of argument and input from many people (shout out > to Mark Nottingham most especially, whom I feel should have gotten an > author credit) on various IETF maillists, and against considerable pressure > from some in the DNS, ICANN and other naming communities who didn't want to > set a precedent nor open a gateway to "more exceptions for new TLDs". > > Reading this thread I can confirm that transparent proxies (of several > implementations) were considered to be outside of the scope of the > specification, not by intention but rather as a consequence of the DNS > community being **extremely motivated** to prevent the existence or > official sanction for anything that could be construed as extending DNS by > default, without going through the full DNS standards processes. > > There was (and, I suspect, remains) very much an attitude of DNS being > practically sacred and unamendable unless overseen by an elite priesthood > of experts, and as such all the "Tor" stuff was presented to them and to > the standards committees as being *"something utterly different from DNS, > really, we swear, honest, this is more of a namespace bookkeeping issue > than anything else"* — in order to prevent the standard being shot to death > by DNS zealots. > > Also: the ".onion" resolutions which "leak" into the global DNS network > were at the time — and probably remain — both a nuisance and a huge > information leak that gets mined by various state security agencies; those > participants who perceived that as an issue saw the RFC as an issue to > address both the noise and the leak by drawing a very firm line between DNS > and Onion addressing, hence the text which is under discussion here. > > Myself? I am looking at the application wants sympathetically, but with a > perspective of 36 years of Unix. To be frank I believe that the process we > went through and the points that were made during the RFC are prettymuch > valid, and I believe that using DNS as transport for a hack to resolve > Onion addresses is ill-advised, even massively dangerous, for the reasons > described. > > I have sympathy for the DNS resolver community being explicit about banning > ".onion" and I think that doing so would be good for Onion privacy; but > that doesn't mean that I find the *need* to resolve .onion addresses to a > virtual IP address to be illegitimate. > > Back in the 1990s we used to deal with their being different namespaces for > different networks[2] using the /etc/nsswitch.conf service which was > literally designed[3] to address this kind of problem; the acronym stands > for "Name Service Switch"[4] and it's how local naming in huge intranets > used to be implemented. > > As such, why not just build a small service to perform this mapping lookup > properly and splice it into nsswitch.conf, and save yourself from having to > police the DNS clients for data leakage re: "This IP address just tried to > look up `supersecretleakysite234567abcde.onion`"? Hey Alec, Thank you for taking the time to write such an informative response. I, too, come from a hihgly UNIX-centric background and can understand the direction you are going in. Though I don't have 36 years of UNIX experience, I've now spent more than half my age in UNIX (or UNIX-like) environments, hacking both on the kernel and userland. We're speaking the same language. :-) The problem with relying on system modifications, like nsswitch.conf, is that the switch to everything-on-smartphone makes solutions like that impossible or impractical. I'm unaware of even a single major smartphone vendor that permits that level of customization. Granted, my own lack of awareness does not mean there isn't a phone out there that permits modifying system configuration files--just that my knowledge is incomplete. I agree that infoleaks, especially of .onion DNS requests, is problematic. However, I disagree that prohibiting it in broadly monocultured libraries (libcurl) is an advisable approach. While I can appreciate and understand the many nuances of this particular problem, it is one that is indeed difficult to solve. Are there other commonalities between "infoleaky" deployments that could be improved? It seems to me that outright prohibition should be a method of last resort. Are we already there? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev