Subject: [DNSOP] More after onion? was Re: Some distinctions and a request

From: Edward Lewis <[email-masked]>
Date: Wed, 1 Jul 2015 12:26:43 +0000

On 7/1/15, 1:47, "DNSOP on behalf of str4d" <[email-masked] on
behalf of [email-masked]> wrote:
>.onion and .i2p (and to my knowledge, the other proposed P2P-Names
>TLDs too) have to conform to DNS rules in order to be usable in legacy
>applications that expect domain names.

I'd been told that "onion." was a one-time thing, that in the future
conflicts wouldn't happen.  What I read in the quoted message is that
"onion."'s request isn't a one-time thing but a sign of things to come.

I'm sympathetic to the use the path of least resistance - e.g., use names
that syntactically are DNS names - instead of building a separate
application base.  I expect innovation to be free-form and thus a stream
of unpredictable requests to reserve names for special purposes, including
DNS-like names.

What DNSOP can comment on is how the DNS "reacts" to names, whether in
protocol or operational convention, once they are known before they
achieve some degree of widespread adoption. To what extent is an effort
made (by whomever) to detect these budding namespaces, is this proactive?

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 1 Jul 2015 09:05:16 -0400

(no hats, for the moment)

Ed,

It seems to me that this is exactly the issue: we've already had multiple drafts requesting new entries in the special use names registry, and expect more. Your note sounds as if you're fairly sanguine about "a stream of unpredictable requests"; however, based on what we've seen so far, I admit I'm not.

I'm still re-immersing in DNSOP after being entirely absorbed in other work the last couple of weeks, but I want to support us continuing this discussion, because it seems to me that the point Andrew started the thread to make is valid: we don't have a coherent view of how the relevant namespaces (based on DNS protocol, compatible with DNS protocol but intended for different protocol use, or otherwise) interact. 

The painful immediate consequence is that we're trying to apply RFC 6761 and finding that it remains subjective to do so, with an element of "beauty contest" in the deliberations that means outcomes are unpredictable. There's no meaningful guidance we can give developers on what names it's "safe" for them to use in new protocols, or even for specific uses in-protocol, and as Andrew and others have pointed out, there may even be ambiguity about what our own registries mean in protocol or operational terms. 

Longer term, this lack of clarity has implications for both architecture and policy for the DNS, including our ability to support innovation and to coordinate with other groups in the IETF and beyond.

best,
Suzanne

On Jul 1, 2015, at 8:26 AM, Edward Lewis <[email-masked]> wrote:

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

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 1 Jul 2015 10:08:27 -0400

Ed,

First-- apologies for the misunderstanding.

On Jul 1, 2015, at 9:53 AM, Edward Lewis <[email-masked]> wrote:
> 
> Trying to be more clear, I have in the past imagined that today someone is
> inventing a new communications technology, in 6 months will need to cobble
> an identifier space and in 2 years the IETF-connected crowd detects
> significant deployment of this and needs to decide whether to register a
> TLD to avoid name collisions.  I've been told that this wouldn't happen
> because the IETF will have rules - which I am skeptical would "prevent"
> the situation from happening.

I don't think we have "rules" or even guidelines now that have any chance of preventing it. 

I agree we'll never prevent it completely; it's the nature of the DNS and the internet that people can do things with names and they don't have to ask the IETF first.

But I don't think it's impossible that we'll be able to provide guidance, such that developers who follow it are reasonably sure of avoiding the various types of collisions and ambiguities we're concerned about-- and such that there's a clear basis for saying "You're doing something outside of the guidance we can provide about how names work in the internet, you're on your own." 

> To underscore - I am not against the innovation.  I am urging that the
> processes put in place are future proof by being "reactionary" - reacting
> to the new names, not trying to fend off the situation.  I.e., in
> agreement with the words below "trying to apply RFC 6761 and finding that
> it remains subjective".

This supports the initial suggestion that we need to get serious about a 6761bis, am I correct?

thanks,
Suzanne

> 
> On 7/1/15, 9:05, "Suzanne Woolf" <[email-masked]> wrote:
> 
>> It seems to me that this is exactly the issue: we've already had multiple
>> drafts requesting new entries in the special use names registry, and
>> expect more. Your note sounds as if you're fairly sanguine about "a
>> stream of unpredictable requests"; however, based on what we've seen so
>> far, I admit I'm not.
>> 
>> I'm still re-immersing in DNSOP after being entirely absorbed in other
>> work the last couple of weeks, but I want to support us continuing this
>> discussion, because it seems to me that the point Andrew started the
>> thread to make is valid: we don't have a coherent view of how the
>> relevant namespaces (based on DNS protocol, compatible with DNS protocol
>> but intended for different protocol use, or otherwise) interact.
>> 
>> The painful immediate consequence is that we're trying to apply RFC 6761
>> and finding that it remains subjective to do so, with an element of
>> "beauty contest" in the deliberations that means outcomes are
>> unpredictable. There's no meaningful guidance we can give developers on
>> what names it's "safe" for them to use in new protocols, or even for
>> specific uses in-protocol, and as Andrew and others have pointed out,
>> there may even be ambiguity about what our own registries mean in
>> protocol or operational terms.
>> 
>> Longer term, this lack of clarity has implications for both architecture
>> and policy for the DNS, including our ability to support innovation and
>> to coordinate with other groups in the IETF and beyond.
>> 
>> 
>> best,
>> Suzanne
>> 
>>

---

From: Edward Lewis <[email-masked]>
Date: Wed, 1 Jul 2015 14:35:35 +0000

On 7/1/15, 10:08, "Suzanne Woolf" <[email-masked]> wrote:
>
>But I don't think it's impossible that we'll be able to provide guidance,
>such that developers who follow it are reasonably sure of avoiding the
>various types of collisions and ambiguities we're concerned about-- and
>such that there's a clear basis for saying "You're doing something
>outside of the guidance we can provide about how names work in the
>internet, you're on your own."

(struct IETF *) We can always provide guidance.  But processes cannot rely
on applicants (tacit or not) to either be aware of the guidance or, more
significantly, to heed it.  Prepare for the best, expect the worst.  (Or
that "conservative, liberal" bon mot.)  I certainly don't think it is
"right" to *expect* that everyone will heed the guidance, so we need to
build the process as if we didn't give the guidance in the first place.

>This supports the initial suggestion that we need to get serious about a

Yes.  I'm not satisfied with the process in RFC 6761.

---

From: "Joe Abley" <[email-masked]>
Date: Wed, 01 Jul 2015 11:28:28 -0400

> First-- apologies for the misunderstanding.

It seems appropriate for someone at this point to make a joke about 
onion leaving a bad taste in the mouth. But not me. I'm not that guy.

Joe

---

From: Warren Kumari <[email-masked]>
Date: Wed, 1 Jul 2015 14:23:15 -0400

> But I don't think it's impossible that we'll be able to provide guidance, such that developers who follow it are reasonably sure of avoiding the various types of collisions and ambiguities we're co…

<Warren points at ALT-TLD>

Yup, we will not be able to prevent people from using an identifier
space that looks like a DNS name not rooted in the DNS, but we *can*
provide them with guidance and a safe place to do this sort of thing,
namely under the .alt TLD.

> This supports the initial suggestion that we need to get serious about a 6761bis, am I correct?

I believe so, but instead of simply raising the bar to get a special
use name (which will simply result in people squatting more), I think
we need to provide solid, usable advice and an option for people...

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Richard Barnes <[email-masked]>
Date: Wed, 1 Jul 2015 14:26:42 -0400

> we need to provide solid, usable advice and an option for people...

+many to what Warren says.

We do our best work when we do engineering, not rule-making.  Let's
engineer a solution here that's more appealing than squatting.  For my
money, alt-TLD looks about right.

--Richard

---

From: Edward Lewis <[email-masked]>
Date: Wed, 1 Jul 2015 18:54:37 +0000

How does that help this:

>>>>>>On 7/1/15, 1:47, [email-masked] wrote:

Having a alt-TLD is fine.  But what if names are proposed, experimented
and deployed outside the sphere of influence of the IETF and/or working
group?  Writing this as someone who is unfamiliar with "other proposed
P2P-Names" efforts and whether they want to engage with "standards bodies"
before deploying.  I've gotten the impression that members of those
efforts dislike standards processes - I may be wrong but that's the
impression I've gotten from the discussion on this list.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 1 Jul 2015 15:05:38 -0400

> impression I've gotten from the discussion on this list.

The thing that got .onion to the IETF is that they needed to be
"official".  (So that they could get certificates for .onion names.)
Until they get an RFC 6761 registration, they're in a grey zone of
being neither officially DNS names nor officially not DNS names.

ISTM that the benefit of .alt is that it creates a
clearly-not-normal-DNS zone.  We would have to check with the CAs, but
I think that that would do a lot to prevent issues like what .onion
ran into.  My hope would be that that benefit would make it appealing
enough for at least some of these other pseudo-TLDs to tolerate the
switching cost.

