-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi,
Why run a separate process instead of using unix socket or TCP socket?
Since a Namecoin domain can point to IP addresses and ICANN-based DNS names in addition to onion service names, and a Namecoin domain owner might wish to switch between these configurations without causing downtime or forcing their users to change behavior, I recommend against this. However, see the open question below:
Open question: If a Namecoin domain points to an onion service, end users might expect encryption to be built in, and this assumption will be violated if the Namecoin domain switches to using an IP address. However, Namecoin domains can include TLS fingerprints, which would be enforced for both the IP address and the onion service address. Is it sufficient to tell users that TLS is required if they want encryption for Namecoin-addressed services, or is some additional mechanism needed here to avoid bad things?
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.
------------------------------------------------- 75% of Americans don't like Clinton or Trump. Don't waste your vote, say 'No' to the US Oligarchy and give it to Gary Johnson. (paid for by VFEMail)
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options!
On 10/08/2016 08:50 AM, 61wxgp60@vfemail.net 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.
Jesse V:
On 10/08/2016 08:50 AM, 61wxgp60@vfemail.net 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
-
61wxgp60＠vfemail.net -
Jeremy Rand -
Jesse V