Re: [homenet] review of draft-ietf-homenet-redact and draft-ietf-homenet-dot

Jari Arkko <jari.arkko@piuha.net> Mon, 13 March 2017 13:11 UTC

Return-Path: <jari.arkko@piuha.net>
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 29E3F1295F4 for <homenet@ietfa.amsl.com>; Mon, 13 Mar 2017 06:11:41 -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, RP_MATCHES_RCVD=-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 4IFI_Welr00H for <homenet@ietfa.amsl.com>; Mon, 13 Mar 2017 06:11:40 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id CC6631295F0 for <homenet@ietf.org>; Mon, 13 Mar 2017 06:11:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2A9E02CCC1; Mon, 13 Mar 2017 15:11:39 +0200 (EET) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvewJP4v0LZE; Mon, 13 Mar 2017 15:11:38 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B46382CC5E; Mon, 13 Mar 2017 15:11:38 +0200 (EET) (envelope-from jari.arkko@piuha.net)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_66644FA6-C309-4430-ADCC-CCFF934C727E"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <E6A9DDF9-A430-4FBE-B361-3CDE9B7B34C2@gmail.com>
Date: Mon, 13 Mar 2017 15:11:38 +0200
Message-Id: <A0E85A81-3B2F-4999-9510-627C6C11E781@piuha.net>
References: <42ECD4C1-3A87-414C-91D3-8B709A8B3FB5@piuha.net> <20170312135930.GF13811@mx4.yitter.info> <E6A9DDF9-A430-4FBE-B361-3CDE9B7B34C2@gmail.com>
To: Ralph Droms <rdroms.ietf@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/nvdQIthUEvY9Pab3P7Lb7E1duy8>
Cc: HOMENET <homenet@ietf.org>
Subject: Re: [homenet] review of draft-ietf-homenet-redact and draft-ietf-homenet-dot
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 13 Mar 2017 13:11:41 -0000

>>> Also, the insecure delegation in the root zone puts us into a
>>> place where we have not been before, process-wise, because
>>> this is a special use domain name and a proper TLD at the same
>>> time, causing us to run both the ICANN and the IETF process,
>> 
>> As long as we understand "run the ICANN process" as including "getting
>> ICANN to invent such a process", I agree with the above.

This is my understanding as well.

> I agree with Andrew and think we need to consider this step quite carefully.  This text in the IANA considerations section:
> 
>    IANA is requested to set up insecure delegation for '.homenet' in the
>    root zone pointing to the AS112 service [RFC7535], to break the
>    DNSSEC chain of trust.
> 
> does not explain that there is no process through which IANA can set up that delegation.  It may not even be an IANA process.  If this text were to be published in an RFC, I don't think IANA can carry out that instruction today, and I don't think IANA has the authority to negotiate a process through which it can carry out the instruction in the future.
> 
> I think this text should be modified in some way, before the document is published, to recognize explicitly that no such process exists today and that such a process is requested as part of the implementation of the published document.
> 
> The homenet WG is, I believe, aware of the need for a process for instantiating an insecure delegation as requested in the -dot document.  In my opinion, the implicit request for such a process should be made explicit in some way.

Good advice. Thanks.

Jari