Subject: [DNSOP] moving forward on special use names

From: Suzanne Woolf <[email-masked]>
Date: Mon, 12 Sep 2016 16:19:06 -0400

Dear Colleagues,

As we discussed in Berlin, we need to move forward with adopting a problem statement draft for further work on special use domain names. 

Issues of usage around the domain name space are part of our charter, and the IESG has expressed interest more than once in having a clear basis for dealing with future cases such as the request for .onion in the special use domain names registry or the needs of the HNCP protocol. The Chairs determined that the WG should have a problem statement before attempting to specify changes to RFC 6761 or other possible solutions. 

The problem statement needs to be a WG document, with a WG commitment to get to consensus on it.

We have two internet-drafts that have been submitted for discussion as problem statements. They’re both individual submissions and the work of their named authors. They cover many common features of the landscape but they’re also written from slightly different viewpoints. It seems unlikely that they can be combined, so we simply have to ask the WG to choose.

Both drafts have been revised in the last few days. 

The drafts are:
	https://datatracker.ietf.org/doc/draft-tldr-sutld-ps/ <https://datatracker.ietf.org/doc/draft-tldr-sutld-ps/>
	https://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/ <https://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/>
	
We’re opening a 2-week discussion period for the WG, to end on Sept. 26. At the end of that time we’ll adopt one of these drafts for further work by the WG. 

Shortly thereafter we will also be soliciting views on how the IETF might address the problems we’ve identified with special use domain names.

Please read these drafts and tell us which you think the WG can adopt as a problem statement, from the IETF perspective, about the various issues we’ve discussed on special use names. We need your comments on the record— being able to demonstrate the WG’s decision process is important— so please write to the list.

Assuming some level of agreement on a problem statement, we’re tentatively scheduling an interim WG meeting for next steps, in mid-October.

thanks all,
Tim & Suzanne

---

From: Warren Kumari <[email-masked]>
Date: Mon, 12 Sep 2016 18:43:10 -0400

On Monday, September 12, 2016, Suzanne Woolf <[email-masked]> wrote:

> Dear Colleagues,
>
>
> As we discussed in Berlin, we need to move forward with adopting a problem
> statement draft for further work on special use domain names.
>
> Issues of usage around the domain name space are part of our charter, and
> the IESG has expressed interest more than once in having a clear basis for
> dealing with future cases such as the request for .onion in the special use
> domain names registry or the needs of the HNCP protocol. The Chairs
> determined that the WG should have a problem statement before attempting to
> specify changes to RFC 6761 or other possible solutions.
>
> We have two internet-drafts that have been submitted for discussion as
> problem statements. They’re both individual submissions and the work of
> their named authors. They cover many common features of the landscape but
> they’re also written from slightly different viewpoints. It seems unlikely
> that they can be combined, so we simply have to ask the WG to choose.
>
> https://datatracker.ietf.org/doc/draft-tldr-sutld-ps/
> https://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/
>
> We’re opening a 2-week discussion period for the WG, to end on Sept. 26.
> At the end of that time we’ll adopt one of these drafts for further work by
> the WG.
>

Thank you - we are looking forward to any and all comments, and a healthy
debate...

Please, I know many are tired of this topic, but it really is important, so
please participate and send in your views.

W

>
>
> Shortly thereafter we will also be soliciting views on how the IETF might
> address the problems we’ve identified with special use domain names.
>
> Please read these drafts and tell us which you think the WG can adopt as a
> problem statement, from the IETF perspective, about the various issues
> we’ve discussed on special use names. We need your comments on the record—
> being able to demonstrate the WG’s decision process is important— so please
> write to the list.
>
> Assuming some level of agreement on a problem statement, we’re tentatively
> scheduling an interim WG meeting for next steps, in mid-October.
>

-- 
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: Alain Durand <[email-masked]>
Date: Tue, 13 Sep 2016 12:54:26 +0000

> On Sep 12, 2016, at 6:43 PM, Warren Kumari <[email-masked]> wrote:
> 
> Please, I know many are tired of this topic, but it really is important, so please participate and send in your views.

+1
I also would like to strongly recommend people read the latest version of each documents. They both have evolved significantly over time.

Alain.

---

From: "John Levine" <[email-masked]>
Date: 16 Sep 2016 18:13:56 -0000

>	https://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/

Having read them both, neither one thrills me but I'd give the nod to
adpkja.  The "Internet Names" in tldr seems to me a bad idea, since
there are a lot of other names on the Internet such as URIs and handle
system names, and this is about domain names.

It seems to me there are four kinds of names we have to worry about, and
neither draft calls them all out clearly:

* Names resolved globally with the DNS protocol, i.e.
  ordinary DNS names

* Names resolved globally with an agreed non-DNS protocol, e.g.
  .onion via ToR

* Names resolved locally with an agreed non-DNS protocol, e.g,
  .local via mDNS

* Names resolved locally with unknown protocols, e.g. .corp and
  .home, the toxic waste names

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Sep 2016 14:41:29 -0400

Don't forget names resolved locally with the DNS Protocol, like
1.1.168.192.in-addr.arpa.   A lot of the names you describe as "toxic
waste" are likely resolved this way.

On Fri, Sep 16, 2016 at 2:13 PM, John Levine <[email-masked]> wrote:

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

---

From: "John Levine" <[email-masked]>
Date: 16 Sep 2016 18:46:40 -0000

>waste" are likely resolved this way.

I suppose split horizon fits in there somewhere, but the toxic waste I was
thinking about is stuff like .corp and .belkin which leak out of random
old bits of hardware and software.

R's,
John

>-=-=-=-=-=-
>[Alternative: text/html]
>-=-=-=-=-=-
>-=-=-=-=-=-
>-=-=-=-=-=-

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Sep 2016 14:54:46 -0400

Split horizon is another thing.   I'm talking about locally resolved zones
(RFC 6303).

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Sep 2016 14:57:24 -0400

> system names, and this is about domain names.

BTW, if this is your only reason for preferring one document to the other,
it's pretty thin.   Maybe "Internet Names" is the wrong term to use.   It's
one that we came up with pretty much on the spur of the moment in Buenos
Aires, because we didn't want to use "Domain Names," because "Domain Names"
is too easily confused with "Domain Name System Protocol."   Personally, I
like Domain Names, but I agree that the term begs for confusion.

Point being, whichever document you like, we ought to figure out what term
to use.   If it's "Domain Name," I'm fine with that.  I  used "Internet
Name" because that seemed to be the consensus in the room, not because I'm
wedded to it.

---

From: "John R Levine" <[email-masked]>
Date: 16 Sep 2016 15:14:25 -0400

> Split horizon is another thing.   I'm talking about locally resolved zones

I see that as a kind of split horizon.  One of the problems with the toxic 
waste is that we don't know how much of it is from names that are supposed 
to be resolved locally but escaped (much of .corp I would guess) and how 
much is just mistakes (.belkin.)

R's,
John

>>>>   .home, the toxic waste names

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Warren Kumari <[email-masked]>
Date: Fri, 16 Sep 2016 15:18:54 -0400

On Fri, Sep 16, 2016 at 2:57 PM, Ted Lemon <[email-masked]> wrote:
> one that we came up with pretty much on the spur of the moment

Actually, IIRC it originally came from a suggestion made in the ARCING
BoF, where it enjoyed quite strong support.
But, we are (of course) happy to change it to whatever the WG wants.
When reading these documents and choosing your preferred one, please
keep in mind that whatever you select is a *starting point* -- the
authors of whichever document will incorporate whatever changes the WG
asks for.

>  in Buenos

Yup, we will do whatever the WG asks of us.
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: Warren Kumari <[email-masked]>
Date: Fri, 16 Sep 2016 17:44:21 -0400

> authors of whichever document will incorporate whatever changes the WG

... and I have just posted a new version with the term Domain Names -
I (and I think Ted) prefer Internet Names, but our preferences are not
important, we want to do whatever the WG wants.
If y'all want us to change back, 'tis trivial (this is in git)....

W

---

From: "John R Levine" <[email-masked]>
Date: 16 Sep 2016 17:58:01 -0400

> important, we want to do whatever the WG wants.

Personally, I'm more concerned with getting the issues identified, and 
then we can decide what to call them.  Anyone else like my four pronged 
strategy?

Regards,

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Sep 2016 18:03:56 -0400

Section 4.1.2 of the tldr document actually says almost exactly what you
said in your four-pronged strategy, but without the pejorative bit.
However, it only talks about this in the case of special-use names, not in
the case of names generally.   I certainly generally agree with the
taxonomy you're proposing, although I could do without the pejorative bit,
and I think it needs to mention RFC 6303-style names, which I think you
left out.   Whether this taxonomy belongs in the document is certainly a
valid question.   The taxonomy that is _in_ the document could fairly
easily be adapted to say what you said, and I would support doing that.

---

From: "John R Levine" <[email-masked]>
Date: 16 Sep 2016 18:10:07 -0400

> said in your four-pronged strategy, but without the pejorative bit.

I just looked at it again, and don't see anything about the toxic waste 
names.  Since they're the ones that are hard, I really think we need to 
call them out.  Feel free to come up with a different metaphor if you 
don't like the one about a part of the DNS space that's too polluted to 
use.

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Sep 2016 18:15:14 -0400

o  When a top-level name is used as a means either of marking the
      rest of a Domain Name for resolution using a protocol other than
      DNS, or is used for resolution of names with no global meaning,
      not all software that processes such names will understand the
      names' special meanings.  Consequently, any such use results in
      queries for those names being sent to authoritative servers.

On Fri, Sep 16, 2016 at 6:10 PM, John R Levine <[email-masked]> wrote:

> call them out.  Feel free to come up with a different metaphor if you don't
> like the one about a part of the DNS space that's too polluted to use.
>
> R's,
> John
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Sep 2016 18:17:47 -0400

Hm, possibly what you mean is that it's not mentioned explicitly enough.
I think the document covers the problem in quite a bit of detail, but the
private domains stuff is mostly in the history section; I could understand
if you felt that this provided insufficient clarity.

---

From: "John R Levine" <[email-masked]>
Date: 16 Sep 2016 18:35:03 -0400

Perhaps this would be a good time to stop and see if anyone else is paying 
attention.

Regards,

---

From: Warren Kumari <[email-masked]>
Date: Fri, 16 Sep 2016 19:10:34 -0400

> if you felt that this provided insufficient clarity.