--Richard

---

From: "John Levine" <[email-masked]>
Date: 1 Jul 2015 20:41:51 -0000

>money, alt-TLD looks about right.

I agree.  On the other hand, since we are not the tsars of the
Internet, it is fairly likely that no matter what we do, someone will
start using .ramp (a stronger version of .onion) rather than .ramp.alt
and it will become widely enough used that it makes technical sense to
keep it out of the DNS, like .onion and .home.

That would not be a disaster.  I don't even see it as a problem, so
long as we have a process to weigh the pros and cons and decide
whether to add it to the list of domain names that are excluded from
the DNS.  (It may cause gnashing of teeth at ICANN as it screws up
someone's business plan, which is definitely not our problem.)

I suppose that if we update RFC 6761 it would be polite to send a note
to ICANN reminding them that anyone who wants to add a new TLD to the
DNS should consider as one of the risks that it collides with a name
that is excluded for technical reasons, but I see no reason to go
farther than that.

R's,
John

---

From: Warren Kumari <[email-masked]>
Date: Wed, 1 Jul 2015 16:59:52 -0400

> enough for at least some of these other pseudo-TLDs to tolerate the

It also provides the ability for the IETF to push back more easily on
some applications.

Warning: The following is how this plays out in my mind. Many things
in here are a little odd, but, hey, it's my imagination, not yours...

Dramatis personae:
Applicant: A young, eager developer.
IETF (personification): Played by someone who looks like a cross
between Spencer Dawkins and Scott Bradner. For some reason speaks with
a strong Scottish accent...

Without .alt:
(Applicant enters stage left)
Applicant: I'd like .foo added to the SUN registry please. I've
developed a resolution service that maps from names of cartoon
characters to IP addresses, and is use by many many people. It meets
all the RFC6761 requirements....
IETF: You did a bad thing. You should not have simply squatted on a
label. Anyway, a namespace made up of cartoon character names is
silly...
Applicant: But this meets all of the 6761 requirements, and I've got
dozens of people using this. Anyway, I didn't really have an
alternative, did I? How is anyone supposed to innovate in the
namespace?!
IETF: Well, erm.... you should have... errrr... um... ideally you
would... err... Yeah, OK, we'll make .foo be a Special Use Name, but
don't do it again, OK?!
(Applicant skips off stage left, IETF plods off stage right, looking dejected)

With .alt:
(Applicant enters stage left)
Applicant: I'd like .foo added to the SUN registry please. I've
developed a resolution service that maps from names of cartoon
characters to IP addresses, and is use by many many people. It meets
all the RFC6761 requirements....
IETF: You did a bad thing. You should not have simply squatted on a
label; we have a defined process and location for this sort of thing,
it's called .alt  <IETF waves sheaf of papers> Anyway, cartoon
characters as a basis for a namespace? Really?
Applicant: But I didn't know about .alt... and I've got dozens of
users, dozens I tell you...<shakes fist>
IETF: Sorry, ignorantia legis neminem excusat.
Applicant: Fine....
(Applicant stomps off stage left in a bit of a huff, IETF looks
remarkably smug, then exits stage right to further examine navel)
[ Unfortunately the IETF ends up looking like a bit of an ass here,
but redeems itself later by doing something helpful for the community,
or, at least, entertaining... Hey, I did warn you that things in my
brain are often a little, um, surreal... ]

The IETF can still add things to the RFC6761 / RFC6761bis registries,
but at least has:
A: provided an alternative for people who /want/ to do the right thing and
B: more of a leg to stand on if we need to push back on nuisance
applications in the future.

W

---

From: Warren Kumari <[email-masked]>
Date: Wed, 1 Jul 2015 17:03:14 -0400

... and this was only intended to go to Richard and Ed, not waste the
entire WGs time with my bizarre imaginings...

W

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Jul 2015 21:42:58 -0400

Hi Ed,

On Wed, Jul 01, 2015 at 12:26:43PM +0000, Edward Lewis wrote:
> that syntactically are DNS names

I note that the Subject: line of your note still contains a vestigial
reference to the thread I started recently on this, and your message
nevertheless returns to collapsing "domain names" and "DNS names".

I don't know whether I've simply failed to explain the distinction I'm
trying to make, or whether you reject the premise.  Could you please
be clear about which it is?

To me, the _point_ of onion. is that it is not a DNS name.  You're
right that it has the same syntax -- because it is a domain name, but
not (intended to be) a DNS name.  The registration of the name in the
special use registry would achieve that end.

You might object that this distinction is extremely hard, because
there's nothing about the label itself to signal this namespace shift,
and unaware clients will therefore automatically just treat such names
as DNS names, not special-use domain names.

I happen to agree with that, but we cannot hold back this tide: it was
let loose once local. became an in-band protocol switch, without any
registration, in Apple's widely-deployed Bonjour service.  We might
wish that people hadn't abused the namespace to turn it into protocol
switches as well as everything else, but the history of SRV through
Bonjour shows that this technique is popular and unlikely to go away.
Commanding the tide to stay back when you are neck deep in water is
not likely to work.

Therefore, I claim, we need to make some clear distinctions and
understand what has actually happened, and then adjust to the new reality.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: str4d <[email-masked]>
Date: Wed, 1 Jul 2015 22:37:12 +0000 (UTC)

Edward Lewis wrote:
>> We do our best work when we do engineering, not rule-making.
>> Let's engineer a solution here that's more appealing than
>> squatting.  For my money, alt-TLD looks about right.
> 
> How does that help this:
> 
>>>>>>>> .onion and .i2p (and to my knowledge, the other
>>>>>>>> proposed P2P-Names TLDs too) have to conform to DNS
>>>>>>>> rules in order to be usable in legacy applications
>>>>>>>> that expect domain names.
> 
> Having a alt-TLD is fine.  But what if names are proposed,
> experimented and deployed outside the sphere of influence of the
> IETF and/or working group?  Writing this as someone who is
> unfamiliar with "other proposed P2P-Names" efforts and whether they
> want to engage with "standards bodies" before deploying.

I admit to being highly surprised that you are unfamiliar with the
P2P-Names draft[0], given that it pre-dates the later .onion-only
draft. To save you trawling through the archives, the P2P-Names draft
was proposed to bring the TLDs contained within onto the SUN registry
under RFC 6761. However, neither I2P nor Tor (I cannot speak for the
others) engaged with any standards body before deploying, because
(IMHO, I was not around at the time)

a) there was no clear indication that the floodgates would (or could)
be opened for TLDs, and therefore no obvious reason for concern, and
b) RFC 6761 did not exist at the time. I2P deployed .i2p in 2003[1],
and Tor deployed .onion in 2004[2]; RFC 6761 was published in 2013.

