Re: Last Call: RFC7344 Automating DNSSEC Delegation Trust Maintenance to standards track

Paul Wouters <paul@nohats.ca> Wed, 16 November 2016 12:08 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777871297C3 for <ietf@ietfa.amsl.com>; Wed, 16 Nov 2016 04:08:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Level:
X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497] 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 iQ-Z6h9EcCHT for <ietf@ietfa.amsl.com>; Wed, 16 Nov 2016 04:08:41 -0800 (PST)
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 41A161297C2 for <ietf@ietf.org>; Wed, 16 Nov 2016 04:08:34 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tJjhb34mNz8r; Wed, 16 Nov 2016 13:08:31 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1479298111; bh=HELoUqIlaWZEmUxfBAs9f/1ouirctUb/7TVcqGztoJo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=TD137kK88tQrlhgWIh7lKFAJskEoGnGJgjAKUE/A687bpF7ZvvUToONsmCD7WUYX8 jd1L04EmQD+MOloBEdLmicKoE/ux2dxrwo3WyM7Wsbc6mXfctjfVuFuSLg043aoK1k gEjZiyjclHez6j7S0PZXkZW6DuzkXzVq4FsMbc5M=
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 8tVeqyEmUJwP; Wed, 16 Nov 2016 13:08:29 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 16 Nov 2016 13:08:29 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6D0BD5C83A; Wed, 16 Nov 2016 07:08:28 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 6D0BD5C83A
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 588CB40DAA4B; Wed, 16 Nov 2016 07:08:28 -0500 (EST)
Date: Wed, 16 Nov 2016 07:08:28 -0500
From: Paul Wouters <paul@nohats.ca>
To: Benjamin Kaduk <kaduk@mit.edu>
Subject: Re: Last Call: RFC7344 Automating DNSSEC Delegation Trust Maintenance to standards track
In-Reply-To: <20161115054611.GN86797@kduck.kaduk.org>
Message-ID: <alpine.LRH.2.20.1611160706000.4488@bofh.nohats.ca>
References: <147908623055.5563.514732510355874303.idtracker@ietfa.amsl.com> <20161115054611.GN86797@kduck.kaduk.org>
User-Agent: Alpine 2.20 (LRH 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/B8G8XPZq8Evd7Fs7TTRNzmxsaSI>
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2016 12:08:42 -0000

On Mon, 14 Nov 2016, Benjamin Kaduk wrote:

> Section 3 (of RFC 7344) specifies that the absence of a CDS/CDNSKEY record
> in the child means that no changes are to be made to the DS records in the
> parent.  An attacker that is able to prevent the parent zone's resolvers
> from seeing the CDS/CDNSKEY records would thus be able to prevent the DS
> update, a denial of service.  One would hope that the DNSSEC-enabled
> parent zone would use a validating resolver when it queries the child
> zone, but it is probably worth mentioning explicitly, and the behavior
> in the error case when the query fails.

If an attacker is messing with your packets and filtering/changing
records you will get a DNSSEC error. So if witholding the CDS RRset,
your resolver would get a BOGUS or INDETERMINATE answer. And it knows
something fishy is going on and it would hopefully try again shortly.
It would surely not interpret this as "proof" there is no CDS RRset.

Paul