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

[Ivan Tham]

meejah  wrote:

> 
> It was suggested I post this to tor-dev; I prototyped a small thing
> that allows the prop-279 APIs to be tested against actual-Tor without
> changing Tor. That is, it does the "abuse the control-protocol" thing
> but speaks to prop-279 style subprocesses.
> 
> This is just proof-of-concept and would need a little more fleshing out,
> but should be sufficient to proceed with prototype implementations of
> prop-279 clients.
> 
>https://github.com/meejah/TorNS
> 
> -- 
> meejah
> 
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

I have created a simple client where it uses the hosts file, originally
planned for GSoC but I had missed the chance to submit it.

The part for the cancel still needs improvement, feel free to use it.

My repo: http://git.pickfire.tk/banana/
GH repo: https://github.com/pickfire/banana (mirror)

Good luck and have a nice day!
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[meejah]

It was suggested I post this to tor-dev; I prototyped a small thing
that allows the prop-279 APIs to be tested against actual-Tor without
changing Tor. That is, it does the "abuse the control-protocol" thing
but speaks to prop-279 style subprocesses.

This is just proof-of-concept and would need a little more fleshing out,
but should be sufficient to proceed with prototype implementations of
prop-279 clients.

   https://github.com/meejah/TorNS

-- 
meejah

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Yawning Angel]

On Sat, 8 Apr 2017 08:47:51 +0100
Alec Muffett  wrote: 
> However: on this conference call it was made abundantly clear to all
> present - one could almost hear fingers being wagged - that it would
> be a bad thing for Onion addresses to (1) contain anything other than
> alphanumerics and non-leading-hyphens, (2) collide with IDNs and
> PunyCode.
> 
> Now: I flatly do not know where this is documented; it may possibly
> be some intersection of DNS and HTTP RFCs, and if we want to take the
> approach that "everything should be permitted unless it is explicitly
> forbidden!" then yes we should go chase those documents down so that
> we have rationales for our self-imposed bondage.

Ironically, I struggled with this a bit when I pushed for making tor
clients reject "obviously malformed" destinations right when they hit
the SOCKS server.

From what I remember/can tell, RFC 1912 has the rules on what a valid
`hostname` is, RFC 2181 suggests that DNS server implementations should
not enforce restrictions on what a valid `hostname` is, and from
experience enforcing strict RFC 1912 on the real internet breaks
`nytimes.com`.

RFC 6125 mandates "LDH Lables" (RFC 5890), but is only applicable to
TLS.

> However if we want to seek the path of least resistance and effort,
> the answer is obvious to any seasoned network administrator:
> 
> * alphanumeric
> * (whatever DNS label length)
> * (whatever DNS overall length)
> * single, and only single, dots at label separators
> * single, and only single, hyphens as spacers
> * (i'm trying to think if there are any more obvious constraints, but
> can't)
> 
> ...which will traipse merrily through any system one cares to name.

tor currently enforces most of those (label length is notably not
checked), and also allows:

 * `_` because `core3_euw1.fabrik.nytimes.com` despite what the RFCs
   say.

 * Trailing `.` used sometimes to make it explicit that the domain is
   absolute.

See: https://gitweb.torproject.org/tor.git/tree/src/common/util.c#n1080

> That's a lovely idea; one more to add to the mix is the process
> documented at:
> 
> https://github.com/alecmuffett/the-onion-diaries/blob/master/basic-production-onion-server.md
> 
> ...of hijacking addresses out of the DHCP network space and using
> them to configure interfaces with genuine, resolvable Onion names.
> It makes SSH and Apache configuration really clear when you can use
> the genuine onion address in configuration ("Listen") directives, etc.
> 
> But then that's /etc/hosts - that's *not* what goes to a Certificate
> authority to be signed, and it's the latter that the committees get
> exercised about.

Sure.

> Hyphenation, readability studies, boutique & frou-frou name schemes
> invented at the Tech University of Mercedes-Benz, and other shooting
> ourselves in the foot can, and should, come later. :-)

I'd be ok with, and would likely even advocate for "If you want your
naming system to be shipped with Tor Browser, it should follow certain
guidelines, including mandatory syntax, a label registry, and etc",
which is a matter of policy.

But that to me is orthogonal to "there should be a flexible way to
offload name resolution" (a matter of implementation).

In practical terms the tor code would need modifications to allow
anything super exotic anyway, and I doubt anything will actually get
shipped with Tor Browser[0] till long after prop 224 is fully
implemented.

Regards,

-- 
Yawning Angel

