Re: How do we get the whole world to upgrade to DNSSEC capable resolvers?

Jelte Jansen <jelte@NLnetLabs.nl> Fri, 25 July 2008 23:14 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8324A3A68AE; Fri, 25 Jul 2008 16:14:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.288
X-Spam-Level:
X-Spam-Status: No, score=-102.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIvHAJbQLt6D; Fri, 25 Jul 2008 16:14:34 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7F6073A67AD; Fri, 25 Jul 2008 16:14:34 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KMWO6-000EV0-Ml for namedroppers-data@psg.com; Fri, 25 Jul 2008 23:07:50 +0000
Received: from [2001:7b8:206:1:7200:ff:fe00:28e3] (helo=sol.nlnetlabs.nl) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <jelte@NLnetLabs.nl>) id 1KMWO2-000EUj-Hg for namedroppers@ops.ietf.org; Fri, 25 Jul 2008 23:07:48 +0000
Received: from jelte (vhe-520087.sshn.net [195.169.221.157]) by sol.nlnetlabs.nl (Postfix) with ESMTP id DF854131430; Sat, 26 Jul 2008 01:07:44 +0200 (CEST)
Received: from [192.168.8.11] (dragon [192.168.8.11]) by jelte (Postfix) with ESMTP id 7788716B9D8; Sat, 26 Jul 2008 01:07:44 +0200 (CEST)
Message-ID: <488A5CC8.7010009@NLnetLabs.nl>
Date: Sat, 26 Jul 2008 01:07:52 +0200
From: Jelte Jansen <jelte@NLnetLabs.nl>
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
MIME-Version: 1.0
To: Andrew Sullivan <ajs@commandprompt.com>
Cc: namedroppers@ops.ietf.org
Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers?
References: <2FFE6519-7E9C-4DE8-AF69-697A4D875011@nominum.com> <20080723191636.GB32507@outpost.ds9a.nl> <8A91CF57-0CBD-4CF2-BF59-C7D59CB4B7B9@virtualized.org> <20080724060743.GA7420@outpost.ds9a.nl> <48886C4D.4020500@ca.afilias.info> <63C0FFE7-17E6-4ECE-9A12-0537FE2E3F4B@ca.afilias.info> <4888FED2.6060204@NLnetLabs.nl> <E7388E94-D031-4059-91F9-1596A254E21C@ca.afilias.info> <20080725193101.GB8193@outpost.ds9a.nl> <BEADC795-3C76-407A-A979-2B0AAACE0328@ca.afilias.info> <20080725221002.GK29775@commandprompt.com>
In-Reply-To: <20080725221002.GK29775@commandprompt.com>
X-Enigmail-Version: 0.95.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Sullivan wrote:
> [no hat]
> 
> On Fri, Jul 25, 2008 at 03:36:15PM -0400, Joe Abley wrote:
> 
>> It seems to me that a bare validator, freshly started, with no cache and no 
>> special configuration, knows nothing about what zones in the world are 
>> secured and which are not.
> 
> I thought, in any case, that the hypothetical case you were talking
> about was a laptop in a hotel room.  Sure, there are people on this
> list who know how to set up and configure a full validating resolver
> for these purposes.  But the stub resolver is still dependent on
> what's upstream, and that's what's going to be on a laptop, I think.
> So if the compromise is on the network between the stub and the
> validator, you're hosed.  (I thought this was the point someone
> up-thread was making.  No?)
> 

Exactly, if you cannot trust your resolver, or the so-called last mile,
you need to do your own verification, and for that you need to configure
your trust anchors, be it a set for a signed root, DLV, or plain manually.

Without any 'start of trust' configuration, DNSSEC wouldn't help if
you're in a hotel room. Luckily, without any configuration, DNSSEC won't
help you at home either. But with it, you should be able to use any
middlebox you *know* is in bad hands, and you'll still be able to know
whether or not the data you get is correct.

This is why people are pushing for a signed root, and this is why people
are pushing for automated trust anchor rollover (rfc5011).

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIilzI4nZCKsdOncURAiOFAJkB/qgk+nuhQ9y3417u95jnhI4CbwCdFRtg
ZULzzcnBIQB6qP7YaJeXX98=
=xxR1
-----END PGP SIGNATURE-----

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>