From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id A8EB821F426 for ; Fri, 3 Oct 2014 02:28:43 -0700 (PDT) X-AuditID: 1209190f-f79aa6d000005b45-b5-542e6c49ab60 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 1E.65.23365.94C6E245; Fri, 3 Oct 2014 05:28:41 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s939SeDg026489; Fri, 3 Oct 2014 05:28:40 -0400 Received: from [192.168.9.137] (c-174-63-87-168.hsd1.ma.comcast.net [174.63.87.168]) (authenticated bits=0) (User authenticated as andersk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s939ScgK012101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 3 Oct 2014 05:28:39 -0400 Message-ID: <542E6C43.9030002@mit.edu> Date: Fri, 03 Oct 2014 05:28:35 -0400 From: Anders Kaseorg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Simon Kelley References: <535EACCB.7090104@thekelleys.org.uk> <20140428232459.GA55372@redoubt.spodhuis.org> <535FA793.8020502@thekelleys.org.uk> In-Reply-To: <535FA793.8020502@thekelleys.org.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixG6nruuZoxdicOKeuEXf150sFns2nmSx OPKrm9Gic/FjdovTR8MdWD1WzdnA6rFz1l12j+0XzzB57O1/yBbAEsVlk5Kak1mWWqRvl8CV sb+5i7lgvXjF9/k/2BoY9wl1MXJySAiYSDzes5QFwhaTuHBvPVsXIxeHkMBsJomdfe+ZIZwN jBKzPp5mhHAuMElsOP2DEaSFV0BN4uvPi8wgNouAqkTzjB9go9iA4h+OfmUFsUUFwiRONt9i h6gXlDg58wlYjYiAlsTRDx1MIEOZBaYyStxt3go2SFggVeL6vz1MILaQwHRmid5JdV2MHByc AoYSWybxgISZBWwl7szdzQxhy0s0b53NPIFRcBaSFbOQlM1CUraAkXkVo2xKbpVubmJmTnFq sm5xcmJeXmqRrolebmaJXmpK6SZGUMhzSvLvYPx2UOkQowAHoxIP74cbuiFCrIllxZW5hxgl OZiURHnDk/VChPiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwno4DyvGmJFZWpRblw6SkOViUxHk3 /eALERJITyxJzU5NLUgtgsnKcHAoSfBaZAM1ChalpqdWpGXmlCCkmTg4QYbzAA2PA6nhLS5I zC3OTIfIn2JUlBLnTc4CSgiAJDJK8+B6YSnpFaM40CvCvNog7TzAdAbX/QpoMBPQ4Hf2uiCD SxIRUlINjDHPGTekiq7ca3fFTzGj/pTP4pgk+S25c+s3RGgKZG08wqH2tH1lZGPhGt16A6bD Ho+e1Dye0zlP58dxRsbrvh92r/23UOZTymvu1WaPo+RjloZtS5cVu9YgkdYecMSzsqI503r+ PcZPiY9nZB/zqP2W/vEig7Z7Ur7pmpWJt6K7Hz75/aGBUYmlOCPRUIu5qDgRAGJfqD8kAwAA Cc: dnsmasq-discuss@thekelleys.org.uk, cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014 X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 09:29:12 -0000 I just ran into this timeout behavior myself while testing the new DNSSEC support in OpenWrt 14.07 (dnsmasq 2.71-4). After staring at the problem for a few hours, I think there’s something wrong with your justification. On 04/29/2014 09:22 AM, Simon Kelley wrote: > To do that, we need to find proof (NSEC or NSEC3 records) that a DS > doesn't exist somewhere between ds.test-ipv6.com and the root. Bear in > mind that dnsmasq is a DNS forwarder, not a recursive DNS server, so it > doesn't know where the zone cuts are. > > The current strategy it to start at ds.test-ipv6.com and do DS queries. > There are three possible results. > > unsigned NOERROR -> chop one label off the RHS and repeat > DS record -> definite Bad Guy activity, return BOGUS > signed no DS record -> we expect unsigned original answer, return > INSECURE result.ds.test-ipv6.com This bottom-up algorithm also seems to have a security problem that’s just as bad as one with the top-down algorithm that you rejected below. Consider the same department.campus.university.edu example, where campus and edu are signed zones, and university is not a zone. • An attacker forges an evil response for A department, and forges an unsigned NODATA for DS department. • dnsmasq chops off one label, and the attacker forges an unsigned NODATA for DS campus. • dnsmasq chops off another label, and gets the legitimately signed NODATA for DS university. • dnsmasq incorrectly concludes that everything inside university is expected to be unsigned, and returns the INSECURE evil response. So if nothing else, the top-down algorithm seems less impractical and equally insecure. And maybe we can fix it; see below. > The other alternative approach is to start from the root and add labels, > but that has a problem. > > Consider > > department.campus.university.edu > > where there are zone cuts between university and edu and between > department and campus. > > All the zones are signed, so if we look up something under .department, > we expect a signature, if we don't get it, we check > > DS .edu gives an answer > DS university.edu gives secure NODATA > > secure no DS means that the original unsigned answer should be accepted, > except that it shouldn't. There's no way to distinguish between secure > lack of DS because we've reached an unsigned branch of the tree, and > secure lack of DS because we're not at a zone cut, except if we know > where the zone cuts are, and we don't. Having just looked through RFC 5155 for clues: isn’t that the purpose of the NS type bit in the NSEC3 record? In this example, DS university would give an NSEC3 record with the NS bit clear. That signals that we should go down a level and query DS campus. In this case we find a signed DS there. But if we were to find an NSEC3 with the NS bit set, then we’d know that we’ve really found an unsigned zone and can stop going down. Anders