Re: [homenet] WGLC on draft-ietf-homenet-dot-05

[Ted Lemon <[e-mail]>]

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 <[e-mail]> 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