Subject: Re: [DNSOP] More complete review of draft-grothoff-iesg-special-use-p2p-names-01

From: Christian Grothoff <[email-masked]>
Date: Wed, 01 Jan 2014 22:36:10 +0100

On 01/01/2014 12:44 AM, Andrew Sullivan wrote:
> On Tue, Dec 31, 2013 at 09:06:38PM +0100, Christian Grothoff wrote:
>>
>> What kind of metric do you propose, and how do you propose to acquire it?
> 
> From what you're saying about the different cases, it sounds like
> different metrics are going to be relevant.  For instance, it seems
> you could just count for .bit, but presumably the Tor examples could
> be worked out from rough estimates of the size of the Tor network.  

Yes, but to what end?

>> And again, a key question for me is, if you really want to _encourage_
>> people to _first_ deploy at large scale and _then_ reserve the name.
> 
> No, I don't.  What has happened here is, frankly, that the namespace
> was squatted on, and you're trying to normalize.  I think that's
> valuable and I want to support it.  But what would have been _better_
> is to have a discussion early when the names were being built into
> protocols.  How to do that is also a problem, but maybe if we can make
> it relatively painless in this case it will be more obvious that it
> could be less hard in future when it's needed.

Well, my point is that if you expect everybody to first get an RFC through
to document everything they are doing, expect squatting.

>> so a better question might be if there should be a process
>> to "unreserve" names should they fall into disuse.
> 
> How would you know?  If you can't count users of .gnu now (don't even
> know what "users" means, indeed), how would you know when it was safe?

Nobody working on maintaining the software and/or no user community
would be a strong indicator, and that's something one can find out
by looking / asking people.

>>> _Many_ of the references seem to be works in progress or unstable web
>>> pages.  That needs to be fixed for this document to be a useful
>>> specification.
>>
>> I was told that i2p2.de recently moved to geti2p.net.  Which other
>> pages are unstable in your experience? ("Worked for me...").
> 
> Oh, sorry.  I meant the other "stable": normally, we want the
> references in documents (and require the normative references) to be
> "stable references" in the sense that the target can't change.  So a
> URI isn't enough -- we need a permanent reference to a versioned
> document.  (This is the reason RFCs can't be changed once they're
> published.  They're an archival series.  If you want to "update" an
> RFC, you replace it with a new one.)

It is unclear to me how we even _could_ provide such a stable
document, especially for Namecoin and I2P where I don't even
see academic publications documenting the system on the horizon.
For Tor/GNS, we might be able to point to such references, but
of course then we have the problem that the protocols may still
evolve (there are ongoing discussions about changes to ".onion"),
so the "stable" links might then be outdated, whereas the links
we provided might remain current.

So even in the cases where "stable" links may exist, I'm
not convinced that only providing such "stable" links is
desirable.  But we could try to add additional references
to more stable design documents in cases where these
exist.

