IETF Logo Mail Archive

Re: [DNSOP] CD (Re: Whiskey Tango Foxtrot on key lengths...)

Nicholas Weaver <nweaver@icsi.berkeley.edu> Wed, 02 April 2014 05:38 UTC

Return-Path: <nweaver@icsi.berkeley.edu>
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 7EBCD1A011F for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 22:38:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.611
X-Spam-Level:
X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Nh3ofgBpdCIv for <dnsop@ietfa.amsl.com>; Tue, 1 Apr 2014 22:38:07 -0700 (PDT)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id A7F831A0116 for <dnsop@ietf.org>; Tue, 1 Apr 2014 22:38:07 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 231E62C4030; Tue, 1 Apr 2014 22:38:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bg8UtX-q28XG; Tue, 1 Apr 2014 22:38:00 -0700 (PDT)
Received: from [10.0.1.22] (c-76-103-162-14.hsd1.ca.comcast.net [76.103.162.14]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 90C332C4006; Tue, 1 Apr 2014 22:37:59 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_B017D213-8733-4BD7-9C75-B99A5D5E99D6"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Nicholas Weaver <nweaver@icsi.berkeley.edu>
In-Reply-To: <CAAF6GDcP77MBBUJbEdQgOqOLh2UHPEOmxYNTaAO-8F=OdLYxOQ@mail.gmail.com>
Date: Tue, 01 Apr 2014 22:37:57 -0700
Message-Id: <08BE138B-9F40-4302-810F-98850B91D813@icsi.berkeley.edu>
References: <0EA28BE8-E872-46BA-85FD-7333A1E13172@icsi.berkeley.edu> <53345C77.8040603@uni-due.de> <B7893984-2FAD-472D-9A4E-766A5C212132@pch.net> <102C13BE-E45E-437A-A592-FA373FF5C8F0@ogud.com> <474B0834-C16B-4843-AA0A-FC2A2085FEFB@icsi.berkeley.edu> <CAMm+Lwh-G7D5Cjx4NWMOhTjBZd=VVRHiPdK7L1zm-P0QRP8P2Q@mail.gmail.com> <20140401223943.528B71226903@rock.dv.isc.org> <CAAF6GDe=39bmVDOtox+9coaH7R06erm-JUK19ZwPEUVkxepKTg@mail.gmail.com> <20140402003159.B4B631228652@rock.dv.isc.org> <CAAF6GDdLs3V9JMa8jgD_asYqhmt=PCaBAmk4LO0JaX_q6q0UHQ@mail.gmail.com> <20140402024919.GA97087@isc.org> <CAAF6GDcP77MBBUJbEdQgOqOLh2UHPEOmxYNTaAO-8F=OdLYxOQ@mail.gmail.com>
To: Colm MacCárthaigh <colm@allcosts.net>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/PAwKTwcgn2ClH9KcmxlIZyI63tI
Cc: Nicholas Weaver <nweaver@icsi.berkeley.edu>, Bill Woodcock <woody@pch.net>, "dnsop@ietf.org" <dnsop@ietf.org>, Evan Hunt <each@isc.org>, Phillip Hallam-Baker <hallam@gmail.com>, Matth?us Wander <matthaeus.wander@uni-due.de>
Subject: Re: [DNSOP] CD (Re: Whiskey Tango Foxtrot on key lengths...)
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: Wed, 02 Apr 2014 05:38:11 -0000

On Apr 1, 2014, at 10:24 PM, Colm MacCárthaigh <colm@allcosts.net> wrote:
>  
> I don't think this makes much sense for a coherent resolver. If I were writing a resolver, the behaviour would instead be;  try really hard to find a valid response, exhaust every reasonable possibility. If it can't get a valid response, then if CD=1 it's ok to pass back the invalid response and its supposed signatures - maybe the stub will no better, at least fail open. If CD=0, then SERVFAIL, fail closed. 

The bigger problem is not the CD case, but getting the data at all to validate locally.  

A lot (and I mean a LOT) of NATs give a DNS proxy that doesn't understand or forward requests for DNSSEC information. Heck, even Apple (which in my opinion makes the best overall CPE) doesn't do this right.  These NATs don't give the IP of the real recursive resolver, which often does support DNSSEC (and, in the case of Comcast, even validates).

Which means you have to go around and do a full local fetch, starting at the root and going down from there to validate on the client.

And then, to make matters worse, you have the hotspots and similar cases which force the user to use the configured recursive resolver.  Fortunately, most of those support fetching DNSSEC records.  But note that I said most, not all....

--
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

v2.23.0 | Report a Bug | By Email