Speaking of history, DNSOP spent a huge amount of time talking about those
specific strings a year or two ago (and decided to not adopt Lyman's doc).
We can mention the issue in more depth (John, do you have any suggested
text (especially if we can avoid mentioning the specific strings again)?),
but we don't want to get into relitigating the whole topic here.

W

>
> On Fri, Sep 16, 2016 at 6:10 PM, John R Levine <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>

---

From: "John Levine" <[email-masked]>
Date: 17 Sep 2016 00:10:36 -0000

>but we don't want to get into relitigating the whole topic here.

This is the toxic waste bit.  The names don't make sense in the 6761
special use registry, since they're not being used in any way that is
or can be standardized, but they also aren't suitable for delegation
due to widespread de facto use.  I also expect that if we redid last
year's debate in anything like the same way, we'd have the same
result, one or two highly motivated people who work for TLD applicants
would sabotage it.

As I hardly need tell you, it is utterly unclear whether it makes more
sense to have the IETF reserve them or, to switch hats and encourage
ICANN to put them on a list of names that aren't in use but can't be
delegated as SAC045 suggests.

One reason that the latter makes slightly more sense is that it's
likely that some of those names will eventually become less polluted,
so the list needs to be reconsidered every once in a while (years.)
For example, I gather that it's been a decade since Belkin stopped
making routers that leak .belkin traffic, and at some point most of
them will be gone.

R's,
John

---

From: Alain Durand <[email-masked]>
Date: Sat, 17 Sep 2016 14:18:25 +0000

What would really help here would be standardize a way to measure toxicity. We could then track a specific string toxicity over time, and maybe then define a threshold where it is OK or not OK to delegate that particular string.

I would personally agree with your assessment that maintaining this list in 6761 is problematic, for the reason mentioned in section 3.f of darft-adpkja:

"f.  [RFC6761] does not have provision for subsequent management of
       the registry, such as updates, deletions of entries, etc…”

Alain.

> On Sep 16, 2016, at 8:10 PM, John Levine <[email-masked]> wrote:
>

---

From: "John R Levine" <[email-masked]>
Date: 17 Sep 2016 11:09:51 -0400

> What would really help here would be standardize a way to measure toxicity. We could then track a specific string toxicity over time, and maybe then define a threshold where it is OK or not OK to d…

Yes, and that gets back to the question of whose job that is.  As you 
know, ICANN has done a lot of work on name collisions.  Some of it is 
pretty good like this report by JAS:

https://www.icann.org/en/system/files/files/name-collision-mitigation-final-28oct15-en.pdf

Some of it, like a wildcard that returns 127.0.53.53 for a few months, is 
clever but strikes me as wishful thinking.

The IETF has technical expertise, but no way to do studies.

R's,
John

Regards,

---

From: Ted Lemon <[email-masked]>
Date: Sat, 17 Sep 2016 11:37:08 -0400

I would just like to point out that what we are talking about doing is
documenting the problem that we think needs to be addressed.   One of the
reasons we published a new document about this is that it seemed that the
original effort had gone way too far down the path toward solutions,
without there being a clear agreement on what problems exist, and what
problems we as a working group can get consensus to try to address.

This discussion is again going down the solution space path.   I understand
the motivation, and I don't disagree with it, but I really would like to
get a problem statement before we start talking about solutions.

On Sat, Sep 17, 2016 at 10:18 AM, Alain Durand <[email-masked]>
wrote:

> What would really help here would be standardize a way to measure
> toxicity. We could then track a specific string toxicity over time, and
> maybe then define a threshold where it is OK or not OK to delegate that
> particular string.
>
> I would personally agree with your assessment that maintaining this list
> in 6761 is problematic, for the reason mentioned in section 3.f of
> darft-adpkja:
>

---

From: "John R Levine" <[email-masked]>
Date: 17 Sep 2016 11:41:46 -0400

> I would just like to point out ...

I would like to wait and see what other people think about it.

Regards,

---

From: Alain Durand <[email-masked]>
Date: Sat, 17 Sep 2016 17:37:46 +0000

> On Sep 17, 2016, at 11:38 AM, Ted Lemon <[email-masked]> wrote:
> 
> One of the reasons we published a new document about this is that it seemed that the original effort had gone way too far down the path toward solutions, without there being a clear agreement on what problems exist, and what problems we as a working group can get consensus to try to address.

Ted,

You have repeated that claim many times. I have asked you last meeting, and will ask you again, to point out exactly where do you think the current adpkja document goes into solution space.

Alain

---

From: Ralph Droms <[email-masked]>
Date: Sat, 17 Sep 2016 15:44:20 -0400

> On Sep 17, 2016, at 11:37 AM, Ted Lemon <[email-masked]> wrote:
> 
> I would just like to point out that what we are talking about doing is documenting the problem that we think needs to be addressed.   One of the reasons we published a new document about this is that it seemed that the original effort had gone way too far down the path toward solutions, without there being a clear agreement on what problems exist, and what problems we as a working group can get consensus to try to address.
> 
> This discussion is again going down the solution space path.   I understand the motivation, and I don't disagree with it, but I really would like to get a problem statement before we start talking about solutions.

Emphatically +1.

- Ralph

> 
>> On Sat, Sep 17, 2016 at 10:18 AM, Alain Durand <[email-masked]> wrote:

---

From: Ted Lemon <[email-masked]>
Date: Sat, 17 Sep 2016 16:08:14 -0400

Alain, here's an example, from the abstract:

   When an end-user triggers resolution of a name on a system that
   supports multiple, different protocols or resolution mechanisms, it
   is desirable that the protocol used is unambiguous, and that requests
   intended for one protocol are not inadvertently answered using
   another protocol.

This is a solution described in terms of a problem, not a problem statement.

This problem pervades the document.   You haven't stepped back and wiped
the slate clean and tried to explain the problem that we have--you've just
described the problem with 6761.   You've retrofitted some of what's
described in the tldr document, so that the document as it is now is in a
sense more comprehensive, but it's still structured on the basis of the set
of assumptions you started with, so that it tends to drive in a particular
direction, rather than trying to neutrally describe the problems.

If you look at the tldr document, you will see that the set of problems
that are stated there imply _contradictory_ solutions.   This is because
that's the problem we face: there is no easy solution to this problem, and
we need to consider the tradeoffs.   If I were to read your document
without considering the larger problem space, the solution it implies would
be very clear.   That's not the case for the tldr document.   There is no
one clear solution implied by the tldr document.   That was a deliberate
choice.   We, as a working group, need to think about the tradeoffs, and
not just go in a particular direction.

---

From: Alain Durand <[email-masked]>
Date: Sun, 18 Sep 2016 00:30:17 +0000

> On Sep 17, 2016, at 4:08 PM, Ted Lemon <[email-masked]> wrote:
> 

Seriously? I don’t see any solution being described here. Plus, this is an abstract, not the meat of the document.

> This problem pervades the document.   You haven't stepped back and wiped the slate clean and tried to explain the problem that we have--you've just described the problem with 6761.   You've retrofitted some of what's described in the tldr document, so that the document as it is now is in a sense more comprehensive, but it's still structured on the basis of the set of assumptions you started with, so that it tends to drive in a particular direction, rather than trying to neutrally describe the problems.
> 
> If you look at the tldr document, you will see that the set of problems that are stated there imply _contradictory_ solutions.   This is because that's the problem we face: there is no easy solution to this problem, and we need to consider the tradeoffs.   If I were to read your document without considering the larger problem space, the solution it implies would be very clear.   That's not the case for the tldr document.   There is no one clear solution implied by the tldr document.   That was a deliberate choice.   We, as a working group, need to think about the tradeoffs, and not just go in a particular direction.

On October 8th, 2016, the chairs asked the design team to work on a 6761 problem statement, Here is the text from Susanne:

""Efforts by the IETF to administer the Special Use Names registry under the provisions of RFC 6761 have proven to be controversial, consume large amounts of time and attention, and lead to outcomes that are confusing, unsatisfying, or both to operators and implementers. As a first stage towards implementing the guidance of the IESG on this subject (http://www.ietf.org/blog/2015/09/onion/ <http://www.ietf.org/blog/2015/09/onion/>, and IESG comments during the discussion of the draft at http://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/ballot/ <http://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/ballot/>), the DT is asked to produce a brief internet-draft for Yokohama, outlining the issues. It's expected to be structured as a problem statement to the extent practical, as we've come to the preliminary conclusion that one of the challenges in applying RFC 6761 is that it's unclear on what problem it's intended to solve and what criteria to consider.”

It is pretty clear to me that the problem statement was to be limited to RFC6761, which we executed on.
You are perfectly free to believe we were wrong in our understanding of the chair’s directions, or that, the chairs were wrong in their direction.

The working group now need to decide if they’d rather like a limited and concise description of issues surrounding 6761 or if they rather like a discussion of the larger issues surrounding special names in general.

Now, I will pause and give space to other working group participants to express their opinion.

Alain.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 17 Sep 2016 20:52:38 -0400

On Sat, Sep 17, 2016 at 8:30 PM, Alain Durand <[email-masked]>
wrote:
>
> The working group now need to decide if they’d rather like a limited and
> concise description of issues surrounding 6761 or if they rather like a
> discussion of the larger issues surrounding special names in general.
>

Exactly right.

---

From: avri doria <[email-masked]>
Date: Sun, 18 Sep 2016 16:21:50 -0400

On 12-Sep-16 16:19, Suzanne Woolf wrote:
> It seems unlikely that they can be combined, so we simply have to ask
> the WG to choose.

I do not understand this point.  Having now read both IDs, I see
relevant points for the ongoing discussion in both of them.   I see them
as complementary where both contribute to defining the problem in a
comprehensive way.

I think it would make sense to ask the authors to combine their efforts,
that being a first step in finding consensus on how to proceed -
otherwise the back and forth continues once a winner is picked.  Perhaps
enlist the help of one of the neutral knowledgeable people in the group
to bring the two groups of authors together in a base draft that
discusses the issues in language both groups can live with with a strict
focus on problems and their explanation.  I may be misreading the 2 IDs,
but I do not think there should be that many sticking points once there
is a decision to work it out.

I think trying to pick a winner from these two documents, both useful
expositions of the issues, is not the best way to produce a problem
statement.

Some individual comments on the drafts.

---

Some specific comments on TLDR Special-Use Names Problem

> Although IETF and ICANN nominally have authority over this
> namespace, neither organization can enforce that authority over
> any third party who wants to just start using a subset of the
> namespace. Reasons for doing this may include:

I would recommend also including something like "ignorance of there
being procedures, or lack of knowledge that the IETF & ICANN have
processes"as one of the bullets.

> this process is
> likely to be slow and difficult, with an uncertain outcome.
>
I am not sure how this differentiates from other IETF processes.  They
all take longer than one would expect and always have an uncertain
outcome.   This makes it seem like this problem is somehow special in
that respect.

> There is demand for more than one name resolution protocol for
> Internet Names, but Internet Names contain no metadata to indicate
> which protocol to use to resolve them.

probably worth indicating that one DNS mechanism that exists is broken
and that others are offering non standard methods of adding metadata or
treating existing data as metadata.

> More than one name resolution protocol is bad, in the sense
> that a single protocol is less complicated to implement and
> deploy.

This would seem contingent on there being no way to differentiate
applicability

> However, the MoU specifically exempts domain names
> assigned for technical use, and uses the example of ’IN-ADDR.ARPA’
> and ’IP6.ARPA’ to illustrate.

I think the issue here is the breadth of the definition for 'technical
use'. Most any names issue can be defined in such a way so as to have a
technical use. 

> 4.2.1. Multicast DNS

This section seems to be arguing a case as much as explaining an issue.

> 4.2.2. The .onion Special-Use TLD

Need to also look at the precedent this has set and whether the IETF
wishes to reinforce this as a precedent.

> 4.2.4. Name Collision in the DNS
> Name Collision in the DNS [SDO-ICANN-COLL] is a study commissioned by
> ICANN that attempts to characterize the potential risk to the
> Internet of adding global DNS delegations for names that were not
> previously delegated in the DNS, not reserved under any RFC, but also
> known to be (.local) or surmised to be (.corp) in significant use for
> special-use-type reasons (local scope DNS, or other resolution
> protocols altogether).

This study is from before the new gTLD program.  The assumption in the
report need to be tested against what actually happened in the round of
new gTLDs before it can be included as part of the fact basis for this
work.  We also need information on the degree of success that the
various mitigation strategies had in overcoming possible problems to
have a full picture of the problem as it has been shown in practice.

----

re Problem Statement for the Reservation of Special-Use Domain Names
using RFC6761

> The applicants for [RFC6761] status cannot be guaranteed that
> leakage will not occur and will need to take this into account
> in their protocol design.

This seems an example of a statement that includes both a problem and a
possible solution.

Additionally I think that putting the names pictures in the broader
context is important, even though dnsop WG will be restricted to
solutions based on DNS. Seems important to understand the larger system
DNS is part of these days and moving into the future.

avri

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: "John Levine" <[email-masked]>
Date: 18 Sep 2016 21:10:28 -0000

>> It seems unlikely that they can be combined, so we simply have to ask

The more I think about it, the more I think that they're both too
long, and we'd be better off with a one or two sentence description of
what we're trying to do, perhaps along these lines:

  * Describe how and when to recognize domain names that are handled
  in ways other than the DNS.  (That's mDNS and .onion)

or

  * Describe how and when to recognize domain names that should not
  be delegated in the DNS. (That's the toxic waste.)

or maybe something else, so long as it's short.

Also, FYI:

>> 4.2.4. Name Collision in the DNS ...

>have a full picture of the problem as it has been shown in practice.

At a meeting a couple of weeks ago, I believe that someone said that
the junk traffic at the roots for each of .corp, .home and .mail still
greatly exceeds all of the traffic for the new gTLDs.  So I think it's
safe to say none of the mitigation strategies have worked.

The wildcard 127.0.53.53 and such are clever, but none of the domains
that have been delegated had significant collision issues to start
with so it's hard to argue they've been effective.

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Sun, 18 Sep 2016 18:31:04 -0400

Avri, thanks for the markups--I will take care of the ones that are
actionable, and respond in a separate message, because I want to address
the question of merging explicitly, along with John's comment about brevity.

Why not merge the two documents?  This sounds reasonable on the surface,
but please understand how we got here.   The chairs asked the design team
to write a document.   Certain members of the design team wrote a document,
the initial version of which was published prior to the Yokohama IETF.   A
second version was published prior to Buenos Aires, and I decided that I
should really read it and send comments.

I read the document, wrote about four pages of comments, realized that my
comments were going to be longer than the document, and decided to talk to
people in the community before continuing.  I went out and talked to
various people in the community in Buenos Aires, including someone from
ICANN, members of the IAB, working group participants, the author of RFC
6761, members of the adpkja design team, and various others, and concluded,
based on those conversations, that we needed a new document.   Based on
that, I wrote a document that _does not reflect my personal opinion_, and
then bounced it off Ralph, one of the adpkja design team members, to see if
I'd done okay.   He had some suggestions, which were incorporated.

So the document as it stands is an attempt, which I believe was successful,
to enumerate a comprehensive set of problems relating to the problem 6761
attempted to address, as expressed by the various people I consulted.
These people are mentioned by name in the acknowledgments section.   I
didn't consult everybody, but I think most of the people whom I didn't
consult agree with what's in adpkja, which I read thoroughly, so I believe
I captured their positions as well.  Importantly, the people I consulted do
not all agree on what the scope of the problem is; that's why it was so
important to collect all of their input.

Both sets of authors have already incorporated into their respective
documents what they think is good about the other document.   Either
document, effectively, contains what that set of authors thinks a merge
should look like.   So suggesting a merge at this point doesn't make sense.
  What we really need to know is which document the working group thinks is
a better starting place.   If there's something missing from that document
that the working group wants to add, they can do so after it is adopted.

To John's point, short isn't actually good, because it's important to
document the context--this is a fairly important discussion, and it doesn't
make sense to lose the history of it.   But we tried to keep the actual
problem statement short and pithy; if you really think it's too long,
perhaps you could suggest shorter wordings that still capture the actual
problems.

---

From: "John Levine" <[email-masked]>
Date: 18 Sep 2016 23:43:46 -0000

>document the context--

No, really, short is essential.  I'm happy to add the context once we
have a concise statement of what the problem is.

> But we tried to keep the actual

Ah.  See previous message for some examples.  In neither of the
documents can I tell whether dealing with the toxic waste names is
supposed to be in or out of scope.

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Sun, 18 Sep 2016 20:32:55 -0400

Dealing with toxic waste names is out of scope for the problem statement.
The problem of toxic waste names is mentioned in the tldr problem statement
as a problem, which could potentially be dealt with if the working group
decides it's in scope.   That's why the document is written the way it is.
  Remember, the point of this document is not to supersede RFC 6761: it's
to describe the problem that we have been moved to solve as a result of the
challenges we have faced and the things we have learned while trying to
follow the process described in RFC 6761.

---

From: "John R Levine" <[email-masked]>
Date: 18 Sep 2016 20:47:41 -0400

> Dealing with toxic waste names is out of scope for the problem statement.

Well, that's one theory.  Let's see of other people agree.

R's,
John

Regards,

---

From: Phill <[email-masked]>
Date: Sun, 18 Sep 2016 21:00:00 -0400

There is actually a fifth type of name, escaped names. Right now, the only names we have of this type are SRV protocol tags, (_http._tcp.example.com) and internationalized names (xn—wev.com)

I want to add a third set of escaped names, one that has similar functionality to .onion but does not leak as much information.

example.com.m​f--​b2gk​6​-​duf5​y​-​gyyl​​-jn5e​d​

This is a strong domain name and to interpret it we require a policy that is validated under the UDF fingerprint b2gk​6​-​duf5​y​-​gyyl​​-jn5e​d​. This in turn is a base 32 encoding of 92 bits of digest value plus an 8 bit version string. The fingerprint is over a content type identifier plus some content as specified here.

https://tools.ietf.org/html/draft-hallambaker-udf-03 <https://tools.ietf.org/html/draft-hallambaker-udf-03>

The content is typically going to be some sort of cryptographic key (PGP, PKIX, SSH, JOSE, whatever) that signs some sort of assertion that states how the address ‘example.com’ is to be interpreted.

The trick here is that we can now bind security policy direct to any DNS name without having to muck about with DNSSEC, or for that matter any other PKI standard other than the particular standard we want.

Lets say that Alice is using OpenPGP and her OpenPGPv5 key is mw83i-32ri4-83klq-3odp3. We can form an address from that:

[email-masked]

Now that isn’t an address that we can interpret without access to Alice’s public key. Which is actually what I kinda want because I am fed up of spam. The fact that I give you my address does not mean I want just anyone being able to use it.

In the ordinary course of business, my ‘strong name aware’ mailer knows that it has to resolve mf--mw83i-32ri4-83klq-3odp3 somehow before it can use that email address. If I just type it into Outlook, the client will happily pass it on to my mail server and then it will get ‘stuck’ unless the mail system can figure out how to use that address. Which is exactly what you would want to happen with confidential mail.

If the address can be resolved, the result is normally going to be a policy that says what protocols the address can be used with and how.

Now, naturally, a split horizon DNS would be one natural place to provide access to a resolution service, but it need not be the only one.

The use of strong DNS names represents a major step forward in achieving a genuinely decentralized Web. Instead of there being an institution at the trust apex of the Internet, there is a digest function and a PKI scheme.

> On Sep 16, 2016, at 2:13 PM, John Levine <[email-masked]> wrote:
> 
>> The drafts are:

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 18 Sep 2016 21:38:38 -0400

There is actually a fifth type of name, escaped names. Right now, the only
names we have of this type are SRV protocol tags, (_http._tcp.example.com)
and internationalized names (xn—wev.com)

I want to add a third set of escaped names, one that has similar
functionality to .onion but does not leak as much information.

example.com.m
​f--​
b2gk
​
6
​-​
duf5
​
y
​-​
gyyl
​​-
jn5e
​d​

This is a strong domain name and to interpret it we require a policy that
is validated under the UDF fingerprint b2gk
​
6
​-​
duf5
​
y
​-​
gyyl
​​-
jn5e
​d​. This in turn is a base 32 encoding of 92 bits of digest value plus an
8 bit version string. The fingerprint is over a content type identifier
plus some content as specified here.

https://tools.ietf.org/html/draft-hallambaker-udf-03

The content is typically going to be some sort of cryptographic key (PGP,
PKIX, SSH, JOSE, whatever) that signs some sort of assertion that states
how the address ‘example.com’ is to be interpreted.

The trick here is that we can now bind security policy direct to any DNS
name without having to muck about with DNSSEC, or for that matter any other
PKI standard other than the particular standard we want.

Lets say that Alice is using OpenPGP and her OpenPGPv5 key is
mw83i-32ri4-83klq-3odp3. We can form an address from that:

Now that isn’t an address that we can interpret without access to Alice’s
public key. Which is actually what I kinda want because I am fed up of
spam. The fact that I give you my address does not mean I want just anyone
being able to use it.

In the ordinary course of business, my ‘strong name aware’ mailer knows
that it has to resolve mf--mw83i-32ri4-83klq-3odp3 somehow before it can
use that email address. If I just type it into Outlook, the client will
happily pass it on to my mail server and then it will get ‘stuck’ unless
the mail system can figure out how to use that address. Which is exactly
what you would want to happen with confidential mail.

If the address can be resolved, the result is normally going to be a policy
that says what protocols the address can be used with and how.

Now, naturally, a split horizon DNS would be one natural place to provide
access to a resolution service, but it need not be the only one.

The use of strong DNS names represents a major step forward in achieving a
genuinely decentralized Web. Instead of there being an institution at the
trust apex of the Internet, there is a digest function and a PKI scheme.

The drafts are:

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Sun, 18 Sep 2016 21:57:26 -0400

Okay, this is an interesting application that would certainly require some
sort of 6761-style action.   Do you believe that it is not covered by the
current problem statement?

On Sun, Sep 18, 2016 at 9:00 PM, Phill <[email-masked]> wrote:

> If the address can be resolved, the result is normally going to be a
> policy that says what protocols the address can be used with and how.
>

---

From: George Michaelson <[email-masked]>
Date: Mon, 19 Sep 2016 12:05:23 +1000

This is an instance of embedding. [email-masked]}.{non-DNS-part}
is not subject to special delegation rules in some sense, because the
test of {non-DNS-part} requires no DNS action. If its synonymous with
_special_label_.{non-DNS-part}.{example.com} then its about a
conversation with upper systems to perform the transformation. If
{non-DNS-part} doesn't obey domain rules, and is not deterministically
structured, it can be {non-DNS-part}.some.sub.dom.ain eg .ALT and work
fine. It doesn't have to be a terminal on the RHS.

For .onion we were told this was non-negotiably not available. So now
we have the generic problem: upper name handling systems 'above' the
DNS don't want to be required to do work, to mangle apparent-names,
purported-named (whatever they are) according to any proscriptive
ruleset, to determine what to do: They want the DNS to do the work,
that drives them into a state to handle the exceptions.

Thats where my primary complaint in shut-it-down came in: This is an
unreasonable burden on the hierarchy of domain-names, as a thing in
itself.

"we" can't have it both ways. We can't have clean domain-name models
and coerce the domain-name model to cope with non-domain-name
concepts. And "we" can't keep it simple up in applications/URI space,
if we have to do special-case handling up there.

Shame we did think 6761 fixed this: it doesn't.

On Mon, Sep 19, 2016 at 11:57 AM, Ted Lemon <[email-masked]> wrote:
>> f--
>> -
>> -
>> -
>> d
>> -
>> -
>> -
>> d. This in turn is a base 32 encoding of 92 bits of digest value plus an 8
>> bit version string. The fingerprint is over a content type identifier plus
>> some content as specified here.
>>
>> PKIX, SSH, JOSE, whatever) that signs some sort of assertion that states how
>> the address ‘example.com’ is to be interpreted.
>>
>> public key. Which is actually what I kinda want because I am fed up of spam.
>> The fact that I give you my address does not mean I want just anyone being
>> able to use it.
>>
>> that it has to resolve mf--mw83i-32ri4-83klq-3odp3 somehow before it can use
>> that email address. If I just type it into Outlook, the client will happily
>> pass it on to my mail server and then it will get ‘stuck’ unless the mail
>> system can figure out how to use that address. Which is exactly what you
>> would want to happen with confidential mail.
>>

---

From: william manning <[email-masked]>
Date: Mon, 19 Sep 2016 14:34:56 -0700

maybe others would be interested.

/Wm
---------- Forwarded message ----------
From: william manning <[email-masked]>
Date: Mon, Sep 19, 2016 at 10:49 AM
Subject: Re: [DNSOP] moving forward on special use names
To: John Levine <[email-masked]>

I'm liking Johns approach - There is not a technical solution to a policy
or political problem.   Documenting known ways in which people are using
DNS and DNS-like naming systems might be very useful.   Of course such a
document would benefit greatly from a companion document that defined the
"proper" or "correct" use of the DNS...   If you don't know what is
allowed, then knowing what is out of bounds is very hard indeed.

As constituted, the DNS is made up of three fundamental components, an
ephemeral namespace, servers which publish parts of that namespace, and
resolvers which query the servers about the namespace.  The second and
third components use a specific suite of protocols to ask/answer questions
about the namespace.  Usually this is what people in the IETF refer to as
"the DNS".   Some groups reuse the namespace, but use different protocols,
 some use the protocols, but not the namespace.

Are all of these DNS?  Any of them DNS?  if not, why not?

/Wm

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 20 Sep 2016 04:57:49 -0400

Avri,

Thanks for your efforts on this; I see authors have replied to specific comments.

I just want to clarify what amounts to a process point:

> On Sep 18, 2016, at 4:21 PM, avri doria <[email-masked]> wrote:
> 

As a personal opinion, I agree with you.

> is a decision to work it out.

The authors are always free to do that.

In the meantime, however, in the interests of getting some kind of movement, the chairs are reminded that:
	1. We do need some basis for moving forward, and the roadmap we set out last year(!) does call for adoption of a problem statement as a next step. 
	2. Once we have a WG document adopted, it becomes easier, from a process perspective, for any participant in the WG to ask for the edits they want, since we’re supposed to be progressing towards a consensus document. In a real sense the question at hand is a very practical one: “Which of these documents do you think needs less work?"

Again, thanks!

Suzanne

---

From: David Cake <[email-masked]>
Date: Tue, 20 Sep 2016 17:32:09 +0800

I tend to think that they may be within scope for the problem statement, but it is likely that existing solutions (e.g. ICANN refusing to delegate them while they remain toxic) are adequate to deal with the problem. 

David

> On 19 Sep 2016, at 8:47 AM, John R Levine <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Sep 2016 07:29:46 -0400

What is out of scope of the problem statement is saying what to do about
them. :)

On Tue, Sep 20, 2016 at 5:32 AM, David Cake <[email-masked]> wrote:

> I tend to think that they may be within scope for the problem statement,
> but it is likely that existing solutions (e.g. ICANN refusing to delegate
> them while they remain toxic) are adequate to deal with the problem.
>
> David
>

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 20 Sep 2016 07:46:41 -0400

Indeed….Please keep in mind we’re not talking about a final document here. While it would be nice to have a document that was almost ready for WG consensus, there’s room to discuss the final scope in the WG.

The “toxic waste” names are a “use case” in the sense that people keep asking about. The identified need for a default namespace in the homenet protocols represents another use case.

Suzanne

> On Sep 20, 2016, at 7:29 AM, Ted Lemon <[email-masked]> wrote:
> 
> What is out of scope of the problem statement is saying what to do about them. :)
> 
> On Tue, Sep 20, 2016 at 5:32 AM, David Cake <[email-masked] <mailto:[email-masked]>> wrote:
> > On 19 Sep 2016, at 8:47 AM, John R Levine <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > John Levine, [email-masked] <mailto:[email-masked]>, Taughannock Networks, Trumansburg NY
> > Please consider the environment before reading this e-mail. https://jl.ly <https://jl.ly/>
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>
> 
>

---

From: Alain Durand <[email-masked]>
Date: Tue, 20 Sep 2016 19:17:25 +0000

> On Sep 20, 2016, at 7:46 AM, Suzanne Woolf <[email-masked]> wrote:
> 

There are many use cases for reserving names under 6761 or an updated version of it. We saw that last year: people have an unlimited imagination on how to use such special names… good or bad, this is not the question.

It could be tempting for the problem statement to list all of those use cases. Actually, if 6761 did not exist, that might even have been the right thing to do. But this is not where we are now.

Where we are is that the iETF ran into a number of issues running both the process and the registry described in RFC6761. Draft-adpkja is attempting to list those issues, first by looking at process issues (section 3), then issues related to the operation of the registry (section 4), and, at last, looking at issues related to the strings under consideration themselves (section 4). The perspective taken by the authors is that these set of issues are real. Each of them need to, and can be, addressed. Hence a problem statement that focuses narrowly on something that can be fixed as opposed to boiling the ocean listing issues that, if the discussion from the last 18 months is any guidance, the working group may never reach consensus on.

Alain, strictly speaking on my own behalf, not my employer’s.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Sep 2016 15:56:59 -0400

I have a lot of sympathy for the worry about boiling the ocean, but
actually my fear is that if we do not enumerate all the problems and talk
about what we have to give up to solve this one or that one, we will never
reach consensus regardless of how small a teakettle we put on to boil,
because we will have left out people who have a strong stake in those
unaddressed problems, and they will not agree to the document, because
despite us not having addressed those problems, nevertheless the resulting
document will impact them.