>>>     [â¦] Note that ".gnu"
>>>    names SHOULD follow the naming conventions of DNS.
>>>
>>> What does this mean exactly? 
>>
>>> Is this the LDH rule?
>>
>> Yes, in the sense of "SHOULD".
> 
> Ok.  This is probably the right interpretation of the STD 13
> "preferred syntax" (== LDH rule).  What STD 13 says, in effect, is
> that you can put anything in there, but things will tend to work
> better if you follow LDH.  (Note that RFC 1123 actually relaxed the
> rule, because originally labels couldn't start with a number either.)
> 
> What is the reason for continuing this tradition in GNS?  (That's
> probably out of scope for this document and even this draft, but the
> LDH rule has been a PITA and it's one of the things that would be nice
> to ditch if we could.)

Just backwards-compatibility with applications.

>>> Is GNS subject to IDNA?
>>
>> Yes.
> 
> Wow.  Are you sure you want to buy that much pain?

Well, again it's about backwards-compatibility with applications.
Browsers give us IDNA, so we deal with that.

>>> Or are labels just bags
>>> of octets?  
>>
>> No.
> 
> Why not?  If the LDH rule is only SHOULD, then what do you do with
> octets outside that range?  

Here's the short answer:

if (IDNA_SUCCESS !=
    idna_to_ascii_8z (label, &output, IDNA_ALLOW_UNASSIGNED))
   disallow();

Everything else goes.

>>> Are they only 63 octets each, with a maximum 255 limit?
>>
>> Yes, in the sense of "SHOULD". However, if the DNS protocol is not
>> used ("pure" GNS resolution with GNS-enabled applications where
>> a DNS packet is never created) is is theoretically permitted for
>> an application to not enforce these constraints.
> 
> This advice is worth what you're paying for it :) but I think that's
> going to hurt you in the long run.  You're going to get
> interoperability problems between people who actually enforce 63/255
> and people who don't.  Again, out of scope for this.

Well, right now our code enforces the 255 limit on everything, but
I wanted to leave a loophole in case that limit ever becomes a
problem in the future, for example if we ever need to resist
quantum cryptography and need much longer public keys.

>>  Also, yes, in theory appending
>> "f97f3b153fed6604230cd497a3d1e9815b007637.exit"
>> even once can cause one to run over the 255 limit on DNS names,
>> in which case the answer is "tough luck, won't work".
> 
> Ok.  It would be good to note that.
> 
> For the whole issue, then, I'd suggest something along these lines:
> 
>     Because every name ending in .exit is at least possibly a valid
>     hostname in itself, it should be noted that it is theoretically
>     possible for those names to be picked up and used in the construction
>     of .exit names again.  There is no reason to do this, but it is
>     possible.  In constructing such a name, it is possible to exceed
>     the total length limit for DNS names.  Such names may fail or
>     behave unpredictably when used with DNS resolvers.

Fine with me.

>> Well, if I had a 4,000-entry /etc/hosts file shared with tens of
>> thousands of other users, I think I would also try to put all of
>> those entries under some special TLD to ensure everyone knew that
>> I was using names from that list, as opposed to ordinary DNS names
> 
> Why?  My employer runs dyndns.org, among other names.  We have way
> more than 4,000 names under there.  Why wouldn't that work just as
> well in this case?

Well, you're running a DNS operation doing this, whereas these
are names that should not escape to DNS and users are supposed
to be aware that using those names gives them additional privacy.
Adding some DNS name as the suffix suggests to users that they're
using the "traditional" Internet, and here it is important to
make it clear that they are not.  And as it is not just a few
names, just using the label also is not nice, hence "label.i2p".

>> Well, I always thought of Namecoin and bitcoin as money-burning
>> activities, but feel free to invest in Namecoin then ;-). 
> 
> Snort.  I didn't say it'd make money _for me_!

Given that the code is GPL, why do you then allude to the fact
that it might make lots of money for someone else?  My point was
that if you really believe it to be that profitable, you should
make it work for you. If you believe that there is not much money
to be made, then suggesting that the users should pay 150k for
using some GPL'ed P2P software makes little sense.

>> I agree with you that the _technical_ reasons for a TLD are likely
>> the weakest for Namecoin, and I suspect the marketing/usability
>> concerns were the dominating reason.  But again, we're documenting
>> how it was deployed.
> 
> Yes.  But this is one of those joints between mere protocol and
> policy, because some time ago ICANN became responsible for the policy
> of root zone operation.  (The analogy with Apple is a good one -- the
> deployment of .local was, frankly, a similar case of
> namespace-squatting.)  Nobody cared about this before ICANN adopted an
> in-principle indefinite expansion of the root zone, but now we have a
> problem.
> 
> Getting evidence of the number of actual use (however we work that
> out) will go a long way in the argument, though.  On the other hand,
> suppose the registration doesn't happen.  The reason that .local (or,
> probably more directly comparable in this case, .corp) should possibly
> be on the special-use registration list is because we know that there
> are services using those names and that there will be security and
> user-confusion side effects if those names are also registered in the
> DNS name.  Similar arguments for this case wouldn't hurt.

Well, that is obviously the main argument for RFC 6761, and merely
by referencing that document this should be clear. But, as I think
you already suggested, we can stress that point more in the abstract.

>>> ajs@[gnu.org.f97f3b153fed6604230cd497a3d1e9815b007637.exit]?  I bet
>>> not.  It's simply not true that names and numbers can everywhere be
>>> used interchangeably.
>>
>> I don't quite see why this would not work in principle, assuming your
>> mail client is configured to route SMTP over Tor and the specified
>> exit supports exiting on port 25 to gnu.org.
> 
> Because the [ ] notation signals that what's in there is an IP
> address, not a name.

Ah, got it. We'll change the wording to try to address this.

>> I guess the question is what you define as "DNS resolver".  For example,
>> is the "dns2gns" proxy --- which speaks DNS (to applications) and then
>> forwards
>> ".gnu" and ".zkey" to GNS and everything else to DNS --- a "DNS resolver"?
> 
> Only partly.  This is similar to the confusion we had about recursive
> resolvers and caching name servers.  In the DNSSEC documents, you can
> see discussion about "the resovler side of a recursive name server"
> and "the name server side of a recursive name server" (or something
> similar).  Your example is of a general-purpose resolver system that
> does both DNS and GNS.  For the purposes of protocol, then, you have
> something like (ASCII art, sorry):
> 
>     resolver ---->  DNS ---->  DNS resolver ---> DNS
>      |----->  GNS --->  GNS resolver ---> GNS
> 
> For the purposes of implementation, these may well all be the same
> code.  But for the purposes of the protocol, we need to distinguish
> them.

