Re: [DNSOP] DNSSEC corner case -- (surfaced by homenet vs stub validators)

Evan Hunt <each@isc.org> Fri, 31 March 2017 02:57 UTC

Return-Path: <each@isc.org>
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 CB5841296FA for <dnsop@ietfa.amsl.com>; Thu, 30 Mar 2017 19:57:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 iywjIczJ57pN for <dnsop@ietfa.amsl.com>; Thu, 30 Mar 2017 19:57:04 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 7037E127333 for <dnsop@ietf.org>; Thu, 30 Mar 2017 19:57:04 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [149.20.48.19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id EA238349412; Fri, 31 Mar 2017 02:57:02 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id DC733216C1C; Fri, 31 Mar 2017 02:57:02 +0000 (UTC)
Date: Fri, 31 Mar 2017 02:57:02 +0000
From: Evan Hunt <each@isc.org>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Message-ID: <20170331025702.GA99337@isc.org>
References: <CAH1iCirtMRLM8Lutmb+nPMmcN1qpOqKZSHOZP=in9AwynCBN7w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAH1iCirtMRLM8Lutmb+nPMmcN1qpOqKZSHOZP=in9AwynCBN7w@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2TnPK8QqI6-Luu7A85bDmUf_VQ8>
Subject: Re: [DNSOP] DNSSEC corner case -- (surfaced by homenet vs stub validators)
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: Fri, 31 Mar 2017 02:57:06 -0000

On Thu, Mar 30, 2017 at 07:23:46PM -0500, Brian Dickson wrote:
> What seems to be "missing" (as in, maybe it is a corner case that wasn't
> noticed before), is the ability for a security-aware resolver to "signal"
> to a stub, that it is deliberately not returning DNSSEC records, even
> though the stub set the DO bit (DO=1).

Why would the stub trust such a signal? Seems like an easy mechanism
for a downgrade attack.

> Or is it far too late to be suggesting changes for sub-resolver DNSSEC
> signaling?

Signaling from the resolver to the stub doesn't seem like a promising
approach to me.

If for some reason you can't put an insecure delegation in the global
DNS, then it would work to configure both the stub and the resolver with
(*sigh*) a permanent NTA for .hab.arpa or whatever.

(I was so very firm in my advocacy that NTAs should always be temporary
when RFC 7646 was being written. Please let's just have insecure
delegations?)

-- 
Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.