Subject: Re: [homenet] WGLC on "redact" and "homenet-dot"

From: Ray Bellis <[email-masked]>
Date: Thu, 1 Dec 2016 14:02:38 +0000

On 21/11/2016 13:25, Ralph Droms wrote:
> (Updated comments on draft-ietf-homenet-dot originally posted prior to the WG last call)

Thanks Ralph.

I'd like to remind the WG that the LC is due to run until Friday
December 16th, so please anyone else with comments please get them in.

Ray

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Dec 2016 10:46:24 -0500

One thing that I think the working group should be aware of, although I
don't know if this awareness will change anything, is that the situation
with the .homenet allocation is less simple than we would prefer: it's not
really simply a matter of adding .homenet to the special use domain names
registry.   The reason is that we need DNS resolution to work properly for
domains under .homenet, and this has to work even if a host is doing DNSSEC
validation.

At present, if you were to configure a homenet router with .home or
.homenet as the local domain, this would work perfectly nicely until you
turned on DNSSEC validation, at which point all the names in either
hierarchy would disappear.   The reason for this is that the root zone
provides proof of nonexistence for nonexistent names in that zone.

It is possible to address this problem by requesting ICANN to put an
insecure delegation in the root zone.   The problem is that from a process
perspective, this is a _lot_ more heavyweight than doing a special-use
domain name allocation, and has no guarantee of success.   This wasn't such
an issue for .onion when we did it, because .onion _wants_ a secure denial
of existence--we _never_ want a .onion query to actually happen if the name
has been handed to a resolver that doesn't understand .onion explicitly.
This is not true for .homenet.

There are two approaches we can take to this.   One is to proceed--ask
ICANN to do the delegation and see what happens.   The other is to take the
more expedient, less satisfying approach: use .home.arpa instead of
.homenet.   I'm not in love with this as an end solution, but it has the
advantage that the IAB controls .arpa, and so we can get an unsecure
delegation right away assuming the IAB agrees.   I see no reason to think
they would not.   It's a bit more typing, and there is the problem that the
fourth google result for arpa is "Advanced Research Projects Agency.   But
it would work, and quickly, and would keep the whole process in the family.

The other alternative is to continue with the original plan: do the
special-use names registry allocation, and send a liason to ICANN asking
them to do the unsecure delegation.   The downside to this approach is that
we won't know whether the outcome will be success or failure for a long
time, possibly several years.   And the outcome could very well be failure.
  The upside is that we get the name we all want; the downside is that we
are a long way down the road with no win.

I should point out that whichever way we go, we already have solved the
immediate problem: we have a name that HNCP can use, the potential
liability for IETF is dealt with, and our prototypes can be made to work.
So I am personally okay with either decision.   Our AD, Terry, may have
more of a sense of what ICANN will do (but to some extent he really can't
know, because it's up to committees within ICANN to actually make this
decision).   I'm mentioning this now not to derail the process, but simply
to make it really clear what our expectations should be.   The reason that
this didn't come up in Seoul is that it didn't actually click for me that
we had a serious problem until several of us were chatting on the way out
of the room, after the working group had already decided to proceed.

On Thu, Dec 1, 2016 at 9:02 AM, Ray Bellis <[email-masked]> wrote:

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

---

From: Ralph Droms <[email-masked]>
Date: Mon, 12 Dec 2016 11:29:29 -0500

Ted - thanks for posting a clear summary of the situation for WG discussion and consensus.  Two questions in line…