Agreed.  We should probably add your ASCII art and adopt this kind
of terminology to clarify resolver vs. DNS resolver vs. GNS resolver.

>> I think you're mis-reading the point here, as the Namecoin block chain
>> is not obtained using the usual DNS protocol from some authority. So
>> DNS server operators that wanted to do this would NOT go out to some
>> IP address of a TLD operator that was granted ".bit" operation from
>> ICANN to fetch the block chain; instead, they'd have to participate
>> in the Namecoin network to observe block chain updates (a rather
>> daunting process, so this "MAY" is one that I personally don't expect
>> to see happening anytime soon by any major ISP).
> 
> This is an even worse idea.  What you're suggesting there is that
> recursive name server operators should add the .bit name to the
> answers they give out; but they don't get that answer from the DNS.

I think we wrote this as "MAY", not "SHOULD".  The point was that
if you do this, you still don't break user expectations --- they
get the value they (presumably) wanted.  However, you're right that
this turns the "recursive DNS resolver" into a "recursive resolver".
I'm not exactly sure why you think this would be so terrible, but
I'm happy to debate this issue (I don't even have a particularly
strong opinion).

> Quite apart from what happens in the presence of DNSSEC (I think it's
> "fails completely"), I think it is in general bad advice to tell
> people to populate their DNS caches with data from outside the DNS.

Well, it'd be a "resolver cache", not a "DNS cache" at this point ;-).

>> I expect them to be handed around by end-users and within applications.
>> I do not expect them to be handed around within UDP packets on port 53
>> (with the exception of ".bit").
> 
> But they will be:
>
>> I expect that this MAY happen, but if the draft is accepted, one
>> of our goals is to explicitly authorize DNS operators to prevent
>> this.
> 
> You can't "prevent it".  You can just have them swallowed somewhere
> else in the DNS system.  They _will_ get passed around on port 53.
> Therefore,

Well, I mean that DNS operators can "prevent it" in some cases,
but of course not categorically.

>>> "resolved or did not".  But perhaps what you are saying is that these
>>> ought to be added to the list in RFC 6303, and that they should always
>>> answer NXDOMAIN?  I could certainly live with that.
>>
>> Yes, exactly.  The formulation did end up a bit unclear and should
>> be fixed.  Our intention was exactly to allow servers to immediately
>> return NXDOMAIN without going to the root.
> 
> what I'd do is take a page out of RFC 6303, or follow the text in
> question 4 in the RFC 6761 discussion of .test:
> 
>    4.  Caching DNS servers SHOULD recognize test names as special and
>        SHOULD NOT, by default, attempt to look up NS records for them,
>        or otherwise query authoritative DNS servers in an attempt to
>        resolve test names.  Instead, caching DNS servers SHOULD, by
>        default, generate immediate negative responses for all such
>        queries. [â¦]

Yep, that's fine.

>> Again, thanks for your comments, we'll try to address those in the
>> next iteration, many of these were really helpful.
> 
> Glad to be of help.  
> 
> Best regards (and happy 2014),

Happy 2014 to you, too.

---

From: "Guangqing Deng" <[email-masked]>
Date: Thu, 2 Jan 2014 14:46:19 +0800

comments in-line.

Guangqing Deng
CNNIC 

From: Joe Abley
Date: 2014-01-01 06:41
To: Christian Grothoff
CC: hellekin; IETF DNSOP WG; wachs; jacob; Andrew Sullivan
Subject: Re: [DNSOP] More complete review of draft-grothoff-iesg-special-use-p2p-names-01

>On 2013-12-31, at 15:06, Christian Grothoff <[email-masked]> wrote:

>You can reserve a name for $10/year, no IETF process required. Less if you reserve under an existing domain name.

>The key question for me is, why do any of these uses necessarily require reservation of a TLD label, or something that looks like one?

>If (to take an example at random) Tor users could make use of names outside of the DNS that look like DNS names under a .ONION TLD, why could they not just as easily make use of >names that end in ONION.EFF.ORG?

Another factor may be the resolution delay, if real-time is really very important for those so called P2P applications. Usually in the hierachical  DNS system, the resolution delay of domain names like EXAMPLE.ONION is less than that of those like EXAMPLE.ONION.EFF.ORG. So maybe we should consider more about does the TLD (like .ONION) is really needed? 

>The general answer to this question (in the DNS world) is that names will appear in television ads and billboard posters, and hence need to be short and memorable. I'm not sure how >convincing that answer is (time will tell, I guess) but it seems less convincing for naming schemes that involve easily-typo'd, long hexadecimal strings as interior labels. These are >presumably not intended for direct entry by users. Where is the need for a pithy TLD?

