IETF Logo Mail Archive

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

Paul Wouters <paul@nohats.ca> Tue, 20 March 2018 11:44 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 09363127078 for <dnsop@ietfa.amsl.com>; Tue, 20 Mar 2018 04:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 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] 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 iuT5Babd39Mi for <dnsop@ietfa.amsl.com>; Tue, 20 Mar 2018 04:44:40 -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 B216E12E8B0 for <dnsop@ietf.org>; Tue, 20 Mar 2018 04:44:14 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 405B0q3trJz36q; Tue, 20 Mar 2018 12:44:11 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1521546251; bh=wxrdrxJEp/nJX3Wd1sUdyO01eV0Sr2Qjed/7yPdUdIw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=sOMG72RId0aNvR2FqMfsIw1Jn14sMJQH2hOpomIc7ZupNlTcn6+3weFjI/j2eUdEU PgkBYyJDtsXQE8KBJB/vZOeY0YAi827B/eS8wOh8r9fpWg4Bd/r2MCTSBLkaG919hZ rjq+tVhepAQdSReHtBJ6QlR2DXs/MfYIy+U41owI=
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 nITitPhss0G2; Tue, 20 Mar 2018 12:44:05 +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; Tue, 20 Mar 2018 12:44:05 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id E1D06366701; Tue, 20 Mar 2018 07:44:04 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca E1D06366701
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D6316402332F; Tue, 20 Mar 2018 07:44:04 -0400 (EDT)
Date: Tue, 20 Mar 2018 07:44:04 -0400
From: Paul Wouters <paul@nohats.ca>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
cc: dnsop@ietf.org
In-Reply-To: <20180320112653.GA10054@laperouse.bortzmeyer.org>
Message-ID: <alpine.LRH.2.21.1803200740520.29013@bofh.nohats.ca>
References: <alpine.LRH.2.21.1803190813150.31565@bofh.nohats.ca> <20180319163434.GA25738@laperouse.bortzmeyer.org> <CA+nkc8CWtXOiXCVQf4iyJwBS1K4seLxsJmtZyRyz7yuCn+u8hQ@mail.gmail.com> <20180319194945.GG3322@mournblade.imrryr.org> <20180320112653.GA10054@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/wscLzvHqJNIuRMxGBs2KnE1iIAM>
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: Tue, 20 Mar 2018 11:44:42 -0000

On Tue, 20 Mar 2018, Stephane Bortzmeyer wrote:

>> 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.
>
> I don't think that you replied to Bob's remark. He said that the
> proposal is useless because it addresses only the case of "answering
> authoritatively for their child domain", not the "directing child
> domain to someplace".

The goal of the document is to make such malicious changes visible.

If the parent needs to replace NS/DS records, these are easily
auditable identically to Certificate Transparency (rfc 6962bis)
We only need to look (log) the DS/DNSKEY and we do not have
to monitor all TLSA and other security RRtypes. Without this flag,
we need to track and log every DNS RRtype that has public key material
in it.

Paul

v2.23.0 | Report a Bug | By Email