Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00

Florian Weimer <fweimer@bfk.de> Wed, 21 October 2009 09:10 UTC

Return-Path: <fweimer@bfk.de>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21AB03A6782 for <dnsop@core3.amsl.com>; Wed, 21 Oct 2009 02:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.724
X-Spam-Level:
X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_54=0.6]
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 ffVIsmliYGRV for <dnsop@core3.amsl.com>; Wed, 21 Oct 2009 02:10:12 -0700 (PDT)
Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 3A3E93A6359 for <dnsop@ietf.org>; Wed, 21 Oct 2009 02:10:10 -0700 (PDT)
Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1N0XCz-0000cb-2j; Wed, 21 Oct 2009 11:10:17 +0200
Received: by bfk.de with local id 1N0XCy-0004Dl-VA; Wed, 21 Oct 2009 09:10:16 +0000
To: Alex Bligh <alex@alex.org.uk>
References: <OFA656600E.F5229B3D-ON80257650.005247BF-80257650.00527644@nominet.org.uk> <82skde36c9.fsf@mid.bfk.de> <DE23E9BF50E437E2D5CA65C8@Ximines.local> <82ljj61gle.fsf@mid.bfk.de> <200910202329.n9KNT56j048843@drugs.dv.isc.org> <1F61DD04-14A6-4349-8650-9CF27D27C3BC@hopcount.ca> <200910210145.n9L1j8of033780@drugs.dv.isc.org> <8263a9xnem.fsf@mid.bfk.de> <OFD7B965B7.53CC1C17-ON80257656.0028D85C-80257656.002974DF@nominet.org.uk> <82zl7luov4.fsf@mid.bfk.de> <A0DDFB2F94500799B7F0B37F@Ximines.local>
From: Florian Weimer <fweimer@bfk.de>
Date: Wed, 21 Oct 2009 09:10:16 +0000
In-Reply-To: <A0DDFB2F94500799B7F0B37F@Ximines.local> (Alex Bligh's message of "Wed\, 21 Oct 2009 09\:59\:12 +0100")
Message-ID: <82fx9dun7r.fsf@mid.bfk.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Ray.Bellis@nominet.org.uk, dnsop@ietf.org, Joe Abley <jabley@hopcount.ca>
Subject: Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 21 Oct 2009 09:10:13 -0000

* Alex Bligh:

> --On 21 October 2009 08:34:39 +0000 Florian Weimer <fweimer@bfk.de> wrote:
>
>>>> Mark, I din't think this is true given how the proposed protocol
>>>> works.  For a start, you often cannot fetch the DNSKEY RR for ARPA
>>>> before running the protocol.
>>>
>>> Indeed LOCAL.ARPA would need to be unsigned.
>>
>> Not really.  Why would it need to exist in the public tree at all?
>> All we need is agreement from both ICANN and IETF that LOCAL.ARPA is
>> reserved and not to be delegated in the official tree.
>
> OK, let's try this one again. LOCAL.ARPA is not delegated at all.
> It is unsigned.

If it is not delegated, it will be signed (as Mark pointed out).

> Necessarily, ARPA. will have no records for LOCAL.ARPA

Then its non-existence will be signed.

> Moreover the queries into DOMAIN.LOCAL.ARPA are going to be made
> in an environment where we suspect DNSSEC queries don't work, as
> there is, ex hypothesi, possible a misbehaving proxy in the way.

Right.  (Otherwise, you wouldn't use class IN for this stuff.)

> So there are two separate security risks: cache poisoning on the
> recursive server (this needs addressing and I have some ideas),
> and a theoretical Kaminsky style attack on the individual
> non-DNSSEC queries to DOMAIN.LOCAL.ARPA. 

Don't worry too much about spoofing from off-path attackers.  ISPs
have plenty of means to prevent it (granted, for IPv4 directly over
Ethernet, there's no standard way of doing things which conserves
address space, but that's a different issue).

As I've tried to explain, spoofing by the resolver operator itself is
the relevant issue here.  It breaks the proposed protocol.  Please
tell me how I can explain this in a better way---perhaps I shouldn't
say "spoofing" but "DNS rewriting", "NXDOMAIN redirection",
"Sitefinder", "online help page", or something else, but it's really
spoofing.

Note that this problem will not go away when you bring LOCAL.ARPA or
DOMAIN.LOCAL.ARPA into existence.  People say "NXDOMAIN redirection"
but they really mean "arbitrary DNS manipulation".  It doesn't stop at
NODATA response or the second level of the tree.

-- 
Florian Weimer                <fweimer@bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99