On Tue, Sep 20, 2016 at 3:17 PM, Alain Durand <[email-masked]>
wrote:

> The “toxic waste” names are a “use case” in the sense that people keep
> asking about. The identified need for a default namespace in the homenet
> protocols represents another use case.
>
>
>
> There are many use cases for reserving names under 6761 or an updated
> version of it. We saw that last year: people have an unlimited imagination
> on how to use such special names… good or bad, this is not the question.
>
> It could be tempting for the problem statement to list all of those use
> cases. Actually, if 6761 did not exist, that might even have been the right
> thing to do. But this is not where we are now.
>
> Where we are is that the iETF ran into a number of issues running both the
> process and the registry described in RFC6761. Draft-adpkja is attempting
> to list those issues, first by looking at process issues (section 3), then
> issues related to the operation of the registry (section 4), and, at last,
> looking at issues related to the strings under consideration themselves
> (section 4). The perspective taken by the authors is that these set of
> issues are real. Each of them need to, and can be, addressed. Hence a
> problem statement that focuses narrowly on something that can be fixed as
> opposed to boiling the ocean listing issues that, if the discussion from
> the last 18 months is any guidance, the working group may never reach
> consensus on.
>

---

From: hellekin <[email-masked]>
Date: Wed, 21 Sep 2016 23:17:25 +0000

On 09/20/2016 08:57 AM, Suzanne Woolf wrote:
>
> In a real sense the question at hand is a very practical one:
> “Which of these documents do you think needs less work?"
> 

Having read both drafts, and from the perspective of "Names resolved *
with an agreed non-DNS protocol", I agree with Avri that they can be
complementary, and find draft-tldr-sutld-ps-04 to "need less work".

This despite my other message which situates the problem space out of
these two drafts.

Regards,

==
hk