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.
- [DNSOP] DNSSEC corner case -- (surfaced by homene… Brian Dickson
- Re: [DNSOP] DNSSEC corner case -- (surfaced by ho… Evan Hunt