IETF Logo Mail Archive

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

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 19 March 2018 19:49 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 2791C12D93F for <dnsop@ietfa.amsl.com>; Mon, 19 Mar 2018 12:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 r9NUaaJwR4nD for <dnsop@ietfa.amsl.com>; Mon, 19 Mar 2018 12:49:46 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857BD12D890 for <dnsop@ietf.org>; Mon, 19 Mar 2018 12:49:46 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3DF637A330A; Mon, 19 Mar 2018 19:49:45 +0000 (UTC)
Date: Mon, 19 Mar 2018 19:49:45 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop <dnsop@ietf.org>
Message-ID: <20180319194945.GG3322@mournblade.imrryr.org>
Reply-To: dnsop@ietf.org
References: <alpine.LRH.2.21.1803190813150.31565@bofh.nohats.ca> <20180319163434.GA25738@laperouse.bortzmeyer.org> <CA+nkc8CWtXOiXCVQf4iyJwBS1K4seLxsJmtZyRyz7yuCn+u8hQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CA+nkc8CWtXOiXCVQf4iyJwBS1K4seLxsJmtZyRyz7yuCn+u8hQ@mail.gmail.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/h7IY7fDrKo9x3cULJW-SRhxMwBU>
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 19:49:48 -0000

On Mon, Mar 19, 2018 at 02:12:38PM -0400, Bob Harold wrote:

> > > 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.
>
> If the parent simply pointed the NS and DS records to a different version
> of the zone, that would accomplish the same effect, even with a
> 'delegation-only' flag, so the 'delegation-only' flag really does not solve
> the problem.

The 'delegation-only' flag does not *by itself* prevent parent
domains from answering authoritatively for their child domains,
but it could make "certificate-transparency" more tractable for
DNSSEC.

The idea is to log the DNSKEY RRs observed at each zone apex.
Without the proposed flag, one would also have to log denial of
existence which would make the logs much too large.  CT for DNSSEC
may be impractical anyway, but this flag could make it more realistic.

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email