> I've gotten the impression that members of those efforts dislike
> standards processes - I may be wrong but that's the impression I've
> gotten from the discussion on this list.

I certainly don't dislike standards processes. What I _do_ dislike is
inconsistency and poor documentation/education. If DNSOP / IETF wants
to ensure that future applications root their name spaces in .alt or
wherever else instead of choosing a .TLD to add to the SUN registry,
then developers _need to know about it_. I personally agree with
Richard that .alt is far more appealing than the struggle to get a
.TLD added to the SUN registry, but the longer it took me to discover
.alt, the harder it would be to justify switching. (It's for this
reason that .i2p is as unlikely as .onion to be moved into .alt, with
well over a decade of use, and .alt not even in existence yet.)

Having it stated in an RFC is definitely better than the status quo,
but IMHO it would be much better to have an FAQ page that clearly
outlines the IETF's / working group's position, itself backed by
references to RFCs. Then use SEO to get it near the top of any related
search query. It wouldn't take much work, and the IETF's / working
group's sphere of influence would be far wider as a result. Developers
love bullet points :P

str4d

[0]
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-nam
es/
[1] https://geti2p.net/en/meetings/059
[2]
https://en.wikipedia.org/wiki/Tor_%28anonymity_network%29#cite_ref-or-lo
cating_85-0

---

From: Edward Lewis <[email-masked]>
Date: Thu, 2 Jul 2015 11:40:33 +0000

I hope you don't mind replying publicly to this, because I think you did a
very good thing describing it as a one-act play.  (Seriously.)  Kinda like
why we parody Harry Callahan at times.  (That's "Dirty Harry's" name for
those under the age of, oh 50.)

>(Applicant enters stage left)

But what if the applicant's name is Godot (and never appears on stage)?
[https://en.wikipedia.org/wiki/Waiting_for_Godot]

Let's say someone does this.  They squat on .foo.  They never engage the
IETF.

Traffic is seen for .foo.  A lot of DNS queries to 8.8.8.8 ask for foo.
names and data, I mean.

The operators of recursive servers have no idea what is generating the
ever-growing queries for foo. and so, like other annoying queries, begin
to filter them.

One day someone else wants to launch a .FOO TLD.

(Stay tuned for the sequel "Universal Acceptance")

The objective of a registry is to map object to entity for the sake of
(among a few services) uniqueness.  The latter part of that statement is
often forgotten.  The uniqueness is not just to protect the entity to
which the object is mapped, but to protect all others from running into
it.  Collisions are not always hi-jacks, where the collider wants to
tackle the object, sometime they are like tripping hazards where the
collider just didn't see it or have a chance to see it.

One red herring here is that there's a domain name market.   There is.  To
the IETF that should simply mean that the likelihood of collisions is
higher than it was without a market.  And yes, ICANN has processes for
dealing in that market.  But that's not important here.

There's one other factor in all of this, coming in out of the blue.  I
recall a talk at DNS-OAC in spring of 2013 where someone tracked down a
source of query traffic that could be categorized as "annoying."  After
much effort, the source was a music app using the DNS as a
"ping/keep-alive" service, meaning the app, which had not reason to use
DNS much, know that by repeatedly sending traffic it kept up tunnels, etc.
 The point is - the presenter went though a lot of trouble and only with
luck, identified the source.  This is part of the desire for a registry -
so we can figure out where and why traffic is coming into servers.

That talk - I just can't find it...I thought it would be here, but I don't
see it:
https://indico.dns-oarc.net/event/0/contributions

Or maybe I'm making it all up.

That's why I still think there's a need, even with an alt-TLD, for a
process to register special use names, special in a technical way.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 2 Jul 2015 13:05:37 +0000

On 7/1/15, 18:37, "DNSOP on behalf of str4d" <[email-masked] on
behalf of [email-masked]> wrote:

>draft.

I don't read everything, and I'm not usually focusing on this.  That's the
trouble with volunteers.

>(IMHO, I was not around at the time)

That's fair.  This is all volunteer.  (That is why it's up to the IETF to
define how to "react.")

>I certainly don't dislike standards processes.

Of course not - you are engaging with the process.

> What I _do_ dislike is inconsistency and poor documentation/education.

Then you've come to the wrong place. ;)

> If DNSOP / IETF wants

You're right.  To underscore, it's because of the groups that don't
engage, and have no responsibility to do so, that the IETF has to "defend"
itself.

>It wouldn't take much work

Keep in mind that the IETF isn't a "thing", it's a collection of people
volunteering time.  What I mean to say, not much work, but it's like
trying to jump out of the ocean back into a boat [kinda like this:
http://www.bbc.com/sport/0/american-football/30744474].

---

From: hellekin <[email-masked]>
Date: Thu, 02 Jul 2015 11:10:01 -0300

On 07/02/2015 10:05 AM, Edward Lewis wrote:
> 
> You're right.  To underscore, it's because of the groups that
> don't engage, and have no responsibility to do so, that the IETF
> has to "defend" itself.
> 
> Keep in mind that the IETF isn't a "thing", it's a collection
> of people volunteering time.  What I mean to say, not much work,
> but it's like trying to jump out of the ocean back into a boat.
>

I could not agree more with Str4d.  Processes are not at fault: aren't
we having a rough consensus about the Internet as an open society?

For your information, draft-grothoff-iesg-special-use-p2p-names-00 was
published on *November 14, 2013* [0]. It has been submitted to 4
revisions to date, without counting the newly split drafts at the
request of DNSOP list members into a draft per system (.bit [1], .exit
[2], GNS [3], and .i2p [4]).

As a final comment to help you catch up with "the process", the .alt
draft [5] first appeared on June 06, 2015, and the original mention of
.onion was removed from its fifth revision following my request to
confirm that .onion was not covered by this draft (per the draft
author.) I think you know this because your comments were also included
in this version of the .alt draft.

I am very surprised that you did not read the P2PNames draft, and hope
you will now read the 5 drafts that came from it (I include .onion [6]
to the 4 mentioned above).

Regards,

==
hk

P.S.: As Christian Grothoff mentioned, I was interested in making these
5 drafts leanier, following the .onion model, and bring the (common)
details into an informational RFC instead. If you think 5 drafts are too
much reading, that might help, especially as there's a lot of redundancy
from one to the next.

[0]:
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-nam
es/00/
[1]:
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-bit
/
[2]:
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-exi
t/
[3]:
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-gns
/
[4]:
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-i2p
/
[5]: https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/
[6]: https://datatracker.ietf.org/doc/draft-appelbaum-dnsop-onion-tld/