>If the answer is "well, it wasn't done that way, and there's a huge deployed base" then I would take the time to consider migration strategies away from schemes that seem to involve top->level DNS labels towards schemes that don't. It's inevitable that these names will leak to the DNS, and those leaks will be easier to mitigate the further the names are from the DNS root.

>> this.  Right now, a well-configured, 100% RFC-compliant DNS resolver
>> MUST pass a request for ".onion" to the root.  With this draft, we
>> want to explicitly ALLOW 100% RFC-compliant DNS resolvers to instead
>> immediately return NXDOMAIN and thus avoid the security and performance
>> implications of leaking such queries to the root.

>The IETF is not the resolver police. Resolver operators mitigate weird problems with approaches like this all the time. It's a mistake to imagine that a blessing enshrined in a document >published by the IETF will immediately trigger changes in deployed infrastructure, or that deployed infrastructure is being hamstrung by the lack of such a blessing.

>Consider, however, the different degrees of chaos that might result from:

>(a) instruct all the resolver operators in the world to maintain configuration that special-cases a growing list of DNS names. or

>(b) chose your naming scheme (again, think ONION.EFF.ORG) such that the NXDOMAINs, negative caching, sinkholing, whatever can be controlled by someone who cares about Tor (the >EFF.ORG administrator) without requiring any special handling elsewhere.

>Option (b) is much more friendly to the Internet.

>Joe

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 2 Jan 2014 06:41:46 -0500

> to document everything they are doing, expect squatting.

As I suggested at the start of this thread, that's actually a
different question, and one the IETF needs to engage broadly.  I am
not sure what to think.

On the one hand, I agree with you that there is the practical fact:
people might just do this.

On the other hand, the reason people historically felt this was ok was
because the root zone was (as zones go) small and stable.  That is, if
you stepped on a namespace at the top level, you had reasons to
suppose you weren't getting in anyone's way and precedent to expect
that you wouldn't face many negative effects in the future.  In the
present régime, however, those assumptions are both false.  So this
might actually just be an education problem to the rest of the world:
"You used to think this was safe.  It never was, but it used to work.
In future, you should expect it to break."  

> by looking / asking people.

Which people?  We have learned (the hard way) on the Internet that any
assumption something will go away is extremely brittle.  In practice,
once you've started using a namespace, it's there for good (or at
least a very long time.  Just for instance, A6 records have long since
been deprecated, but one continues to see some queries).

> see academic publications documenting the system on the horizon.

That's going to be awkward, then.  It's kind of hard to justify the
allocation of a TLD by this special procedure if it's for some sort of
protocol that might never go anywhere and might not even use that TLD
in the long run.

> we provided might remain current.

That's an excellent way to document software systems but a poor way to
document specifications.  A specification document needs to say, "This
is what $x is for."  If the purpose of $x changes, you deprecate the
old and publish something new in order that someone else can come
along and code against whatever the spec is.  Should people coding
know about the changes that are happening while they're looking at the
"stale" spec?  Yes, certainly.  But at the very least, if one wants to
evaluate interoperability, it becomes necessary to point at something
stable.

Now, you might argue that this is a case of no interoperability.  But
that's not quite true: the specification is saying (for instance) that
an intermediate resolver SHOULD intercept these names and generate
RCODE=3.  That's a testable question of interoperation.  Could it
change?  Who knows?  We need a stable reference in order to know what
the behaviour is supposed to be at a given time.

I'm willing to help write stubby I-Ds, if need be, to document these
things.  They wouldn't need to describe everything about the various
systems, I think; just to describe the rules about the names in each
case.  I'll see if I can work up an example today or tomorrow and send
it off-list.

> names, just using the label also is not nice, hence "label.i2p".

I think this missed the point.  It could just as easily say
"label.i2p.invalid", for instance, which would guarantee that the
whole thing would already be covered by the .invalid rules.  The i2p
system would need to look for a name ending in "i2p.invalid", of
course, which is very slightly more work.  But once you're looking at
labels, peeling one off is nothing.

Now, I suppose some applications would check for names under .invalid
and stop immediately, knowing they're not allowed to be looked up.
For that reason, we might want to create a special space in (say)
.arpa for this.  Call it localdef.arpa.  Inside localdef.arpa is a
completely locally-defined namespace, and applications would be free
to do whatever they wanted there.  Then you could have
i2p.localdef.arpa.  Applications that don't know about localdef.arpa
still won't block because .arpa is a perfectly good domain.
Applications that do will know to strip off localdef.arpa and do stuff
according to their magic label.  This is _still_ not using the DNS.
It's just living comfortably inside the DNS namespace, which is not
what setting up random TLDs does.

> that it might make lots of money for someone else? 

