Re: [homenet] Secdir last call review of draft-ietf-homenet-dot-12

Ted Lemon <mellon@fugue.com> Wed, 30 August 2017 02:03 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624B91321A5 for <homenet@ietfa.amsl.com>; Tue, 29 Aug 2017 19:03:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LX6zJWuPT8o for <homenet@ietfa.amsl.com>; Tue, 29 Aug 2017 19:03:15 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9F961320C9 for <homenet@ietf.org>; Tue, 29 Aug 2017 19:03:14 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id k126so22763218qkb.4 for <homenet@ietf.org>; Tue, 29 Aug 2017 19:03:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=02jvH5tqYuRSttIYJWbrvNUqe9Gbyh80Ze62j3UWZNY=; b=g8dtw8HO2kLFmGA2S36Xowzy6r29avse6b0VrxnUjPnZg3V92WbRNQrh+GWElBmhRZ 5OYze/jnu5va+r4yvV5Kv8FI9ubV0xLnr6SqFEr3lTLsoaWmFMl3c/D+82maMehY0xbC QyY6SDFdBwtTAWC7jtkWy08bj4VOAYBrjBpDEScAJDiHGPSkQ6QtXpoD+xTUIOF46ZRl IkfgWWl2Pcslv0/8tftNPd9uG6f1lCd40Bwci/BYM/0/42+r1yuae4fK21wIfZh8oVJx Kca2QDCI6/QF9rosm1clCaoiC4MSCd2ZR1PJufc/8vXI/J6avaCKvf+Xw3QKzayVZjmZ gstQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=02jvH5tqYuRSttIYJWbrvNUqe9Gbyh80Ze62j3UWZNY=; b=lFL5od6hJ+887HBce3MfqnK8vpHoQO74kmUPBSo89gQotPSGdd+1G/+X+9/kCbNC01 DB5R7GFZqjwUp2ce3N+GPjqfmcdel00/poRS2hpagtH1+uR8f9HNVGQmCc/gQZdeuTC8 Pzuv3MakvHzUrZ5lETOS8777uqiDDov8cuTb0iLxqejHmrs4y1DObIH+1UVJjiUqZfcM HFah181TIY1P4XDaWE3LMrknFj/bP9Qsxjte9HB7rsvbZEJW/iItCv8q5KsFyGxEizZ0 OXS2B87zcNXdfNy2MTw4LWfoGrBZOrLAPN7qZsD+jwLo/kfzi3CbrVrejLoEAVCuSJFb EhoA==
X-Gm-Message-State: AHYfb5gddCEAZJd/YdtfHaHrn7fLPn+fNmD6A7VcAWxW/jalqxcwi8fu SyMcgsAuS9LPckyV
X-Received: by 10.55.103.151 with SMTP id b145mr8231501qkc.78.1504058593596; Tue, 29 Aug 2017 19:03:13 -0700 (PDT)
Received: from cavall.w50.lede.home (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id q88sm2973371qtd.80.2017.08.29.19.03.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Aug 2017 19:03:12 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <5C378A81-AB6B-4F2F-8D97-CDED30D788AE@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_35742441-512C-4B16-A871-25F8F5ED881A"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 29 Aug 2017 22:03:10 -0400
In-Reply-To: <150307463977.14156.2178189421671973906@ietfa.amsl.com>
Cc: secdir@ietf.org, HOMENET <homenet@ietf.org>
To: Daniel Migault <daniel.migault@ericsson.com>
References: <150307463977.14156.2178189421671973906@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/l9FQmFt1SAQ_RGVG3x_9hHBbFHg>
Subject: Re: [homenet] Secdir last call review of draft-ietf-homenet-dot-12
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Aug 2017 02:03:21 -0000

Thanks for the review, Daniel.   I've included changes based on your observations inline.

On Aug 18, 2017, at 12:43 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:
> Abstract
> 
>   This document specifies the behavior that is expected from the Domain
>   Name System with regard to DNS queries for names ending with
>   '.home.arpa.', and designates this domain as a special-use domain
>   name. 'home.arpa.' is designated for non-unique use in residential
>   home networks.  Home Networking Control Protocol (HNCP) is updated to
>   use the 'home.arpa.' domain instead of '.home'.
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%      
> MGLT: I would personally start by saying the document defines a
> special-use domain name and then defines the behavior. 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%      

No change

>   Users and devices within a home network (hereafter "homenet") require
>   devices and services to be identified by names that are unique within
>   the boundaries of the homenet [RFC7368].  The naming mechanism needs
>   to function without configuration from the user.  While it may be
>   possible for a name to be delegated by an ISP, homenets must also
>   function in the absence of such a delegation.  A default name with a
>   scope limited to each individual homenet needs to be used.
> 
>   This document corrects an error in [RFC7788], replacing '.home' with
>   'home.arpa.' as the default domain-name for homenets. '.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].
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   
> MGLT: I believe that more important than the leak is that the 
> introduction of .home in the root zone has been identified as
> highly risky. Another reason for not adopting it are also some
> uncertainty about its introduction into the root zone.    
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   

This is irrelevant, because the IETF hasn't asked ICANN for a delegation.   We deliberately left out this discussion because it's a moot point now and potentially a political hot potato.   I personally agree with you that this is important, but I think despite its importance, we got out of that what we needed, and it's better not to mention it here.

>   This document registers the domain '.home.arpa.' as a special-use
>   domain name [RFC6761] and specifies the behavior that is expected
>   from the Domain Name System with regard to DNS queries for names
>   whose rightmost non-terminal labels are 'home.arpa.'.  Queries for
>   names ending with '.home.arpa.' are of local significance within the
>   scope of a homenet, meaning that identical queries will result in
>   different results from one homenet to another.  In other words, a
>   name ending in 'home.arpa.' is not globally unique.
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   
> MGLT: I think the text mentioned in the beginning of the paragraph 
> above should be in the abstract. That was the sense of my previous
> comment. 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%      

The point of an abstract is to give a quick summary of what the document does, not to recapitulate what it does.   This is a bit of a hobby horse for me, so I'm not going to lengthen the abstract to include more details unless my AD tells me I have to.   I do appreciate your point, but I do not think that the additional text that you are referring to is necessary in the abstract.

>   DNS queries for names ending with '.home.arpa.' are resolved using
>   local resolvers on the homenet.  Such queries MUST NOT be recursively
>   forwarded to servers outside the logical boundaries of the homenet.
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   
> MGLT: "local resolvers" seems to me mis-leading. Your resolver may
> be local but still forward the query to the Global Internet. I do
> not see better ways to say it other than inside the boundaries of
> the homenet. Maybe we could say:   
> 
>   DNS queries for names ending with '.home.arpa.' are resolved using
>   homenet specific resolution mechanisms. 
> 
> Eventually an informational reference to the simple naming 
> architecture may be added so the reader can refer to the doc
> for further information. For full disclosure Ted and I are
> co-authors.  
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   

The document makes this really clear in a later section.   The text you are proposing to add makes it _less_ clear.   I do not think this change is a good idea.

>   Some service discovery user interfaces that are expected to be used
>   on homenets conceal information such as domain names from end users.
>   However, it is still expected that in some cases, users will need to
>   see, remember, and even type, names ending with 'home.arpa.'.  It is
>   therefore desirable that users identify the domain and understand
>   that using it expresses the intention to connect to a service that is
>   specific to the homenet to which they are connected.  Enforcing the
>   fulfillment of this intention is out of scope for this document.
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   
> MGLT: I have difficulties understanding the paragraph above. If 
> the idea is to say home.arpa has special meaning that should be
> considered by GUIs I would propose the following ordering.
> 
> It is
>   therefore desirable that users identify the domain and understand
>   that using it expresses the intention to connect to a service that is
>   specific to the homenet to which they are connected. 
> Some service discovery user interfaces that are expected to be used
>   on homenets conceal information such as domain names from end users.
>   However, it is still expected that in some cases, users will need to
>   see, remember, and even type, names ending with 'home.arpa.'.  
> Enforcing the
>   fulfillment of this intention is out of scope for this document.   
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   

The text here is actually present as a justification for why we wanted '.home' but didn't get eliminated.   I don't think there'd be consensus to completely eliminated it, but I've clarified it by taking out the text that I think confused you:

    Some service discovery user interfaces that are expected to be used
    on homenets conceal information such as domain names from end users.
    However, it is still expected that in some cases, users will need to
    see, remember, and even type, names ending with 'home.arpa.'.  The
    working group hopes that this name will in some way indicate to as
    many readers as possible that such domain names are referring to
    devices in the home, but we recognize that it is an imperfect
    solution.

>   2.  Application software SHOULD NOT treat names ending in
>       'home.arpa.' differently than other names.  In particular, there
>       is no basis for trusting names that are subdomains of
>       'home.arpa.' (see Section 6).
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   
> MGLT: a domain name ending in home.arpa may be resolved differently
> that a regular domain name. As a result a different treatment is 
> applied. I think that "treat" means that no special meaning - other
> that the domain name is inside the homenet boundaries - should be 
> associated to a home.arpa. If I am correct I would limit the 
> consideration to the name rather then the application. 
> I would suggest the text below:
> 	
> names ending in home.arpa SHOULD NOT be associated any other 
> properties than the affiliation to the homenet. In particular, there
>       is no basis for trusting names that are subdomains of
>       'home.arpa.' (see Section 6).
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   

This section is present in accordance with RFC 6761 and is required to talk about applications, so this change would not make sense in that context.   I agree that talking about applications in this case is fraught, but with that in mind I think the text is as good as we can do.   I think that your proposed change makes it less clear, because you haven't said what you mean by "properties."   The only property that I think is really important here is trust, so clarifying that "home.arpa" does not imply extra trust is important.   Think of this in the context of https://w3c.github.io/webappsec-secure-contexts/ <https://w3c.github.io/webappsec-secure-contexts/>.   This text is to specifically exclude that sort of assumption, not that I think the W3C would make such a mistake!

>   3.  Name resolution APIs and libraries MUST NOT recognize names that
>       end in '.home.arpa.' as special and MUST NOT treat them
>       differently.  Name resolution APIs MUST send queries for such
>       names to a recursive DNS server that is configured to be
>       authoritative for the 'home.arpa.' zone appropriate to the
>       homenet.  
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   
> MGLT: I believe the text below does not concern the library but 
> the resolver. It is different to say libraries MUST NOT have 
> specific considerations for home.arpa than a resolution service 
> that may use different libraries MUST NOT consider the home.arpa
> differently. 
> My understanding of the text below is that the resolver and the
> authoritative server for the home.arpa MUST be co-located. The
> reasons I think this is not exact is that resolution for 
> home.arpa can also be provided by other mechanisms than an 
> authoritative server. Typically, resolution can be done by 
> requesting Authoritative Servers, Advertising Proxies, Hybrid 
> Proxies (now called Discovery Proxies)....
> The other reason is do not see the text below accurate is that
> you may have a DNS Proxy that transparently to the end user split
> the resolution between homenet specific resolutions when home.arpa
> is encountered while other names are sent to the ISP resolver.
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   

No, this text is required by RFC 6761 to address the behavior of local stub resolvers and resolution libraries.   Changing it to talk about recursive resolvers and proxies would make it incorrect according to those requirements.   That said, I have substantially revised that text and it may now make more sense to you:

    3.  Name resolution APIs and libraries MUST NOT recognize names that
        end in '.home.arpa.' as special and MUST NOT treat them as having
        special significance, except that it may be necessary that such
        APIs not bypass the locally configured recursive resolvers.
        One or more IP addresses for recursive DNS servers will usually
        be supplied to the client through router advertisements or DHCP.
        For an administrative domain that uses names in 'home.arpa.',
        such as a homenet, the recursive resolvers provided by that
        domain will be able to answer queries for subdomains of
        home.arpa; other resolvers will not, or will provide answers that
        are not correct within that administrative domain.
        A host that is configured to use a resolver other than one that
        has been provided by the local network may be unable to resolve,
        or may receive incorrect results for, names in sub domains of
        'home.arpa.'.  In order to avoid this, it is permissible that
        hosts use the locally-provided resolvers for resolving
        'home.arpa.' even when they are configured to use other
        resolvers.
I also added this related text to the security considerations section:

    In Section 4, item 3, an exception is made to the behavior of stub
    resolvers allowing them to query local resolvers for subdomains of
    'home.arpa.' even when they have been manually configured to use
    other resolvers.  This behavior obviously has security and privacy
    implications, and may not be desirable depending on the context.  It
    may be better to simply ignore this exception and, when one or more
    recursive resolvers are configured manually, simply fail to provide
    correct answers for subdomains of 'home.arpa.'.  At this time we do
    not have operational experience that would guide us in making this
    decision; implementors are encouraged to consider the context in
    which their software will be deployed when deciding how to resolve
    this question.
>   4.  Caching resolvers conforming to this specification MUST support
>       DNSSEC queries.  While validation is not required, it is strongly
>       encouraged; a caching resolver that does not validate answers
>       that can be validated may cache invalid data; this will prevent
>       validating stub resolvers from successfully validating answers.
> 	   
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   
> MGLT: I see the text above as a recommendation for caching resolvers
> in the homenet, but the relation to the home.arpa is unclear to me. 
> Was the intention to say that names under the home.arpa zone SHOULD 
> be secured with DNSSEC so caching resolvers MUST support DNSSEC 
> validation. In addition, these caching resolvers MUST also be able 
> to be configured with a Trust Anchor for the home.arpa.	   
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   

The text was actually incorrect.   I've substantially rewritten that item:

        A.  Recursive resolvers at sites using 'home.arpa.'  MUST
            transparently support DNSSEC queries: queries for DNSSEC
            records and queries with the DO bit set ([RFC4035] section
            3.2.1) .  While validation is not required, it is strongly
            encouraged; a caching recursive resolver that does not
            validate answers that can be validated may cache invalid
            data; this will prevent validating stub resolvers from
            successfully validating answers.

The other requirements you list are impossible, because we don't have a mechanism for generating such trust anchors, nor for disambiguating between different instances of such trust anchors that a host may need in order to use resources on different homenets.   Furthermore, requiring host changes is out of charter.   I agree with you in principle that this needs to happen, and as you are aware we are working on addressing this problem, both in homenet and in dnssd.   But we can't address it here.

>       It is permissible to combine the recursive resolver function for
>       general DNS lookups with an authoritative resolver for
>       'home.arpa.'; in this case, rather than forwarding queries for
>       subdomains of 'home.arpa.' to an authoritative server, the
>       caching resolver answers them authoritatively.  The behavior with
>       respect to forwarding queries specifically for 'home.arpa.'
>       remains the same.
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   
> MGLT: The full consideration seems to me to be conformance to RFC6303.
> In particular the recommendations for DNSSEC in RFC 6303 seems to me
> accurated and are not specifically mentioned here. Maybe that should 
> be clearly stated that all considerations of RFC6303 should be 
> considered as home.arpa is of local scope. 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   

I think you are missing the point of this text.  The behavior for RFC6303 was already specified a few paragraphs earlier, and is required for all resolvers, not just homenet resolvers.   This text is simply allowing a homenet router implementation to either implement a caching server and a separate authoritative server, or merge the two into a hybrid authoritative/recursive server.   You can do this today with an out-of-the-box BIND 9 installation.
	   
>   5.  No special processing of 'home.arpa.' is required for
>       authoritative DNS server implementations.  It is possible that an
>       authoritative DNS server might attempt to check the authoritative
>       servers for 'home.arpa.' for a delegation beneath that name
>       before answering authoritatively for such a delegated name.  In
>       such a case, because the name always has only local significance
>       there will be no such delegation in the 'home.arpa.' zone, and so
>       the server would refuse to answer authoritatively for such a
>       zone.  A server that implements this sort of check MUST be
>       configurable so that either it does not do this check for the
>       'home.arpa.' domain, or it ignores the results of the check.
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   
> MGLT: I understand this as being incorrect. The resolver can also be configured 
> with a trust anchor. I would refer to the RFC6303:
> 
> As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
>   namespaces, the zones listed above will need to be delegated as
>   insecure delegations, or be within insecure zones.  This will allow
>   DNSSEC validation to succeed for queries in these spaces despite not
>   being answered from the delegated servers.
> 
>   It is recommended that sites actively using these namespaces secure
>   them using DNSSEC [RFC4035] by publishing and using DNSSEC trust
>   anchors.  This will protect the clients from accidental import of
>   unsigned responses from the Internet.	   
> 	   
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   

This text is about authoritative servers, not resolvers.   Locally-served zones are covered under item 4.

>      The 'home.arpa.' special-use name does not require a special
>      resolution protocol.  Names for which the rightmost two labels are
>      'home.arpa.' are resolved using the DNS protocol [RFC1035].
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   
> MGLT: If home.arpa are no different than other resolutions and we 
> start from the root zone responses are likely to be NXDOMAIN. I 
> think we should clarify that DNS is used as a transport protocol, 
> but that resolution may be handled differently.
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   

No, this is incorrect.   The DNS protocol is being used to do resolution.   No host changes are required.

>   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.
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%      
> MGLT: I think that DS is meant rather than trust anchor.
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   

A DS record is a trust anchor.   I've updated it as follows:

  It is not possible to install a trust anchor (a DS RR) 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).  
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%      
> MGLT: This is unclear where the denial of existence is set. Is 
> that in the home.arpa zone or the arpa zone. 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   

