Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)

Stephane Bortzmeyer <bortzmeyer@nic.fr> Mon, 19 March 2018 16:37 UTC

Return-Path: <bortzmeyer@nic.fr>
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 9935312D7EC; Mon, 19 Mar 2018 09:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 yWJutULFJPX7; Mon, 19 Mar 2018 09:37:49 -0700 (PDT)
Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [92.243.4.211]) (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 70B2312D7FC; Mon, 19 Mar 2018 09:37:49 -0700 (PDT)
Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id 1075DA05BA; Mon, 19 Mar 2018 17:37:48 +0100 (CET)
Received: by godin (Postfix, from userid 1000) id 639CFEC0BB8; Mon, 19 Mar 2018 17:34:34 +0100 (CET)
Date: Mon, 19 Mar 2018 16:34:34 +0000
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Paul Wouters <paul@nohats.ca>
Cc: dnsop <dnsop@ietf.org>, Trans <trans@ietf.org>, Liang Xia <frank.xialiang@huawei.com>, Wes Hardaker <wes@hardakers.net>
Message-ID: <20180319163434.GA25738@laperouse.bortzmeyer.org>
References: <alpine.LRH.2.21.1803190813150.31565@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.LRH.2.21.1803190813150.31565@bofh.nohats.ca>
X-Transport: UUCP rules
X-Operating-System: Ubuntu 16.04 (xenial)
X-Charlie: Je suis Charlie
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/XN5YM9QPojZMTyM_PYaklPtM7Z4>
Subject: Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)
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: Mon, 19 Mar 2018 16:37:52 -0000

On Mon, Mar 19, 2018 at 08:22:03AM -0400,
 Paul Wouters <paul@nohats.ca>; wrote 
 a message of 57 lines which said:

> We have just submitted a draft aimed at increasing the security of
> the DNSSEC with respect to the power that parental zones have over
> their children.

I'm opposed to this idea.

> While the root and TLD zones are asumed to be almost exclusively
> delegation-only zones,

This is unrelated. You mix two different things, the administrative
issue and the technical one (every subdomain in its own zone). gouv.fr
is administratively a delegation from .fr but is in the same zone.

> the root zone operator (or any level higher in the hierarchy than
> the target victim) could briefly remove the NS and DS records, and
> create a "legitimate" DNS entry for "www.example.org"

That's the DNS. It is a tree. Protecting childs against the parent is
a non-goal, or otherwise we should move to some alternative to DNS
(Namecoin is cool).

> The aim here is to counter the argument that the root key and TLD
> keys are all powerful and under government control, and can therefor
> never be trusted.

I've read the draft and still can understand nothing in this sentence.

> 2) Allow the creation of DNSSEC transparency logs

May be mentioning draft-zhang-trans-ct-dnssec would be nice?

>  The DELEGATION_ONLY flag has a strong overlap in functionality with
>  the Public Suffix List as both signal a formal split of authority
>  between parent and child.

May be mentioning the defunct DBOUND working group would be a good
idea?