It seems pretty clear that most of the alternative-currency systems
tend to attract speculators at the beginning.  I note that namecoin
attempts to blunt this compared to bitcoin, but new currencies are
_always_ the domain of speculators at the beginning.  To someone
interested in the new-TLD business (and I assure you that neither my
employer nor I are), that could look like someone trying to make money
without "paying their dues".

I don't know how far I buy this argument; I'm just trying to point out
the collision here between the IETF allocation procedure and the
regular TLD allocation procedure at ICANN.  (I freely admit that the
problem is caused at least partly by the somewhat dubious "cost
recovery" amount of US$185,000.  If I were boss of the world, there'd
be a lot of things I'd change.  You may imagine that ICANN's rules
would not make my first pass :-). )

> I'm happy to debate this issue (I don't even have a particularly

Unfortunately, many people have had the bright idea of injecting
things into "the recursive server" in order to "satisfy user
expectations".  This causes a number of (widely-documented) problems,
and in any case relies on a faulty picture of the real data paths for
DNS data.  It's true that the model is mostly ok for >90% of all
traffic, but the problems show up in the minority.  Even a very small
minority of problems turns into a major headache for help desks --
usually not the help desk of whever had the bright idea.  So, the IETF
cannot responsibly suggest yet another class of positive answer be
added to these intermediate resolvers.  NXDOMAIN seems to be harmless.
Everything else seems to cause trouble.

> Well, it'd be a "resolver cache", not a "DNS cache" at this point ;-).

So what happens when that resolver gets a query from an end system
that is doing its own validation?  What if the CD bit is set on that
query?  Now, what if different applications on the same end system
have different resolver libraries, and one is asking for DNSSEC and
the other isn't?  Won't that be kinda confusing?  All this would need
to be spelled out in detail for an intermediate multimode resolver
that might synthesize DNS responses.  Yes, these are corner cases.
Those furry blobs you see in the corners of the DNS are not dust
bunnies.  They're monsters, and they bite.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Jan 2014 12:00:14 -0800

> to document everything they are doing, expect squatting.

We do. And squatters should expect that the name that they are using might eventually be legitimately assigned later, possibly to someone whose intentions are quite different from the squatters. This is how the IETF has worked for over 20 years. The purpose of RFC 6761 is not to say "if you start squatting on a TLD, you will be able to later get it reserved". It is to say "if there are legitimate errors in TLD use, those can be dealt with".

It seems that one of the themes of your responses here is "the TLDs are now being used in software and we won't change that software ever". If that is a correct reading, then there really isn't any reason to move forwards on these requests. The folks using the names are squatting, and will continue to do so regardless of the outcome of the application, much less the outcome of ICANN later allocating those TLDs to someone else.

On the other hand, if the software using the currently-squatted TLDs are willing to change the names, there is room for discussion. One possibility for RFC 6761 is that an application can specify a use for a non-allocated TLD, and a random string (short, typeable, but unlikely to be wanted by anyone in the ICANN space) can be generated for that. So, instead of ".bit" (which has high value), ".gp4x7" could be allocated. That gets the community what they want (a string that ICANN is prevented from later allocating) and follows the spirit of RFC 6761.

--Paul Hoffman

---

From: Christian Grothoff <[email-masked]>
Date: Thu, 02 Jan 2014 22:30:04 +0100

On 01/02/2014 09:00 PM, Paul Hoffman wrote:
>> Well, my point is that if you expect everybody to first get an RFC
>>  through to document everything they are doing, expect squatting.
> 
> We do. And squatters should expect that the name that they are using
>  might eventually be legitimately assigned later, possibly to someone
>  whose intentions are quite different from the squatters. This is how
>  the IETF has worked for over 20 years. The purpose of RFC 6761 is
> not to say "if you start squatting on a TLD, you will be able to
> later get it reserved". It is to say "if there are legitimate errors
> in TLD use, those can be dealt with".

Well, let's just say my reading of the intent of RFC 6761 is different.

> It seems that one of the themes of your responses here is "the TLDs 
> are now being used in software and we won't change that software 
> ever".

You need to learn about about free software here, as you're assuming
that anyone really is in a position to say that. These are GPL projects,
thus anyone can change that software in any way they feel like.  I'm
merely suggesting that my personal opinion is that such a patch is
unlikely to be widely adopted. You're welcome to prove me wrong, writing
the patch should be hardly any work, after all.

> If that is a correct reading, then there really isn't any reason to 
> move forwards on these requests. The folks using the names are 
> squatting, and will continue to do so regardless of the outcome of 
> the application, much less the outcome of ICANN later allocating 
> those TLDs to someone else.

Didn't Apple squat on ".local" and get it reserved using RFC 6761? I
think you're are in total denial of facts that have been discussed in
this context on this very list already.