> On Dec 12, 2016, at 10:46 AM, Ted Lemon <[email-masked]> wrote:
> 
> One thing that I think the working group should be aware of, although I don't know if this awareness will change anything, is that the situation with the .homenet allocation is less simple than we would prefer: it's not really simply a matter of adding .homenet to the special use domain names registry.   The reason is that we need DNS resolution to work properly for domains under .homenet, and this has to work even if a host is doing DNSSEC validation.
> 
> At present, if you were to configure a homenet router with .home or .homenet as the local domain, this would work perfectly nicely until you turned on DNSSEC validation, at which point all the names in either hierarchy would disappear.   The reason for this is that the root zone provides proof of nonexistence for nonexistent names in that zone.
> 
> It is possible to address this problem by requesting ICANN to put an insecure delegation in the root zone.   The problem is that from a process perspective, this is a _lot_ more heavyweight than doing a special-use domain name allocation, and has no guarantee of success.   This wasn't such an issue for .onion when we did it, because .onion _wants_ a secure denial of existence--we _never_ want a .onion query to actually happen if the name has been handed to a resolver that doesn't understand .onion explicitly.   This is not true for .homenet.
> 
> There are two approaches we can take to this.   One is to proceed--ask ICANN to do the delegation and see what happens.   The other is to take the more expedient, less satisfying approach: use .home.arpa instead of .homenet.   I'm not in love with this as an end solution, but it has the advantage that the IAB controls .arpa, and so we can get an unsecure delegation right away assuming the IAB agrees.   I see no reason to think they would not.   It's a bit more typing, and there is the problem that the fourth google result for arpa is "Advanced Research Projects Agency.   But it would work, and quickly, and would keep the whole process in the family.
> 
> The other alternative is to continue with the original plan: do the special-use names registry allocation, and send a liason to ICANN asking them to do the unsecure delegation.   The downside to this approach is that we won't know whether the outcome will be success or failure for a long time, possibly several years.   And the outcome could very well be failure.   The upside is that we get the name we all want; the downside is that we are a long way down the road with no win.

So, now I’m a little confused by the alternatives; for clarity, does the paragraph that begins “The other alternative” refer back to the “ask ICANN to do the delegation” approach?

> 
> I should point out that whichever way we go, we already have solved the immediate problem: we have a name that HNCP can use, the potential liability for IETF is dealt with, and our prototypes can be made to work.

Are you referring to “.home”, “.homenet”, “.home.arpa” or some other name to use as the HNCP default?

- Ralph

> So I am personally okay with either decision.   Our AD, Terry, may have more of a sense of what ICANN will do (but to some extent he really can't know, because it's up to committees within ICANN to actually make this decision).   I'm mentioning this now not to derail the process, but simply to make it really clear what our expectations should be.   The reason that this didn't come up in Seoul is that it didn't actually click for me that we had a serious problem until several of us were chatting on the way out of the room, after the working group had already decided to proceed.
> 
> On Thu, Dec 1, 2016 at 9:02 AM, Ray Bellis <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/homenet <https://www.ietf.org/mailman/listinfo/homenet>
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Dec 2016 11:44:38 -0500

> So, now I’m a little confused by the alternatives; for clarity, does the paragraph that begins “The other alternative” refer back to the “ask ICANN to do the delegation” approach?

Possibly I could have proofread that one more time before I sent it.   The other alternative that I am referring to in the second paragraph is the first alternative I referred to in the first paragraph.   That is, _not_ the expedient version.

> Are you referring to “.home”, “.homenet”, “.home.arpa” or some other name to use as the HNCP default?

What I mean is that whichever alternative we proceed with, we can use that name as the new name to put into the HNCP spec.   So either .homenet or .home.arpa.

---

From: james woodyatt <[email-masked]>
Date: Mon, 12 Dec 2016 11:00:20 -0800

On Dec 12, 2016, at 07:46, Ted Lemon <[email-masked]> wrote:
> 
> I'm not in love with this as an end solution, but it has the advantage that the IAB controls .arpa, and so we can get an unsecure delegation right away assuming the IAB agrees.   I see no reason to think they would not.   It's a bit more typing, and there is the problem that the fourth google result for arpa is "Advanced Research Projects Agency.   But it would work, and quickly, and would keep the whole process in the family.  

A third available option is to obtain a new “regular” top-level domain for IAB to control that has a better name than “arpa.” and use that for the insecure delegation to the “home” subdomain.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Dec 2016 15:03:42 -0500

That is a separate discussion. We can't standardize on a process that
doesn't yet exist.

On Dec 12, 2016 1:59 PM, "james woodyatt" <[email-masked]> wrote:

> I'm not in love with this as an end solution, but it has the advantage
> that the IAB controls .arpa, and so we can get an unsecure delegation right
> away assuming the IAB agrees.   I see no reason to think they would not.
> It's a bit more typing, and there is the problem that the fourth google
> result for arpa is "Advanced Research Projects Agency.   But it would work,
> and quickly, and would keep the whole process in the family.
>
>
> A third available option is to obtain a new “regular” top-level domain for
> IAB to control that has a better name than “arpa.” and use that for the
> insecure delegation to the “home” subdomain.
>
>
> --james woodyatt <[email-masked]>
>
>
>
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Dec 2016 07:25:42 +1100

