[tor-dev] Proposal 274: A Name System API for Tor Onion Services

[Jeremy Rand]

Jesse V:
> On 10/08/2016 08:50 AM, 61wxgp60 at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161011/185f9ac6/attachment.sig>