> On the other hand, if the software using the currently-squatted TLDs
>  are willing to change the names, there is room for discussion. One 
> possibility for RFC 6761 is that an application can specify a use for
> a non-allocated TLD, and a random string (short, typeable, but 
> unlikely to be wanted by anyone in the ICANN space) can be generated
>  for that. So, instead of ".bit" (which has high value), ".gp4x7" 
> could be allocated. That gets the community what they want (a string
>  that ICANN is prevented from later allocating) and follows the
> spirit of RFC 6761.

Sorry, Hollywood-math about the 'value' of a name has also already been
discussed.  However, I'm willing to agree that ".bit" has value to
society --- because it is already used by Namecoin. A name that is not
even used has no established value.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 2 Jan 2014 17:18:24 -0500

On Thu, Jan 02, 2014 at 10:30:04PM +0100, Christian Grothoff wrote:
> Didn't Apple squat on ".local" and get it reserved using RFC 6761? 

Not exactly, no.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Joe Abley <[email-masked]>
Date: Thu, 2 Jan 2014 18:01:54 -0500

Hi there,

On 2014-01-02, at 01:46, Guangqing Deng <[email-masked]> wrote:

>> If (to take an example at random) Tor users could make use of names outside of the DNS that look like DNS names under a .ONION TLD, why could they not just as easily make use of names that end in ONION.EFF.ORG?
>  

Well, that's what local caches and long TTLs are for. But in this case, any query of this kind that hits the real DNS is by definition junk (it's a query for a name from a non-DNS namespace that has leaked into the DNS) so I can't imagine what performance difference this could possibly make.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Jan 2014 15:02:00 -0800

> Well, let's just say my reading of the intent of RFC 6761 is different.

I'm interested to hear what others think.

> that anyone really is in a position to say that.

I didn't say you were in a position to say that; I said that it sounded like you were saying you were.

> These are GPL projects,

Quite true, but irrelevant to your request for the names.

No.

> I

Or, we simply disagree about what happened.

> even used has no established value.

And we disagree here as well, but at least it is now more clear what you are thinking in your application.

--Paul Hoffman

---

From: Suzanne Woolf <[email-masked]>
Date: Sun, 5 Jan 2014 11:39:47 -0500

Hi,

(chair hat on, not sure it fits right quite yet….)

Thanks Andrew for the thorough review on this draft, and everyone for substantive followups.

To put the topic of this draft, and "special names" generally, into some context: 

The "special names" registry is established in RFC 6761, which specifies "standards action or IESG approval" as the threshold for adding names. It also specifies in some detail what an RFC justifying such registrations needs to cover. (Section 4, 'If it is determined that special handling of a name is required in order to implement some desired new functionality, then an IETF "Standards Action" or "IESG Approval" specification [RFC5226] MUST be published describing the new functionality.' See also the registry at http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml).

Accordingly, the outcome of a discussion of this draft, or any special names request, in DNSOP should be any advice or insight we have as DNS experts for the IESG. 
The WG has no specific role in the process except as we can help the IESG decide whether to approve this set of additions to the registry.

Ted Lemon has participated here in earlier discussion of this draft, and I hope other IESG members will also feel free to step in and speak for themselves on their concerns. But earlier discussion, here and elsewhere, suggests that the most helpful input would be along a couple of lines:

1. The primary concern is on the specifics of whether this draft complies with RFC 6761 adequately to allow DNS implementors and operators to treat the proposed names consistently and interoperably, without unacceptable side effects. 

2. It may also be useful to consider any concerns on the scalability or architectural implications of special names: Andrew's comments in his review on the "deep and extremely confusing path of mixing the domain name system and other namespaces," the possibility that such requests will not remain rare events, etc. This goes to the question of how high the barrier to approval for new special names should be, as the p2p draft is the first invocation of RFC 6761 since its publication and seems likely to be taken as precedent.

best,
Suzanne

Re:
On Dec 30, 2013, at 7:04 PM, Andrew Sullivan <[email-masked]> wrote:

> Dear colleagues,
> 
> I made some remarks in the earlier discussion of
> draft-grothoff-iesg-special-use-p2p-names-00.  In this message, I
> attempt to review draft-grothoff-iesg-special-use-p2p-names-01
> completely.  I hope these remarks are useful.
> 
> Overall
> =======
> 
> I remain extremely concerned that this effort represents another step
> along a deep and extremely confusing path of mixing the domain name
> system and other name spaces.  I think the IETF needs to figure out
> whether we're going to accept that, historically, we had multiple name
> spaces but that now we're going to have one big one; or whether we're
> going to continue pretending that every other name space doesn't end
> up wandering into the DNS anyway.  (If there are additional
> alternatives, I am unable to think of them.)  I think a pragmatic
> answer is to accept that, given the number of places we expose domain
> name slots, anything that uses a name is going to end up having to be
> somehow compatible with domain name slots.  But I think that is a
> wide-ranging discussion that almost certainly needs to be tackled
> #separately from the consideration of this particular draft.
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 6 Jan 2014 09:39:32 +0100

