Subject: [DNSOP] Barry Leiba's Abstain on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Fri, 21 Aug 2015 11:37:07 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-dnsop-onion-tld-00: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I believe the IETF shouldn't be involved with registering special-use
TLDs for things that have been squatted on, and thus helping to
circumvent ICANN's normal process.  I know there are a bunch of other
such TLDs that people/organizations would have us snag for them, and I
very much want to avoid that nasty iceberg, of which this is the tip.

That said, I well understand the deployed code involved and the
importance of keeping things working in this case, and I don't want to
stand in the way.  So I'm standing aside with an "Abstain" ballot.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 21 Aug 2015 20:15:26 +0100

Hiya,

I'm pretty sure I'll be a yes ballot on this (after I re-read the
draft which I've not read for quite a while). And I don't expect
either of us to change our ballot, but that said, I hope you don't
mind explaining your ballot a little more since I'm not getting part
of your argument and that part could be relevant if/when other special
use name drafts are processed. (Or if/when someone tries to win the
race and first improve IETF handling of special-use names.)

On 21/08/15 19:37, Barry Leiba wrote:
> circumvent ICANN's normal process.  

The above confuses me.

Do ICANN have any process for allocating special-use names that will
not be used in the DNS? I am not aware of such but it may exist. I
am also not at all clear that I'd accept that ICANN ought be in that
particular business.

Note: I am not saying what I think of, not asking what you think of,
ICANNs new gTLD programme, but for the sake of this discussion, let's
assume that programme is "normal";-) But that process is surely not
one that could be used for special-use names that are required by
protocols that require not using those names in DNS queries.

Secondly, I don't get what you are saying you think about current IETF
consensus (i.e. RFC 6761). Are you saying that:

a) you don't agree with 6761? or
b) that 6761 is fine but only for not-yet-deployed special-use names?

If (a) I'm not sure that's our (IESG) role, and (b) seems highly
unlikely to be workable (if one assumes an I-D has to wend its way
through the process the special-use name will be deployed before IESG
evaluation). So maybe you mean something else?

> I know there are a bunch of other

That's why I'm asking my questions above - I do think there's more work
to be done here amounting to some combination of improving 6761 and
figuring out how to properly handle the other queued-up strings.

In passing I have to say that I don't agree there's been nasty snaggy
squatting on the tip of any iceberg, (sounds painful that:-) And in a
pot-calls-kettle-black moment, I'm not sure that kind of language is
guaranteed to help us resolve what is a tricky issue in a very tricky
environment. But I guess crossing the streams of an anonymity overlay
and DN$ was never going to end up very pretty;-)

> stand in the way.  So I'm standing aside with an "Abstain" ballot.

Given what I think is your position, abstaining seems like the
right action to take.

I think you are quite correct that standing in the way here would
have bad consequences.

S.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 21 Aug 2015 17:40:34 -0400

> race and first improve IETF handling of special-use names.)

And I see you are a "yes", and I certainly have no interest in trying
to convince you or anyone to change or ballot a certain way.  I'm only
expressing my own opinion here.

My point here is that there were always other ways of doing this
besides using a made-up TLD, and it was always possible to use 6761 to
reserve a name early on.  Neither of those paths were taken, which is
where my characterisation of "squatting" came in.  It used to be
thought of as safe, if not entirely legitimate, to do that, because
only a relatively few things were valid TLDs.

Now that ICANN has opened up the TLD space, it has become a clear
issue, and we're being asked -- and not because of work in the IETF --
to retroactively protect this TLD from assignment to someone else by
reserving it for a particular software project.  In general, I simply
don't think we should be doing that.  In *this* case, I think doing it
serves the public good sufficiently that I'll accept that we've been
backed into it.  In the general case, I think we should send
applicants to ICANN to make their case there.  That fits under this
stipulation, from RFC 6761 Section 3:

   Reservation of a Special-Use Domain Name is not a mechanism
   for circumventing normal domain name registration processes.

I know there are a number of other TLDs waiting for this same
treatment, and, as I said, while I understand the need to proceed in
this case, I think it would be a mistake to continue doing this for
case after case of other such TLDs.  If we need to do more of this, we
should reserve one specific TLD for it (or use one we already have),
and have the uses migrate to that TLD.

Barry

---

From: joel jaeggli <[email-masked]>
Date: Fri, 21 Aug 2015 15:39:41 -0700

