Subject: [homenet] Review of draft-ietf-homenet-dot-03

From: Jon Mitchell <[email-masked]>
Date: Sat, 18 Mar 2017 21:29:40 -0700

Reviewer: Jon Mitchell
Review result: Has Issues

I have reviewed this document as part of the Operational directorate's

ongoing effort to review all IETF documents being processed by the
IESG.  These 
comments were written with the intent of improving the operational
aspects of the 
IETF drafts. Comments that are not addressed in last call may be
included in AD reviews 
during the IESG review.  Document editors and WG chairs should treat
these comments 
just like any other last call comments. 

Overall - document has issues, could likely benefit from further
reviews.  This document was asked for early review by with a specific
request instructions to look at in context of RFC6761 definition of
special use domain names as well as from the operational implications
of having an unsigned root zone.  Having read the document and a
number of related works that I found useful in understanding further
the implications of this document (such as those laid out by
draft-ietf-dnsop-sutld-ps-03), I think it would be useful for this
document to go through an additional further early review by dnsop
working group directly, however here is my non-DNS expert feedback:

This document does spell out handling for .homenet as required by
RFC6761, specifically in Section 3 of the draft, and does seem to
adequately fit under the definition of a special used domain name,
primarily only based on the difference of user experience with the
domain (criteria #1).  That said, I have several concerns with the
wording in this draft regarding criteria in this section, here they
are in the same numbered list as in the draft (and as required by
RFC6761).

1.  This does not adequately identify that users should not treat
.homenet like any other domain name in the sense that entries in this
top level domain are pretty much guaranteed to be non-unique, and
likely this will pose general confusion, service reachability, as well
as security concerns that are somewhat glossed over as well in the
security considerations section of the draft.

2.  All though this states that applications should not consider
.homenet domain has having an elevation of security, user facing
applications may want to actually notify users of the special behavior
of this domain and the fact that it is more insecure as the names are
not globally unique and using them outside of the local networking
environment will likely have unexpected results.  Further applications
are pretty much guaranteed to not be able to have certificate based
trust of the hosts at this domain since they are not globally unique.

3.  No issues with section wording which basically prescribes no
difference from normal DNS behavior, although this section is a bit
verbose about how a host gets it's nameservers, which seems
unnecessary.

4.  This section is a bit confusing as it says that .homenet is
effectively a locally served zone as described by RFC6303, but then
there is no request for IANA to add this to the locally served zones
registry which was established by that RFC, not to mention that
registry does not currently contain any non reverse zones today.  My
reading is that homenet's desired behavior for this and section 5 are
similar to the description of the .test domain handling in RFC6761,
and I'm curious (not familiar with history or timing of the two
documents) that none of the domain handling in RFC6761 defer to
RFC6303 for specification handling like .homenet tries to do here.

5 and 6.  Similar concern as above, wonder why same wording as
prescribed for .test domain in RFC6761 is not used for .homenet

7.  No concerns.

Concerns with security considerations - user surprise (and threat) is
something that is basically being designed into this use case, as well
as is the need to disable DNSSEC and some of the ability to use
certain types of certificate based application security that relies on
CA trust based on names.  This doesn't feel adequately called out.

IANA considerations - as described below section doesn't mention
locally served zone registry, although it's unclear as described above
whether or not that's really the behavior desired.