Re: [DNSOP] .arpa

Ray Bellis <ray@bellis.me.uk> Thu, 23 March 2017 17:50 UTC

Return-Path: <ray@bellis.me.uk>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8D6128B37 for <dnsop@ietfa.amsl.com>; Thu, 23 Mar 2017 10:50:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 V-lEWDkbTBUt for <dnsop@ietfa.amsl.com>; Thu, 23 Mar 2017 10:50:18 -0700 (PDT)
Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83EEE129AC4 for <dnsop@ietf.org>; Thu, 23 Mar 2017 10:50:17 -0700 (PDT)
Received: from dhcp-wifi-246.sql1.isc.org ([149.20.50.246]:64154) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1cr6sH-00046r-Ih (Exim 4.72) for dnsop@ietf.org (return-path <ray@bellis.me.uk>); Thu, 23 Mar 2017 17:50:13 +0000
To: dnsop@ietf.org
References: <20170323042741.79108.qmail@ary.lan> <2C6B4EB6-D0F0-44A8-95E4-68DF32244639@fugue.com> <20170323163205.GD19105@mx4.yitter.info> <500af1ed-5425-4452-ad8e-c2d511ee738d@bellis.me.uk> <850A8729-8762-4375-90EF-50CDF4AC232E@gmail.com>
From: Ray Bellis <ray@bellis.me.uk>
Message-ID: <47548136-78d7-8c53-462e-62439d6194ac@bellis.me.uk>
Date: Thu, 23 Mar 2017 10:50:14 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <850A8729-8762-4375-90EF-50CDF4AC232E@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PlPS191lkftJ_VJluVrcxZHEx0M>
Subject: Re: [DNSOP] .arpa
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2017 17:50:20 -0000


On 23/03/2017 10:34, Suzanne Woolf wrote:

> I’m trying to make sure I understand what the special use reservation
> accomplishes in the absence of the insecure delegation.
> 
> If I read your comment correctly, I can infer two things about the
> protocol, whether the insecure delegation is delayed or refused, at
> least in the short term:
> 
> 1. The protocol is sufficiently functional for deployment without
> working capability for DNSSEC validation.

Correct, in so much as "the protocol" is actually "DNS".

The HNCP protocol is only used to configure the domain name used for
local resolution, but Homenet's zeroconf nature requires that there be a
default value, and as such Homenet / HNCP is not fully deployable
without an agreed default.

The presence of ".home" as that default in RFC 7788 was a mistake, and
the current pair of drafts is our attempt to rectify that.

Hence w.r.t Matt Pounsett's argument that the -redact document go first
and then the assignment of ".homenet" be done later, the Homenet WG has
argued *very* strongly that this is not acceptable because it leaves
HNCP in an indeterminate state.

> 2. Having a single-label name is more important for the functioning
> of the protocol than having DNSSEC validation work.
> 
> Is this a fair assessment of the WG’s view?

Not quite - DNSSEC should work correctly on any Homenet resolver which
has the appropriate trust anchor configured.

The insecure delegation is required to allow validating stub resolvers
in hosts to access .homenet names without the signed proof of
non-existence that's currently in the root from getting in the way.

Since those validating stubs are currently exceedingly rare, we can live
without that insecure delegation _for now_.

Ray