Okay, I think I've procrastinated on responding to this long enough, and Ray
and Mark seem to feel even more strongly about that than I do. Sorry for
taking so long, and thanks very much for the careful review!
> On Apr 30, 2017, at 8:06 PM, Suzanne Woolf <suzworldw...@gmail.com> wrote:
> Sec. 1, Introduction
>
> 1. Existing text: "The '.home.arpa' domain replaces '.home' as the default
> domain used by the Home Networking Control Protocol (HNCP)"
>
> There's an accepted erratum on this, since the "reservation" of .home
> occurred without reference to the relevant registry, so it would be helpful
> for anyone trying to understand why this document exists to point that out.
>
> Suggested new text: "The '.home.arpa' domain corrects an error in RFC7788,
> replacing '.home' as the default domain used by the Home Networking Control
> Protocol (HNCP)."
OK
> 2. "Also, ICANN has about a dozen applicants for the '.home' top-level domain
> name, which creates a significant risk of litigation if it were claimed by
> the IETF outside of that process."
>
> I don't think it's either necessary or useful to speculate in an IETF
> standards-track technical document about either ICANN policy or associated
> litigation risk. The technical reason (the risk of name collision within the
> homenet or ISP environment) and the standards process reason (the fact that
> RFC 7788 entirely sidestepped IETF discussion of .home as a special use name
> for this purpose) are probably adequate justification here.
Makes sense.
> In addition, this text doesn't touch at all on the fact a delegation in the
> global DNS is considered necessary for the default zone in order to properly
> support DNSSEC, or the rationale for it, or the potential difficulty of
> obtaining it in the root zone.
>
> Finally, it's unclear why a separate document is needed to support redaction
> of ".home" from RFC 7788, when this document replaces it with ".home.arpa."
> anyway. This document is standards track and already updates RFC 7788.
>
> The sentence about existing applicants for .home could be simply removed.
> Brief additional explanation about why a name in .arpa is preferable to one
> in the root might also be helpful.
>
> Old text: "The '.home.arpa' domain replaces '.home' which was specified in
> [RFC7788] as the default domain-name for home networks. '.home' had
> been selected as the most user-friendly option. However, there are
> existing uses of '.home' that may be in conflict with this use:
> evidence indicates that '.home' queries frequently leak out and reach
> the root name servers [ICANN1] [ICANN2]. Also, ICANN has about a
> dozen applicants for the '.home' top-level domain name, which creates
> a significant risk of litigation if it were claimed by the IETF
> outside of that process. As a result, the use of '.home' has been
> deprecated; this document updates [RFC7788] to replace '.home' with
> '.home.arpa', while another document, [I-D.ietf-homenet-redact]
> deprecates the use of the '.home' TLD.
>
> New text: "The '.home.arpa' domain replaces '.home' which was specified in
> [RFC7788] as the default domain-name for home networks. Initially, '.home'
> had
> been selected as the most user-friendly option. However, there are
> existing uses of '.home' that may be in conflict with this use:
> evidence indicates that '.home' queries frequently leak out and reach
> the root name servers [ICANN1] [ICANN2]. In addtion, it's desirable that
> there
> should be a delegation for the homenet default domain name in the global
> DNS,
> for compatibility with DNSSEC. There is an existing process, under control
> of
> the IETF and the IAB, for creating such a delegation under .arpa [RFC3172].
> However, there is no such process for creating a name under the root zone,
> which
> is not administered by the IETF, so creating such a process would involve
> unknown costs in time and effort. As a result, the use of '.home' has been
> deprecated.
>
> This document updates [RFC7788] to replace '.home' with '.home.arpa', while
> another document, [I-D.ietf-homenet-redact] deprecates the use of
> the '.home' TLD."
>
This is the new text as I've updated it:
The '.home.arpa' domain corrects an error in [RFC7788], replacing
'.home' as the default domain-name for home networks. '.home' had
been selected as the most user-friendly option. However, there are
existing uses of '.home' that may be in conflict with this use:
evidence indicates that '.home' queries frequently leak out and reach
the root name servers [ICANN1] [ICANN2].
In addition, it's necessary, for compatibility with DNSSEC
(Section 5), that an unsigned delegation be present for the name.
There is an existing process for allocating names under '.arpa'
[RFC3172]. No such process is available for requesting a similar
delegation in the root at the request of the IETF, which does not
administer that zone. As a result, the use of '.home' is deprecated.
> 3. Existing text: "....DNS queries for names whose rightmost non-terminal
> label is 'homenet'."
>
> Suggested new text: "....DNS queries for names whose rightmost non-terminal
> labels are '.home.arpa'."
OK
> Sec. 2, General Guidance
>
> 4. Existing text: "The domain name '.home.arpa.' is to be used for naming
> within a home network.” I looked for a handy reference for describing what's
> a "home network”; the closest I could find was Sec. 3.7.3 of RFC 7368.
The term "residential home network" is used in RFC 7368. I think that it's
sufficient to just say that—the section you reference in RFC 7368 is at best a
distraction, and at worst confusing in this context.
> 5. Existing text: "DNS queries for names ending with '.home.arpa.' are
> resolved using local resolvers on the homenet." It might be helpful to also
> note that they're not intended to be resolvable from outside the homenet
> (relevant for some new text I think the "Security Considerations" will need,
> see below).
That's out of scope for this document, and it's not clear that there is
consensus on this point: there are in fact services that "phone home," and this
is one of the use cases that's wanted for homenet. It's likely that in order
for such use cases to work, some global name would be required, but the point
is that answering this question seems way out of scope for the document we are
discussing.
> Sec. 3, Domain Name Reservation Considerations
>
> 6. Existing text: "...when serving queries for names ending with
> '.home.arpa.'"
>
> This sounds odd, as the resolution process isn't usually called "serving
> queries"
>
> Suggested new text: "....when responding to queries for names ending with
> 'home.arpa'."
I changed it to "when resolving queries" because actually we are talking about
both sides of the discussion, not just the server side.
> 7. Existing text "Applications SHOULD treat domain names ending with
> '.home.arpa.' just like any other FQDN, and MUST NOT make any assumption on
> the level of additional security implied by its presence."
>
> Is the suggestion that the user or system might automatically place a higher
> level of trust in "home.arpa" names than other FQDNs, which might not be
> appropriate? If so, a sentence clarifying that would be helpful.
I don't really know how to fully address this comment. What I wrote is as
follows:
2. Application software SHOULD NOT process names ending in
'.home.arpa' specially. In particular, it would not be correct
to assign a higher level of trust to such names: although such
names might refer to resources on the application user's home
network, there is no basis for validating this assumption at a
protocol level, and hence such an assumption would create an
attack surface for devices roaming to other networks.
> 8. As a related observation, it would be appropriate to suggest local
> "home.arpa" zones should be signed and resolvers should validate them,
> particularly given the caution above about assuming too much about security
> within the homenet. As the document stands, the reference to DNSSEC as the
> reason for requiring a delegation in the global DNS for .home.arpa stands
> pretty much alone and unmotivated. (This may belong under “Security
> Considerations.”)
Yes, I updated Security considerations to talk about this in more detail (see
below)
> 9. Existing text: "Unless configured otherwise, recursive resolvers and DNS
> proxies MUST behave as described in Locally Served Zones ([RFC6303] Section
> 3)."
>
> This text is mildly confusing, because I think it says "resolvers and proxies
> must do this, unless they do something different." I'm guessing it's supposed
> to mean "This is the expected behavior unless something more useful is
> configured," but I'm not sure exactly how to say that.
The point of this is to avoid queries to home.arpa leaking. If the local name
resolution service doesn't recognize '.home.arpa' it should respond
authoritatively with NXDOMAIN to queries to subdomains of that name, and with
artificial NS and SOA records for the name itself.
I've updated the text as follows:
4. Unless configured to serve subdomains of 'home.arpa', recursive
resolvers and DNS proxies MUST behave as described in Locally
Served Zones ([RFC6303] Section 3). Recursive resolvers that are
part of a home network MAY be configured manually or
automatically (e.g., for auto-configuration purposes) to act
differently, e.g., by querying another name server configured as
authoritative for part or all of the '.home.arpa' domain, or
proxying the request through a different mechanism.
> 10. Existing text: "Only a DNS server that is authoritative for the '.arpa'
> zone or is configured to be authoritative for '.home.arpa' or a subdomain of
> '.home.arpa' will ever answer a query about '.home.arpa.'"
>
> It might be wise to note that servers for .arpa will not actually know about
> the local instance of .home.arpa, and a query to those servers for
> information about the local .home.arpa zone will not produce useful results.
> Thus, resolvers inside the homenet should avoid queries to .arpa for names in
> home.arpa. (Resolvers outside the homenet will most likely find the .arpa
> servers, and terminate the resolution process there, which is also as it
> should be.)
I added this:
The delegation
returned by servers authoritative for '.arpa' will not match the
delegation returned by a local resolver that is actually
answering for '.home.arpa.'
> This isn't a special failing of .arpa or of being in an SLD; if the name were
> ".homenet" instead, the same problem would occur: the parent (whether it's
> the root or a TLD) is not in a position to know anything about the local
> instance of an ambiguously-named child zone from a name in the root. This is
> why the recursive resolver that the stub asks for resolution services should
> be configured to be authoritative for the home.arpa zone, including DNSSEC
> trust anchors.
The picture presented by the local resolver of the delegation should be
consistent, so the only way to get the official delegation would be to query an
authoritative server for '.arpa' directly. This is explicitly discussed in
point 3, so I think adding more clarifying text here would be redundant.
> 11. Existing text: "'home.arpa' is a subdomain of the 'arpa' top-level
> domain, which is entirely operated by the Internet Architecture Board."
>
> Actually, no; it's operated by IANA, under the administrative authority of
> the IAB, which in turn is responsible under the rules established in RFC
> 3172. This doesn't change the relevant policy of course, but allows for a
> reference on why there's no need to worry about registrars.
>
> Suggested new text: "'home.arpa' is a subdomain of the 'arpa' top-level
> domain, which is operated under the authority of the Internet Architecture
> Board according to the rules established in RFC 3172. There are no other
> registrars for .arpa."
>
The text is now:
7. 'home.arpa' is a subdomain of the 'arpa' top-level domain, which
is operated by IANA under the authority of the Internet
Architecture Board according to the rules established in
[RFC3172]. There are no other registrars for .arpa.
> Sec. 4, Updates to Home Networking Control Protocol
>
> 12. Existing text: "Names for which the rightmost non-terminal label is
> 'homenet' are resolved using the DNS protocol [RFC1035]."
>
> Suggested new text: "Names for which the rightmost two labels are 'home.arpa'
> are resolved using the DNS protocol [RFC1035]."
OK
> Sec. 5, Security Considerations
>
> 13. Existing text "....query ending with '.home.arpa.' is expected...." is
> ambiguous. Suggested new text: "....query for an FQDN in the domain
> '.home.arpa.' is expected...."
>
> 14. Existing text describing why the delegation needs to exist and not be
> signed is not clear. This is a somewhat arcane topic, but DNS administrators
> who have been told repeatedly for some years now that they should use DNSSEC
> whenever possible will be puzzled by an apparent directive that home.arpa not
> be signed.
>
> I suggest the document should have an additional paragraph describing the
> resolution process in which it's helpful to have the global delegation exist
> and be unsigned.
>
> The text that's there now ("The reason that this delegation must not be
> signed is that not signing the delegation breaks the DNSSEC chain of trust,
> which prevents a validating stub resolver from rejecting names published
> under 'home.arpa' on a homenet name server.") isn't adequate because it
> doesn't explain how this condition could possibly arise: if the stub resolver
> is asking the global DNS for names published under .arpa, it's because it
> hasn't asked a resolver that has locally configured .home.arpa. It can't
> reject names it has no way to get in the first place.
>
> If a stub resolver asks a local, recursive resolver for home.arpa names and
> the resolver is configured to serve .home.arpa as a local zone, authoritative
> data for the zone (signed or not) is available to the stub. If the stub
> resolver asks a resolver that doesn't have .home.arpa as a locally served
> zone, it will ask the root, but it's not clear what happens to allow the stub
> to find locally relevant information in the results of that attempt to
> resolve and validate the name in the global context of the DNS. So it's not
> clear what sequence of resolution steps results in a useful answer that's an
> unsigned NXDOMAIN.
I've updated this as follows:
It is not possible to install a trust anchor for this zone in the
'.arpa' zone. The reason for this is that in order to do so, it
would be necessary to have the key-signing key for the zone
([RFC4034] Section 5). Since the zone is not globally unique, no one
key would work.
An alternative would be to install a authenticated denial of
existence ([RFC4033] Section 3.2). However, this assumes that
validation is being done on a caching resolver that is aware of the
special local meaning of '.home.arpa'. If a host stub resolver
attempts to validate a name in .local.arpa, an authenticated denial
of existence of 'home' as a subdomain of 'arpa.' would cause the
validation to fail. Therefore, the only delegation that will allow
names under '.home.arpa' to be resolved is an unsigned delegation.
Consequently, unless a trust anchor for the particular instance of
the '.home.arpa' zone being validated is manually configured on the
validating resolver, DNSSEC signing of names within the '.home.arpa'
zone is not possible.
Although in principle it might be useful to install a trust anchor
for a particular instance of '.home.arpa', it's reasonable to expect
that a host with such a trust anchor might from time to time connect
to more than one network with its own instance of '.home.arpa'. Such
a host would be unable to access services on any instance of
'.home.arpa' other than the one for which a trust anchor was
configured.
It is in principle possible to attach an identifier to an instance of
'.home.arpa' that could be used to identify which trust anchor to
rely on for validating names in that particular instance. However,
the security implications of this are complicated, and such a
mechanism, as well as a discussion of those implications, is out of
scope for this document.
> Sec. 9 "References"
>
> 15. RFC 3172 should be added as a reference to support the request for a
> delegation in .arpa for .home.arpa.
OK
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
