Jesse V: > On 10/08/2016 08:50 AM, 61wxgp60@xxxxxxxxxxx wrote: >> How about specifying whether the Namecoin domain should point to .onion >> or clearnet in the domain? We can require that TLDs for such service >> must end in either: >> >> o o: The name points to a .onion name. >> >> o i: The name points to an IP address. >> >> o a: The name points to a clearnet domain name. >> >> So example.zkeyo points to 66tluooeeyni5x6y.onion. example.zkeyi >> points to 192.0.2.1 or (and?) 2001:db8::1. example.zkeya points to >> example.com. > > I don't think this is in scope of a naming system API. The naming system > probably has its own rules and users should be aware of those rules when > they use the naming system. For example, the Onion Name System (OnioNS) > will likely use ".tor" and I enforce that names must point to either > ".tor" or ".onion", thus keeping it all internal. During my trial tests > today, the client code followed a chain until ".onion". > > This is an API for onion services, so it doesn't make sense to handle > clearnet TLDs. There are other and easier ways of doing that, such as > alternative DNS roots. The specific reason that a Namecoin domain owner may wish to have a CNAME to a clearnet TLD is that they may wish the IP address (at the name example.bit) to be controlled by insecure infrastructure (say, some random clearnet domain registrar), but the TLS fingerprint (at the name _443._tcp.example.bit) to be controlled by their own keys via Namecoin. This is a perfectly reasonable use case: if the IP address is forged, nothing bad happens (visitors will just get a TLS error), but if the TLS fingerprint is forged, a MITM attack happens. I would argue that this use case is actually very relevant for Tor, simply because Tor exits are known to do MITM attacks with higher frequency than typical ISP's in most countries. That said, there's no reason I can see why an end user would care about whether an A/AAAA record or a CNAME record was used, so I don't think it makes sense to have an explicit way for an end user to request that one be allowed and the other not be allowed. I also realize that the applicability of CNAME is dependent on what naming system is used. In Namecoin it makes sense; in OnioNS it doesn't (unless I'm unaware of some reason why OnioNS would want it). Since it's dependent on the naming system, I would argue that this behavior should not be dictated by Prop274; the naming system should be able to handle that itself. The only place where it matters to Tor or Tor Browser is when a non-TLS connection is established and the end user wants end-to-end encryption+authentication, in which case .onion is okay, but both A/AAAA records and CNAME records are not. It's unclear to me exactly what the mechanism should be to specify that. Cheers, -Jeremy
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev