Subject: [DNSOP] WG review of draft-ietf-homenet-dot-03

From: Suzanne Woolf <[email-masked]>
Date: Sun, 19 Mar 2017 21:44:24 -0400

Hi,

The INT Area Director who oversees the homenet WG, Terry Manderson, has asked DNSOP participants to review https://www.ietf.org/id/draft-ietf-homenet-dot-03.txt <https://www.ietf.org/id/draft-ietf-homenet-dot-03.txt>, "Special Use Top Level Domain '.homenet’”, with the following aspects in mind:

1) in terms of RFC6761

2) in terms of the _operational_ position of an unsigned entry in the root zone as requested in this document, to break the chain of trust for local DNS resolution of .homenet names.

This document is the product of the homenet WG, which has asked the IESG to approve it for publication, so our comments are strictly advisory to the IESG. There was some discussion of the draft on this list shortly after it appeared, in November 2016, but it’s always the AD’s prerogative to ask for additional review.

thanks,
Suzanne & Tim

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 19 Mar 2017 19:03:18 -0700

On 19 Mar 2017, at 18:44, Suzanne Woolf wrote:

> Hi,
>
> The INT Area Director who oversees the homenet WG, Terry Manderson, 
> has asked DNSOP participants to review 
> https://www.ietf.org/id/draft-ietf-homenet-dot-03.txt 
> <https://www.ietf.org/id/draft-ietf-homenet-dot-03.txt>, "Special Use 
> Top Level Domain '.homenet’”, with the following aspects in mind:
>
> 1) in terms of RFC6761
>
> 2) in terms of the _operational_ position of an unsigned entry in the 
> root zone as requested in this document, to break the chain of trust 
> for local DNS resolution of .homenet names.
>
> This document is the product of the homenet WG, which has asked the 
> IESG to approve it for publication, so our comments are strictly 
> advisory to the IESG. There was some discussion of the draft on this 
> list shortly after it appeared, in November 2016, but it’s always 
> the AD’s prerogative to ask for additional review.

Clarifying question for Terry: do you want us reviewing it now, or after 
he has released it for IETF Last Call? I ask because the draft's authors 
are aware that there are still a bunch of 6761-ish issues (from two 
different reviewers, of which I am one), so there might be refinements 
coming before IETF Last Call, or maybe not.

---

From: George Michaelson <[email-masked]>
Date: Mon, 20 Mar 2017 14:06:28 +1000

Where's the measurement of existing use?

Do we understand to what extent this label is already in use, and
potentially has operational issues?

-G

On Mon, Mar 20, 2017 at 12:03 PM, Paul Hoffman <[email-masked]> wrote:
>> The INT Area Director who oversees the homenet WG, Terry Manderson, has
>> asked DNSOP participants to review
>> <https://www.ietf.org/id/draft-ietf-homenet-dot-03.txt>, "Special Use Top
>> Level Domain '.homenet’”, with the following aspects in mind:
>>
>> 1) in terms of RFC6761
>>
>> 2) in terms of the _operational_ position of an unsigned entry in the root
>> zone as requested in this document, to break the chain of trust for local
>> DNS resolution of .homenet names.
>>
>> This document is the product of the homenet WG, which has asked the IESG
>> to approve it for publication, so our comments are strictly advisory to the
>> IESG. There was some discussion of the draft on this list shortly after it
>> appeared, in November 2016, but it’s always the AD’s prerogative to ask for
>> additional review.
>
>
> Clarifying question for Terry: do you want us reviewing it now, or after he
> has released it for IETF Last Call? I ask because the draft's authors are
> aware that there are still a bunch of 6761-ish issues (from two different
> reviewers, of which I am one), so there might be refinements coming before
> IETF Last Call, or maybe not.
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Russ Housley <[email-masked]>
Date: Mon, 20 Mar 2017 11:43:52 -0400

I have a big problem with Section 6 of draft-ietf-homenet-dot-03.  If the domain name is to be published in the root zone, then I do not think that the special-use TLD registration is appropriate.  That said, if the requirement for publication in the root zone is removed, I do not have a problem with proceeding with a special-use TLD registration.

Russ

> On Mar 19, 2017, at 9:44 PM, Suzanne Woolf <[email-masked]> wrote:
> 
> Hi,
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Mar 2017 12:28:00 -0400

> I have a big problem with Section 6 of draft-ietf-homenet-dot-03.  If the domain name is to be published in the root zone, then I do not think that the special-use TLD registration is appropriate.…

You seem to have missed out on the discussion that we had on this, Russ.   The problem is that we don't have a choice.   Either it is a special-use name, which means literally that, or it is not.   It can't not be a special-use name, because its use is special—that is, different than other names.

At the same time, it is a name that is resolved using the DNS protocol.   Its special use requires this.   I think we go into that in the document, but to recap, if there is no un-signed delegation, validating resolvers will find any subdomain of the name invalid, and so the special use won't work.

We could of course require resolvers to special-case this particular domain, but I think you can see that that sort of solution doesn't scale, so I presume you are not suggesting we do this.

So, with that in mind, can you articulate _why_ you think that the publication in the root zone and the special use registration are together, as you put it, "inappropriate"?

---

From: Russ Housley <[email-masked]>
Date: Mon, 20 Mar 2017 12:47:31 -0400

Ted:

> So, with that in mind, can you articulate _why_ you think that the publication in the root zone and the special use registration are together, as you put it, "inappropriate”?

We have a different view of the intended purpose of the special-use TLD registry.  Sadly, the RFC does not include language that resolves this difference.

In my opinion, a special-use TLD MUST NOT be published in the root zone.  If you believe that this TLD needs to be published in the root zone, then the special-use registry is an inappropriate path to getting the domain name assigned.

Russ

---

From: Jim Reid <[email-masked]>
Date: Mon, 20 Mar 2017 16:51:14 +0000

> On 20 Mar 2017, at 04:06, George Michaelson <[email-masked]> wrote:
> 

I'll be happy to plough through the 2016 DITL dataset and count TLD strings of interest. What ones would the WG like me to count?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Mar 2017 12:59:57 -0400

> We have a different view of the intended purpose of the special-use TLD registry.  Sadly, the RFC does not include language that resolves this difference.

I understand that we have different views.   However, I am asking you specifically to articulate _your_ view.

You have said that in your opinion special-use names must not be published in the root zone, but that was already obvious from what you said previously.   What I am asking you to do is explain _why_ special-use names must not be published in the root zone.

---

From: Russ Housley <[email-masked]>
Date: Mon, 20 Mar 2017 13:08:01 -0400

> You have said that in your opinion special-use names must not be published in the root zone, but that was already obvious from what you said previously.   What I am asking you to do is explain _why…

There are other processes for adding names to the root zone.  In my opinion, using the special-use TLD registry as a means of putting a name, even one that has a different scope and use case, is an end run around that process.

Russ

---

From: Ralph Droms <[email-masked]>
Date: Mon, 20 Mar 2017 13:14:25 -0400

> On Mar 20, 2017, at 1:08 PM, Russ Housley <[email-masked]> wrote:
> 
> 
>> 

Russ - In my opinion, the special-use domain registry is not being used to put the name in the root zone.  The observation is that the special-use definition of this TLD requires both an entry in the special-use domain name registry, and an entry in the root zone.  There is no process at present for adding such an entry to the root zone.  draft-ietf-homenet-dot-03 explicitly recognizes the lack of such a process and that a process may need to be developed.

Seems to me the important issue is that the entry in the root zone is required for correct operation of the locally-served .homenet zone, even if no process exists for creating that entry.  The appropriate parties can collaborate to develop any needed processes...

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Mar 2017 13:16:09 -0400

> There are other processes for adding names to the root zone.  In my opinion, using the special-use TLD registry as a means of putting a name, even one that has a different scope and use case, is an…

So it seems to me that your position is not that it's inappropriate for a name to both be registered in the root zone and in the special-use names registry, but rather that two processes would have to be followed in order for this to happen.   Is that a reasonable interpretation of what you have said?

Also, can you talk about what you think the process should be?   Are you saying that this is not a technical use under the MoU, or just that for this particular technical use, a different process is required?

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Mar 2017 18:16:56 +0000

On Monday, March 20, 2017 5:08:01 PM GMT Russ Housley wrote:
> There are other processes for adding names to the root zone.  In my opinion,
> using the special-use TLD registry as a means of putting a name, even one
> that has a different scope and use case, is an end run around that process.

as much as i'd like to see "localhost IN AAAA ::1" added to the root zone, i 
agree with russ's position here-- reservations are in IETF-land, whereas 
actual content is in ICANN-land.

---

From: Russ Housley <[email-masked]>
Date: Mon, 20 Mar 2017 15:38:52 -0400

> So it seems to me that your position is not that it's inappropriate for a name to both be registered in the root zone and in the special-use names registry, but rather that two processes would have…

No.  In my opinion, the special-use TLD registry is not appropriate for the assignment of any name that will appear in the root zone.  As I said in my first note, my view is that TLDs assigned through the special-use registry MUST NOT be published in the root zone.

If you have a domain names that is to appear in the root zone, then the existing process ought to be used for that to happen.

Further, the intent is that .homenet will be used with the DNS protocol.  Section 3 of the document makes it very clear that users, applications, resolution APIs, and most resolvers will not to treat that domain name in a special in any way.  For this reason, I do not think it meets the definition of a special-use domain name in RFC 6761, which says:

   ... if a domain name has special properties that affect the
   way hardware and software implementations handle the name, that apply
   universally regardless of what network the implementation may be
   connected to, then that domain name may be a candidate for having the
   IETF declare it to be a Special-Use Domain Name and specify what
   special treatment implementations should give to that name.

So, I think that the desired outcome requires the use of the existing process to get it registered in the root zone and some standards-track RFC to describe the environment where:

       … Only a DNS server that is authoritative for the root ('.') or is
       configured to be authoritative for '.homenet' or a subdomain of
       '.homenet' will ever answer a query about '.homenet.’

Steve Crocker has already stated that he does not believe that entries that cannot be DNSSEC signed belong in the DNS root zone.  I know that others share this view.  For this reason, I do not think that the IETF should approve a document that specifies this processing until the root zone publication process is successful.

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 20 Mar 2017 15:44:39 -0400

Ralph:

> Seems to me the important issue is that the entry in the root zone is required for correct operation of the locally-served .homenet zone, even if no process exists for creating that entry.  The appropriate parties can collaborate to develop any needed processes…

I would be fine with collaboration between the IETF and ICANN to come up with a way to make this happen, but that is not what this document says.

This document registeres the .homenet TLD in the special-use registry and then tasks IANA "to arrange for an insecure delegation for '.homenet' in the root zone.  This delegation MUST NOT be signed, …”

This document does not describe a collaborative approach.

Russ

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Mar 2017 16:15:50 -0400

> This document does not describe a collaborative approach.

The document specifies what the working group needs to have happen in order for the specification to work.   How the collaboration happens is out of scope for the homenet working group.   The working group understands that a process needs to be invented, and I believe that the document says so.

> Steve Crocker has already stated that he does not believe that entries that cannot be DNSSEC signed belong in the DNS root zone.  I know that others share this view.  For this reason, I do not thin…

Yes, I understand that Steve Crocker has said this.   And perhaps Steve Crocker's opinion should be considered normative.   However, like you, Steve didn't give a technical reason why this policy must be applied universally, even in the case of technical uses.

We have a legitimate question to answer here.   It seems reasonable to say that under the MoU, the IETF can designate a name for the use that homenet is trying to designate.   Maybe the IETF consensus will be that the IETF should not designate this particular use.   But it doesn't make sense to me that the IETF should decide not to try to do what the working group thinks is the right thing technically, because the process for doing this thing is not yet known.   If the IETF doesn't try to do this, the process will never be known.   So I don't see how this can be a valid technical objection to going forward with the proposal.

>        '.homenet' will ever answer a query about '.homenet.’

I don't think this is a correct reading of RFC 6761.   If it were, we could drop most of the considerations in section 5 of the document.

As for the process, it may be that in the end, ICANN pushes back and says no, absolutely not, we won't do this.   But when they say that, they will give a reason.   It is their decision to make, not ours, as long as they don't violate the MoU.   Our decision is whether or not to ask them to make this decision.

Maybe there is a good reason not to ask them.   If so, you haven't yet stated that reason.

---

From: Steve Crocker <[email-masked]>
Date: Mon, 20 Mar 2017 16:57:19 -0400

Ted, et al,

I’ve been watching this dialog and staying silent, but since I’m referenced and quoted directly, let me offer some points.

First, neither my opinion as an individual nor my opinion as an official of ICANN should be considered definitive, normative or otherwise compelling except and unless the substance of what I say makes sense.  (Well, I guess when I speak officially as chair of ICANN’s board, it’s been coordinated and approved in advance and carries the weight of the organization, but I haven’t spoken in that capacity on this subject and I expect that if and when ICANN does speak officially on this subject, it’s likely to come from others.)

Second, speaking as an observer and with some familiarity with DNS, DNSSEC and with the process related to entering strings into the root zone, the homenet sequence seems backwards to me.  I would have expected the coordination to happen before or during the working group.  If the homenet spec is approved as a proposed standard but there’s no agreement to put .homenet into the root or there is a glitch somewhere else in the coordination, the IETF will be in the position of having published an unimplementable standard.  Running code is the hallmark of the IETF and a primary distinguishing characteristic, so I’m surprised and puzzled if this is the path the IETF is taking.

Third, having now read the homenet spec, I see what the point is, but I can also see a bunch of questions.  It looks like the idea is to establish a local DNS tree that is good only within a home or similar contained environment.  This is analogous to a 192.168.x.x environment.  To make this work, ignoring DNSSEC for a minute, it seems to me the DNS queries have to go to a DNS resolver that is acting as a local authoritative server for .homenet.  This is problematic because there are often multiple DNS stub resolvers operating within a single machine, and there’s no guarantee they will send their queries to a particular local DNS server.  The only way I see to force the issue is to intercept all queries headed for port 53 outside the local environment and examine them for .homenet.

Fourth, I’m not sure I understand what the issue is with DNSSEC.  If the queries are intercepted locally and if you trust the internal environment — an assumption you might want to ponder carefully as internal environments become ever more complicated and populated by devices and software from many, many sources — DNSSEC doesn’t come into play.  If the queries are not intercepted locally, you’ll get the official answer, viz NXDOMAIN.  I gather you want something else, and perhaps I didn’t read carefully enough to understand what that something else is and why it would be helpful.

What emerged most clearly for me in reading the homenet spec is the apparent desire to have a locally served domain, which seems similar in some respects to a classic split domain, and the real challenge, as best I can see, is characterizing the perimeter and internal topology.

And returning to the first point, let’s do indeed get people together to understand how the parts are supposed to fit together.  Over at ICANN we try very hard to be of service and we also take the security and stability of the DNS, and particularly the root, very seriously.  A non-standard request is almost going to be the beginning of lengthy discussion.  Our mind set will be aimed at getting it right, not arguing about who’s in charge.

Steve

> On Mar 20, 2017, at 4:15 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Mar 20, 2017, at 3:44 PM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Mar 2017 17:14:36 -0400

On Mar 20, 2017, at 4:57 PM, Steve Crocker <[email-masked]> wrote:
> First, neither my opinion as an individual nor my opinion as an official of ICANN should be considered definitive, normative or otherwise compelling except and unless the substance of what I say makes sense

I was being facetious, in case it wasn't obvious. :)

> Second, speaking as an observer and with some familiarity with DNS, DNSSEC and with the process related to entering strings into the root zone, the homenet sequence seems backwards to me.  I would…

It is a bit backwards.   The name '.home' got allocated in the HNCP RFC without due process, so we wound up suddenly needing to fix that.

> Third, having now read the homenet spec, I see what the point is, but I can also see a bunch of questions.  It looks like the idea is to establish a local DNS tree that is good only within a home o…

You should bear in mind that homenet is assuming the Internet of maybe five years from now, more so than the Internet of now, although obviously we'd like to get done sooner than that.   So you should assume that stub resolvers never, ever do anything so foolish as to trust a recursive resolver to validate for them.  And, indeed, as you say, any resolver that doesn't use the host's resolver configuration to figure out which resolver to talk to isn't going to be able to resolve queries in the .homenet domain.

We don't consider this to be a serious problem.   Are you aware of some reason to think it is?

> Fourth, I’m not sure I understand what the issue is with DNSSEC.  If the queries are intercepted locally and if you trust the internal environment — an assumption you might want to ponder carefully…

The queries are being resolved by a local resolver.  But they are being validated by the stub.   So if the local resolver gives an answer that doesn't come with a secure denial of existence, it'll work.   If not, the stub will find any answer for .homenet to be invalid, because there is a chain of trust, and the chain of trust says that .homenet doesn't exist.

> What emerged most clearly for me in reading the homenet spec is the apparent desire to have a locally served domain, which seems similar in some respects to a classic split domain, and the real cha…

We are addressing a problem with locally-served zones that existing documents do not address.

> And returning to the first point, let’s do indeed get people together to understand how the parts are supposed to fit together.  Over at ICANN we try very hard to be of service and we also take the…

Understood and appreciated.   If the document reads as suggesting something other than this, I apologize, since I probably wrote that text.   The working group's intention matches what you have said here.

---

From: Steve Crocker <[email-masked]>
Date: Mon, 20 Mar 2017 17:44:27 -0400

Thanks for the quick response.

> On Mar 20, 2017, at 5:14 PM, Ted Lemon <[email-masked]> wrote:
> 
> I was being facetious, in case it wasn’t obvious. :)

Heh.  I guess it wasn’t as obvious to me as it should have been.

> You should bear in mind that homenet is assuming the Internet of maybe five years from now, more so than the Internet of now, although obviously we'd like to get done sooner than that.   So you should assume that stub resolvers never, ever do anything so foolish as to trust a recursive resolver to validate for them.  And, indeed, as you say, any resolver that doesn’t use the host's resolver configuration to figure out which resolver to talk to isn't going to be able to resolve queries in the .homenet domain.

It is hard to predict how things are going to evolve.  The idea that all stub resolvers will be validating everything they get is a nice goal, and I certainly wouldn’t want to choose a path that precludes that, but I think it’s prudent to also design for the present.  Assume we’ll be somewhere along the path between here and there.

If you assume the local environment is going to get complicated and that signing of the local domain will become important in order to guard against hijacking by errant devices inside the perimeter, it looks to me there will have to be a local trust anchor. For devices brought into the environment, DHCP already assigns the IP address and the DNS servers.  It can “easily” be augmented to hand out the public key of the local hierarchy.  Or, I suppose, since I’ve just posited that the DHCP server will tell the new device which DNS server to use, the device could then query the DNS server to find out if it has a signed .homenet domain and what its public key is.

I’m typing as I’m thinking, and I may have overlooked something quite basic and embarrassing.  I’ll stop typing now ;)

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Mar 2017 18:19:45 -0400 (EDT)

> If you assume the local environment is going to get complicated and that signing of the local domain will become important in order to guard against hijacking by errant devices inside the perimeter…

I am assuming that if stubs are validating, then they must also support
excluding special queries from validation, such as mDNS, .onion and
.homenet.

The .homenet queries should never reach real DNS servers, so I would
not think an insecure delegation in the root is required. If the DNS
resolver doesn't know how to handle .homenet, it is already as wrong
as it can be, regardless of the type of answer.

I thought the reason to ask for a Special Names domain was to ensure
no one else can register and launch .homenet in the future.

Paul

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Mar 2017 18:27:42 -0400

> If you assume the local environment is going to get complicated and that signing of the local domain will become important in order to guard against hijacking by errant devices inside the perimeter…

My theory for how to do the trust anchor is ToFU.   When you first notice you're on a homenet, query a well-known name in the homenet domain; that name will have a UUID attached to it.   That UUID identifies the homenet; if you've seen that homenet before, you look for the KSK that you stashed for it, and use that as a trust anchor.   If you don't recognize the UUID, you're on a different homenet, so you fetch a new KSK and set up a new chain of trust.

Of course, this assumes a certain sort of threat model which may not be the right one.

What I would expect to see happen is actually that very few stub resolvers validate until something egregiously bad happens that validation would have helped with. and then suddenly practically everything will start validating.   So I think it's pretty dangerous to have a situation where that will suddenly break service discovery on the homenet.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Mar 2017 18:32:24 -0400

> excluding special queries from validation, such as mDNS, .onion and

I don't think this is a reasonable assumption.   We don't, for example, assume that all resolvers exclude mDNS, or that all resolvers exclude .onion.   In the case of .onion, we'd prefer that the stub validate, so that it realizes there's no point in sending a query against a .onion domain.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 Mar 2017 00:48:27 +0000

On Mon, Mar 20, 2017 at 05:44:27PM -0400, Steve Crocker wrote:

> > You should bear in mind that homenet is assuming the Internet of maybe
> > five years from now, more so than the Internet of now, although obviously
> > we'd like to get done sooner than that.   So you should assume that stub
> > resolvers never, ever do anything so foolish as to trust a recursive
> > resolver to validate for them.  And, indeed, as you say, any resolver that
> > doesn�t use the host's resolver configuration to figure out which resolver
> > to talk to isn't going to be able to resolve queries in the .homenet
> > domain.
> 
> It is hard to predict how things are going to evolve.  The idea that all
> stub resolvers will be validating everything they get is a nice goal, and
> I certainly wouldn�t want to choose a path that precludes that, but I
> think it�s prudent to also design for the present.  Assume we�ll be
> somewhere along the path between here and there.

>From a system and software engineering perspective I continue to
be surprised at suggestions that stub resolvers are the *right*
place to do DNSSEC validation.  As much as much as this may maximize
security, it is such poor separation of duties that I don't see it
being at all attractive in practice.

FWIW, when adding DANE support to Postfix, it was plainly obvious
that DNSSEC validation belongs in the local resolver, and Postfix
just needs to trust its "AD" bit.  The only thing missing from the
traditional libresolv API is some way for the application to specify
the resolver address list from the application (as "127.0.0.1"
and/or "::1").  Some systems have a newer stub API (res_nquery,
...), but this API is not yet sufficiently universal.

Indeed, if it becomes important to be able to locally exclude
various namespaces from DNSSEC, this is far more easily done in a
local "unbound" and the like, than in the stub resolver.

So I am making a bold prediction that the maximally secure validating
stub resolvers are not likely to catch on.  The necessary DNS
sophistication belongs squarely in a dedicated separate resolver.
 
-- 
	Viktor.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Mar 2017 21:06:40 -0400

On Mar 20, 2017, at 8:48 PM, Viktor Dukhovni <[email-masked]> wrote:
> FWIW, when adding DANE support to Postfix,

Viktor, forgive me, but this is such a completely different use case than what we are talking about.   In this case, the Postfix mailer and the recursive validating resolver are both operated by the same entity.  You can use TSIG and be satisfied, or even trust the IP address if you are naive.

The homenet use case is completely different.   Here we are talking about devices that routinely roam among operational domains with no basis for trust or even knowledge of the trustworthiness of the local resolver.   In this case, trusting the local resolver could be anywhere from completely safe, to an opportunity to have your butt sniffed by your employer, to a completely corrupt Wifi hotspot that's been set up specifically to attack your device.   Trusting the network in this case is simply nonsensical, and there is no trust relationship that could make TSIG work.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 20 Mar 2017 21:23:52 -0400

> excluding special queries from validation, such as mDNS, .onion and

What possible basis do you have for this?  This is in effect a
requirement that every validating stub (or resolver?  I dunno) be
upgraded to support homenet.

That _might_ be ok, but it's not in the design parameters of the
original work AFAICT.

> The .homenet queries should never reach real DNS servers

But they're going to.  We've had local since at least the neolithic
age, in Internet terms, and yet the global DNS still sees those
queries.

> as it can be, regardless of the type of answer.

This doesn't follow.  If the resolver gets it wrong in the case of a
provably-unsigned answer, it can just continue its resolution as it
ever wanted.  It won't be able to validate, since it does not have a
local trust anchor.  But it'll work.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 Mar 2017 02:15:38 +0000

On Mon, Mar 20, 2017 at 09:06:40PM -0400, Ted Lemon wrote:

> The homenet use case is completely different.   Here we are talking about
> devices that routinely roam among operational domains with no basis for
> trust or even knowledge of the trustworthiness of the local resolver.

When I say "local", I don't mean on a nearby node on the local
network, I mean the loopback interface, i.e. a process on the same
device.

What's attractive here, is that real resolvers (local to the same
device) already have the requisite feature-set, and there's no need
to augment stub resolvers with features already handled by local
recursive resolvers.  If a device is too dumb to run a separate
resolver process, I don't expect it'll have a trustworthy DNSSEC
implementation in its stub resolver.

-- 
	Viktor.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Mar 2017 22:48:28 -0400

> network, I mean the loopback interface, i.e. a process on the same

That would qualify as a stub resolver in the sense that we are talking about here: a resolver that is on the local host, and not on some server out there on the wire.   You're right to make the distinction, but I'm not sure what the right term is.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Mar 2017 23:08:11 -0400 (EDT)

> upgraded to support homenet.

https://tools.ietf.org/html/rfc7686 dated October 2015 did this too:

    3.  Name Resolution APIs and Libraries: Resolvers MUST either respond
        to requests for .onion names by resolving them according to
        [tor-rendezvous] or by responding with NXDOMAIN [RFC1035].

    4.  Caching DNS Servers: Caching servers, where not explicitly
        adapted to interoperate with Tor, SHOULD NOT attempt to look up
        records for .onion names.  They MUST generate NXDOMAIN for all
        such queries.

    5.  Authoritative DNS Servers: Authoritative servers MUST respond to
        queries for .onion with NXDOMAIN.

> But they're going to.

Of course. I was just saying that when they do, there is no good answer
for them.

> local trust anchor.  But it'll work.

But any answer it gets makes no sense anyway, as it doesn't have the
actual required data of the real local .homenet zone. So whether you
give a NXDOMAIN or SERVFAIL or return an A record with 127.0.53.53
doesn't really matter, whether you are 8.8.8.8 or 216.146.35.35.

I guess the only possible exception to this is if the device in the
.homenet got multiple DNS servers from DHCP, and only one of them
and not the first one handles .homenet properly. Of course that's
a pretty broken setup to begin with, so I'm not too worried about
breaking that more.

Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 21 Mar 2017 00:22:49 -0400

Hi,

On Mon, Mar 20, 2017 at 01:14:25PM -0400, Ralph Droms wrote:

> Russ - In my opinion, the special-use domain registry is not being
> used to put the name in the root zone.  The observation is that the
> special-use definition of this TLD requires both an entry in the
> special-use domain name registry, and an entry in the root zone

I am having a hard time making the above two sentences consistent.
This special-use case requires an entry in the root zone, and so by
definition the entry into one (the special-use registry) with
processing rules that require normal DNS processing, combined with the
request for a provably-insecure delegation, is either incoherent or
else links the two registries.  I don't know which it is, but I see no
way it can be other than one of them.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Mar 2017 22:12:47 -0700

Viktor Dukhovni wrote:
> ...

trusting a dns response's AD bit to tell you that the responder has done
careful signature checking all the way back to a trust anchor you have
confidence in, doesn't fit the hotel or coffee shop scenario -- you do
not want your hotel or coffee shop in the role of making a secure
introduction between you and your bank, for example.

serious security -- that is, which passes the laugh test -- is end to end.

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Mar 2017 22:23:44 -0700

> introduction between you and your bank, for example.

since the hotel is unlikely to transmit on an interface that's local to
the same device, let me amend this as follows:

trusting the AD bit just because the packet appears to have been
generated locally is a dangerous model. if the specification requires
that the stub have explicit and non-default cause for confidence in the
sender's identity and fidelity, then there's no way to test for this,
and since there's no way to test for it, it won't be widely implemented.
time to market is the primary driver for a product or service's lifetime
revenue envelope, and any requirement that won't face acceptance and/or
interoperability testing, WILL be left out.

the thing you CAN test for is whether the signatures are valid. which is
why first dan kaminsky and later paul wouters wanted to send the full
signature chain. perhaps that can be merged in here: if the stub
resolver can see the full signature chain and do its own validation,
then it ought to believe that the data is authentic. this would put the
burden on system vendors to put signature chain gathering/expansion into
their on-device RDNS or DNS Proxy, so that local stubs saw same.

-- 
P Vixie

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 Mar 2017 16:52:55 +1100

In message <[email-masked]>, Russ Housley wr
ites:

> I have a big problem with Section 6 of draft-ietf-homenet-dot-03.  If the
> domain name is to be published in the root zone, then I do not think that
> the special-use TLD registration is appropriate.  That said, if the
> requirement for publication in the root zone is removed, I do not have a
> problem with proceeding with a special-use TLD registration.
>
> Russ

Russ,
       what is different between the special use domain name
10.in-addr.arpa name being published in the in-arpa.arpa zone and
the special use domain name (to be) homenet being published in the
root zone.

* They are BOTH published/expected to be published in the parent zone.
* They BOTH do not expect lookups except of DS records at that name.
* Both want to break chain of trust from the root zone at the name.

>From a operational point of view there is zero difference, yet you
say one should be published and one shouldn't.

What is you technical reasoning behind this.

Nowhere does making a name special use preclude publishing it?

There are other special use names that really should also be in the
registry because they are baked into software.

in-addr.arpa is special use because that is the name we use to
construct IPv4 address to name lookups.

ip6.arpa is special use because that is the name we use to construct
IPv6 address to name lookups.

Both of these should be is the special use domain registry.

Mark

> root zone as requested in this document, to break the chain of trust for
> local DNS resolution of .homenet names.
> >
> IESG to approve it for publication, so our comments are strictly advisory
> to the IESG. There was some discussion of the draft on this list shortly
> after it appeared, in November 2016, but it’s always the AD’s prerogative
> to ask for additional review.
> >
> >
> >
> > thanks,
> > Suzanne & Tim

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 Mar 2017 16:58:18 +1100

> actual content is in ICANN-land.

Well a insecure delegation of localhost with the local resolver providing
content would also work.

Note the draft does not specify content.  It specifies FUNCTIONALITY.
There is a difference.

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 21 Mar 2017 08:50:53 -0400

Hi,

No hats, except DNS/names geek who has spent a lot of time talking with policy people about why and how the root zone is (and isn’t) special.

> On Mar 20, 2017, at 3:38 PM, Russ Housley <[email-masked]> wrote:
> 
> Ted:
> 

I’d probably state my version of this argument slightly differently: I think Russ is interpreting draft-ietf-homenet-dot-03 as unilaterally imposing a requirement on another body, possibly in violation of that body's own policies and processes, or at least creating a need for them to respond outside of established process.

In this case, “the existing process” simply doesn’t cover what’s being asked for, and extending the existing process to cover what’s being asked for cannot unilaterally be done by the IETF as a body. This creates an external dependency and a need for the IETF to attempt to resolve it— an attempt that may well end in disappointment.

A “special use name” is NOT necessarily a single label name. There is *no* necessary connection between “special use name” and “TLD,” any more than there’s a necessary connection between “special use name” and “the string has the letters of my pony’s name in it". One hypothetical string may be better for a specific use than another, but the characteristics of the string required are protocol-specific (including the significance of the dot), not intrinsic to the registry or to domain names generally. 

To add some color to the problem being created here, I’ll suggest looking at the question we’d be asking if the request were not for “.homenet,” but for “.homenet.arpa” or “.homenet.foo” (where “foo” is a TLD in the current DNS root zone).

If the request were for “homenet.arpa,” we wouldn’t be having this conversation at all. The “.arpa” TLD is under the administrative control of the IAB, there’s existing process for asking the IAB to add a name to .arpa (signed or not, delegated or not), and there’s existing process within the IETF community for providing input to IAB decisions on the subject (see RFC 3172). Personally I’d be happy to advocate for the IAB to approve adding an unsigned delegation for .homenet.arpa to the .arpa zone; it seems to me it wouldn’t even require much change to the draft to satisfy RFC 3172, Sec. 3.

If the request were for “homenet.foo,” we’d be having a different conversation about the implications, but we still wouldn’t be creating a new external process dependency. Operationally speaking, there are literally hundreds of TLDs whose existing policies would allow for the registration of “homenet” as a second level name. In my view it would be unwise to use one when the .arpa alternative is available, because future changes to the rules for such domains are outside of the control of the IETF and the standards process, but at least we wouldn’t be asking for an entirely new process from an external actor under no obligation to give us one.

I see no justification in draft-ietf-homenet-dot for a single-label name, except an implicit suggestion in Sec. 2 para. 2 that the specific string was chosen to be memorable in cases where homenet names are exposed to users. 

I *strongly* suggest that if this document is to be used as justification to create an entirely new process for updating the root zone, coordinated between the IETF and the external body that controls the root zone, the justification should be *much* more explicit.

Suzanne

---

From: Philip Homburg <[email-masked]>
Date: Tue, 21 Mar 2017 14:28:42 +0100

> ...), but this API is not yet sufficiently universal.

For me (not DANE, but SSHFP, not a lot of difference) it was very clear that
an interface like getdns is a lot better than sending DNS packets to localhost
and hope that something will do the right thing.

Obviously, getdns could be implemented by talking to a local recursive
resolver. But that's just an implementation detail.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 21 Mar 2017 09:39:17 -0400

Ted - has the operation of .homenet, as described in draft-ietf-homenet-dot-03, been demonstrated?

- Ralph

---

From: Paul Wouters <[email-masked]>
Date: Tue, 21 Mar 2017 09:54:02 -0400 (EDT)

On Tue, 21 Mar 2017, Suzanne Woolf wrote:

[also speaking as individual only]

> I see no justification in draft-ietf-homenet-dot for a single-label name, except an implicit suggestion in
> Sec. 2 para. 2 that the specific string was chosen to be memorable in cases where homenet names are exposed to
> users. 

That seems good enough for me. The problem of DNS being the only
real name space for endusers is very well understood. And I still
regularly have to refind my printer based on checking my dhcp server
logs, something not available to regular endusers. The requirement
is very real.

> I *strongly* suggest that if this document is to be used as justification to create an entirely new process
> for updating the root zone, coordinated between the IETF and the external body that controls the root zone,
> the justification should be *much* more explicit.

This .home / .homenet issue has already been going on for a very long
time. The longer we wait with resolving this issue, the worse the
deployment situation will be of software mixing .home vs .homenet.

Suggesting we postpone .homenet while figuring out a new IETF/ICANN
process, something that can take years, would basically doom this rename
and install .home as the defacto standard. Once this new process
would be completed, it would lead to new breakage, and the new
software would be forced to look into both domains, or if the
install base is big enough for .home, would be better of ignoring
a new .homenet altogether.

As for requiring an insecure entry in the root, I'm still not convinced
it buys us that much. Resolvers on the stub that bypass the local
DHCP supplied DNS servers need to be modified anyway to use the local
DNS servers to request .homenet entries, whether they support DNSSEC
or not. So that leaves DNSSEC capable DNS resolvers that use the DHCP
supplied servers as forwarder entries in need of such an unsigned entry
only. I do think that such DNSSEC capable software tends to be maintained
by the OS and could gain special handling of the .homenet domain. And if
not, I seriously wonder if those enduser DNS stubs/servers implement
RFC-5011 well enough to survive the upcoming KSK rollover. Or any
other homenet protocol update in the future. So I would say an insecure
delegation would be nice to have but not required. And if it would shave
of a year of creating a new process between IETF, ICANN and the MoU,
then I'd say for the deployment as a whole, it would be better to get
the Special Use Domain ASAP without an entry in the root.

Paul

---

From: Ralph Droms <[email-masked]>
Date: Tue, 21 Mar 2017 10:00:43 -0400

> On Mar 21, 2017, at 12:22 AM, Andrew Sullivan <[email-masked]> wrote:
> 
> Hi,
> 

Let me try again...  As I see the process, draft-ietf-homenet-dot-03 defines the protocol behaviors for ".homenet".  draft-ietf-homenet-dot-03 requests an entry in the root zone for .homent and an entry in the special-use names registry.  While those two actions are related, and the entry in the special-use names registry may describe behavior that depends on the entry in the root zone, I think of the request for the entry in the root zone as coming explicitly from draft-ietf-homenet-dot-03 rather than implicitly from the entry in the special-use names registry.

The point I'm trying to make is that making the entry in the special-use names registry is not a back door to an entry in the root zone.  The request for the entry in the root zone has to be explicit; in this case, in draft-ietf-homenet-dot-03.

- Ralph

---

From: Jim Reid <[email-masked]>
Date: Tue, 21 Mar 2017 14:01:03 +0000

> On 21 Mar 2017, at 13:54, Paul Wouters <[email-masked]> wrote:
> 
> and install .home as the defacto standard.

At the risk of pouring petrol on the fire, .home *is* the defacto standard. Queries for this TLD account for ~4% of the 2016 DITL root server traffic. That's more than every delegated TLD except .com and .net. And the traffic for .home has been increasing in both absolute and relative terms in recent years. 3-4 years ago, it was ~3% of the DITL data set.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 21 Mar 2017 15:05:21 +0100

> This .home / .homenet issue has already been going on for a very
> long time. The longer we wait with resolving this issue, the worse
> the deployment situation will be of software mixing .home vs
> >homenet.

Do we really expect homenet to be only ever used in a 'home'? It seems to
me that homenet is an interesting technology that would work in any small 
IPv6 network, i.e. a small office. 

In that context, using the string 'homenet' would be very confusing to users
outside a home context. Maybe reserving a name that has less context would
be better.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 21 Mar 2017 10:07:45 -0400

> On Mar 21, 2017, at 10:05 AM, Philip Homburg <[email-masked]> wrote:
> 

If draft-ietf-homenet-dot-03 specified homenet.arpa, the IETF could assign as many different names as wanted for different scoping scenarios, without interacting with ICANN for each assignment.

Just sayin'

- Ralph

---

From: Paul Wouters <[email-masked]>
Date: Tue, 21 Mar 2017 10:09:34 -0400 (EDT)

> At the risk of pouring petrol on the fire, .home *is* the defacto standard. Queries for this TLD account for ~4% of the 2016 DITL root server traffic. That's more than every delegated TLD except .c…

Can we tell from the queries or a timeline of query quantity if this
is generic .home pollution that predates the homenet protocol suite,
or actually the result the homenet protocol suite being deployed?

Although I fear sticking to .home would be a legal issue, even if it
would be the technical best solution.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 21 Mar 2017 10:12:01 -0400 (EDT)

> If draft-ietf-homenet-dot-03 specified homenet.arpa, the IETF could assign as many different names as wanted for different scoping scenarios, without interacting with ICANN for each assignment.

arpa is a loaded name for some non-US citizens.

localnet.ietf ? :P

Paul

---

From: Ralph Droms <[email-masked]>
Date: Tue, 21 Mar 2017 10:14:38 -0400

> On Mar 21, 2017, at 10:12 AM, Paul Wouters <[email-masked]> wrote:
> 

Fine suggestion...would require just one interaction with ICANN, then the IETF can assign whatever names are requested.

- Ralph

---

From: Jim Reid <[email-masked]>
Date: Tue, 21 Mar 2017 14:30:22 +0000

> On 21 Mar 2017, at 14:09, Paul Wouters <[email-masked]> wrote:
> 

What's this "we"? :-)

The short answer to your question Paul is I don't know. If someone could confirm what qname/qtype tuples are limited to the homenet suite, I could go looking for them in the DITL datasets. This will not be a trivial task. One year's DITL data generally consists of a few TB of data spread over 300K compressed pcap files containing a total of ~100B queries. It takes about 1 day of elapsed time and a few CPU-weeks to chug through that.

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 21 Mar 2017 10:31:33 -0400

Paul,

I’d like to make sure I understand your comment, as I’m not completely sure it addresses mine.

As I read your response, you’re willing to forgo a root zone entry, and the DNSSEC behavior the WG has reached consensus it wants, in order to have an entry in the special use name registry for “homenet”. Is that correct?

If so….I see your point and I hope the IESG  is listening, as I don’t think it’s the HOMENET WG consensus; as written, this draft asks for both a single-label name and certain behavior with respect to DNSSEC, which means asking for an entry in the root zone.

A little more, below.

> On Mar 21, 2017, at 9:54 AM, Paul Wouters <[email-masked]> wrote:
> 

The requirement for a name that will resolve in the DNS? Sure.

The requirement for a single label/TLD that will resolve in the DNS root zone? Dramatically less clear to me, and nothing you say above is specific to the root.

From the perspective of the DNS protocol, which string is used to fill a domain name slot is mostly immaterial as long as strings are generated and parsed according to the recognized rules; they’re interchangeable— what matters is that they’re unique within the relevant namespace. The root of a hierarchical namespace is mathematically special in a few ways, but I haven’t seen a case that the name used by HNCP requires any of them. At the same time, the root of the DNS namespace is quite clearly special in the administrative sense; I’m trying to separate the two sets of considerations.

> deployment situation will be of software mixing .home vs .homenet.

For the purpose of the question I’m asking, I’m indifferent between the strings “.home" and “.homenet”. The policy problems with “.home" are significantly larger than with “.homenet”, but asking for a root zone entry at all is a significant problem for the current draft, no matter what string is involved.

> a new .homenet altogether.

Again, I’d like to make sure the problem I was trying to address is clear.

Asking for a delegation in the root zone, particularly an unsigned one, as this document currently does, *will* essentially require "figuring out a new IETF/ICANN process, something that can take years.” This is true no matter what string is being requested. 

It’s simple fact that a name elsewhere in the tree does not have the same obstacle.

Suzanne

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 21 Mar 2017 15:44:13 +0100

Jim Reid writes:

 > The short answer to your question Paul is I don't know. If someone
 > could confirm what qname/qtype tuples are limited to the homenet
 > suite, I could go looking for them in the DITL datasets. This will
 > not be a trivial task. One year's DITL data generally consists of a
 > few TB of data spread over 300K compressed pcap files containing a
 > total of ~100B queries. It takes about 1 day of elapsed time and a
 > few CPU-weeks to chug through that.

It has been done. See page 25 of the CDAR report
<https://www.icann.org/en/system/files/files/cdar-root-stability-final-08mar17-en.pdf>
which was announced two weeks ago
<https://www.icann.org/news/announcement-2017-03-08-en>.

	jaap

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 21 Mar 2017 10:53:29 -0400

> arpa is a loaded name for some non-US citizens.

RFC 3172 was written in 2001….which predates the vast majority of internet availability and use, and in fact quite a large number of internet users. Respectfully, I’ve always wondered who has this problem (US or non-US) besides network infrastructure geeks Of a Certain Age (yes, including myself, and many IETF participants).

> localnet.ietf ? :P

For DNSOP participants, I hope this discussion is suggesting some possible ways forward now that we have a problem statement; it’s not clear whether such work will occur in DNSOP, but if work is needed, we should be thinking about how to do it.

Suzanne

---

From: Mark Andrews <[email-masked]>
Date: Wed, 22 Mar 2017 02:00:08 +1100

What is the point of having a MoU that names may need to be assigned
in the root namespace if there cannot be a entry added to the root
namespace if there is a technical need to it?

.onion names were never supposed to be looked up using the DNS protocol
so there is no need to the entries to exist.  Any DNS lookups should
return NXDOMAIN to the client.

.homenet on the other had uses DNS as the resolution protocol.  Existing
tools should just work.  Part of making them work is to provide a
break in the DNSSEC chain of trust.  There is only one way to do
that.

As for the name it needs to be in *stable* place in the namespace.
We have exactly two of these today.  The root and arpa.  The homenet
working group decided that the root was a more appropriae place than
arpa.

Mark

In message <[email-masked]>, Suzanne Woolf write
s:
> Paul,
>
> Id like to make sure I understand your comment, as Im not completely sure
> it addresses mine.
>
> As I read your response, youre willing to forgo a root zone entry, and
> the DNSSEC behavior the WG has reached consensus it wants, in order to
> have an entry in the special use name registry for homenet. Is that
> correct?
>
> If so.I see your point and I hope the IESG  is listening, as I dont think
> its the HOMENET WG consensus; as written, this draft asks for both a
> single-label name and certain behavior with respect to DNSSEC, which
> means asking for an entry in the root zone.
>
> A little more, below.
>
> > also speaking as individual only
> >
> The requirement for a single label/TLD that will resolve in the DNS root
> zone? Dramatically less clear to me, and nothing you say above is
> specific to the root.
>
> From the perspective of the DNS protocol, which string is used to fill a
> domain name slot is mostly immaterial as long as strings are generated
> and parsed according to the recognized rules; theyre interchangeable what
> matters is that theyre unique within the relevant namespace. The root of
> a hierarchical namespace is mathematically special in a few ways, but I
> havent seen a case that the name used by HNCP requires any of them. At
> the same time, the root of the DNS namespace is quite clearly special in
> the administrative sense; Im trying to separate the two sets of
> considerations.
>
> >> I *strongly* suggest that if this document is to be used as
> justification to create an entirely new process
> >> for updating the root zone, coordinated between the IETF and the
> external body that controls the root zone,
> For the purpose of the question Im asking, Im indifferent between the
> strings .home" and .homenet. The policy problems with .home" are
> significantly larger than with .homenet, but asking for a root zone entry
> at all is a significant problem for the current draft, no matter what
> string is involved.
>
> Again, Id like to make sure the problem I was trying to address is clear.
>
> Asking for a delegation in the root zone, particularly an unsigned one,
> as this document currently does, *will* essentially require "figuring out
> a new IETF/ICANN process, something that can take years. This is true no
> matter what string is being requested.
>
> Its simple fact that a name elsewhere in the tree does not have the same
> obstacle.
>
>
> Suzanne
>
>
>

---

From: Jim Reid <[email-masked]>
Date: Tue, 21 Mar 2017 15:11:59 +0000

> On 21 Mar 2017, at 15:00, Mark Andrews <[email-masked]> wrote:
> 
> The homenet working group decided that the root was a more appropriae place than
> arpa.

That doesn't mean their decision was the right one. In retrospect, the stand-off in this WG and between the IETF and ICANN about "special" TLDs (for some definition of special) suggests they made a poor choice.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Mar 2017 11:33:43 -0400

> That doesn't mean their decision was the right one. In retrospect, the stand-off in this WG and between the IETF and ICANN about "special" TLDs (for some definition of special) suggests they made a…

What stand-off?

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 21 Mar 2017 13:30:01 -0400

Jim,

In the interests of preserving a distinction here that I believe is important: 

> On Mar 21, 2017, at 10:01 AM, Jim Reid <[email-masked]> wrote:
> 
> 

“Lots of queries for .home” doesn’t imply that it’s a “defacto standard” for anything in particular.

Is there any evidence connecting the use of the string “.home” in queries to the DNS with any particular protocol, type of equipment, network configuration, or software? 

thanks,
Suzanne

---

From: Tim Chown <[email-masked]>
Date: Tue, 21 Mar 2017 18:34:18 +0000

> On 21 Mar 2017, at 17:30, Suzanne Woolf <[email-masked]> wrote:
> 
> Jim,
> 

In the UK, I believe the largest residential ISP has used the .home suffix on millions of its CPEs for several years.

How much of that leaks is another question.

Tim

---

From: Ray Bellis <[email-masked]>
Date: Tue, 21 Mar 2017 11:36:15 -0700

On 21/03/2017 10:30, Suzanne Woolf wrote:

> Is there any evidence connecting the use of the string “.home” in
> queries to the DNS with any particular protocol, type of equipment,
> network configuration, or software?

It's known to be the default domain configured in 5+ million BT home
gateway routers, although I don't know if those have been shown to be
the cause of any leakage towards the root system.

Ray

---

From: Ralph Droms <[email-masked]>
Date: Tue, 21 Mar 2017 14:36:50 -0400

> On Mar 21, 2017, at 2:34 PM, Tim Chown <[email-masked]> wrote:
> 

Do you happen to know how names with the .home suffix are resolved?

- Ralph

---

From: Tim Chown <[email-masked]>
Date: Tue, 21 Mar 2017 21:28:19 +0000

Hi,

> On 21 Mar 2017, at 18:36, Ralph Droms <[email-masked]> wrote:
> 
> 

Not with BT, so can’t confirm myself.  I’ll ping someone at BT offlist and cc you.

(I’m with an ISP that supported IPv6 some time ago, but BT are now pretty much there…)

Tim

---

From: Jim Reid <[email-masked]>
Date: Wed, 22 Mar 2017 07:05:28 +0000

> On 21 Mar 2017, at 14:53, Suzanne Woolf <[email-masked]> wrote:
> 
> RFC 3172 was written in 2001…

RFC 3172 was an attempt to rewrite history and contrive an acronym: Address and Routing Parameter Area - really?

> Respectfully, I’ve always wondered who has this problem (US or non-US) besides network infrastructure geeks Of a Certain Age (yes, including myself, and many IETF participants).

It's a convenient tool for those hostile to USG "control" of the Internet: ie the US military is responsible for everything under .arpa, the US military's ARPA has still got some special status in the operation/development/control of the Internet, etc, etc. [And say things like "if .arpa isn't for US military control, why can't the string be changed?" or ".arpa hasn't been renamed since the Internet started 25-30 years ago. That proves ARPA/DoD is in charge of the Internet.".] It's utter nonsense of course. But that doesn't stop government officials and policymakers from making these arguments. I have seen them do this many times. Sigh. RFC3172 didn't make things better.

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 22 Mar 2017 09:11:57 +0100

> It's a convenient tool for those hostile to USG "control" of the Internet: ie the US military is responsible for everything under .arpa, the US military's ARPA has still got some special status in…

The important thing in RFC3172 is Appendix A, the letter by which US Government (via Karen Rose), that was then in charge, set the scope for the IANA and use of .ARPA.

The next big step was the end of the contract(s) between US Gov and ICANN Oct 1 2016.

Many steps of course remain, but it is important to separate facts from rumors, while at the same time not ignore the need for proper and correct information and informed discussions.

   paf

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 22 Mar 2017 07:40:36 -0400

> On Mar 22, 2017, at 3:05 AM, Jim Reid <[email-masked]> wrote:
> 

Well, no. I thought it wasn’t rewriting anything, but setting a future direction. (The backronym was cute or annoying, depending on your POV, but ultimately not that important.)

> It's a convenient tool for those hostile to USG "control" of the Internet: ie the US military is responsible for everything under .arpa, the US military's ARPA has still got some special status in the operation/development/control of the Internet, etc, etc. 

So the answer to “Why not actually use it where it’s technically suitable” is essentially “installed base”? 

I don’t mean to sound flippant— I’m just trying to understand the view that there’s a bigger obstacle to using .arpa than there is to asking ICANN for a root zone entry and engaging with all of the resulting complexities.

thanks,
Suzanne

---

From: Tim Chown <[email-masked]>
Date: Wed, 22 Mar 2017 11:50:12 +0000

> On 22 Mar 2017, at 11:40, Suzanne Woolf <[email-masked]> wrote:
> 

Surely the people who would make comments about (say) homenet.arpa are already making comments about in-addr.arpa and ip6.arpa?  So is there really that great a harm in using .arpa for additional things (that make many lives easier in many other ways)?

Tim

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Mar 2017 08:51:55 -0400

> Surely the people who would make comments about (say) homenet.arpa are already making comments about in-addr.arpa and ip6.arpa?  So is there really that great a harm in using .arpa for additional t…

How often do you type a reverse name into a URL bar or an ssh command?   These are different use cases.

---

From: Tim Chown <[email-masked]>
Date: Wed, 22 Mar 2017 14:50:33 +0000

> On 22 Mar 2017, at 12:51, Ted Lemon <[email-masked]> wrote:
> 
> On Mar 22, 2017, at 7:50 AM, Tim Chown <[email-masked] <mailto:[email-masked]>> wrote:

Interesting question then as to how often a typical home user would need to do so, if there’s GUI-driven service discovery on top?

Tim

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Mar 2017 10:53:23 -0400

> Interesting question then as to how often a typical home user would need to do so, if there’s GUI-driven service discovery on top?

How often do end users access the web ui of their browser?

(I don't know, just curious if you do.)

---

From: Tim Chown <[email-masked]>
Date: Wed, 22 Mar 2017 15:11:41 +0000

> On 22 Mar 2017, at 14:53, Ted Lemon <[email-masked]> wrote:
> 
> On Mar 22, 2017, at 10:50 AM, Tim Chown <[email-masked] <mailto:[email-masked]>> wrote:

Well, when I print, it’s by selecting a printer by a name (that I or someone gave it) from a list of printers I’ve already discovered (or configured).
When I throw a movie from my phone to the TV, it’s by hitting an icon on the video player.
If I play from a music collection, it’s listed as an icon in Finder on my Mac, as are NAS devices.

I’d like to think such uses are largely all GUI/icon driven.  Or perhaps increasingly voice driven, like Alexa. How often will foo.homenet.arpa, or foo.homenet be used in typical cases? 

Is the explicit .arpa use case around using the service or device/service management?  Perhaps the latter is when I’m more likely to do web-based or ssh/CLI management. 

Tim

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Mar 2017 11:18:19 -0400

> If I play from a music collection, it’s listed as an icon in Finder on my Mac, as are NAS devices.

Sorry, I meant how often do users access the web ui of their internet gateway.   I agree that all of the above uses are generally preferably done using a GUI.   Even the web UI might be done with a GUI, but you will see the address in the address bar.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 22 Mar 2017 09:19:24 -0700

On 22/03/2017 08:11, Tim Chown wrote:

> I’d like to think such uses are largely all GUI/icon driven.  Or perhaps
> increasingly voice driven, like Alexa. How often will foo.homenet.arpa,
> or foo.homenet be used in typical cases? 

I use ".local" to access several devices in my home network that are not
hidden behind a UI "discovery client", including my ADSB receiver and my
NAS.

I also use it for SSH access to devices that announce that service via
Bonjour rather than having to put their IPs in /etc/hosts everywhere.

Arguably I'm not "typical", but IMHO we shouldn't be designing for the
lowest common denominator.

Either way, the Homenet WG has reached its consensus decision to request
".homenet" rather than ".homenet.arpa".

I personally don't mind if it takes longer for the requested insecure
delegation to happen than for the special-use reservation to happen -
the former shouldn't be a blocker for the latter.

To those that say "no insecure delegations in the root zone" because
"DNSSEC is good", my argument is that in this particular case blocking
the request would *inhibit* use of DNSSEC in edge networks and on stub
resolvers.  The whole point of the insecure delegation is to
*facilitate* correct use of DNSSEC within Homenets.

Ray (no hat)

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 22 Mar 2017 13:11:44 -0400

Hi,

> lowest common denominator.

That argument is absurd on the face of it, because anyone sufficiently
clueful about systems to be using ssh or hand-entering domain names is
also sufficiently clueful to recognize that maybe they should use the
google search result that pertains to networking rather than the US
DoD.  (Presumably these are the same people who have figured out that
iab.org and iab.com are not the same organizations.)  Therefore,
homenet.arpa would work just fine for such people, there'd be no
design for LCD, and also we'd get something that would work and
wouldn't involve a constitutional crisis for IANA.

> ".homenet" rather than ".homenet.arpa".

Since the point of this discussion is to inform IETF consensus,
HOMENET's consensus is not the only thing that counts.  It is entirely
possible that HOMENET's consensus will not be the IETF consensus.

> "DNSSEC is good"

I don't think anyone is saying anything about that.  The point is that
_someone else_ gets to decide.  The IETF has literally no say in the
decision about what goes in the root zone itself, and hasn't since the
IETF signed its MoU with ICANN.  (Some argue that for this reason the
IETF must never allocate a top-level label.  I do not agree with them,
but there is absolutely no question about whether we are in a position
to decide actual registrations in the root zone.)

The plain fact is that the IETF IANA considerations in
draft-ietf-homenet-dot-03 makes a request of IANA that the IETF has no
business making, because we are requesting an entry in a registry
whose policy is controlled by someone else.  It's clear that the
weasel words "arrange for" are there to pretend we're not making such
a request it, but the MUST NOT be signed is an attempt to specify
protocol operation in a registry where we have no business working.
If this proceeds as IETF consensus, it will be apparent that it is the
IETF, not ICANN, that threatens the stability of the IANA
arrangements.  I hope we do not have to explore that rathole in my
lifetime.

Best regards,

A (speaking, of course, for myself)

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 22 Mar 2017 13:45:40 -0400

> namespace if there is a technical need to it?

You are conflating "root namespace" and "root zone of the DNS".  We
have in fact created the former.  But this draft asks for the latter,
which is different.  We have an MoU, and it says that we won't meddle
in that zone.

Best regrds,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Wed, 22 Mar 2017 14:00:52 -0400

> On Mar 22, 2017, at 1:11 PM, Andrew Sullivan <[email-masked]> wrote:
> 
> Hi,
> 

I agree that the request is misdirected toward IANA and misplaced in an "IANA Considerations" section.  If the IETF consensus is to find a way to instantiate the appropriate entry in the root zone, such an instantiation should acknowledge several realities and recognize that IETF is making a request of ICANN.  It seems to me homenet-dot should be revised:

* take the relevant text out of the IANA considerations section
* add a section that
  - motivates and explicitly defines the desired entry in the root zone
  - suggests that a request be made directly to ICANN 
  - explicitly points out that no process for such a request exists, and it might be necessary for IETF and ICANN to develop a mutually acceptable process before the request from .homenet can be considered
  - asks for IETF advice on this plan

- Ralph

---

From: "John Levine" <[email-masked]>
Date: 23 Mar 2017 04:27:41 -0000

In article <[email-masked]> you write:
>IETF is making a request of ICANN.  It seems to me homenet-dot should be revised:
>
>  - explicitly points out that no process for such a request exists, and it might be necessary for IETF and ICANN to develop a mutually
>acceptable process before the request from .homenet can be considered

Don't forget

  - waits many, many years while ICANN does what ICANN does about anything new

At this point I see the only plausible options as choose .homenet and
require all validating resolvers to special-case it, or choose
.homenet.arpa and put whatever DNSSEC magic we need into .arpa.

While I don't think that the technical issues are particularly complex
around changing the rules to put a .homenet stub or opt-out in the
root, I can absolutely guarantee that if ICANN considers it, there
will be a long queue of opportunists insisting that their particular
awful root hacks are just like .homenet and ICANN has to do them, too.
They are wrong, but ICANN is poorly defended against people with a
mission and a lot of free time.

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Mar 2017 08:34:14 -0400

> .homenet.arpa and put whatever DNSSEC magic we need into .arpa.

The working group is aware of the "wait many years" part of this approach, and is willing to try and see.   If the working group sees no progress over the course of the next few years, we may shift to the latter approach.

At present, the former approach isn't necessary because hosts don't validate.   It could be argued that we are not treating this potential emergency seriously enough; one solution would indeed be to require that resolvers special-case .homenet, but if we are to do that, it would be good to have a complete specification for how that is done, and that would be in a follow-on document.

---

From: "John R Levine" <[email-masked]>
Date: 23 Mar 2017 10:00:31 -0400

> The working group is aware of the "wait many years" part of this 
> approach, and is willing to try and see.  If the working group sees no 
> progress over the course of the next few years, we may shift to the 
> latter approach.

Just out of curiosity, is there anyone in the homenet WG who regularly 
engages with ICANN, through AC's or SO's or the like?

R's,
John

---

From: Matthew Pounsett <[email-masked]>
Date: Thu, 23 Mar 2017 10:06:10 -0400

> appeared, in November 2016, but it’s always the AD’s prerogative to ask for
To first answer the two questions in the call for reviews:  I see no
technical problems either with the RFC6761 application in the draft, or
with having an unsecured delegation in the root zone, should 'homenet.' be
chosen to anchor HNCP names.   There's a clear technical need for special
handling at the border between the local network and the Internet (local
names) and–in the absence of a specification for getting local trust
anchors into every validating resolver inside the local network–an
unsecured delegation for whatever name is chosen to facilitate end-to-end
security.

The reason we have a problem here is that this has been gone about in
entirely the wrong order, and procedurally leaves the IETF in a difficult
position.  We have no business demanding a root zone delegation from ICANN,
and publishing an RFC that requires that to happen in order to be useful is
tantamount to making that demand, regardless of how nicely the demand is
worded.

The need to correct the mistakes of the HNCP draft has, I think, resulted
in a rush that has been detrimental to careful consideration.  At the risk
of repeating the obvious, so that I can refer back to this list, what
should have been done is:
1) speak to ICANN (the community) about whether/how it's possible for IETF
to reserve & delegate an unsecured name from the root
2) if the community says yes, and after a process is defined, pick a name
that doesn't conflict with anything (including DITL research)
3) write the draft to reserve the name