In message <[email-masked]>, james woodyatt writes:
> > that the IAB controls .arpa, and so we can get an unsecure delegation
> > right away assuming the IAB agrees.   I see no reason to think they would
> > not.   It's a bit more typing, and there is the problem that the fourth
> > google result for arpa is "Advanced Research Projects Agency.   But it
> > would work, and quickly, and would keep the whole process in the family.
>
> A third available option is to obtain a new “regular” top-level domain
> for IAB to control that has a better name than “arpa.” and use that for
> the insecure delegation to the “home” subdomain.

Do you mean a new GTLD with all the baggage that entails or a special
name with a signed delegation in the root zone as apposed to a
insecure delegation or some other mechanism?

The problem with the regular GTLD process is that there is a upfront
cost and annual costs as well as a whole guide book of rules which
are inappropriate for this exercise.

The special names process reserves the name.  It is silent about
adding delegations to the root zone (secure or insecure).

Third mechanism ????

Mark

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

---

From: james woodyatt <[email-masked]>
Date: Mon, 12 Dec 2016 13:30:06 -0800

> Third mechanism ????

Basically, I’m trying to point out that if you don’t like “Advanced Research Projects Agency” showing up in searches on the gTLD part of Home.gTLD when gTLD=arpa, then you can fix that whole class of problem for every IETF working, not just us, by obtaining a new gTLD and using a new subdomain of that instead. That’s the third option available. Not saying it’s a good one. Just that it isn’t one or the other.

Get you a domain that does both: 1) puts the insecure delegation into a zone controlled by IAB, and 2) avoids using the confusing “arpa" gTLD.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Dec 2016 16:32:37 -0500

That is not an option for this working group.   Whether or not it is a good
idea is another topic, but that option is definitely not an option for this
working group, because it is not in our charter.   If some other working
group _had already gotten_ such a TLD, then we could talk about using it,
but placing such a process in the critical path doesn't make sense.

On Mon, Dec 12, 2016 at 4:30 PM, james woodyatt <[email-masked]> wrote:

> Basically, I’m trying to point out that if you don’t like “Advanced
> Research Projects Agency” showing up in searches on the gTLD part of
> Home.gTLD when gTLD=arpa, then you can fix that whole class of problem for
> every IETF working, not just us, by obtaining a new gTLD and using a new
> subdomain of that instead. That’s the third option available. Not saying
> it’s a good one. Just that it isn’t one or the other.
>
> Get you a domain that does both: 1) puts the insecure delegation into a
> zone controlled by IAB, and 2) avoids using the confusing “arpa" gTLD.
>
>

---

From: james woodyatt <[email-masked]>
Date: Mon, 12 Dec 2016 13:56:46 -0800

On Dec 12, 2016, at 13:32, Ted Lemon <[email-masked]> wrote:
> 
> That is not an option for this working group.   Whether or not it is a good idea is another topic, but that option is definitely not an option for this working group, because it is not in our charter.   If some other working group _had already gotten_ such a TLD, then we could talk about using it, but placing such a process in the critical path doesn't make sense.

The procedural argument for using a special-purpose gTLD (instead of assigning IETF with a new general-purpose gTLD and making a special-purpose subdomain of that) seems to rest on language in the charter that I would think is pretty broad, and maybe broad enough to think it’s really either “both" or “neither" that are really in the charter.

>> The working group will also liason with external
>> standards bodies where it is expected that there are normative
>> dependencies between the specifications of the two bodies.

I say this because I’m really not thrilled by the prospect of *this* (from your original message):

>>> The downside to this approach is that we won't know whether the outcome will be success or failure for a long time, possibly several years.   And the outcome could very well be failure.

That “possibly several years” bit is what really stopped me in my tracks.

I would strongly prefer that we avoid the risks above by using a special-purpose subdomain of a gTLD owned by IETF. I don’t really care which gTLD we use, and if “arpa” is really the only reasonable choice, then so be it. However, I can imagine a world where the Working Group decides that “arpa” is unacceptable for whatever reason and decides that it’s better to wait until IETF has another domain with a better name. And I’m not ready to tell them I think that would be a very bad idea.

Actually, I think it’s probably a very bad idea. But, I’m in favor of using a subdomain of “arpa” instead of some new gTLD, so I’m already in a minority, and I’m prepared to lose that argument.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Dec 2016 17:14:21 -0500

