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

[Ray Bellis]

In light of the extensive discussion around the (non-existent) process
for requesting an insecure delegation for .homenet [*], Mark and I have
decided to allow more time for this to be considered, and therefore are
extending the WGLC to Friday January 6th.

In the meantime, Ted is shortly going to be spinning revisions of the
two documents to address other comments received so far.

Ray and Mark

[*] see Ted's email of 15:46 UTC on 12th December

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Andrew Sullivan]

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
a...@anvilwalrusden.com

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Suzanne Woolf]

(no hats)

> On Dec 15, 2016, at 12:20 PM, Ted Lemon  wrote:
> 
> On Dec 15, 2016, at 11:05 AM, Jacques Latour  > wrote:
>> 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.

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


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ted Lemon]

On Dec 15, 2016, at 11:05 AM, Jacques Latour  wrote:
> 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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Jacques Latour]

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:homenet-boun...@ietf.org] On Behalf Of Ted Lemon
Sent: December-12-16 10:46 AM
To: HOMENET
Subject: Re: [homenet] WGLC on "redact" and "homenet-dot"

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 
mailto:r...@bellis.me.uk>> wrote:


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

__

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

[Ralph Droms]

> On Dec 14, 2016, at 10:42 AM, Ted Lemon  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

> 
> On Wed, Dec 14, 2016 at 9:20 AM, Ralph Droms  wrote:
> 
> > On Dec 12, 2016, at 5:14 PM, Ted Lemon  wrote:
> >
> > On Dec 12, 2016, at 4:56 PM, james woodyatt  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.
> >
> >
> > ___
> > homenet mailing list
> > homenet@ietf.org
> > https://www.ietf.org/mailman/listinfo/homenet
> 
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ted Lemon]

.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  wrote:

>
> > On Dec 12, 2016, at 5:14 PM, Ted Lemon  wrote:
> >
> > On Dec 12, 2016, at 4:56 PM, james woodyatt  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.
> >
> >
> > ___
> > homenet mailing list
> > homenet@ietf.org
> > https://www.ietf.org/mailman/listinfo/homenet
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ralph Droms]

> On Dec 12, 2016, at 5:14 PM, Ted Lemon  wrote:
> 
> On Dec 12, 2016, at 4:56 PM, james woodyatt  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.
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ted Lemon]

On Dec 12, 2016, at 4:56 PM, james woodyatt  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.

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.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ted Lemon]

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  wrote:

> On Dec 12, 2016, at 12:25, Mark Andrews  wrote:
>
>
> 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.
>
>
> --james woodyatt 
>
>
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Mark Andrews]

In message <585d7369-28a8-4b6d-be77-c94b42ca4...@google.com>, james woodyatt 
writes:
>
> On Dec 12, 2016, at 07:46, Ted Lemon  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.

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

> --james woodyatt 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ted Lemon]

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"  wrote:

> On Dec 12, 2016, at 07:46, Ted Lemon  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 
>
>
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ted Lemon]

On Dec 12, 2016, at 11:29 AM, Ralph Droms mailto:rdroms.i...@gmail.com>> wrote:
>> 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?

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.

>> 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?

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.___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ralph Droms]

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  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  > wrote:
> 
> 
> 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
> 
> ___
> homenet mailing list
> homenet@ietf.org 
> https://www.ietf.org/mailman/listinfo/homenet 
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ted Lemon]

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  wrote:

>
>
> 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
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ray Bellis]

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ralph Droms]

(Updated comments on draft-ietf-homenet-dot originally posted prior to the WG 
last call)

I suggest that the paragraph in the Introduction that motivates the change from 
.home to .homenet be augmented or replaced with the reasons Ray listed in 
earlier e-mail:

1.  we cannot be sure that using .home is consistent with the existing (ab)use
2.  ICANN is in receipt of about a dozen applications for ".home", and some of 
those applicants no doubt have deeper pockets than the IETF does should they 
decide to litigate

This sentence appears in section 2:

   Names ending with '.homenet.'  MUST refer to
   services that are located within a home network (e.g., a printer, or
   a toaster).

I think "services" is too restrictive; in fact, the examples are really devices 
or hosts, not services provided by those devices.  What is the restriction 
"located within a home network", and what, exactly, does it mean?  In my 
opinion, this document should focus on name evaluation within the .homenet 
locally served zone.

Also in section 2, the phrase "Although home networks most often provide one or 
more service discovery mechanisms," assumes the reader knows that many service 
discovery mechanisms hide the domain name of the service or host and, hence, 
.homenet.

In section 3, the response to item 3 in the SUDN reservation considerations 
could be clarified by specifying that any queries in the .homenet zone must be 
forwarded to a DNS service as configured by explicitly by HNCP or other 
appropriate local configuration mechanism coordinated with .homenet resolution, 
as opposed to just “configured”.  A manually configured entry for some external 
server is “configured”, but not configured in a helpful way.

Also in item 3, s/for '.homenet'./for domain names ending in '.homenet'/

In item 4, s/part of the domain/part or all of the '.homenet' domain/

Given the existence of draft-ietf-dnsop-terminology-bis, it would be helpful 
(at least, I would find it helpful) to use the agreed common terminology; for 
example “recursive resolver” instead of “Caching DNS servers”.

In the answer for question 5, it might help the reader to specify which zones 
the “authoritative servers” are authoritative for.

“DNS server operator” is likely a term of art in the answer for question, but 
it’s not clear to me which operators and servers are referred to, here.  
Although passive voice should be avoided, it might be appropriate to simply 
write “DNS servers outside a home network should not be configured to be 
authoritative for .homenet.

- Ralph

> On Nov 17, 2016, at 11:27 PM, Ray Bellis  wrote:
> 
> This email commences a four week WGLC comment period on
> draft-ietf-homenet-redact and draft-ietf-homenet-dot
> 
> Please send any comments to the WG list as soon as possible.
> 
> Whilst there was a very strong hum in favour of ".homenet" vs anything
> else during the meeting, and there's some discussion of that ongoing
> here on the list - I'd like us to please keep the discussion of the
> choice of domain separate from other substantive comment about the
> drafts' contents.
> 
> thanks,
> 
> Ray
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet