Re: [dane] [Trans] CT for DNSSEC

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 20 March 2017 23:01 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80387127077; Mon, 20 Mar 2017 16:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 wXIy7ARaWSY9; Mon, 20 Mar 2017 16:00:58 -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 A40F6126D85; Mon, 20 Mar 2017 16:00:58 -0700 (PDT)
Received: from [172.31.30.83] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (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 BD8047A32F1; Mon, 20 Mar 2017 23:00:57 +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: <CAAFsWK1Jeq18mLsKJpv3DJzhrHzX1Z=rQpyxX5TmF+AOLX8-3Q@mail.gmail.com>
Date: Mon, 20 Mar 2017 19:00:56 -0400
Cc: IETF DANE Mailinglist <dane@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <9FC39E28-4285-40F8-8FE9-283FA83B1A0A@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>
To: trans@ietf.org
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dane/BTz0wleC5tSqPpOxB0bjR6vzT_4>
Subject: Re: [dane] [Trans] CT for DNSSEC
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Mar 2017 23:01:00 -0000

> On Mar 20, 2017, at 6:43 PM, Wei Chuang <weihaw@google.com>; wrote:
> 
>>> 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.
> 
> Can you expand on how the the DOE record (which I assumes means
> denial-of-existence) could work with an adversarial parent?

Yes, DOE is denial of existence.  When the child sends NS queries
as part of qname minimization a negative response (no NS records) 
will include signed NSEC(3) records to that effect, signed by the
parent zone.  These are candidates for logging.

An insecure positive response will include NSEC(3) records proving
the non-existence of the DS RRset (possibly via the opt-out flag).
These can also be logged.

A secure positive response, can also be logged, and the follow-up
query for any associated DS records will again either yields an
answer that can be logged, or DOE that can be logged.

The key question is how to avoid logging ridiculous volumes of
data that can DoS any log service and also disclose too much.

Hence the suggestion to consider using the PSL as a cut-off
mechanism.  One would also not log NXDOMAIN responses to NS,
which might allow parent domains to lie about non-existence,
but is surely necessary to guard against filling logs with
junk.

There are likely many issues this fails to consider, but I
think that's a reasonable starting point to explore further.

-- 
	Viktor.