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