> I would strongly prefer that we avoid the risks above by using a special-purpose subdomain of a gTLD owned by IETF. I don’t really care which gTLD we use, and if “arpa” is really the only reasonabl…

Remember that if we allocated some subdomain like .arpa, we would face a different procedural problem with ICANN that would almost certainly take a similar amount of time to resolve.

From a process perspective, trying to get ICANN to do an insecure delegation for .homenet is actually a worthwhile thing to do; the challenge is that it introduces some substantial potential for delay and uncertainty.   So does your non-.arpa TLD idea, so from our perspective there is no difference, whether or not there may be some difference for the IETF as a whole.   We will almost certainly be visiting that problem space in the future.

That said, if expedient is what the WG wants, .arpa is what’s expedient.   As I say, I am not leaning strongly in either direction.   I think that a strong argument for one choice or the other would either have to do with .homenet being technically better for some reason, or with the delay being unacceptable.   Right now I don’t think we’re under that kind of time pressure, which is why I’m not more exercised about the possibility of a long delay in getting .homenet delegated.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 14 Dec 2016 09:20:57 -0500

> On Dec 12, 2016, at 5:14 PM, Ted Lemon <[email-masked]> wrote:
> 

Ted - I agree that a new SUDN (.alt? draft-ietf-dnsop-alt-tld-06) would face procedural issues, although not (in my opinion) with ICANN.  We have .arpa as a precedent and designating .alt as an SUDN is strictly an IETF matter ... assuming appropriate notification to and consultation with ICANN.  The point is that we have the procedure with ICANN in place, whereas an insecure delegation for .homenet has no such process.

One of the issues that (again, strictly my opinion) that has held up draft-ietf-dnsop-alt-tld-06 is the lack of a real use case as motivation for progressing a designation of .alt.  Perhaps now, with a name for homenet under .alt, we have both a use case and a generalized solution to motivate designation of .alt

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Dec 2016 10:42:16 -0500

.alt may not need an insecure delegation.   It depends on whether anything
under .alt is meant to be resolved using DNS.

On Wed, Dec 14, 2016 at 9:20 AM, Ralph Droms <[email-masked]> wrote:

> >> I would strongly prefer that we avoid the risks above by using a
> special-purpose subdomain of a gTLD owned by IETF. I don’t really care
> which gTLD we use, and if “arpa” is really the only reasonable choice, then
> so be it. However, I can imagine a world where the Working Group decides
> that “arpa” is unacceptable for whatever reason and decides that it’s
> better to wait until IETF has another domain with a better name. And I’m
> not ready to tell them I think that would be a very bad idea.
> >
> > Remember that if we allocated some subdomain like .arpa, we would face a
> different procedural problem with ICANN that would almost certainly take a
> similar amount of time to resolve.
>
> Ted - I agree that a new SUDN (.alt? draft-ietf-dnsop-alt-tld-06) would
> face procedural issues, although not (in my opinion) with ICANN.  We have
> .arpa as a precedent and designating .alt as an SUDN is strictly an IETF
> matter ... assuming appropriate notification to and consultation with
> ICANN.  The point is that we have the procedure with ICANN in place,
> whereas an insecure delegation for .homenet has no such process.
>
> One of the issues that (again, strictly my opinion) that has held up
> draft-ietf-dnsop-alt-tld-06 is the lack of a real use case as motivation
> for progressing a designation of .alt.  Perhaps now, with a name for
> homenet under .alt, we have both a use case and a generalized solution to
> motivate designation of .alt
>
> - Ralph
>
> >
> > From a process perspective, trying to get ICANN to do an insecure
> delegation for .homenet is actually a worthwhile thing to do; the challenge
> is that it introduces some substantial potential for delay and
> uncertainty.   So does your non-.arpa TLD idea, so from our perspective
> there is no difference, whether or not there may be some difference for the
> IETF as a whole.   We will almost certainly be visiting that problem space
> in the future.
> >
> > That said, if expedient is what the WG wants, .arpa is what’s
> expedient.   As I say, I am not leaning strongly in either direction.   I
> think that a strong argument for one choice or the other would either have
> to do with .homenet being technically better for some reason, or with the
> delay being unacceptable.   Right now I don’t think we’re under that kind
> of time pressure, which is why I’m not more exercised about the possibility
> of a long delay in getting .homenet delegated.
> >
> >

