IETF Logo Mail Archive

Re: [Trans] [dane] CT for DNSSEC

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 17 March 2017 18:46 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB546129406; Fri, 17 Mar 2017 11:46:33 -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 CsbjOFX-7Ugw; Fri, 17 Mar 2017 11:46:32 -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 4B217128AB0; Fri, 17 Mar 2017 11:46:32 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 516B17A32F1; Fri, 17 Mar 2017 18:46:31 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <C54BF614-378D-4A0A-964F-AE372E064D42@vpnc.org>
Date: Fri, 17 Mar 2017 14:46:28 -0400
Cc: IETF DANE Mailinglist <dane@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org>
References: <CAAFsWK0bCDZmg0csCfXAJ1=jqbOBc7sUUvSg-6ZKjxuAQKmQPA@mail.gmail.com> <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> <CAAFsWK2z1AR6RZToQvw7s_t_u+333Jyk6pUQ5KznbsrQGxkvgQ@mail.gmail.com> <C54BF614-378D-4A0A-964F-AE372E064D42@vpnc.org>
To: trans@ietf.org
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/EL2X3oVOYcTAHfJzsfP3sWE7u4Y>
Subject: Re: [Trans] [dane] CT for DNSSEC
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Mar 2017 18:46:34 -0000

> On Mar 17, 2017, at 2:20 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> 
>> Is this because you're worried about the parent removing evidence of DNSSEC
>> for the child in the spoofing scenario?
> 
> No, this is because the parent can spoof any data for the child. It is unrelated to DNSSEC.

With qname minimization, the parent will first need to deny an NS
RRset for the child, and those DOE records are better candidates
for logging than routine non-NS queries.  So logging can be limited
to NS/DS queries, but that still leaves us with the problem of how
to avoid logging non-existence of NS/DS for all the sundry leaf
nodes. The public suffix list might be a useful resource here...

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email