On Wed, Jan 01, 2014 at 10:36:10PM +0100,
 Christian Grothoff <[email-masked]> wrote 
 a message of 245 lines which said:

> document, especially for Namecoin and I2P where I don't even see
> academic publications documenting the system on the horizon.

Also, the request from Andrew Sullivan to have "stable" references is
reasonable (it would be better to have "stable" references) but it is
a "nice to have", it is not mandatory in IETF processes here (RFC
6761, section 4 does not require it, nor any general RFC or IETF
process document does, for instance RFC 2223 - or its never-approved
successor - does not mention that requirment).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 6 Jan 2014 09:46:26 +0100

On Thu, Jan 02, 2014 at 12:00:14PM -0800,
 Paul Hoffman <[email-masked]> wrote 
 a message of 16 lines which said:

> And squatters should expect that the name that they are using might
> eventually be legitimately assigned later, possibly to someone whose
> intentions are quite different from the squatters.

Come on, that's completely unrealistic. Can you imagine ICANN
delegating .local to any one, after it has been used massively by
Apple Bonjour, even before RFC 6761 sanctioned it? Can you imagine
ICANN delegating .onion to someone, giving the number of collisions it
would generate? ICANN did many stupid things but this one seems very
unlikely.

> The purpose of RFC 6761 is not to say "if you start squatting on a
> TLD, you will be able to later get it reserved".

But it is exactly what happened with the first actual use of RFC 6761,
.local.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 6 Jan 2014 09:47:04 +0100

On Thu, Jan 02, 2014 at 05:18:24PM -0500,
 Andrew Sullivan <[email-masked]> wrote 

> > Didn't Apple squat on ".local" and get it reserved using RFC 6761? 

Yes, Apple did so. Exactly.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 6 Jan 2014 09:52:35 +0100

On Tue, Dec 31, 2013 at 05:41:13PM -0500,
 Joe Abley <[email-masked]> wrote 
 a message of 106 lines which said:

> The key question for me is, why do any of these uses necessarily
> require reservation of a TLD label, or something that looks like
> one?

"require" is a strong word. But there are many reasons why a TLD is
better:

* shortness and memorability, that you already mentioned in your message

* dependency. For systems that are intented to allow independance from
organisations like the US governement, using a domain name which is
under a TLD controlled by the US rules may be a problem. Let's assume
Tor people are ready to switch from .onion to .onion.eff.org. For
normal Tor requests (which stay outside of the DNS protocol), it is
not a problem. Now, for leaked requests, something that will certainly
happen, .onion.eff.org depends on two more actors, besides the root,
and that may be seen as contradictory with the political goal of Tor
services.

> (b) chose your naming scheme (again, think ONION.EFF.ORG) such that the NXDOMAINs, negative caching, sinkholing, whatever can be controlled by someone who cares about Tor (the EFF.ORG administrator) without requiring any special handling elsewhere.
> 

But the ship already sailed: RFC 6761 choosed a)

---

From: Paul Wouters <[email-masked]>
Date: Mon, 6 Jan 2014 10:01:06 -0500 (EST)

> would generate? ICANN did many stupid things but this one seems very

I'll believe this when .mail won't get delegated......

Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 6 Jan 2014 10:43:15 -0500

On Mon, Jan 06, 2014 at 09:39:32AM +0100, Stephane Bortzmeyer wrote:
> 6761, section 4 does not require it

I think I disagree.  6761 section 4 says 

   If it is determined that special handling of a name is required in
   order to implement some desired new functionality,

We need some way to make that determination, or else there's no reason
to allocate the labels.  In order to make such a determination, we'd
need either a stable reference or else details in the draft that wants
to allocate the new label.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Jan 2014 07:47:07 -0800

On Jan 6, 2014, at 12:46 AM, Stephane Bortzmeyer <[email-masked]> wrote:

> Apple Bonjour, even before RFC 6761 sanctioned it?

No, because of the significant technical discussion of .local that happened in the IETF for many years before the new gTLD round. However...

> Can you imagine
> would generate?

Yes, definitely. ICANN acknowledges that many of the new TLDs that are being added right now have collisions.

> ICANN did many stupid things but this one seems very
> unlikely.

We disagree (about the latter part).

> But it is exactly what happened with the first actual use of RFC 6761,

If you think that a name that was squatted, extremely widely deployed, and heavily discussed in the IETF is equivalent to a name that was squatted, barely deployed, and not even specified in an RFC, that's fine. Others might disagree for somewhat obvious reasons.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 6 Jan 2014 10:49:00 -0500

> Yes, Apple did so. Exactly.

It may be true that RFC 6761 was in effect created in order to
regularlize the .local use, but my claim is that the .local use was
more akin to the current issues with .corp and .home than like these
cases, where penetration is quite a bit smaller.  (I realise that
.onion is important to Tor, but I am sceptical that Tor has the
Internet penetration that Bonjour did long before 6761 was published.
Certainly Namecoin use is insignificant compared to what Bonjour was.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 6 Jan 2014 17:09:12 +0100

On Mon, Jan 06, 2014 at 10:49:00AM -0500,
 Andrew Sullivan <[email-masked]> wrote 
 a message of 21 lines which said:

> (I realise that .onion is important to Tor, but I am sceptical that
> Tor has the Internet penetration that Bonjour did long before 6761
> was published.

Based on a completely unscientific guess, I don't think so. You've
never done shopping on Silk Road? :-)

But I disagree with the method of adding requirments which were not in
RFC 6761 (which does not talk about the size of the installed base).

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Jan 2014 08:53:00 -0800

> RFC 6761 (which does not talk about the size of the installed base).

It sounds like you're saying that if I create a protocol that is supposed to be only run on LANs that uses a TLD such as .stephane, I should be able to get an RFC 6761 allocation, regardless of how little it is deployed. If so, I disagree strongly. If not (and I hope not), *you* need to talk about size of the installed base.

--Paul Hoffman

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Jan 2014 13:48:04 -0500

On Jan 6, 2014, at 10:49 AM, Andrew Sullivan <[email-masked]> wrote:
> I realise that

It seems to me that TOR is a pretty vital application, even if it's not as popular as .local (which, let's be honest, is almost never seen, much less typed, by an end user).   I am deeply skeptical of the idea that the only relevant factor here is how widespread the squatting is on a particular top-level special-use domain.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 6 Jan 2014 15:54:17 -0500

On Mon, Jan 06, 2014 at 01:48:04PM -0500, Ted Lemon wrote:
> It seems to me that TOR is a pretty vital application, even if it's
> not as popular as .local (which, let's be honest, is almost never
> seen, much less typed, by an end user). 

   Addresses in ".onion" are opaque, non-mnemonic, alpha-semi-numeric
   hashes corresponding to an 80-bit truncated SHA1 hash over a given
   Tor hidden service's public key. 

I'm pretty sure things in .onion are never supposed to be seen, much
less typed, by an end user too.

> I am deeply skeptical of
> the idea that the only relevant factor here is how widespread the
> squatting is on a particular top-level special-use domain.

I have never suggested that's the only relevant factor.  But I have
suggested that the argument, "This needs to be a TLD that steps on the
standard ICANN allocation mecahnism because it's already widely
deployed," needs some evidence of that wide deployment.  In the case
of .onion, for instance, it is very far from obvious to me that the
name needed to have been allocated directly beneath the root (as
opposed to, say, inside .arpa); but if Tor is already widely deployed,
the argument in favour of allocating that string in the root due to
practical side effects is made stronger.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 6 Jan 2014 12:56:53 -0800

> less typed, by an end user too.

You'd like to think that, but sorry no.  They are seen all the time:

If you don't already have it bookmarked, you are going to have to type in or cut and paste or the like http://silkroad6ownowfk.onion if you want to visit the current incarnation of the Silk Road in order to invest in your future prosecution...

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 6 Jan 2014 16:32:01 -0500

> You'd like to think that, but sorry no.  They are seen all the time:

No, that's different.  Now you're saying that sometimes people use
these for purposes other than what's documented, so they hand them
around.  If _that's_ the case, then on top of everything else the
documentation in this case is wrong, and therefore the argument for
the allocation is bad.

Look, I'm not opposed to these allocations in principle, but if we're
going to have two completely different ways of registering top level
domains and they're going to be responsible to two completely
different allocation bodies until the actual moment of registration
with IANA, then we are going to have to be _extremely careful_ with
how we do this.  It's true that .local was sort of a prior example,
but as Paul already pointed out there are quite significant
differences in the way that emerged.  Not the least of the differences
is that .local got going in an environment in which most of us were in
a position to assume the root zone was fairly small and fairly stable.
Those assumptions are now violated, and the plans for that violation
were announced a few years ago.  Conditions are different, and I think
it appropriate therefore to respond differently.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Jan 2014 09:26:25 +0100

On Mon, Jan 06, 2014 at 04:32:01PM -0500,
 Andrew Sullivan <[email-masked]> wrote 
 a message of 35 lines which said:

> Now you're saying that sometimes people use these for purposes other
> than what's documented,

I don't understand. Handing around .onion URLs is done all the time
and it's the normal use (specially important since you cannot use
Google on Tor hidden services). What is "not documented" here?