Re: [DNSOP] Fwd: Re: [[e-mail]: I-D Action: draft-grothoff-iesg-special-use-p2p-names-00.txt]

[Christian Grothoff <[e-mail]>]

On 12/01/2013 06:45 PM, Jacob Appelbaum wrote:
> FYI - if you can reply, it would be helpful, I am about to fly to Europe.

I'll try.

> -------- Original Message --------
> Subject: Re: [DNSOP] [[e-mail]: I-D Action:
> draft-grothoff-iesg-special-use-p2p-names-00.txt]
> Date: Sun, 1 Dec 2013 12:35:44 -0500 (EST)
> From: Paul Wouters <[e-mail]>
> To: Ted Lemon <[e-mail]>, Jake Appelbaum <[e-mail]>
> CC: Stephane Bortzmeyer <[e-mail]>, dnsop WG <[e-mail]>
> 
> On Sun, 1 Dec 2013, Ted Lemon wrote:
> 
>> On Dec 1, 2013, at 11:48 AM, Stephane Bortzmeyer <[e-mail]> wrote:
>>> For the record, I've reviewed
>>> draft-grothoff-iesg-special-use-p2p-names-00, I find it well-written
>>> and clear and I fully support it. Registering these names would be a
>>> very good idea.
>>
>> Why do you support it?   Why is registering these names a good idea?
> 
> I'm curious too. I'd rather see a generic method instead of an
> (incomplete?) list of domain names to reserve. Why wasn't .bofh on
> that list? 

Because I'm not aware of a P2P system implementing ".bofh", and if there
is one,
they don't seem to be interested in documenting this or working with us.
 Some
other developers did see our draft and reached out to us to be included, and
the list will thus be expanded by one more system for -1.  Aside from that,
if there are unrelated systems, they should probably write their own RFC, as
their requirements may differ.  Finally, there isn't a "generic" method, as
different pTLDs have different requirements.  ".local", ".test", ".arpa" and
".onion" don't all fit under one umbrella.  Also, I believe any attempt to
document "everything" that happens on the Internet is doomed to failure,
so the
best we can hope for is an "incomplete", but coherent set of documents that
document everything that may be important for users and operators.

> Why was .gnu on that list? What if GNU or someone else
> wishes to register .gnu as a new gTLD based on a trademark? Who
> are we to disallow that?

This was explicitly approved by GNU.  You're welcome to ask Richard
Stallman himself.  Dozens of other GNU maintainers and packages are
also involved to some degree.  So unless you're suggesting that the
GNU project should allow someone ELSE to have a trademark on "GNU",
I think this is not about you disallowing something, but you preventing
the GNU project from using ".gnu".

> This also seems similar to the USENET problem, where John Gilmore
> proposed/created the alt.* hierarchy.
>
> It would make more sense to me to reserve something like .alt where
> people can plugin onion.alt, gnu.alt, etc, and are guaranteed that
> the .alt domain will never actually be delegated by the root. That
> means new players who want some peer to peer, no DNS dependancy don't
> have to come back here to reserve _their_ names later on.

And who'll manage ".alt"?  Now we'll need another process for managing
assignment within ".alt", break compatibility for millions of users with
hundreds of thousands of domains and for what exactly?  I could equally
suggest that ICANN should just be given ".icann", and so it becomes
"www.google.com.icann".  After all, who put them in charge?

> And once you go that way, one can wonder why not use the already
> existing .local for that? Perhaps avoid talking to different protocol
> software is a good enough reason not to re-use .local.

There are plenty of reasons not to use ".local", starting with that the
names in our draft are non-local, or that the deployed software and
existing users don't use ".local".  Again, this is NOT a standardization
process, this is an _informational_ draft/RFC that documents what is
happening.  We'll continue to use ".onion", ".i2p", and ".gnu".  Users
do not need someone's blessing to do so, but from a technical point of
view it makes a lot of sense to document these pTLDs and give guidance
to operators. That's what we're trying to do with the RFC, we're not
really asking for "permission".

> But can an RFC even do anything here?  Whether you agree with ICANN
> procedures for new gTLDs or not, if I write some software that becomes
> popular using a .paul pseudo domain, when does it become valid for me
> to request it under RFC 6761?

I'd say yes, if you can justify that information about ".paul" is relavant
to the community.

> What precedent would tor/gnu/zkey/etc set?
> Does IETF even have any say in such matters? Isn't this up to IANA or
> ICANN? What about trademarks? What about lawsuits by Gnu Inc or Onion
> Corp who want their gTLD?

First of all, who'd they sue?  Tor users?  Tor developers?  IETF for
publishing an RFC?  I don't think there'd be ground for suing any of
those parties in this case.  However, more importantly, I think you're
not clear on trademark law.  Trademarks are awarded for a particular
domain and scope AND have to be consistently enforced.  So
unless you know of a global actor in the domain of networking that has
a trademark on GNU that would be recognized by courts and would immediately
sue about ".gnu" (leaving the question who they'd sue to begin with,
the GNU project? That'd be interesting), there's no case to begin with.
So please point me to your .onion inc or .i2p inc before making up some
straw man argument.

> Other questions I would have is why aren't these people using a
> different class from IN? They can have a class of TOR or ONION or GNU?

We considered this, but sadly there's no way to make that work with legacy
software.  I've not found any application that uses DNS today that'd
allow users to switch the class (does your browser or e-mail client allow
this?).  Please let us know how you propose to enable an alternative
name system that uses a different class to be integrated with the code
that is out there, I'm quite interested as I couldn't find a way to
make it work (and usable --- LD_PRELOAD to replace gethostbyname of libc
isn't quite a sane answer in my book).

> The traditional reasons for not using any non-IN class is that a lot
> of software would not work well with that, but in these cases, the
> consumers aren't actually interested in real DNS anyway, and using
> a URI that indicates a different class should not be too hard to plug
> into existing browsers? A specific tor:// URI plugin would make
> more sense to me that sticking with http://sdggjaksgdkgda.onion
> construct, especially as at least with tor right now, you are stuck
> with the SOCKS API anyway. If tor would be truly transparent and map
> to a real ip address handled at the kernel/socket level, then it would
> make even more sense to map tor://sdggjaksgdkgda.onion onto a new DNS
> class like: sdggjaksgdkgda.onion. IN ONION 1.2.3.4 (or perhaps even a
> non-A/AAAA identifier, like a straight public key if that's what the
> new socket family would take)

You're mistaken in that Tor is not _only_ used by browsers -- and
started of as a pure proxy without _any_ modifications to browsers.
The case is even stronger for GNS, where DNS queries can even be
intercepted at the network layer by a dedicated DNS2GNS gateway.

> So I think this draft has a lot of issues, technically and legally.

I'm not a lawyer, but I'm pretty sure your legal opinion is incorrect,
possibly because it is based on partial knowledge of the facts.

As for the technical side, I also don't quite buy your arguments, as
they excessively conflict with usability and seem to be purely based
on the idea that this would set a precedent that would then allow
anyone to "just" write a big system (Tor, GNUnet and I2P are all
projects with about 300,000 LOC) and an RFC and we'd end up with
ten billion special-use reserved pTLDs.   I find that's unlikely to
happen, but even if it did, great, I'd call that progress.


Happy hacking!

Christian