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 protected]] 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
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