While I appreciate that there's some risk this name might be exposed to end
users, and that perhaps some tiny percentage of end users might react badly
to seeing a reference to ARPA, I think that exposure is mostly going to
happen with technology professionals and hobbyists (power users), not the
typical home user.  So while it still may be preferable to use homenet.
over homenet.arpa., I'm unconvinced that it *needs* to be that way.

If HOMENET is set on trying for homenet., then I would recommend proceeding
with draft-ietf-homenet-redact, and shelving this draft until (1) and (2)
can be completed.

If there's a need that draft-ietf-homenet-dot be finalized before (1) and
(2) can happen, then homenet. should be replaced with homenet.arpa..

- Matt

PS: given that there is already talk of lawsuits over home. and corp., and
given that for any name that might be chosen there's likely somebody out
there in the world that thinks that name might be valuable to register, I
think the chances of getting a 'yes' out of the ICANN community is very
nearly zero.

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 23 Mar 2017 10:36:54 -0400

Hi all, and not picking on John….

I think this subthread on process and policy has gone as far as we reasonably can in a DNSOP review of draft-ietf-homenet-dot. We’ve established that different constraints and expectations apply to policy for different portions of the namespace, and that the HOMENET WG believes those differences have been taken into account, and that not everyone in DNSOP agrees.

Please share any new thoughts on how the specified protocol in the draft interoperates with the global public DNS, particularly with regards to DNSSEC or possibly incompatible uses of the namespace, which seem to be within our chartered scope.

I believe the process and policy concerns we’ve raised here can be revisited in an additional request for review or an IETF Last Call, if needed.

thanks,
Suzanne

> On Mar 23, 2017, at 10:00 AM, John R Levine <[email-masked]> wrote:
> 
> Just out of curiosity, is there anyone in the homenet WG who regularly engages with ICANN, through AC's or SO's or the like?
> 
> R's,
> John
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Mar 2017 11:07:08 -0400

> Just out of curiosity, is there anyone in the homenet WG who regularly engages with ICANN, through AC's or SO's or the like?

Possibly one of the two working group chairs.   But how is this relevant?

What's going on here is that we've stumbled over a gap in expectations between IETF participants and the general I* leadership, including ICANN.   What the MoU says is pretty clear, although it certainly could have been a lot clearer, and perhaps many fewer tears would have been shed over this if it had been clearer.

The problem is not that homenet are naive, or that ICANN is difficult, or anything like that.   It's that we are treading new ground.   This is ground we need to tread.   If in fact asking ICANN for delegations in cases of technical uses under the MoU is the wrong thing to do, we should know that.   If it is the right thing to do, we should have a process for doing it.  If the way the document asks is impolitic, we should fix that—it's certainly not what was intended.

I really don't know why we're arguing about this here.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 23 Mar 2017 12:32:05 -0400

Hi,

> The working group is aware of the "wait many years" part of this approach, and is willing to try and see.   If the working group sees no progress over the course of the next few years, we may shift…

As a comment on the document, then (that is what we're discussing,
right?), I'd note that the plan for allocation of a special-use name
contained in the draft does not state clearly (at least in my reading)
whether it is conditional on receiving the relevant unsigned
delegation.  If it _is_ so dependent, then that would be important to
know.  If it is _not_ so dependent, then probably some additional text
is needed (maybe in the security considerations) about the likely
failure of DNSSEC or resolution in such a context.

I hope that's helpful,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ray Bellis <[email-masked]>
Date: Thu, 23 Mar 2017 10:24:57 -0700

> failure of DNSSEC or resolution in such a context.

Good point.

I consider them to be _independent_.  The special use reservation
mustn't be held up waiting for the requested insecure delegation.

Ray

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 23 Mar 2017 13:34:08 -0400

Hi Ray,

> On Mar 23, 2017, at 1:24 PM, Ray Bellis <[email-masked]> wrote:
> 

I’m trying to make sure I understand what the special use reservation accomplishes in the absence of the insecure delegation.

If I read your comment correctly, I can infer two things about the protocol, whether the insecure delegation is delayed or refused, at least in the short term:

1. The protocol is sufficiently functional for deployment without working capability for DNSSEC validation.

2. Having a single-label name is more important for the functioning of the protocol than having DNSSEC validation work.
 
Is this a fair assessment of the WG’s view?

thanks,
Suzanne

---

From: Ralph Droms <[email-masked]>
Date: Thu, 23 Mar 2017 13:40:29 -0400

> On Mar 23, 2017, at 1:34 PM, Suzanne Woolf <[email-masked]> wrote:
> 
> Hi Ray,
> 

Clarification: does this mean "without DNSSEC validation initially but DNSSEC validation is needed eventually" or  "even if DNSSEC validation is never available"?

- Ralph

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 23 Mar 2017 13:43:06 -0400

> On Mar 23, 2017, at 1:40 PM, Ralph Droms <[email-masked]> wrote:
> 
> 
> Clarification: does this mean "without DNSSEC validation initially but DNSSEC validation is needed eventually" or  "even if DNSSEC validation is never available”?

I meant the question to cover both cases. The second question may well be more important in the “never available” case, but that’s part of what I’m trying to understand.

thanks,
Suzanne

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Mar 2017 13:49:49 -0400

> I meant the question to cover both cases. The second question may well be more important in the “never available” case, but that’s part of what I’m trying to understand.

I think in the "never available" case we would obsolete the allocation and choose home.arpa instead.   That would be a bad outcome; if we really think there is no chance of this allocation happening, we shouldn't go down this path.   But I persist in claiming that we need to go down this path one way or the other to get clarity on where we stand with technical uses under the MoU.   We should have done this back in 2000, but better 17 years late than never.

Do please note that what we have proposed does not cause DNSSEC validation to work: rather, absent a pre-configured trust anchor, it causes it to be skipped.

---

From: Ray Bellis <[email-masked]>
Date: Thu, 23 Mar 2017 10:50:14 -0700

On 23/03/2017 10:34, Suzanne Woolf wrote:

> I’m trying to make sure I understand what the special use reservation
> accomplishes in the absence of the insecure delegation.
> 
> If I read your comment correctly, I can infer two things about the
> protocol, whether the insecure delegation is delayed or refused, at
> least in the short term:
> 
> 1. The protocol is sufficiently functional for deployment without
> working capability for DNSSEC validation.

Correct, in so much as "the protocol" is actually "DNS".

The HNCP protocol is only used to configure the domain name used for
local resolution, but Homenet's zeroconf nature requires that there be a
default value, and as such Homenet / HNCP is not fully deployable
without an agreed default.

The presence of ".home" as that default in RFC 7788 was a mistake, and
the current pair of drafts is our attempt to rectify that.

Hence w.r.t Matt Pounsett's argument that the -redact document go first
and then the assignment of ".homenet" be done later, the Homenet WG has
argued *very* strongly that this is not acceptable because it leaves
HNCP in an indeterminate state.

> 2. Having a single-label name is more important for the functioning
> of the protocol than having DNSSEC validation work.
> 

Not quite - DNSSEC should work correctly on any Homenet resolver which
has the appropriate trust anchor configured.

The insecure delegation is required to allow validating stub resolvers
in hosts to access .homenet names without the signed proof of
non-existence that's currently in the root from getting in the way.

Since those validating stubs are currently exceedingly rare, we can live
without that insecure delegation _for now_.

Ray

---

From: Paul Wouters <[email-masked]>
Date: Thu, 23 Mar 2017 14:03:37 -0400 (EDT)

> 1. The protocol is sufficiently functional for deployment without working capability for DNSSEC validation.

No, what was said was there wasn't very much dnssec validating stubs out
there to cause visible problems at this moment.

> 2. Having a single-label name is more important for the functioning of the protocol than having DNSSEC validation work.

The phrase "more important" is pretty meaningless. And as was indicated,
it is all based on the levels of DNSSEC deployment on stubs, which could
change dramatically if one phone vender would suddently enable
validation or default to DNS-over-TLS to 8.8.8.8.

I would also want to add that dnsop (including myself!) pretty much
failed the homenet WG. We were asked to review docs before RFC-7788
got published in April 2016. Then we raised the alarm about .home
and I remember .homenet being a very early alternative, maybe even
suggested by dnsops. And now a year later dnsops is back to telling
homenet they cannot use this string either. I don't think they deserve
another one or two years waiting time to talk about homenet.arpa or
homenet.ietf.

I would again like to suggest that Special Use Names is moved to be
discussed outside dnsops.

Paul

---

From: Ray Bellis <[email-masked]>
Date: Thu, 23 Mar 2017 11:07:49 -0700

> validation or default to DNS-over-TLS to 8.8.8.8.

To be fair, if they did _only_ the latter then the .homenet names would
never resolve anyway...

Ray

---

From: Ralph Droms <[email-masked]>
Date: Thu, 23 Mar 2017 14:11:17 -0400

> On Mar 23, 2017, at 1:50 PM, Ray Bellis <[email-masked]> wrote:
> 
> 
> 

No snark intended, but if "the protocol" were really just DNS, we wouldn't be having this discussion.  Rather, it is the DNS wire protocol using a local resolution context rather than the root zone.  In any event, yes, the locally server homenet zone can function with DNSSEC.

As I see the situation, a problem arises if there is a requirement for DNSSEC at some point in the future, and ".homenet" is found to be unusable as the special-use domain name.  It would be unfortunate to deploy devices with ".homenet" now and find that needs to be changed in the future.

> HNCP in an indeterminate state.

On the other hand, not publishing -redact now leaves ".home" in an indeterminate state in an Internet Standard, for example relative to the TLD assignment process in ICANN.

> without that insecure delegation _for now_.

Again, I'll argue that "for now" is a potentially problematic way of looking at the issue, considering there may be several years of deployment between the selection of .homenet as an SUDN and determination of whether or not the necessary entry in the root zone can be added.

- Ralph

---

From: Paul Wouters <[email-masked]>
Date: Thu, 23 Mar 2017 14:13:45 -0400 (EDT)

> To be fair, if they did _only_ the latter then the .homenet names would