[0]: As much as I hate the fact that port 80 and 443 are basically the
only things that matter, that's basically the situation.


pgpmAOpHG284K.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Alec Muffett]

On 8 April 2017 at 03:23, Yawning Angel  wrote:

> On Fri, 7 Apr 2017 11:44:03 +0100
> Alec Muffett  wrote:
> > If I was in charge, I would say that we risk overthinking this, and it
> > would be better to:
> >
> >- mandate use of fully DNS-compliant syntax, including but not
> > limited to: acceptable max length, max label length, charset and
> > composition
>
> Fully DNS-compliant only limits max length and max label length, unless
> there's something that supersedes RFC 2181.


You have an excellent point, and I remember fondly the happy days at Sun's
Network Security Group when I would set the name of my workstation to "#"
in DNS and use it to break into people's machines because ".rhosts" did not
support comment characters in the way that people expected.

However: on this conference call it was made abundantly clear to all
present - one could almost hear fingers being wagged - that it would be a
bad thing for Onion addresses to (1) contain anything other than
alphanumerics and non-leading-hyphens, (2) collide with IDNs and PunyCode.

Now: I flatly do not know where this is documented; it may possibly be some
intersection of DNS and HTTP RFCs, and if we want to take the approach that
"everything should be permitted unless it is explicitly forbidden!" then
yes we should go chase those documents down so that we have rationales for
our self-imposed bondage.

However if we want to seek the path of least resistance and effort, the
answer is obvious to any seasoned network administrator:

* alphanumeric
* (whatever DNS label length)
* (whatever DNS overall length)
* single, and only single, dots at label separators
* single, and only single, hyphens as spacers
* (i'm trying to think if there are any more obvious constraints, but can't)

...which will traipse merrily through any system one cares to name.

I am purposely leaving specific "label" and "overall" lengths out of this
list because although the correct figures are googleable, they tend to
trigger citation wars and off-by-one arguments so it's safer to discuss
them symbolically.


I intentionally left a lot of this unspecified because one of the use
> cases I envisioned was an "/etc/hosts" analog that lets users easily:
>
>  * Stick all their hidden services under their own name hierarchy.
>
>eg: git.yawning -> .onion
>

(...elided...)

That's a lovely idea; one more to add to the mix is the process documented
at:

https://github.com/alecmuffett/the-onion-diaries/blob/master/basic-production-onion-server.md

...of hijacking addresses out of the DHCP network space and using them to
configure interfaces with genuine, resolvable Onion names.  It makes SSH
and Apache configuration really clear when you can use the genuine onion
address in configuration ("Listen") directives, etc.

But then that's /etc/hosts - that's *not* what goes to a Certificate
authority to be signed, and it's the latter that the committees get
exercised about.

Onion addresses are not really hostnames, they're a machine-readable number
a-la IPv4 and IPv6, which - by amazing, fantastic fortitude - happen to be
exactly compliant with DNS which means that subdomains "work" where they
protocol passes them along in (eg: "Host:" header) metadata.

The Elders of the Internet (TM) did not have the wisdom to see that
"www.127.0.0.1" would be a useful thing; they put everything into tidy
buckets - layer 3 goes here, directory lookup goes there - and at the
outset broke decentralisation and imposed hierarchy by means of user
expectation.

Whomever the clever person was who unbroke it by making tordaemon ignore
"subdomains" should be honoured - they (accidentally?) re-merged the two
namespaces and - so long as Tor walks the knife-edge of being compliant in
both namespaces - then Onion addressing is in an amazing position:

* all the browser technologies which assume DNS can work without
modification
* this includes availability of HTTPS certificates
* and therefore all future web technologies like WebRTC
* but the addresses are end-to-end and self-created, thus obviating the
whip-hand of DNS censorship
* and onion services are effectively "published" (X.25 did similar)
reducing attack surfaces without firewalls / intermediation
* intermediation which Tor bypasses anyway, because NAT-punching /
Rendezvous, etc.

It's hard to express how amazing this situation is; it's really like
winding the clock back to the 1980s and getting a whole new network
architecture, for free, which supports all the modern bells and whistles,
all because of the Host header, SSL-compliance and fake onion subdomains.

This is why it's essential to get this right. :-)

Yawning wrote a bunch of stuff here, but I am gonna elide it and sent this
message to see if it changes anything, and then revisit.

I'll just finish by saying that I am very excited about:

  www.somethingexceefinglylonggoeshereandwearenotreallysureaboutformat.onion

...because we can complain about 

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

[Yawning Angel]

