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

Paul Wouters <paul@nohats.ca> Mon, 19 March 2018 21:53 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 D0AB412D94E; Mon, 19 Mar 2018 14:53:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level:
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 e9IyAwG29q85; Mon, 19 Mar 2018 14:53:26 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::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 BBAE512D957; Mon, 19 Mar 2018 14:53:23 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 404qZB0Z0xzCy6; Mon, 19 Mar 2018 22:53:22 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1521496402; bh=Jf9R42DuAT/j6ShoL6xfxYdL8ZEYb7S/rxcze6edEbQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=QvmvOcroKbmrlHy9C1BUQUVX0wD0XjnSs8NpdLauOQtAWgjGzvvC4rQne/l8eCoCL a7qZ3k+qxcNa6XxeM8JYYSLdi0+YfgK2vfNT1wHY5Kr9JHu4yS0juklLI8/8wTRZ9H hRQZ6kbzMChsa8PFa4FwGwVD3VnD9qM3+Fi/8Krs=
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 2lvFgzQdyvW3; Mon, 19 Mar 2018 22:53:20 +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; Mon, 19 Mar 2018 22:53:19 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 70DE7C98; Mon, 19 Mar 2018 17:53:18 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 70DE7C98
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6C6E940007E9; Mon, 19 Mar 2018 17:53:18 -0400 (EDT)
Date: Mon, 19 Mar 2018 17:53:18 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
cc: dnsop <dnsop@ietf.org>, Trans <trans@ietf.org>
In-Reply-To: <20180319163434.GA25738@laperouse.bortzmeyer.org>
Message-ID: <alpine.LRH.2.21.1803191737220.12290@bofh.nohats.ca>
References: <alpine.LRH.2.21.1803190813150.31565@bofh.nohats.ca> <20180319163434.GA25738@laperouse.bortzmeyer.org>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_xCi7Lm_cyDXengkQubNxsenGa0>
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 21:53:28 -0000

On Mon, 19 Mar 2018, Stephane Bortzmeyer wrote:

> I'm opposed to this idea.

Can you clarify whether you oppose to be a user of this new flag, or
whether you oppose of giving others the option of using this flag?

>> 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 idea is that the current technology cannot tell this difference,
but we know at some point down the chain there (usually) is a real owner
change. This allows a zone to publish that information.

One of the side effects is that is there is no zone cut when traversal
a label, that to use this new flag, you have to turn this label change
into a real zone cut. I believe the setup of that is easy and that there
are no real operational impacts caused by this, but I'm happy to hear
from operators, especially TLDs, if there are any concerns with such
a conversion.

> That's the DNS. It is a tree. Protecting childs against the parent is
> a non-goal

If you can't not trust your friends, who can you not trust? :)

We also did not publish TLSA records in the zone in the old days. Now
we do so there is a clear (new) need to add a bit of protection for the
children against potentially malicious parents. It's completely an
opt-in option for the parent.

Rather then hearing "That's the DNS", I'm more interested in hearing
about whether TLDs would be willing to adopt this solution, and if not,
what actual operational (or organisational?) concerns they would have.

> or otherwise we should move to some alternative to DNS

That is outside the scope of this proposed solution :)

>> 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.

I'm happy to talk in person this week if that helps. Otherwise if you
have specific questions, I can try to answer them here.

>> 2) Allow the creation of DNSSEC transparency logs
>
> May be mentioning draft-zhang-trans-ct-dnssec would be nice?

This document is not about ct-dnssec itself. It has as one of its goals,
to make some kind of ct-dnssec possible. But that will be pursued with
another document (and probably on the trans list)

>>  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?

What specifically about DBOUND is worth mentioning in the document?

Paul