Correct, and DNS software has to be updated to handle this, just like it
needs updating to handle .local and .onion. If the Powers That Be can
agree on the string, we can start updating DNS software now so we are
ready when 5G hits :P

Paul

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Mar 2017 14:30:56 -0400

> No snark intended, but if "the protocol" were really just DNS, we wouldn't be having this discussion.  Rather, it is the DNS wire protocol using a local resolution context rather than the root zone…

So do locally-served zones, by this definition, use a different protocol?

---

From: Matthew Pounsett <[email-masked]>
Date: Thu, 23 Mar 2017 15:38:39 -0400

On 23 March 2017 at 13:50, Ray Bellis <[email-masked]> wrote:

> On the other hand, as Ralph Droms points out, not going ahead with either
leaves .home in an indeterminate state.  And, going ahead with both in the
absence of an answer on the homenet. insecure delegation (assume a
hypothetical third hand) leaves the whole thing undeployable in the
presence of any validation between the local nameserver authoritative for
.homenet and and-user applications.  Validating applicatinos, stubs,
localhost resolvers, and forwarders all break HNCP, unless I've completely
misunderstood something.

Since we're trying to encourage validation as close to the application as
possible, I would think we'd avoid attempting to deploy things that cannot
work with application-level validation.

---

From: Dan York <[email-masked]>
Date: Thu, 23 Mar 2017 20:11:17 +0000

Ted or Ray or others more involved with Homenet, (I have not been)

I've not fully read all of the 80+ messages in this thread over the past couple of days, but Paul's comment below (as well as Ralph Droms' comment the other day about code) made me wonder:

- Do we have any sense of whether people in the industry are going to implement these Homenet protocols in actual devices and operations? 

Have any large vendors committed to deploying the protocols? Software vendors? Hardware vendors?

Or to put it another way - do we have businesses out there asking for these kind of solutions?  Or who are we building it for?

I ask in part because if the IETF did decide to go down the route of interacting with ICANN to make special exceptions in the root zone, these are exactly the kind of questions I could see people at ICANN asking.  It would also speak to the timeframe question. If there are people clamoring for this functionality, that might raise its priority.

Again, I've not been involved with the Homenet WG. I have a very basic understanding of the problem the WG is seeking to solve. But I'm not clear how large of a problem this is seen as within the larger industry.

Thanks to anyone who can shed light on this,
Dan

> On Mar 23, 2017, at 2:13 PM, Paul Wouters <[email-masked]> wrote:
> 

--
Dan York
Senior Manager, Content & Web Strategy, Internet Society
[email-masked]   +1-603-439-0024 
Jabber: [email-masked]  Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Mar 2017 17:01:36 -0400

> I ask in part because if the IETF did decide to go down the route of interacting with ICANN to make special exceptions in the root zone, these are exactly the kind of questions I could see people a…

I can see ICANN people asking these questions too.   However, I wonder if this is really the right approach.   If the IETF has the right under the MoU to ask for root delegations, then it seems to me that the IETF should just be allowed to ask.   There should obviously be a process, and the IETF should not ask frivolously, and certainly shouldn't ask as a way to bypass the gTLD process.   But ultimately it doesn't make sense to me for ICANN to ask this question.

Either IETF can ask for technical-use TLDs to be delegated, or it can't; the question from ICANN's perspective ought to be "(a) is this a technical use?  if not, IETF has no special access.   if so, (b) is the name in dispute?   If so, IETF can't have it.   If not, IETF can have it."   Of course, I'm sure that's hopelessly naive, but the point is that we need to have this conversation and figure this out.   This is true whether the IETF goes ahead with .homenet or not, so whether this is hard or not really shouldn't be a determining factor in whether we try to get .homenet delegated.

That said, of course you can ask this question _in the IETF_ and maybe it's a good question.   The answer is that there is a lot of _interest_, but it's not clear to me that this interest will transform immediately into product on the shelf.   My expectation is that it will start out in open source distros, and in a few high end boxes, and trickle down.   I know various vendors and operators have expressed strong interest in this in the past, but the difficulty of making any forward progress at all within the IETF (this being an example) has been discouraging for them.

So at this point I can't promise that if we build it they will come; they are already here, but they are a bit frustrated, and that could have a negative impact on deployment.   But we wouldn't be trying to build this if we didn't think it was worth building.

---

From: Ray Bellis <[email-masked]>
Date: Thu, 23 Mar 2017 14:35:03 -0700

On 23/03/2017 14:01, Ted Lemon wrote:
> My expectation is that it will start out in open source distros, and
> in a few high end boxes, and trickle down.

AIUI, bits of the Homenet stack (including HNCP) are already available
in OpenWRT.

Ray

---

From: Matt Larson <[email-masked]>
Date: Thu, 23 Mar 2017 17:43:07 -0400

> On Mar 23, 2017, at 2:30 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Mar 23, 2017, at 2:11 PM, Ralph Droms <[email-masked] <mailto:[email-masked]>> wrote:

I think saying "different protocol" is not accurate and risks being a distraction.  Rather, Ralph's comment about "resolution context" is important and gets to the heart of the issue.  Before DNSSEC, a recursive name server could also be authoritative for local zones or use other mechanisms (such as stub zones and conditional forwarding) to "short circuit" resolution to handle the local context and not send traffic to the root, and everything resolved just fine.  Now, with DNSSEC validation enabled, zones in this "local resolution context" need to chain up to a trust anchor somewhere.  If there's not a chain of trust from the root, a local trust anchor is needed for validation to succeed.

Consider a corporate split DNS example.  Let's say Acme Corp maintains two versions of the zone acme.com <http://acme.com/>, one for external consumption (delegated to from .com) and another version for internal use.  Their internal recursive name servers use some mechanism (local authoritative zones, stub zones, etc.) to ensure that internally generated queries resolve against the internal version of acme.com <http://acme.com/>.  Let's also say that Acme Corp signs both the internal and external versions of acme.com <http://acme.com/> and that their internal recursive servers have DNSSEC validation enabled.  The chain of trust from the root leads to the external acme.com <http://acme.com/>, so the internal recursive servers will need a trust anchor for the internal version of acme.com <http://acme.com/> or validation fails.

homenet uses a local resolution context without a local trust anchor, hence the request for special casing in the root.

Matt

---

From: Ralph Droms <[email-masked]>
Date: Thu, 23 Mar 2017 17:47:48 -0400

> So do locally-served zones, by this definition, use a different protocol?

As Matt Larson just pointed out, "different protocol" may turn into a distraction.  .homenet is asking for an entry in the special-use domain name registry and a specific kind of entry in the DNS root zone.  I take those characteristics to differentiate homenet, perhaps as an extension or variant of DNS.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Mar 2017 17:54:31 -0400

> As Matt Larson just pointed out, "different protocol" may turn into a distraction.  .homenet is asking for an entry in the special-use domain name registry and a specific kind of entry in the DNS r…

Is this even necessary?   The MoU uses the example of in-addr.arpa, which is resolved using the DNS protocol, so from the perspective of the MoU, I don't think it is.

---

From: George Michaelson <[email-masked]>
Date: Fri, 24 Mar 2017 08:20:59 +1000

here we go again "because its in running code, its too late to change
so my pre-emptive decision to code to it, trumps any process you ask
we invoke now"

thats called squatting: its what other people do. and I repudiate it.

you should have coded to example.com or a nonce.

-G

---

From: Ray Bellis <[email-masked]>
Date: Thu, 23 Mar 2017 15:26:36 -0700

> you should have coded to example.com or a nonce.

Actually, what's in the code right now is ".home".

The whole point is to get ".homenet" blessed _before_ the code gets
updated to use that, but we also want the amount of time that takes to
be minimised so that the currently baked-in use of ".home" doesn't make
that the de-facto default in perpetuity.

Ray

---

From: George Michaelson <[email-masked]>
Date: Fri, 24 Mar 2017 09:08:32 +1000

then I un-take my rant. apologies for ranting.

but to the sw authors of OpenWRT grrrrrr. parameterized? runtime configurable?

---

From: Ray Bellis <[email-masked]>
Date: Thu, 23 Mar 2017 16:16:52 -0700

> but to the sw authors of OpenWRT grrrrrr. parameterized? runtime configurable?

The option value is run time configurable, because the home owner might
have their own domain that they wish to use.

The argument is over what the default value is that takes over in the
zeroconf case when one hasn't been configured.  I haven't studied the
code to see how its value is specified.

Ray

---

From: Ralph Droms <[email-masked]>
Date: Thu, 23 Mar 2017 22:28:42 -0400

> On Mar 23, 2017, at 5:54 PM, Ted Lemon <[email-masked]> wrote:
> 
> Is this even necessary?

"this" == "differentiate homenet from DNS"?

>   The MoU uses the example of in-addr.arpa, which is resolved using the DNS protocol, so from the perspective of the MoU, I don't think it is.
> 

I was mostly referring to the idea that DNSSEC will work because the homenet name resolution mechanism is "just DNS".  I thought it was important to point out that homenet name resolution isn't exactly DNS, so we should be careful to make assumptions about its behavior based on DNS.

- Ralph

---

From: Ozgur Karatas <[email-masked]>
Date: Sun, 26 Mar 2017 18:17:28 +0300

Hello,

>>  RFC 3172 was written in 2001…

the last updated was made in 2013, right?

Regards,

Ozgur

---

From: Suzanne Woolf <[email-masked]>
Date: Sun, 26 Mar 2017 16:47:15 -0400

> On Mar 26, 2017, at 11:17 AM, Ozgur Karatas <[email-masked]> wrote:
> 
> Hello,
> 

The text of the document did not change. The date appears to be an artifact of a change to the datatracker database or tools, not the content or status of the underlying document.

Suzanne

---

From: "John Levine" <[email-masked]>
Date: 26 Mar 2017 21:06:03 -0000

In article <[email-masked]> you write:
>The text of the document did not change. The date appears to be an artifact of a change to the datatracker
>database or tools, not the content or status of the underlying document.

Probably RFC 7050 which established ipv4only.arpa in November 2013.

R's,
John

---

From: Richard Lamb <[email-masked]>
Date: Sun, 26 Mar 2017 17:12:16 -0700

+1 to all from  frmr usgovie.  We ain't that clever.

On Wednesday, March 22, 2017, Jim Reid <[email-masked]> wrote:

>
> > On 21 Mar 2017, at 14:53, Suzanne Woolf <[email-masked]
> <javascript:;>> wrote:
> >
> RFC 3172 was an attempt to rewrite history and contrive an acronym:
> Address and Routing Parameter Area - really?
>
> > Respectfully, I’ve always wondered who has this problem (US or non-US)
> besides network infrastructure geeks Of a Certain Age (yes, including
> myself, and many IETF participants).
>
> It's a convenient tool for those hostile to USG "control" of the Internet:
> ie the US military is responsible for everything under .arpa, the US
> military's ARPA has still got some special status in the
> operation/development/control of the Internet, etc, etc. [And say things
> like "if .arpa isn't for US military control, why can't the string be
> changed?" or ".arpa hasn't been renamed since the Internet started 25-30
> years ago. That proves ARPA/DoD is in charge of the Internet.".] It's utter
> nonsense of course. But that doesn't stop government officials and
> policymakers from making these arguments. I have seen them do this many
> times. Sigh. RFC3172 didn't make things better.
>
> [email-masked] <javascript:;>

---

From: George Michaelson <[email-masked]>
Date: Sun, 26 Mar 2017 19:36:55 -0500

Its only my personal opinion, but I think the opposition to use of
.ARPA is almost entirely fictive at this point.  In no sense is the
domain solely used or intended for PTR requests, and I have
successfully operated domains which vest A, AAAA and TXT records in
the zone. Its just a string of characters under a prefix.

The useful quality of the prefix is that it was grandfathered in, and
its vested solely and wholly within agencies which are bound to our
process and behaviour norms. Many of the questions over RFC6761 simply
don't apply in .ARPA. There is no problem statement because there is
no problem.

Like all zones of grandfathers age, zone update and publication is a
bit more arcane than we might want, but thats a surmountable problem.

I would far rather see ALT.arpa and notDNS.arpa and even xn--ls8h.arpa
than almost any other alternative right now.

I have absolutely no problem with HOME.arpa and HOMENET.arpa

I expect almost all of the responses to be human- behaviour ones,
which go to "I don't like it because" so I feel no compunction saying
I do like it.

I particularly like that we don't actually have to do very much beyond
note it, and ask IANA to operate a registry for it.

-G

---

From: David Conrad <[email-masked]>
Date: Sun, 26 Mar 2017 17:54:07 -0700

Hi,

On Mar 26, 2017, 5:37 PM -0700, George Michaelson <[email-masked]>, wrote:

> In no sense is the domain solely used or intended for PTR requests,

Is anyone claiming this? If so, that'd be really silly given the contents of the .ARPA zone is:

as112.arpa.
e164.arpa.
in-addr-servers.arpa.
in-addr.arpa.
ip6-servers.arpa.
ip6.arpa.
ipv4only.arpa.
iris.arpa.
uri.arpa.
urn.arpa.

Of those, only two are used for PTR requests.

> note it, and ask IANA to operate a registry for it.

I'll admit I'm a bit confused: what would be in such a registry?

Truth be told, I sort of like the "home.arpa" idea -- seems to dodge a lot of layer 9 stuff (unless, of course, the whole point is to try to resolve layer 9 issues).

Regards,
-drc

---

From: George Michaelson <[email-masked]>
Date: Sun, 26 Mar 2017 20:55:00 -0500

> Of those, only two are used for PTR requests.

Right. Its the 'but ARPA is for reverse DNS' statement which some
people make. I was trying to say no. You said it better. factually.

> I'll admit I'm a bit confused: what would be in such a registry?

the things which are proposed to be in 6761's registry. things which
are being defined as 'doesn't exist' for instance. And, the things
which are required to exist, since some of the SUTLD problem statement
encompasses 'but we need this because SPECIAL' which implies a
delegation. So for both the non-delegated unique assignments in 6761
AND the unique assignments for other reasons, we would have an IANA
registry to say what labels are either repudiated, or accepted and on
what RFC basis.

>
> Truth be told, I sort of like the "home.arpa" idea -- seems to dodge a lot
> of layer 9 stuff (unless, of course, the whole point is to try to resolve
> layer 9 issues).

I want to solve the layer 9 issue by avoiding the layer 9 issue. The
only winning move is not to play. So lets not play in the root.

-G

---

From: Ted Lemon <[email-masked]>
Date: Sun, 26 Mar 2017 21:38:06 -0500

On Mar 26, 2017, at 7:36 PM, George Michaelson <[email-masked]> wrote:
> .ARPA is almost entirely fictive at this point.

I take it that since this is just your personal opinion, we need not discuss it any further?

Forgive me, but I do not think remarks of this sort are constructive.   If there is a reason why the working group consensus should not be followed, it is not that the working group's consensus on the question is "fictive," whatever that means.

My opposition to .arpa, such as it is, is that it suggests a hierarchy that is not present.   I think it's bad UI design, and that's why I prefer .homenet.   This is not a "fictive" objection.   You could argue that I am wrong, or that my opinion on the topic doesn't matter, or that even though I am right, other factors are more important, or that allowing the working group to decide matters like this is wrong, or that this is all irrelevant because we can't have it anyway.

But calling it "fictive" is disrespectful of reasoned discourse, and I encourage those various folks on this thread who have made similar arguments to please try to do better.   I mean no disrespect by this—I'm sure you've been on the receiving end of me making similarly bad arguments.   I just felt it necessary to point out.

---

From: George Michaelson <[email-masked]>
Date: Sun, 26 Mar 2017 21:51:04 -0500

I was thinking about the 'because its the (D)arpa" opposition when I
said that. I think *that* stated reason, is mostly now, a phantom.
Maybe I'm wrong on that too. Maybe its a giant political layer9
football which will come back to haunt us, forever. Given how much of
the planet happily goes into the RIR system to register PTR records
for their addresses, I'm struggling to believe this is a choke-issue
of significance.

You argue a case, as a question of human interaction. You see the
domain as one which is going to require human input, human engagement.
You want a TLD because you want people to interact with it, as a name.
This is not sounding to me like an infrastructure, technical driver
for the existence of a label, it sounds like a use case for UI design
goals, which demands the label exist. Thats the same reasoning as
.Onion was, in some ways.  Thats not a fictional driver, its a strong
motivation. So, I think that argument goes to the part not covered by
"most" in my badly worded statement. I can actually "understand" that
as a real driver. For english speakers, anyway.

The rest of your point, the quality of discourse.. I concede. I wrote
badly.  I deserved your rebuke.

-G

On Sun, Mar 26, 2017 at 9:38 PM, Ted Lemon <[email-masked]> wrote:
> Forgive me, but I do not think remarks of this sort are constructive.   If
> there is a reason why the working group consensus should not be followed, it
> is not that the working group's consensus on the question is "fictive,"
> whatever that means.
>
> My opposition to .arpa, such as it is, is that it suggests a hierarchy that
> is not present.   I think it's bad UI design, and that's why I prefer
> .homenet.   This is not a "fictive" objection.   You could argue that I am
> wrong, or that my opinion on the topic doesn't matter, or that even though I
> am right, other factors are more important, or that allowing the working
> group to decide matters like this is wrong, or that this is all irrelevant
> because we can't have it anyway.
>
> But calling it "fictive" is disrespectful of reasoned discourse, and I
> encourage those various folks on this thread who have made similar arguments
> to please try to do better.   I mean no disrespect by this—I'm sure you've
> been on the receiving end of me making similarly bad arguments.   I just
> felt it necessary to point out.
>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 26 Mar 2017 22:19:26 -0500

> for their addresses, I'm struggling to believe this is a choke-issue

I don't think there is any functional problem with hn.arpa: it could certainly work as a domain under which to put homenet names.   The problem is that it is not representative of what is happening.   With existing uses of .arpa, I don't think this is a problem, but if in fact we expect users to see homenet subdomains, then they should look like what they mean, and they don't mean "a subdomain of arpa."

> for the existence of a label

Here you seem to be claiming that any label that has a meaning that is meant to be understood by end users is not a technical use.   This is not stated in the MoU.   Essentially, if it would be better to reserve a label in the root than under .arpa, then by definition we cannot.   If that's the case, where is the technical use provision in the MoU applicable?   It only makes sense for zones operated by ICANN, and the only zone operated by ICANN of which I am aware (perhaps naively) is the root zone.

So you would seem to be arguing that that provision in the MoU could be struck without harm.   If so, why was it put there in the first place?

---

From: George Michaelson <[email-masked]>
Date: Sun, 26 Mar 2017 22:47:32 -0500

I really have a problem with "that it is not representative of what is
happening" -I mis-wrote to Ray, regarding how I believed he was
characterizing OpenWRT code. How am I meant to interpret what you
wrote here? Why am I not expected to respond, that is squatting in the
face of a discussion about WHY, let alone HOW the delegation should
happen? I should say that when I recall how the XMPP people felt when
they got pushback over standardization of jabber, I felt a lot of
sympathy for their "your nuts" rant: If people are doing this, maybe
recognizing reality is the best option. But that said, This feels like
technical domain-squatting. Thats how I understand 'what is happening'
to be meaingful, but maybe you meant something else? (I really want to
know btw)

I'd invert that second question: if the strong point of merit driving
requests into ICANN for delegation or reservation of labels is the
sense users interact with them, that has to be clearly stated in the
MoU: If there is a technical requirement for a label, it has to be
very very strong to require a new reference in the "." anchored
namespace. If it can exist in s/w under .Arpa it makes far more sense
to do that, than incur the consequence of asking for special treatment
in a heavyweight process. So I think the arbiter in a technical sense,
is "why can't this exist under an existing namespace". I am not
convinced any of the p2p network requests, hash labels, other novel
non-domain forms of label actually have a good case here.  Your
requirement for .homenet/home/.hn is because you expect it to be used
in ways which you believe demand that top state, for people. Thats
where we descend into an argument about if user-needs are technical
(in the sense 6761 meant) or not. I think you made a case they are. So
I am trying to think that way, and reflect on them that way.

(Alain I believe, possibly others has pointed out that any delegation
change in the root zone carries cost consequence which we make light
of, decrying it as lawyer food, but it does exist, and it does have to
be understood as a cost to the community in the wider sense)

I believe the technical merit language was written in a time when we
thought machine-led purposes would dictate needs. I do not believe it
was drawn up for modern times, and I think it was a naieve decision to
proceed with the MoU, and (re)open the door.

So, if the MoU doesn't say "either because strong machine-technical
requirement places this at the root" (I think despite my opposition,
the case for Onion probably had this because of the CA issuance
requirements) or "human interaction requirements make this a
technically motivated label eg home-use excluded from global DNS, but
for human reasons ANCHORED at the root, not a 2LD or 3LD" .. then
maybe it should? Said better of course.

A reductionist response to user need would be "user pays" -Its not one
I like, or subscribe to. But I am driven to note it.
In that sense, it might even be, that the wisest, simplest path for
the IAB to request new gTLD is to offer to pay for the costs, and make
the community understand every time they put this into the IANA
requirements or IAB directions, they are asking real money to be
spent. It would certainly focus the mind.

-G

---

From: Ted Lemon <[email-masked]>
Date: Sun, 26 Mar 2017 22:58:33 -0500

On Mar 26, 2017, at 10:47 PM, George Michaelson <[email-masked]> wrote:
> If there is a technical requirement for a label, it has to be
> namespace.

But the reason you feel this way is that such allocations would preclude gTLD allocations.   gTLD was not anticipated when the MoU was written.   The decision by ICANN to go down that route should not suddenly make it a million times more fraught for the IETF to exercise its use of that part of the MoU.   I assume that ICANN understood the MoU when they went down the gTLD path, so asking the IETF to now self-censor because of this change of circumstance seems unreasonable.

IoW, I do not believe that this is a reasonable test.   The test is not that there be a "strong technical requirement" but that there be a technical use.   Obviously this doesn't give the IETF the right to demand a name that someone else has already laid claim to.   This is why we selected '.homenet.'   AFAIK nobody else wants this name.

The accusation of squatting is silly.   We are going through the correct process.   No squatting is occurring.   '.home' has been used informally by entities other than the participants in the homenet working group, so you can't even accuse us of squatting on that; rather, it was the intention of the proponents of that name to simply make better use of it than the squatters were, in a way that wouldn't impinge on them.

---

From: "Patrik Fältström" <[email-masked]>
Date: Mon, 27 Mar 2017 09:52:33 +0200

> the last updated was made in 2013, right?

One important part is in the letter from NTIA (Karen Rose) to ICANN (Louis Touton) in Appendix A.

A letter sent April 28, 2000.

   Patrik

---

From: Ray Bellis <[email-masked]>
Date: Mon, 27 Mar 2017 07:41:43 -0500

> A letter sent April 28, 2000.

Is it online?   I can't find it in the ICANN correspondence archive.

Ray

---

From: "Patrik Fältström" <[email-masked]>
Date: Mon, 27 Mar 2017 14:51:02 +0200

> Is it online?   I can't find it in the ICANN correspondence archive.

RFC 3172, Appendix A.

<https://tools.ietf.org/html/rfc3172>

   paf

---

From: Jim Reid <[email-masked]>
Date: Mon, 27 Mar 2017 13:51:42 +0100

> On 27 Mar 2017, at 13:41, Ray Bellis <[email-masked]> wrote:
> 

It's in RFC3172.

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 27 Mar 2017 10:36:44 -0400

> On Mar 27, 2017, at 8:41 AM, Ray Bellis <[email-masked]> wrote:
> 
> 
> 

It’s Appendix A to RFC 3172.

Suzanne