On 8/21/15 2:40 PM, Barry Leiba wrote:
> reserve a name early on.

That's an argument that this is moral hazard territory, I think that's a
valid point, however with respect to 6761 the onion namespace
substantially predates the existence of 6761 or the consensus documented
there so I don't think the what if scenario is particularly helpful in
looking at the problem of this draft. The thinking of the IETF community
has evolved over time with the creation of  the registry and the
assignment of .local being a significant (and recent) milestone.

>  Neither of those paths were taken, which is
> case after case of other such TLDs.  If we to do more of this, we

FWIW I think we have to address the problem of how to allow for
experimentation in a way the does not result in future problems like
this  (that could have been avoided); or result in inadvertent pressure
on the domain name system. But that's outside the scope (I hope) of this
draft.

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

---

From: Barry Leiba <[email-masked]>
Date: Fri, 21 Aug 2015 22:28:05 -0400

> there so I don't think the what if scenario is particularly helpful

Indeed, and Stephen pointed that out to me privately as well.  That
was a mistake in my response to Stephen -- I blew that part.

Remember, here, that I'm abstaining *not* because I don't want this
request to be honored, but because requesting these special TLDs in
this manner doesn't scale.  The .onion request was originally bundled
with half a dozen others, and was split from it for a reason.  As we
start to process the other requests, there has to be a line in the
sand.  Having everyone who has deployed some non-IETF thing that turns
out to need a TLD reservation ask us to please intervene and reserve
it for them isn't, I think, what 6761 was meant for, and doesn't
scale.  That's really the issue for me.

In any case, my abstaining doesn't have any direct effect on this
document.  I accept that there's IETF consensus for doing this.  By
abstaining, I'm simply saying that I can't ballot "no objection", but
that I won't stand in the way of rough consensus.  I do think it's
best that we not belabor this further.  As the other ballots come in,
we'll almost certainly approve this document, and, given the
importance of Tor, that will be for the best.

Barry

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 22 Aug 2015 09:09:25 +0200

On 21 Aug 2015, at 21:15, Stephen Farrell wrote:

> not be used in the DNS?

ICANN today do not have any process for doing anything regarding anything in the domain namespace except managing the strings that where applied for in the previous round of ability to get new TLDs.

ICANN has initiated discussions internally on "what must be done before a potential next round of TLDs".

It is not possible to know, of course, what those discussions will lead to.

I.e. you have been able to apply for a TLD that is not only allocated for you in the namespace, you also get it delegated in the DNS in the root that is managed under the contract with NTIA.

You have never been able to request strings for special use that is not created as a TLD.

The policy for the previous round of TLDs included a list of strings that one could not apply for.

On top of that ICANN have made decisions for a few of the strings, where the decisions are:

- Delay delegation indefinitely (sort of, there are many more words)

- Delay delegation as long as the string is viewed as being in the category of high risk strings (according to an evaluation process...etc etc)

To conclude, today you can in practice not go to ICANN and request any string any kind of status except the TLDs allocated or the strings that are part of the current new gTLD round.

<personal view>
My personal view is that the outcome of these discussions in the IETF is very important input to the policy process in ICANN because I think the most important thing is that the processes must together cover the complete namespace used for, among other things, DNS.
</personal view>

   Patrik

---

From: joel jaeggli <[email-masked]>
Date: Sat, 22 Aug 2015 11:35:00 -0700

On 8/21/15 7:28 PM, Barry Leiba wrote:
> document.

yup, I agree. I am fine with that stance, i just want to make sure we
have a common view of events, I think that's very important as we
address the ongoing problem.

thanks
joel

>  I accept that there's IETF consensus for doing this.  By

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 31 Aug 2015 20:57:02 -0400

On Fri, Aug 21, 2015 at 08:15:26PM +0100, Stephen Farrell wrote:
> not be used in the DNS? I am not aware of such but it may exist.

It seems to me that ICANN could well decide that certain names are
just not going to be delegated in the DNS root, and could do that on
the understanding that it is because of existing deployments.  There
is an argument to ne made that the "corp" and "mail" examples are of
this sort, although John Levine might point out that they haven't made
this permanent.

I think the onion case is slightly more troublesome because of the
CA/B Forum decision.  So that's a distinction that makes a difference.

No opinion, but I hope that's a useful observation.

Andrew (individual title only).

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 1 Sep 2015 02:13:45 -0000

>this sort, although John Levine might point out that they haven't made

