Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

Morizot Timothy S <Timothy.S.Morizot@irs.gov> Fri, 13 March 2015 21:02 UTC

Return-Path: <Timothy.S.Morizot@irs.gov>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A091A86F3 for <dnsop@ietfa.amsl.com>; Fri, 13 Mar 2015 14:02:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Qe_8ZoF3Pj9C for <dnsop@ietfa.amsl.com>; Fri, 13 Mar 2015 14:02:48 -0700 (PDT)
Received: from emg4.irs.gov (emg4.irs.gov [IPv6:2610:30:2000:25::91]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9706F1A6FF1 for <dnsop@ietf.org>; Fri, 13 Mar 2015 14:02:47 -0700 (PDT)
Received: from MEM0200CP3XF01.ds.irsnet.gov (mem0200cp3xf01.ds.irsnet.gov [10.219.80.76]) by mem0200vprelay3.is.irs.gov (8.13.8/8.13.8) with ESMTP id t2DL2A7f001910 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Mar 2015 16:02:14 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irs.gov; s=irs-20130926; t=1426280534; bh=nEffqB54sj4cjB2RvI45sIpIhVv+w9FVlCdPuGuiJMg=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=py+W6MN6kJ8DEZf9E8j94PgC0Ia2PAVD5VyRb317OcBQL2jSCdLg7DWU69B+AeG+i IT/rRu9kdWL3MUUJNOx+Jih0GHODj7ILdMqNlbqVA05/cCtFZAUGt2172gtAqL91R4 8EBb4rHmrrisVnqGZWIxOJ9v0jIvfxD2XXzazELo=
Received: from MEM0200CP3DR07.ds.irsnet.gov (10.219.80.70) by MEM0200CP3XF01.ds.irsnet.gov (10.219.80.76) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 13 Mar 2015 16:02:33 -0500
Received: from MEM0200CP3XF04.ds.irsnet.gov ([fe80::3c47:b073:8e3a:ef02]) by MEM0200CP3DR07.ds.irsnet.gov ([fe80::49b:74a9:e278:bc17%14]) with mapi id 14.03.0224.002; Fri, 13 Mar 2015 16:02:33 -0500
From: Morizot Timothy S <Timothy.S.Morizot@irs.gov>
To: Nicholas Weaver <nweaver@icsi.berkeley.edu>
Thread-Topic: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Thread-Index: AQHQXXhexKncgQDHLUeTZsGtIlbAqJ0a5y0AgAAHHYD//7JCYIAAiw+A//+y6kA=
Date: Fri, 13 Mar 2015 21:02:33 +0000
Message-ID: <968C470DAC25FB419E0159952F28F0C06DF65DD3@MEM0200CP3XF04.ds.irsnet.gov>
References: <20150312125913.20188.qmail@cr.yp.to> <3D558422-D5DA-4434-BDED-E752BA353358@flame.org> <m27fulry37.wl%randy@psg.com> <55030A28.8050707@necom830.hpcl.titech.ac.jp> <5503101F.9060205@redbarn.org> <968C470DAC25FB419E0159952F28F0C06DF659F0@MEM0200CP3XF04.ds.irsnet.gov> <00B5D36F-5DFA-46EE-B61B-F5307738A910@icsi.berkeley.edu>
In-Reply-To: <00B5D36F-5DFA-46EE-B61B-F5307738A910@icsi.berkeley.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.219.80.83]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/MpyCh7NrocZUI-DOrVtlO0LR2-g>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 13 Mar 2015 21:02:50 -0000

Nonsense.

I'm not sure exactly what sort of attack profile you have in mind at the registrar with a, but given that the TTL for DS records is generally 24 hours, most attacks at that level will create pretty widespread DNSSEC validation errors for at least that initial day. DNSSEC validation helps a great deal.

B & d are issues securing the first hop if validation is not done on the endpoint itself. Those are valid, but do not mean that DNSSEC validation provides no protection. It certainly protects against an array of cache poisoning attacks even in that configuration. And that's protection the clients would not otherwise have. It definitely makes it a lot harder to use DNS as an attack vector with nobody noticing. One layer of a layered approach.

C is certainly a problem if you don't validate on the end point and trust any random nameserver on any network to which you connect.

However, most enterprise clients and ISP users do tend to have a reliable and reasonably secure path to their first hop recursive nameserver. It's not nearly as secure as validating on the client, but it's much more secure than having no validation whatsoever.

Nor is DNSSEC validation a DOS vector. That's a non sequitur and frankly a pretty silly assertion. Yes, an organization can break their own authoritative DNS (which is related to signing not validation), but frankly DNSSEC is just one of many ways an organization can screw up DNS or anything else in their network. It's best to know what you're doing. Organizations will learn. If you haven't implemented DNSSEC validation yourself, you may not have noticed, but US government agency management of DNSSEC has improved greatly with experience. Outages due to error are less and less common and usually limited in scope when they occur. Since we've been validating all Internet responses for four years and counting now (and tend to interact quite a bit with other agencies), we have noticed the improvement. Refusing to return results when the authoritative DNS response fails validation is good thing, not a bad thing, even when it's the authoritative zone administrators who screwed up their own zone.

DNSSEC validation is not a panacea, but if you refuse to implement it you are denying your users one layer of protection you could pretty easily provide. And given that in the US the large majority of federal agency DNS authoritative zones are signed, you also can't claim there's no benefit to the US public from validation. Implementing validation on recursive nameservers does not protect users from every attack. Nothing does. Nor is it as good as performing validation at the client. But it is a solid first step with real security benefits. And it's a step that can be followed and built upon with further enhancements later.

Scott

-----Original Message-----
From: Nicholas Weaver [mailto:nweaver@icsi.berkeley.edu] 
Sent: Friday, March 13, 2015 3:08 PM
To: Morizot Timothy S
Cc: Nicholas Weaver; dnsop@ietf.org
Subject: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards


> On Mar 13, 2015, at 10:21 AM, Morizot Timothy S <Timothy.S.Morizot@irs.gov> wrote:
> It’s been steadily increasing for years now and gives me an idea what percentage of the US public is protected against certain types of attacks involving our zones. DNSSEC validation is not a panacea, but in a layered approach toward combating fraud and certain sorts of attacks, it does provide a particular sort of protection not available through any other means. Whether or not ISPs sign their authoritative zones matters much less to us than whether or not they implement DNSSEC validation on their recursive nameservers. And that’s not a failure at all. By the measure above (which isn’t perfect, but the best one available) roughly a fifth to a quarter of the US public, the primary consumers of our zones, exclusively use validating nameservers. That’s significant. Would I like to see it higher? Sure. But I’ll take it.
> 

The problem is validation by the recursive resolver is nearly useless for security, but one heck of an effective DOS attack (NASA, HBO, etc)...

Lets look at what real world attacks on DNS are.

a:  Corrupt the registrar.  DNSSEC do any good?  Nope.

b:  Corrupt the traffic in-flight (on-path or in-path).  DNSSEC do any good?  Only if the attacker is not on the path for the final traffic, but just the DNS request.

c:  The recursive resolver lies.  Why would you trust it to validate?

d:  The NAT or a device between the recursive resolver and the user lies.  Again, validation from the recursive resolver works how?


Overall, unless you are validating on the end host rather than the recursive resolver, DNSSEC does a lot of harm from misconfiguration-DOS, but almost no good.

--
Nicholas Weaver                  it is a tale, told by an idiot,
nweaver@icsi.berkeley.edu                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc