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

Paul Wouters <paul@nohats.ca> Mon, 11 March 2019 03:41 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BA27F130EB5 for <dnsop@ietfa.amsl.com>; Sun, 10 Mar 2019 20:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ZtYRfVIcqsnc for <dnsop@ietfa.amsl.com>; Sun, 10 Mar 2019 20:41:36 -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 D49E1130E83 for <dnsop@ietf.org>; Sun, 10 Mar 2019 20:41:35 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44HkRd53Slz1cg for <dnsop@ietf.org>; Mon, 11 Mar 2019 04:41:33 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1552275693; bh=xEyapG9RjZLEKk8PNF1Ybu2z0nzUnZUJxrtWFYcTuQs=; h=Date:From:To:Subject; b=NCrISHXPxPJqwMKaxx8RScoPPw1p9qHHDrV93NlZ+TD+yB4xm+JG0CGx4KtR7lOpa 9G+Kac8qcj4XBKFaAJhgAlSMEe3CgnXuTLXCP/1N7biHPstWPWhAyDaA+Ogl7sLPqc zFy4dwfUoE98B1hATZg+gJdGomN83AKpsBp2Vyls=
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 ZyDZcoPKvmpC for <dnsop@ietf.org>; Mon, 11 Mar 2019 04:41:32 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <dnsop@ietf.org>; Mon, 11 Mar 2019 04:41:31 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7D0395C848; Sun, 10 Mar 2019 23:41:30 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 7D0395C848
Received: from localhost (localhost []) by bofh.nohats.ca (Postfix) with ESMTP id 7521D40C958A for <dnsop@ietf.org>; Sun, 10 Mar 2019 23:41:30 -0400 (EDT)
Date: Sun, 10 Mar 2019 23:41:30 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: dnsop <dnsop@ietf.org>
Message-ID: <alpine.LRH.2.21.1903102327400.31615@bofh.nohats.ca>
User-Agent: Alpine 2.21 (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/wsHHbrLssgn_uQKuyog4ZXtZCyg>
Subject: [DNSOP] Fwd: New Version Notification for draft-pwouters-powerbind-02.txt (fwd)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 11 Mar 2019 03:41:39 -0000

Wes and I updated the powerbind draft.

We did a lot of rewriting to clarify the concept, so of you were confused,
please give this version another read. It clarifies a few issues based
on the responses we had so far, such as the limitations of RRTYPE's for
DELEGATION_ONLY zones (and how to deal with things like ns0.example.org

There were two ideas floating around we did not incorporate.

Any claims (or new bits to claim) parents aren't allowed to skip you is
one idea we did not add, as we couldn't find any behavioural change it
would cause, while causing a lot of politics :)

We also did not incorporate a new bit or bits to allow for variable
limits (eg to support things like co.uk)

We did add an exception for _label as those labels really only convey
information about the zone itself, and can never be mistaken for a
child delegation. This would prevent requiring zone cuts for all _label
directives (although it does not prevent these if you want to do them)

Note that it seems the datatracker broke and is throwing a 404 on the
below Htmlized page. Until that is fixed, you can read the document
on github as well: https://github.com/hardaker/draft-pwouters-powerbind/


---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Sun, Mar 10, 2019 at 11:24 PM
Subject: New Version Notification for draft-pwouters-powerbind-02.txt
To: Paul Wouters <pwouters@redhat.com>om>, Wes Hardaker <ietf@hardakers.net>

A new version of I-D, draft-pwouters-powerbind-02.txt
has been successfully submitted by Paul Wouters and posted to the
IETF repository.

Name:           draft-pwouters-powerbind
Revision:       02
Title:          The DELEGATION_ONLY DNSKEY flag
Document date:  2019-03-10
Group:          Individual Submission
Pages:          9
URL:            https://www.ietf.org/internet-drafts/draft-pwouters-powerbind-02.txt
Status:         https://datatracker.ietf.org/doc/draft-pwouters-powerbind/
Htmlized:       https://tools.ietf.org/html/draft-pwouters-powerbind-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-pwouters-powerbind
Diff:           https://www.ietf.org/rfcdiff?url2=draft-pwouters-powerbind-02

   This document introduces a new DNSKEY flag called DELEGATION_ONLY
   that indicates that the particular zone will never sign zone data
   aside from records at the apex of the zone or delegation records for
   its children.  That is, every label (dot) underneath is considered a
   zone cut and must have its own (signed) delegation.  DNSSEC
   Validating Resolvers can use this bit to mark any data that violates
   the DELEGATION_ONLY policy as BOGUS.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat