Re: [Trans] [dane] CT for DNSSEC
Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 29 March 2017 15:18 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 5E345127599; Wed, 29 Mar 2017 08:18:44 -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=unavailable 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 3drPfO664MML; Wed, 29 Mar 2017 08:18:43 -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 1D73712954A; Wed, 29 Mar 2017 08:11:42 -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 5749C7A32F1; Wed, 29 Mar 2017 15:11:41 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CAAFsWK09KAsYSsDP0mMijYU7E6uw=JyL78kWGiwyJNrn_r3hSw@mail.gmail.com>
Date: Wed, 29 Mar 2017 11:11:40 -0400
Cc: dane@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A86DBCF1-A0E6-4E2F-B588-1DA510771D90@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> <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org> <CAAFsWK1Jeq18mLsKJpv3DJzhrHzX1Z=rQpyxX5TmF+AOLX8-3Q@mail.gmail.com> <9FC39E28-4285-40F8-8FE9-283FA83B1A0A@dukhovni.org> <CAAFsWK09KAsYSsDP0mMijYU7E6uw=JyL78kWGiwyJNrn_r3hSw@mail.gmail.com>
To: trans@ietf.org
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/V8sLRHM648KwUmpW3bygFXs4aGw>
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: Wed, 29 Mar 2017 15:18:45 -0000
> On Mar 29, 2017, at 10:33 AM, Wei Chuang <weihaw@google.com> wrote: > > Why not create an explicit Non-existence of DS (NDS) RR that gets logged along with DS and NS? This is not needed, the NSEC/NSEC3 RRs already serve that role. For NSEC records (RFC4034), an unsigned delegation looks like: example.com. IN NS ns1.example.com. example.com. IN NSEC examplf.com NS example.com. IN RRSIG NSEC ... this proves that NS (or other depending on the content of the type bitmap of the NSEC record) records exist for example.com, but DS records do not. With NSEC3 (rfc5155), and the "opt-out" bit the situation can be more complex because the answer may not establish the existence of example.com. Instead we may get an existence proof for the closest encloser (ancestor domain) and proof that "example.com" is not signed, but no proof of its existence. This means that to avoid spam, a log might want to independently verify the existence of the insecure delegation by repeating the query, so as to avoid storing data for non-existent domains with the insecure NXDOMAIN modified to NOERROR with made up NS records. -- Viktor.
- Re: [Trans] [dane] CT for DNSSEC Wei Chuang
- [Trans] CT for DNSSEC Wei Chuang
- Re: [Trans] [dane] CT for DNSSEC Paul Hoffman
- Re: [Trans] CT for DNSSEC Linus Nordberg
- Re: [Trans] [dane] CT for DNSSEC Wei Chuang
- Re: [Trans] CT for DNSSEC Wei Chuang
- Re: [Trans] [dane] CT for DNSSEC Paul Hoffman
- Re: [Trans] [dane] CT for DNSSEC Viktor Dukhovni
- Re: [Trans] CT for DNSSEC Linus Nordberg
- Re: [Trans] [dane] CT for DNSSEC Wei Chuang
- Re: [Trans] [dane] CT for DNSSEC Wei Chuang
- Re: [Trans] [dane] CT for DNSSEC Viktor Dukhovni
- Re: [Trans] CT for DNSSEC Paul Wouters
- Re: [Trans] [dane] CT for DNSSEC Wei Chuang
- Re: [Trans] [dane] CT for DNSSEC Viktor Dukhovni
- Re: [Trans] [dane] CT for DNSSEC Paul Wouters
- Re: [Trans] [dane] CT for DNSSEC Tony Finch