On Fri, 7 Apr 2017 11:44:03 +0100
Alec Muffett  wrote:
> If I was in charge, I would say that we risk overthinking this, and it
> would be better to:
> 
>- mandate use of fully DNS-compliant syntax, including but not
> limited to: acceptable max length, max label length, charset and
> composition

Fully DNS-compliant only limits max length and max label length, unless
there's something that supersedes RFC 2181.  I'm fine with both of
those restrictions.

>- declare a registry of short, valid labels, in the
> second-from-right position in the name
>- reserve "tor" and "name" in that registry (ie: *.tor.onion,
>*.name.onion)
>- park the entire issue for 12 months

I intentionally left a lot of this unspecified because one of the use
cases I envisioned was an "/etc/hosts" analog that lets users easily:

 * Stick all their hidden services under their own name hierarchy.

   eg: git.yawning -> .onion

 * Increase mobile quality of life by aliasing their HSes to addresses
   consisting entirely of emojis.

   eg: . -> .onion

 * Force redirect any site to anything else, really.

   eg: git.example.com -> .onion
   banner.ads.and.malware.example.com -> 127.0.0.1
   social.spacebook.trackers.example.com -> 127.0.0.1

I could do this with MapAddress, but a plugin would make my life
easier, especially since it beats editing multiple torrc files.

(Going further into this rabbit hole, I assume most exits won't resolve
 the OpenNIC TLDs...  What do I do if I want to view `example.pirate`
 or whatever over Tor?)

> Hence "parking" the issue because this is all meaningless until
> prop224 addresses ship, and there should be plenty of time in the
> next 12 months for people to think about how to fill the usability
> space with $PET_IDEA, and to my mind the changeover period between
> 80-bit and 256-bit addresses should be long enough that nobody need
> fret about it right now.

IMO the existing onion addresses already are a usability disaster.  It
should be easy for researchers to experiment with designs to solve the
problem *now* before prop224 addresses make a bad situation worse.

There's also a world of difference between implementing/shipping the
capability to override the name resolution via plugins, and "Shipping
the YawningCoinNamezTLD plugin with Tor Browser, enabled by default".

Regards,

-- 
Yawning Angel


pgpcFgEVzbcBe.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Alec Muffett]

>
> > 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.
>
> FWIW it's not at all clear to me that this is a concern that IETF or
> ICANN will care about.


Hi.

My name is Alec.

I fought that battle.  I still bear the scars.

Nick is right. Jeremy is not right.

ICANN and IETF and (nobody mentioned) CA/B-Forum members will violently
attack Tor as being weird if it blithely ignores the rest of DNS space.

Also, the concept of the ".alt" domain has been discussed for a long time,
and last I saw will continue to be discussed for a long time.

For Tor to not shoot itself in the head and foot simultaneously, it must:

   1. stick to ".onion" as a top level domain
   2. not tread on the rest of the namespace in any way whatsoever
   3. be able to make credible arguments that whatever exists under
   ".onion" is somehow cryptographic, attested by certs, blockchains, and shit
   like that, rather than "authorities" which would otherwise make the DNSOP
   workgroup feel pissy

If I was in charge, I would say that we risk overthinking this, and it
would be better to:

   - mandate use of fully DNS-compliant syntax, including but not limited
   to: acceptable max length, max label length, charset and composition
   - declare a registry of short, valid labels, in the second-from-right
   position in the name
   - reserve "tor" and "name" in that registry (ie: *.tor.onion,
   *.name.onion)
   - park the entire issue for 12 months

Because some geeks are nerds there will doubtless be arguments about the
creation of a registry, about forking the codebase, about "I am taking my
ball and going home because this is oppression!" and a bunch of other stuff.

Hence "parking" the issue because this is all meaningless until prop224
addresses ship, and there should be plenty of time in the next 12 months
for people to think about how to fill the usability space with $PET_IDEA,
and to my mind the changeover period between 80-bit and 256-bit addresses
should be long enough that nobody need fret about it right now.

The Prop224 migration will be doubtless faster than the IPv6 migration, but
anyone who says the changeover period should be less than 2 years is trying
to kill Tor adoption.

-a

-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[str4d]

On 04/06/2017 09:13 AM, Jeremy Rand wrote:
> Hi Nick!
> 
> Nick Mathewson:
>> 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.
> 
> FWIW it's not at all clear to me that this is a concern that IETF or
> ICANN will care about.  Most DNS recursive servers (e.g. Unbound)
> allow squatting on arbitrary TLD's (this is often used for corporate
> systems that use internal TLD's, but we use it for Namecoin as well),
> and to my knowledge no one has complained to Unbound about the ability
> to misuse this.

Then you haven't been reading the DNSOP working group's mailing list -
the IETF certainly cares. I recommend searching for ".onion",
"special-use", "sutld", or "alt-tld" on their ML viewer [0] and reading
the (extensive) back-history of these discussions. See below for a link
to my earlier comments on this tor-dev thread [1], as well as several
IETF drafts you may wish to read and comment on [2-3].

Cheers,
str4d

[0] https://mailarchive.ietf.org/arch/search/?email_list=dnsop
[1] https://lists.torproject.org/pipermail/tor-dev/2017-April/012153.html
[2] https://tools.ietf.org/html/draft-ietf-dnsop-sutld-ps-03
[3] https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-08



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Nick!

Nick Mathewson:
> 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.

FWIW it's not at all clear to me that this is a concern that IETF or
ICANN will care about.  Most DNS recursive servers (e.g. Unbound)
allow squatting on arbitrary TLD's (this is often used for corporate
systems that use internal TLD's, but we use it for Namecoin as well),
and to my knowledge no one has complained to Unbound about the ability
to misuse this.

Generally I view a pluggable naming system as useful for use cases
besides simply human-readable .onion names.  It's also useful for any
of the various use cases for which people will fiddle with their local
DNS setup (including but not limited to: firewalling, ad-blocking,
debugging infrastructure, internal naming systems that have nothing to
do with .onion, alternate DNS roots like OpenNIC, decentralized naming
systems like Namecoin that aren't being used for .onion).  Yes, you
*could* do this with the control port (OnioNS does this, and Namecoin
has an internal beta of this as well that we've chosen not to release
because we want to engage on Prop279 to make sure that what we release
meets people's needs).  But the control port is extremely dangerous to
expose to untrusted software, so it makes sense to use a dedicated
naming API.  Forcing all these other use cases to use a clunkier, less
secure setup than the "human-readable .onion names" use case is likely
to stifle innovation, lead to duplicated code with different sets of
bugs, and/or discourage use of the naming API because software authors
don't want to rule out the possibility of exploring other use cases
later on.

I can totally see a policy making sense that *the naming systems
distributed by Tor officially* would only allow .onion as input
addresses, but since it sounds like the intent of this proposal is to
enable experiments that aren't officially endorsed by Tor, it's not
clear to me that such a policy would have much immediate effect.

There will probably be a news post posted to the Namecoin website in
the next week or so that's relevant to this point, but I won't include
it here since it's only reviewed by 3 of the Namecoin developers at
this time and I can't rule out needing to make edits to it.  I'll
provide it in this thread when it's posted.  (If for some reason this
issue urgently needs to be decided and waiting a week will derail that
schedule, let me know and I'll see what I can do.)

Also see my next point below:

> I think we might also want to have all output addresses end with
> .onion too.

This definitely makes sense from a UX point of view: everyone already
knows what .onion services are, and they have certain expectations for
what security properties they provide, so just because the 2nd-level
domain isn't a base32 public key shouldn't mean that all those
security properties don't apply.  Using the 2nd level domain to choose
what type of naming system is in use (e.g. .bit.onion) certainly makes
sense here.  But, there are real use cases where users will want the
output address to not be a .onion address: see my point above.

I think a perfectly reasonable policy would be: "If the input name is
.onion, then the output name must also be .onion; otherwise no
restrictions on the output name exist."  This preserves the UX
properties that people expect from .onion, doesn't restrict the other
use cases I mentioned above, and is minimal enough in terms of code
and spec complexity that I expect it would be easy to audit.

> 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.

I don't have a particularly strong opinion on this, although I do
prefer the UX of .bit.onion over .bit.x.onion.  How many naming
systems are we expecting to actually be used here?  I wouldn't expect
any collisions to occur here due to the small number of naming systems
that are even expressing interest -- no collision with .bit exists
even in the wider DNS world 6 years after Namecoin was founded.  Is
there a threat model component here that I'm not seeing?

> I finally suggest that we distinguish names that are supposed to
> be global from ones that aren't.

This makes sense intuitively; is there a specific motivation for this
constraint?

> Section 2.3:
> 
> How about we require that the suffixes be distinct?  If we do that,
> we can drop this "priority" business and we can make the system's 
> behavior much easier to understand and explain.
> 
> Let's require that the TLDs actually begin with a dot.  (That is,
> I think that ".foo.onion" can include "bar.foo.onion", but I don't
> like the idea of "foo.onion" including 

Re: [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  
> wrote:
>> Nick Mathewson  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  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



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Nick Mathewson]

On Mon, Apr 3, 2017 at 8:20 AM, George Kadianakis  wrote:
> Nick Mathewson  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.
>>
>
> 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.
>
> 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.

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.

-- 
Nick
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[George Kadianakis]

Nick Mathewson  writes:

> Hi !  I'll make some comments here on the draft onion naming API at
>
> https://gitweb.torproject.org/torspec.git/tree/proposals/279-naming-layer-api.txt
>
> (Some of  these are probably things you already meant, or already said
> elsewhere.)
>

Thanks for the timely comments! I'm replying to this thread with my
thoughts, but I didn't have time to actually fix the proposal. I'll do
that in The Future.

>
>
> 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.
>

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.

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.

Anyhow, it seems like maintaining the .onion suffix is the right
approach here.

> I finally suggest that we distinguish names that are supposed to be
> global from ones that aren't.
>
> Section 2.3:
>
> How about we require that the suffixes be distinct?  If we do that, we
> can drop this "priority" business and we can make the system's
> behavior much easier to understand and explain.
>

Definitely agreed on this simplification suggestion. The priority
feature has confused people, and it's not that useful. In the future we
could reinstall it if we consider it practical.

> Let's require that the TLDs actually begin with a dot.  (That is, I
> think that ".foo.onion" can include "bar.foo.onion", but I don't like
> the idea of "foo.onion" including "barfoo.onion".)
>

Makes sense.

>
> Section 2.3.1:
>
> Does the algorithm apply recursively?  That is, can more then one
> plugin rewrite the same address, or can one plugin rewrite its own
> output?
>
> (I would suggest "no".)
>

Agreed no. We should specify it.

> I think there should be a way for a plugin to say "This address
> definitely does not exist" and stop resolution.  Otherwise no plugin
> can be authoritative over a TLD.
>

Agreed.

> Section 2.5.1:
>
> Is the algorithm allowed to produce non-onion addresses?  Should it be?
>

I'd say no. We should specify this. 

> Must query IDs be unique?  Over what scope must they be unique? Who
> enforces that?
>

I think the NS API client should enforce that, and maybe the server
should throw an error if it's not unique.

We should specify.

> May query IDs be negative?  Can they be arbitrarily large?
>

We should specify this too.

> I think result should indeed be optional on failure.
>
> Section 2.5.1 and 2.5.2:
>
> We should specify what exactly clients and plugins will do if they
> receive an unrecognized message, or a malformed message.
>

Agreed.

> Section 2.5.3.
>
> See security notes on caching below; client-side caching can lead to
> undesirable results.
>

Agreed.

> As noted above, I agree with requiring all result addresses to be .onion.
>
> Section 3.1:
>
> I prefer the "put everything under .onion" option.   I also think that
> we should require that the second-level domain be 10 characters or
> less, to avoid confusion with existing onion addresses.
>

We should think more about this, but seems reasonable.

>
>
> General questions:
>
> I know we've done stdout/stdin for communication before, but I wonder
> if we should consider how well it's worked for us.  The portability on
> Windows can be kind of hard.
>
> Two alternatives are TCP and named pipes.
>
> Another alternative might be just using the DNS protocol and asking
> for some kind of "ONION_CNAME" record.  (DNS is ugly, but at least
> it's nice and standard.)
>

Yup, I think this is an _important_ open part of the proposal that we
should figure out sooner than later. Ideally, we should consult Nathan
or mtigas or other members of our mobile team. I wish I had done this
during the dev meeting...

TCP seems like a plausible alternative here. Unfortunately, we will have
to invent a new protocol for that tho.

>
> Security notes:
>
> I'd like to know what the browser people think about the risks here of
> (eg) probing to see whether the user has certain extensions installed
> or names mapped.  Maybe .hosts.onion should only be allowed in the
> address bar, not in HREF attributes et al?
>

Yep, David F. also mentioned this problem. We should think of how to

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

[Ivan Tham]

Hi, I would like to do some addition as well.

Section 2.3. System configuration [TORRC]

- Do we really need a priority list?
- Should we just make a priority based on the ordering?

Section 2.3.1. Tor name resolution logic

- Should tor check the  based on regex?
- How should it reponds when  is .a.b?
- Can it accept '*' (without dot) or '.on*' as ?

And about the caching part? Should it be in the spec?

In reply to nickm:

- Maybe we can considering using sockets instead of TCP?
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev