Early Review of draft-ietf-homenet-dot-03
review-ietf-homenet-dot-03-opsdir-early-mitchell-2017-03-18-00

• Status
• Email expansions
• History

• Versions
• 00

Please review this document in two directions.

1) In terms of RFC6761

2) in terms of the _operational_ position of an unsigned entry in the root zone as needed by homenet to break the chain of trust

Review
review-ietf-homenet-dot-03-opsdir-early-mitchell-2017-03-18

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.