---

From: Ralph Droms <[email-masked]>
Date: Wed, 14 Dec 2016 10:56:08 -0500

> On Dec 14, 2016, at 10:42 AM, Ted Lemon <[email-masked]> wrote:
> 
> .alt may not need an insecure delegation.   It depends on whether anything under .alt is meant to be resolved using DNS.

Agreed ...what I was thinking was that .alt would have a secure delegation, and then the IETF could add an insecure delegation to home.alt

Of course, I may be way confused here, as I'm getting close to the boundaries of my DNS skillz.

- Ralph

---

From: Jacques Latour <[email-masked]>
Date: Thu, 15 Dec 2016 16:05:48 +0000

Ted, very clear summary, thank you.

I read the DNSSEC related homenet and dnsop comments and I don’t see how you can have DNSSEC validation for a homenet without a properly signed & delegated domain.  If we want a one shoe fits all solution then we need to have a single common domain used by all homenet, and all homenet need to use/share the same private homenet DNSSEC keys where these common keys can be validated against a common DS record inside the { homenet. home. homenet.arpa. etc } domain.

I think homenet users should have the choice of a generic homenet domain (as above, essentially an unsecure domain) or have the choice to use their own domain name for their homenet, ‘myhome.ca’ along with their own private keys and all. One domain per household. Then you could use your ‘myhome.ca’ DNSSEC infrastructure to secure your home IoT devices ☺

Where do you delegate homenet to? Advanced DNSSEC validation may check for proper delegation?

My 2 cents.

Jacques

From: homenet [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: December-12-16 10:46 AM
To: HOMENET
Subject: Re: [homenet] WGLC on "redact" and "homenet-dot"

I should point out that whichever way we go, we already have solved the immediate problem: we have a name that HNCP can use, the potential liability for IETF is dealt with, and our prototypes can be made to work.   So I am personally okay with either decision.   Our AD, Terry, may have more of a sense of what ICANN will do (but to some extent he really can't know, because it's up to committees within ICANN to actually make this decision).   I'm mentioning this now not to derail the process, but simply to make it really clear what our expectations should be.   The reason that this didn't come up in Seoul is that it didn't actually click for me that we had a serious problem until several of us were chatting on the way out of the room, after the working group had already decided to proceed.

On Thu, Dec 1, 2016 at 9:02 AM, Ray Bellis <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Ralph.

Ray

_______________________________________________
homenet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/homenet

---

From: Bob Harold <[email-masked]>
Date: Thu, 15 Dec 2016 11:57:21 -0500

If an insecure delegation can be made in the root, then could a local trust
anchor be used by those who want their .homenet domain DNSSEC validated?
That seems easier than sharing keys or creating subdomains with nsupdate.
But I don't know much about trust anchors.

-- 
Bob Harold

---

From: Ray Bellis <[email-masked]>
Date: Thu, 15 Dec 2016 16:59:00 +0000

On 15/12/2016 16:57, Bob Harold wrote:
> If an insecure delegation can be made in the root, then could a local
> trust anchor be used by those who want their .homenet domain DNSSEC
> validated?

That's what I would have expected to happen.

> That seems easier than sharing keys or creating subdomains with
> nsupdate.  But I don't know much about trust anchors.

Shared keys would be a nightmare.

Ray

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Dec 2016 12:20:53 -0500

> Where do you delegate homenet to? Advanced DNSSEC validation may check for proper delegation?  

I think we should ask ICANN to set up an unsecured delegation of .homenet to the AS112 servers.   In order for names under .homenet to be validated by DNSSEC, it would be necessary for the validating resolver to have a trust anchor for any homenet on which it wants to do validation, and a means of differentiating between homenets so that it doesn’t use the wrong key to validate.   But that’s out of scope for this discussion: the point of this discussion is simply to figure out whether we want to do the hard thing or the easy thing: .homenet or home.arpa.

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 15 Dec 2016 12:29:48 -0500

(no hats)

> On Dec 15, 2016, at 12:20 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Dec 15, 2016, at 11:05 AM, Jacques Latour <[email-masked] <mailto:[email-masked]>> wrote:

I suspect that this discussion has shown a certain amount of confusion on the subject of exactly how to make name resolution work as implied by what we know so far about what homenets will need to do, and that it might be beneficial to resolve the question in a way that will allow for relatively easy changes later.

Given that any resolver operator who wants to configure their local resolver with special-casing for the homenet default namespace (or any other) can do so, the interesting question is what behavior is expected from the public DNS for queries on the default homenet namespace— and who has to implement it.

Which solution (.homenet or .home.arpa) is easier to refine in light of future experience seems fairly obvious to me. 

Suzanne

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 15 Dec 2016 13:22:59 -0500

Dear colleagues,

I have read draft-ietf-homenet-redact-01.  I think it would be
stronger if the ¶ "The RFC6761 process … notices oversights of this
sort." in section 1 were removed.  I don't especially care, however.
Also, in ¶1 of §1, "This document recomments the use of the '.home'…."
reads as though the present document (i.e. the I-D itself) is making
the recommendation.  Perhaps "That document" instead would work, or
"Said RFC", or something.

I have also read draft-ietf-homenet-dot-00.  I have some comments both
large and small.

In the large, I think the critical questions for the WG is whether the
special name in question (1) needs to have a secure proof of
non-existence in the global DNS and (2) needs to be a TLD.

As far as I can tell, this is a name that is supposed to work in a
site context using standard DNS resolution and protocols.  If that is
true, then there are two possibilities:

    1.  Proveable non-existence doesn't matter, because a
    homenet-aware resolver will already know that .homenet is a
    protocol switch and anything that isn't homenet-aware should fail.

    2.  Proveably insecure delegation is critical so that unmodified
    validating endpoints can use the homenet DNS.

I think our charter tells us we're supposed to achieve (2).  (1) is
the case like .onion, where an endpoint that doesn't know it's doing
onion routing is _supposed_ to fail.  But we were supposed to be
providing a site-local answer that still provided link-local-like
experiences.  So I think we have to do (2).

If that's the case, then we need to ask for a provably insecure
delegation.  If such a delegation needs to be a TLD, then we have to
ask not only for an entry in the special-names registry (which is
under IETF control), but also an entry in the DNS root zone (which is
not under IETF control).  If it does not need to be a TLD, then we
have other options open to us.

If we ask for a provably insecure delegation from the root zone, then
I think we need to be alert to the possibility that ICANN might not
grant it, or might grant it under circumstances we don't like.  The
key thing here is that we are tramping in someone else's IANA
operational space, so we become subject to their rules.

I am very far from convinced that this needs a delegation from the
root, so I would prefer a different name than .homenet.  I think
home.arpa. or mynet.arpa. or whatever would be good enough, but I'm
aware some think "arpa" is a dangerous string.

On the small stuff:

In §1, "evidence indicates that '.home' queries frequently leak out
and reach the root name servers [ICANN1] [ICANN2]", I don't think
that's the issue.  The issue is that home is a well-known, in use TLD
(we know because of those queries), and the consequences of reusing it
are therefore completely unknown.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Steve Crocker <[email-masked]>
Date: Thu, 15 Dec 2016 14:23:00 -0500

Ted,

I am truly confused by your note.  I sense I am missing something fundamental.

See specific questions below.

Thanks,

Steve

> I think we should ask ICANN to set up an unsecured delegation of .homenet to the AS112 servers.

I don’t understand what is meant by an “unsecured delegation.”  I also don’t understand what sort of delegation you want, irrespective of whether DNSSEC is involved.

I think there are two very big hurdles implicit in “I think we should ask ICANN to set up …”  One is the technical hurdle of whether this is a sensible thing technically with respect to the security and stability of the Internet.  It will take a fairly long time and a lot of analysis for ICANN to get comfortable with such a result, and I would not count on a positive outcome.

That’s the first hurdle.  The second hurtle may be even harder.  The only existing procedures for adding new delegations to the root are for:

o New ccTLDs, i.e. when new countries are created and get two letter codes from the ISO 3166 Maintenance Agency;

o New IDN ccTLDs via the Fast Track; and

o New gTLDs through the gTLD process.

The first two would not apply.  The window for the third was closed a while ago and we are studying when and how to reopen the window.  The process is geared toward prospective operators of registries.  A substantial fee is required, and an even more substantial investment in registry operation is required.

I suspect what’s intended here is something qualitatively different, e.g. some sort of entry in the root that returns a fixed result, not a pointer to name servers.  Aside from the technical questions I mentioned above, we would also have to sort out the policy questions, e.g. what are the rules for accepting such requests, what happens if there are competing requests, and perhaps others that aren’t occurring to me as I write this.

>   In order for names under .homenet to be validated by DNSSEC, it would be necessary for the validating resolver to have a trust anchor for any homenet on which it wants to do validation, and a means of differentiating between home nets so that it doesn’t use the wrong key to validate.

Yes, but the way the sentence is written suggests this would difficult or odd.  In a homenet environment, if you have a local name server responding to requests as an authority, it can sign those requests as the authority.  The requesting resolver will have to have the public key associated with the authority.  This is a configuration matter.  When the requesting resolver is told which resolver on the edge of the homenet is authoritative for the homenet environment, it should also learn that resolver’s public key.  This seems like a DHCP issue.

>   But that’s out of scope for this discussion: the point of this discussion is simply to figure out whether we want to do the hard thing or the easy thing: .homenet or home.arpa.

I don’t see a difference between .homenet or home.arpa in this regard.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Dec 2016 15:11:20 -0500

> I don’t understand what is meant by an “unsecured delegation.”  I also don’t understand what sort of delegation you want, irrespective of whether DNSSEC is involved.

There would be a delegation for .homenet in the secure root, which would point at the AS112 servers, and would have no DS records.

> I think there are two very big hurdles implicit in “I think we should ask ICANN to set up …”  One is the technical hurdle of whether this is a sensible thing technically with respect to the securit…

Yup, understood.

> The first two would not apply.  The window for the third was closed a while ago and we are studying when and how to reopen the window.  The process is geared toward prospective operators of registr…

It would not make sense to follow any of these processes.   This is a technical allocation under the terms of the MoU, and we don’t actually know how to do those.   It would, in my view, be extremely weird for ICANN to charge IETF for doing one of these, based on my reading of the MoU, but at the same time ICANN is responsible for operating the zone, so it’s entirely reasonable for ICANN to say "no, we won’t do that," and then the IETF would have to decide that that meant in terms of the MoU.   I would hope that ICANN would not do this, and I think the MoU seems to indicate that they have agreed not to, but it’s uncharted territory, and I think there would have to be a fourth process for this, which is separate from the three you described above.

> I suspect what’s intended here is something qualitatively different, e.g. some sort of entry in the root that returns a fixed result, not a pointer to name servers.

No, just a delegation to AS112 with no DS record would do the job, unless I am missing something.   I will admit to not being an expert on DNSSEC arcana, so that’s entirely possible.

>  Aside from the technical questions I mentioned above, we would also have to sort out the policy questions, e.g. what are the rules for accepting such requests, what happens if there are competing requests, and perhaps others that aren’t occurring to me as I write this.

Yes.   It’s a big can of worms.   We won’t know precisely what’s in it unless we open it.

> Yes, but the way the sentence is written suggests this would difficult or odd.  In a homenet environment, if you have a local name server responding to requests as an authority, it can sign those r…

I don’t think DHCP is the right answer, but the bottom line is that this isn’t really the issue that we need to figure out right now.   Just bear in mind that a validating stub resolver needs to not invalidate answers that are returned within .homenet.

> I don’t see a difference between .homenet or home.arpa in this regard.

If the working group chose to use home.arpa, we would not need to open the aforementioned can of worms.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 16 Dec 2016 07:40:24 +1100

In message <[email-masked]>, Ted Lemon writes:
> > I dont understand what is meant by an unsecured delegation.  I also
> > dont understand what sort of delegation you want, irrespective of whether
> > DNSSEC is involved.
>
> There would be a delegation for .homenet in the secure root, which would
> point at the AS112 servers, and would have no DS records.

I think where the delegation points to is still under debate.  To
make DNSSEC work all that is required is that it a insecure (not unsecure,
there was a lot of debate about the term to use years ago) delegation
which means one without a DS record.

The AS112 server are definitely the wrong set of servers to delegate
to as they are not configured to serve the zone and cannot be made
to serve the zone with reliability.  A different set of anycast
servers however would do.

> > I think there are two very big hurdles implicit in I think we should
> > ask ICANN to set up   One is the technical hurdle of whether this is a
> > sensible thing technically with respect to the security and stability of
> > the Internet.  It will take a fairly long time and a lot of analysis for
> > ICANN to get comfortable with such a result, and I would not count on a
> > positive outcome.
>
> Yup, understood.
>
> > Thats the first hurdle.  The second hurtle may be even harder.  The
> > only existing procedures for adding new delegations to the root are for:
> >
> > o New ccTLDs, i.e. when new countries are created and get two letter
> > codes from the ISO 3166 Maintenance Agency;
> >
> > The first two would not apply.  The window for the third was closed a
> > while ago and we are studying when and how to reopen the window.  The
> > process is geared toward prospective operators of registries.  A
> > substantial fee is required, and an even more substantial investment in
> > registry operation is required.
>
> It would not make sense to follow any of these processes.   This is a
> technical allocation under the terms of the MoU, and we dont actually
> know how to do those.   It would, in my view, be extremely weird for
> ICANN to charge IETF for doing one of these, based on my reading of the
> MoU, but at the same time ICANN is responsible for operating the zone, so
> its entirely reasonable for ICANN to say "no, we wont do that," and then
> the IETF would have to decide that that meant in terms of the MoU.   I
> would hope that ICANN would not do this, and I think the MoU seems to
> indicate that they have agreed not to, but its uncharted territory, and I
> think there would have to be a fourth process for this, which is separate
> from the three you described above.
>
> > I suspect whats intended here is something qualitatively different,
> > e.g. some sort of entry in the root that returns a fixed result, not a
> > pointer to name servers.
>
> No, just a delegation to AS112 with no DS record would do the job, unless
	s/AS112/anycast/
> I am missing something.   I will admit to not being an expert on DNSSEC
> arcana, so thats entirely possible.
>
> >  Aside from the technical questions I mentioned above, we would also
> > have to sort out the policy questions, e.g. what are the rules for
> > accepting such requests, what happens if there are competing requests,
> > and perhaps others that arent occurring to me as I write this.
>
> Yes.   Its a big can of worms.   We wont know precisely whats in it
> unless we open it.
>
> >>   In order for names under .homenet to be validated by DNSSEC, it
> >> would be necessary for the validating resolver to have a trust anchor for
> >> any homenet on which it wants to do validation, and a means of
> >> differentiating between home nets so that it doesnt use the wrong key to
> >> validate.
> >
> > Yes, but the way the sentence is written suggests this would difficult
> > or odd.  In a homenet environment, if you have a local name server
> > responding to requests as an authority, it can sign those requests as the
> > authority.  The requesting resolver will have to have the public key
> > associated with the authority.  This is a configuration matter.  When the
> > requesting resolver is told which resolver on the edge of the homenet is
> > authoritative for the homenet environment, it should also learn that
> > resolvers public key.  This seems like a DHCP issue.
>
> I dont think DHCP is the right answer, but the bottom line is that this
> isnt really the issue that we need to figure out right now.   Just bear
> in mind that a validating stub resolver needs to not invalidate answers
> that are returned within .homenet.
>
> >>   But thats out of scope for this discussion: the point of this
> >> discussion is simply to figure out whether we want to do the hard thing
> >> or the easy thing: .homenet or home.arpa.
> >
> > I dont see a difference between .homenet or home.arpa in this regard.
>

The can of worms is going to need to be opened anyway.  There is
another draft on .localhost which will open it if homenet doesn't.
It that doesn't then the special names discussion will open it.  I
don't see the can of worms staying closed.

The IETF and ICANN are going to need to address this issue.  It
does no one any good to leave it festering.

The only decision to make is homenet going to wait for that discussion
to occur or not.

Mark

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Dec 2016 15:51:46 -0500

> does no one any good to leave it festering.

Yup.   I think that’s the bottom line.

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 15 Dec 2016 21:27:29 -0500

> On Dec 15, 2016, at 3:51 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Dec 15, 2016, at 3:40 PM, Mark Andrews <[email-masked] <mailto:[email-masked]>> wrote:

ICYMI….

DNSOP has been considering exactly this set of issues for some time, and has adopted two relevant drafts:

* Problem statement for special use domain names: https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ <https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/>

* Proposal for new top-level special use domain name as “TLD” for other special use domains: https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ <https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/>

Update to the roadmap from the chairs soon, but we’re looking towards consensus on the problem statement and proposals for updates/refinements to the registry policy set out in RFC 6761.

Comments/reviews on these drafts to DNSOP are welcome. 

Suzanne 
(for the chairs)