[tor-dev] Comments on proposal 279 (Name API)

[str4d]

On 04/04/2017 12:50 AM, Nick Mathewson wrote:
> On Mon, Apr 3, 2017 at 8:20 AM, George Kadianakis <desnacked at riseup.net> wrote:
>> Nick Mathewson <nickm at torproject.org> writes:
>>> Section 2.1 and elsewhere:
>>>
>>> I suggest that we require all address suffixes to end with .onion;
>>> other TLDs are not reserved like .onion is, and maybe we shouldn't
>>> squat any we haven't squatted already.   I think we might also want to
>>> have all output addresses end with .onion too.
>>>
>>> I suggest  also that we might want to reserve part of the namespace
>>> for standardized namespaces and some for experimental or local ones.
>>> Like, if we standardize on namecoin that could be .bit.onion, but if
>>> we don't, it could be .bit.x.onion.

I2P has been doing this for years with *.b32.i2p for unique identifiers
vs *.i2p for hosts.txt-style naming, and I'm planning on writing an I2P
proposal to create a formal registry of 2LDs that implementations need
to know about, so we have the ability to expand in future under the .i2p
TLD. So I don't think it's a stretch for users to understand (although I
have other concerns, see below), and I'd be keen to have a common
standard for specifying subdomains that we can use for interoperability :)

>>>
>>
>> I have mixed feelings about keeping the .onion suffix.
>>
>> One one hand it seems like The Right Thing to do, since we managed to
>> get .onion standarized in the IETF which comes with various
>> benefits. Also, starting to squat other tlds arbitrarily seems like a
>> silly thing to do.

This is the safest space for Tor to work in from a technical
perspective. More specifically, I've been following discussion in DNSOP
ever since the original special-use names draft (containing .onion, .i2p
etc) was posted, and there is no way that the IETF is going to
standardise any new TLD for non-DNS (see below). It's increasingly
unlikely that the non-.onion TLDs in the draft will either (without
industry support like .onion had), so no CA-supported SSL certs for I2P :(

>>
>> However, I also dislike asking users to visit something.bit.onion
>> instead of something.bit, since people are not used to the second tld
>> having a semantic meaning, and I can imagine people getting very
>> confused about what it means.

There's also the problem of transport-agnosticism. Assume there's some
FOOnet that is created for naming that we all decide we want to use.
Users would probably expect that FOOnet names all exist in the same
space, which would not be the case if we had *.foo.onion, *.foo.i2p,
etc. I'm thinking along the lines of IPv4 vs IPv6, where you can have a
DNS name delegate to both via A and AAAA records; you wouldn't want the
name changing just because the underlying transport changed.

> 
> Indeed.  And I'm not only concerned about people becoming confused: I
> am also worried about confused programs.
> 
> Right now, it is easy to answer the question "will Tor handle this
> address specially" -- the only special addresses are the ones ending
> with ".onion", and the legacy suffices ".exit" and ".noconnect" as
> documented as address-spec.txt.  But if we allowed arbitrary TLDs in
> this proposal, then _any_ hostname would potentially be an address
> that Tor would handle specially.
> 

There is a draft currently in working-group last call that will specify
a .alt TLD (or possibly .alt.arpa, it's still being debated [1]), that
future non-DNS names will have to be under. Part of the proposed benefit
is that with a standard TLD, DNS resolvers can just stub out that entire
namespace, ie.

    if fqdn.endswith('.alt'):
       do_non_dns_lookup(fqdn)
    else:
       gethostbyname(fqdn)

Presumably, browsers would do so as well. So it's possible that you
could have *.foo.alt as the URI, but only *.foo is displayed in the
browser (along with some chrome indicating it is non-DNS), similar to
how only the base domain name is shown for some URIs (IIRC that's an SSL
cert verification thing).

The question then is how a browser would handle *.foo being typed in.
You wouldn't want to query DNS and then try *.foo.alt afterwards, as
that would be terrible for privacy, but if they tried *.foo.alt first,
and didn't have FOOnet installed, should they try *.foo in the DNS? The
browser either needs to know the full contents of *.alt (which is not
possibly because by design it will have no official registration), or
every registered TLD in DNS (which won't ever be added as a restriction
because of various legacy local-net vendor TLDs like *.home). So with
this approach, it's likely that .alt would need to stick around.

Lots to think about here...

str4d

[0] https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-08
[1] https://www.ietf.org/mail-archive/web/dnsop/current/msg19983.html

-------------- 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/20170404/2f934772/attachment.sig>