Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Paul Wouters <paul@nohats.ca> Tue, 21 March 2017 13:54 UTC

Return-Path: <paul@nohats.ca>
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 6B6C8126DEE for <dnsop@ietfa.amsl.com>; Tue, 21 Mar 2017 06:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 VeMlkWNWj_6b for <dnsop@ietfa.amsl.com>; Tue, 21 Mar 2017 06:54:09 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 1230F126DED for <dnsop@ietf.org>; Tue, 21 Mar 2017 06:54:09 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vnZ6j5sKhzB8; Tue, 21 Mar 2017 14:54:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1490104445; bh=tjmKeam/n+M9QxVw7I9UxyCacCa+0b1p8vEnzsoNF0Q=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=plUYVAEqdl9tfV84mWYsKFpD+cqvrsKu0gP8V47WZBxz3AUUkR4IG7UFyIu952rrY uGsl6C3JWtjsDvyJENLdI4sbUybN0fbTFdFnPpEB7brY5EcgafAIDs3A2pkemIvvT5 5+oDw+AdBkpv0MRTGt670ocpfCOxAHZQxKqF5VCI=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 6RyF2gfaBdmj; Tue, 21 Mar 2017 14:54:04 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 21 Mar 2017 14:54:04 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1886E353868; Tue, 21 Mar 2017 09:54:03 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 1886E353868
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0249D40D358D; Tue, 21 Mar 2017 09:54:02 -0400 (EDT)
Date: Tue, 21 Mar 2017 09:54:02 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Suzanne Woolf <suzworldwide@gmail.com>
cc: Russ Housley <housley@vigilsec.com>, dnsop <dnsop@ietf.org>, Ted Lemon <mellon@fugue.com>, Terry Manderson <terry.manderson@icann.org>
In-Reply-To: <6DCFBC9D-666A-4A3C-A418-82BB6AE3D25D@gmail.com>
Message-ID: <alpine.LRH.2.20.999.1703210928390.28925@bofh.nohats.ca>
References: <E07AFAEB-2B84-4610-87E7-94CF32CF3761@fugue.com> <7652B138-FEAB-4138-91FB-D71AFE6BEF2C@vigilsec.com> <6DCFBC9D-666A-4A3C-A418-82BB6AE3D25D@gmail.com>
User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/92FxtqxaGQv7-xlVIF5oA_LRHvM>
Subject: Re: [DNSOP] WG review of draft-ietf-homenet-dot-03
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: Tue, 21 Mar 2017 13:54:11 -0000

On Tue, 21 Mar 2017, Suzanne Woolf wrote:

[also speaking as individual only]

> I see no justification in draft-ietf-homenet-dot for a single-label name, except an implicit suggestion in
> Sec. 2 para. 2 that the specific string was chosen to be memorable in cases where homenet names are exposed to
> users. 

That seems good enough for me. The problem of DNS being the only
real name space for endusers is very well understood. And I still
regularly have to refind my printer based on checking my dhcp server
logs, something not available to regular endusers. The requirement
is very real.

> I *strongly* suggest that if this document is to be used as justification to create an entirely new process
> for updating the root zone, coordinated between the IETF and the external body that controls the root zone,
> the justification should be *much* more explicit.

This .home / .homenet issue has already been going on for a very long
time. The longer we wait with resolving this issue, the worse the
deployment situation will be of software mixing .home vs .homenet.

Suggesting we postpone .homenet while figuring out a new IETF/ICANN
process, something that can take years, would basically doom this rename
and install .home as the defacto standard. Once this new process
would be completed, it would lead to new breakage, and the new
software would be forced to look into both domains, or if the
install base is big enough for .home, would be better of ignoring
a new .homenet altogether.

As for requiring an insecure entry in the root, I'm still not convinced
it buys us that much. Resolvers on the stub that bypass the local
DHCP supplied DNS servers need to be modified anyway to use the local
DNS servers to request .homenet entries, whether they support DNSSEC
or not. So that leaves DNSSEC capable DNS resolvers that use the DHCP
supplied servers as forwarder entries in need of such an unsigned entry
only. I do think that such DNSSEC capable software tends to be maintained
by the OS and could gain special handling of the .homenet domain. And if
not, I seriously wonder if those enduser DNS stubs/servers implement
RFC-5011 well enough to survive the upcoming KSK rollover. Or any
other homenet protocol update in the future. So I would say an insecure
delegation would be nice to have but not required. And if it would shave
of a year of creating a new process between IETF, ICANN and the MoU,
then I'd say for the deployment as a whole, it would be better to get
the Special Use Domain ASAP without an entry in the root.

Paul