There is only one place where it can be set.   I have updated the text as follows:
    An alternative would be to provide a authenticated denial of
    existence ([RFC4033] Section 3.2).  This would be done simply by not
    having a delegation from the 'arpa.' zone. 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%      
> MGLT: There are also some privacy issues associated to leaking names
> outside the homenet boundaries. For example daniel_smith.home.arpa
> reveal the identity of the member of the homenet, my_ipad.home.arpa
> reveals the devices you own, the application. 

This is a known issue, and it's up to the vendors of devices to decide how much they are willing to reveal.   There is work going on in dnssd to provide a secure way of doing this.   It's out of scope for this document.   The document doesn't create a new problem here.

> home.arpa may also used in larger environment such as corporate / 
> private. going from one to the other may also leak such information. 

Use of home.arpa is for home networks.   If a corporate environment uses it, it's no different than them using some other ad-hoc name.

> The leak can be from the homenet to the outside world in which case
> one neeed to control the queries sent. But in intruder (or guest) 
> may also access the homenet and proceed to discovery of the names. 
> As a result even though homenet is believe to be a trusted environment, 
> care should be considered while publishing under the home.arpa. as
> well as whose the information is accessible to.   

Yes, an attacker can suborn your home router, and if they do, your privacy will be more easily violated.   And, as with existing technology, devices may or may not reveal private information about you to the network.   This is not a problem that we are creating with this document, and it is not a problem we can solve with this document.   Work to solve this is ongoing; I would prefer to publish this document now rather than holding it up waiting for that other work.

> They might be collision as well. myprinter.home.arpa may be found
> in various environments, and upon discovery you may also - 
> in this example - print confidential information to that printer. 
> In some case you may not even be aware, for example, if your 
> printing information failed home, and is re-activated once you 
> are in another environment.  

This issue is already documented in the security considerations section.

> As information may be sensitive it may be encrypted using IPsec 
> DTLS as described by dprive for both authentication and confidentiality. 

How would we arrange to distribute the trust anchor here?   PKI won't work.   I don't see how we would establish trust with IKE either.   Again, work is going on in dnssd to provide an infrastructure that would allow this, but right now this is empty advice: this is a document about home networks, operated by end users, so if there isn't a way to do this automatically, there is no point in saying that end users should do it: they are never going to read this document.

> When the trust anchor is configured in the resolver, these must be
> able to roll-over the key and should follows the requirements for DNSSEC
> validators. if it is impossible for a resolver to see the difference 
> between an attack and a re-key we are in trouble. 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   

This is an excellent point, and we should consider it when we write the document where we explain how to manage these trust anchors.   This is work that I fully intend to do in homenet, but right now this point doesn't make sense to mention here because this document doesn't provide an automatic way of setting up trust anchors.

>   In order to be fully functional, there must be a delegation of
>   'home.arpa.' in the '.arpa.' zone [RFC3172].  This delegation MUST
>   NOT include a DS record, and MUST point to one or more black hole
>   servers, for example 'blackhole-1.iana.org.' and 'blackhole-
>   2.iana.org.'.  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.
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%      
> MGLT: The zone home.arpa MUST NOT be seen as belonging to the 
> homenet. As a result, NS and DS records for home.arpa does not 
> have meanings outside a specific domain. A Public server outside 
> the boundaries of the homenet MUST consider this traffic as 
> irrelevant and sink.    
> 
> Redirection to as112 without coordination with as112 operator 
> may rather be performed using DNAME. I believe more text should 
> document the two alternative. With the proposed configuration, 
> the query will be directed to a server that is not authoritative for 
> the zone. The response is likely to be REFUSED, while in the other 
> case it is likely to be NXDOMAIN.
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%      

This document was reviewed extensively in DNSOP.   The text specifies what is supposed to happen.   It's not a discussion: it's a directive to IANA and an explanation for the IAB, which operates .arpa.   I cannot make this change without breaking the document.

> 8.  IANA Considerations
> 
>   IANA is requested to record the domain name 'home.arpa.' in the
>   Special-Use Domain Names registry [SUDN].  IANA is requested, with
>   the approval of IAB, to implement the delegation requested in
>   Section 7.
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%      
> MGLT: OK if IANA may make the direct way work. In that case is 
> there any need to update a registry for zone served by as112? 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%      

Yes.   As far as I know the text gives IANA the information they need to do; I do not know how they operate their black hole servers, so I am trusting that these instructions are sufficient.   They have been reviewed by people who understand this problem better than I do, like Andrew Sullivan, Paul Hoffman and Mark Andrews.   I was specifically advised not to overspecify this.   I would rather take their word on this than yours, if you will forgive my saying so. :)

Thanks for the detailed review.   I didn't take all of your suggestions as written, but the document has definitely been improved as a result of this review.