Re: [homenet] Adam Roach's No Objection on draft-ietf-homenet-dot-12: (with COMMENT)

Ted Lemon <ted.lemon@nominum.com> Wed, 30 August 2017 16:26 UTC

Return-Path: <Ted.Lemon@nominum.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 513031321A1; Wed, 30 Aug 2017 09:26:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 oknKNdSO2MET; Wed, 30 Aug 2017 09:26:32 -0700 (PDT)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F51C13202D; Wed, 30 Aug 2017 09:26:32 -0700 (PDT)
Received: from mail.nominum.com (sjc1-exch01.win.nominum.com [IPv6:2620:0:b60:fab4:1026:2045:f02a:5f75]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 777C0740037; Wed, 30 Aug 2017 16:26:01 +0000 (UTC)
Received: from cavall.ether.lede.home (24.60.163.103) by SJC1-EXCH01.WIN.NOMINUM.COM (64.89.235.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1034.26; Wed, 30 Aug 2017 09:25:57 -0700
From: Ted Lemon <ted.lemon@nominum.com>
Message-ID: <BE43223C-D9BE-44A8-853E-DA3C80E22BFD@nominum.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CABCAD0D-2374-46B7-A2AA-3BCCB4321D7A"
MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 30 Aug 2017 12:25:58 -0400
In-Reply-To: <cb24440c-142d-b13f-9eea-8395ca6ac0db@nostrum.com>
CC: draft-ietf-homenet-dot@ietf.org, homenet-chairs@ietf.org, HOMENET <homenet@ietf.org>, The IESG <iesg@ietf.org>, Ray Bellis <ray@bellis.me.uk>
To: Adam Roach <adam@nostrum.com>
References: <150395805175.13203.12325524217824839037.idtracker@ietfa.amsl.com> <6A42DD6D-CE4C-4172-BE83-C0A259A4368D@nominum.com> <cb24440c-142d-b13f-9eea-8395ca6ac0db@nostrum.com>
X-Mailer: Apple Mail (2.3273)
X-Originating-IP: [24.60.163.103]
X-ClientProxiedBy: SJC1-EXCH02.WIN.NOMINUM.COM (64.89.235.69) To SJC1-EXCH01.WIN.NOMINUM.COM (64.89.235.83)
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/CyiBoz9742NX0_6PH8yKOx5HMcs>
Subject: Re: [homenet] Adam Roach's No Objection on draft-ietf-homenet-dot-12: (with COMMENT)
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 16:26:34 -0000

Argh, I spaced out on doing these changes because the security review was so extensive.   Sorry about that.   I'm making changes to my version of the document, but I will refrain from further confusing the datatracker—assuming that this document is approved tomorrow, I can submit an update with these changes and any others that come up on the telechat.

> On Aug 28, 2017, at 11:18 PM, Adam Roach <adam@nostrum.com> wrote:
> Oh! That makes a lot more sense -- I should have chased down that section in 6761. I think what's tripping me up is the introduction in the homenet-dot draft: "This section defines the behavior of systems involved in domain name resolution when resolving queries for names ending with '.home.arpa.' (as per [RFC6761])." -- it would be clearer if it said something more like "This section reserves the '.home.arpa.' subdomain according to the procedures outlined in [RFC6761] section 4."

The requirement to put this in the IANA considerations section is actually probably a bad idea, because it would create a lot of irrelevant chaff for the IANA to parse through.   I think it was well-intended, but I've never actually seen it done this way in previous RFC 6761 allocations.   That said, your basic point is correct—there should be a better explanation of what's going on in this section.   I've updated the introductory text for this section as follows:

	This section specifies considerations for systems involved in domain name resolution
	when resolving queries for names ending with '.home.arpa.'.  Each items in this section
	addresses some aspect of the DNS or the process of resolving domain names that would be
	affected by this special use allocation.  Detailed explanations of these items can be
	found in <xref target="RFC6761"/>, Section 5.


>>> With the explanation in section 6:
>>> 
>>>   it may be useful for the resolver to identify different
>>>   homenets on which it has resolved names
>>> 
>>> Doesn't this mitigation in the security section require name resolution
>>> libraries to recognize names that end in ".home.arpa." as special so that it
>>> can treat them differently?
>> 
>> Section 6 is talking about future work.   If we come up with a way to do this, then it would update this document, changing the normative requirement.
> 
> To me, this reads as something that could be done unilaterally by the local resolver according to their own reasonable notion of what the proper mitigations might be here. I would suggest rephrasing to make it clearer that this suggestion pertains to _future_ work; e.g., "To prevent this from happening, future documents may define behavior that allows resolvers to identify and distinguish among different homenets on which they have resolved names, and take appropriate measures to avoid such confusion."
> 
> 
Yup, that makes sense.   Proposed update:

	  To prevent this from happening, it could be useful for the resolver to securely
	  differentiate between different homenets, and between identical names on different
	  homenets.  However, a mechanism for doing this has not yet been standardized, and
	  doing so is out of scope for this document.  It is expected that this will be explored in
	  future work.

OK?