Well, since I've been dragged in here ...

The ICANN new TLD process had a step that looked at DNS Stability (see
pages 2-11 - 2-15 of the applicant guidebook), but the text in the AGB
makes it clear that the issues they were contemplating were things
like IDN names that aren't valid U-labels.  The issue of collisions
with existing use wasn't seriously addressed until Verisign made an
issue about it, notably with their March 2014 name collision workshop.

It is quite true that while ICANN has said they're not planning to
delegate .corp, .mail, and .home, they still have several million
dollars of unrefunded application fees for those names.  It is not
necessarily bad that the names aren't reserved forever -- for example,
a lot of the informal use of .corp depended on CAs signing .corp
names, which they don't do any more.  It's plausible the enough of the
existing .corp names will eventually move elsewhere that it'd be OK to
delegate it.  The problem is that there is no process, inside or
outside of ICANN, to make that decision.

Applicants call up ICANN every day and scream about how much money
they're losing because they can't implement their business plans.  If
they hear there's collision problems, they say fine, whatever, just
tell us what we have to do to make the collisions go away so we can
start collecting rent.  This has led to some rather odd things.  For
some TLDs, there's a long list of reserved names that look like and
probably are noise, apparently ones that showed up in one of the DITL
snapshots.  Or now there's "controlled interruption", wildcards
installed in a TLD for a few months with 127.53.53.53 A records they
hope people will see in their logs.  That's a perfectly reasonable
experiment, but by itself it's not going to tell anyone whether it's
safe to delegate domains with a lot of prior use.  I don't see ICANN
being opposed to sensible collision management, but I don't see
how to get from here to there.

So anyway, I agreee with everyone else that .onion is odd enough that
it's worth reserving in an RFC, but beyond that, we're in the
uncharted territory between the IETF and ICANN.

R's,
John

---

From: David Cake <[email-masked]>
Date: Tue, 1 Sep 2015 11:16:59 +0800

I’d add that ICANN has no mechanism for specifying how a top level domain should be handled other than the simple delegation/non-delegation binary (it can specify how certain sub-domains should be handled as a condition of delegation). It cannot, as the .onion proposal does, specify that the domain be handled differently by resolvers without delegation.
This alone justifies an IETF mechanism that goes outside ICANNs processes.

David

> On 1 Sep 2015, at 10:13 am, John Levine <[email-masked]> wrote:
>

---

From: "John R Levine" <[email-masked]>
Date: 31 Aug 2015 23:27:46 -0400

> I’d add that ICANN has no mechanism for specifying how a top level 
> domain should be handled other than the simple delegation/non-delegation 
> binary (it can specify how certain sub-domains should be handled as a 
> condition of delegation). It cannot, as the .onion proposal does, 
> specify that the domain be handled differently by resolvers without 
> delegation.

That's not what the draft says.  It says that resolvers MUST (2026 
language) return NXDOMAIN for all .onion queries.

Using Tor is entirely optional, and is handled by applications, not the 
DNS.  It encourages (SHOULD) applications that don't support Tor to fail 
.onion lookups before passing them to the DNS, but that's a minor 
optimization.

R's,
John

---

From: David Cake <[email-masked]>
Date: Tue, 1 Sep 2015 12:01:00 +0800

This is a language quibble. I said ICANN had no mechanisms for specifying how a domain should be handled, and I would think a SHOULD specification is exactly that in formal language. ICANN has no good mechanism to make recommendations for DNS resolver behaviour of an undelegated domain, even minor ones.
And FWIW, its not intended primarily as an optimisation in the sense of efficiency, rather its an attempt to mitigate a privacy leakage in the TOR system. Its certainly not as important as the reservation of the domain, but I don’t think avoiding the privacy issues associated with DNS resolution (as discussed in the recent helpful RFC 7626) is considered that minor in many Tor use cases, even for accidental misuse of .onion names.

David

> On 1 Sep 2015, at 11:27 am, John R Levine <[email-masked]> wrote:
> 
> That's not what the draft says.  It says that resolvers MUST (2026 language) return NXDOMAIN for all .onion queries.
> 
> Using Tor is entirely optional, and is handled by applications, not the DNS.  It encourages (SHOULD) applications that don't support Tor to fail .onion lookups before passing them to the DNS, but that's a minor optimization.
> 
> R's,
> John_______________________________________________
> DNSOP mailing list
> [email-masked]