Re: Forgery resilience idea - wildcard cooperative defense
Paul Vixie <vixie@isc.org> Thu, 07 August 2008 17:23 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 49EBE3A697F; Thu, 7 Aug 2008 10:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.183
X-Spam-Level:
X-Spam-Status: No, score=0.183 tagged_above=-999 required=5 tests=[AWL=0.782, BAYES_00=-2.599, SARE_RAND_1=2]
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 uviUs9PXhxiY; Thu, 7 Aug 2008 10:23:15 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5CC4A3A6BF6; Thu, 7 Aug 2008 10:23:15 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KR98F-000FUc-Pd for namedroppers-data@psg.com; Thu, 07 Aug 2008 17:18:35 +0000
Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <vixie@vix.com>) id 1KR98B-000FTq-Pd for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 17:18:33 +0000
Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 6E60FA66A7; Thu, 7 Aug 2008 17:18:28 +0000 (UTC) (envelope-from vixie@nsa.vix.com)
From: Paul Vixie <vixie@isc.org>
To: Brian Dickson <briand@ca.afilias.info>
cc: Wouter Wijngaards <wouter@NLnetLabs.nl>, Namedroppers <namedroppers@ops.ietf.org>, dns-operations@lists.oarci.net
In-Reply-To: Your message of "Thu, 07 Aug 2008 12:57:00 -0400." <489B295C.3020002@ca.afilias.info>
References: <489AD5E3.20708@nlnetlabs.nl> <45759.1218122552@nsa.vix.com> <489B295C.3020002@ca.afilias.info>
X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1
Date: Thu, 07 Aug 2008 17:18:28 +0000
Message-ID: <59360.1218129508@nsa.vix.com>
MIME-Version: 1.0
X-Vix-MailScanner-Information: Please contact the ISP for more information
X-MailScanner-ID: 6E60FA66A7.EC457
X-Vix-MailScanner: Found to be clean
X-Vix-MailScanner-From: vixie@vix.com
Subject: Re: Forgery resilience idea - wildcard cooperative defense
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
> While doing some free-associating around the Kaminsky presentation, I > began pondering wildcards. > > Specifically, what could we do, using wildcards, to nip the > $RANDOM.example.com problem in the bud? > ... any solution requiring cooperative action/change by both the RDNS and ADNS has a cost that's equivilent to "deploy DNSSEC". the thing that's good about UDP port randomization, or DNS-0x20, is that it only requires change in one place (the RDNS in those cases, but an ADNS-only solution would also be cheaper than "deploy DNSSEC".) for solutions involving "upgrade all nodes", the first term of the expression of deployment cost is in touching all those nodes, and the actual complexity or difficulty of the new protocol is a distant second term, easily managed through normal and inevitable capitalistic incentives. for all solutions having the same cost as "deploy DNSSEC", compare the expected benefits. the DNS datapath is long and twisty and involves both on-wire and off-wire transport. zone storage on primary and secondary servers, zone transfer between those servers, zone content generation from databases, responses from ADNS to RDNS, responses from RDNS to stub, and application to stub API, are all corruptible elements of the DNS datapath. > Thoughts? > > Brian Dickson among all same-cost solutions, which one protects the largest amount of the DNS datapath? hint: it's not based on wildcards. i would love to hear more ideas that involve only one point of action/change, like UDP port randomization or DNS-0x20. paul -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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/>
- Re: Additional filtering of responses Tony Finch
- Additional filtering of responses Wouter Wijngaards
- OFFTOPIC: DNSSEC groupthink versus improving DNS bert hubert
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: Additional filtering of responses Paul Vixie
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Paul Vixie
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Paul Vixie
- RE: OFFTOPIC: DNSSEC groupthink versus improving … Jesper G. Høy
- Re: Additional filtering of responses Roy Arends
- Re: Additional filtering of responses Paul Vixie
- Forgery resilience idea - wildcard cooperative de… Brian Dickson
- Re: Forgery resilience idea - wildcard cooperativ… Paul Vixie
- Re: Additional filtering of responses Roy Arends
- Re: Forgery resilience idea - wildcard cooperativ… bert hubert
- Re: Forgery resilience idea - wildcard cooperativ… Brian Dickson
- Re: Additional filtering of responses Edward Lewis
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Olaf Kolkman
- Re: Additional filtering of responses Tony Finch
- Re: OFFTOPIC: DNSSEC groupthink versus improving … David Conrad
- Re: OFFTOPIC: DNSSEC groupthink versus improving … bert hubert
- Re: Additional filtering of responses Edward Lewis
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Federico Lucifredi
- Re: Additional filtering of responses Paul Vixie
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Mark Andrews
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Paul Vixie
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Paul Vixie
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Mark Andrews
- Re: Additional filtering of responses Mark Andrews
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Mark Andrews
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Mark Andrews
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Mark Andrews
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Mark Andrews
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Brian Dickson
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Mark Andrews
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Brian Dickson
- Re: Additional filtering of responses Masataka Ohta
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: Additional filtering of responses Masataka Ohta
- Re: Additional filtering of responses Roy Arends
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Ralf Weber
- Re: Additional filtering of responses Masataka Ohta
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane at e164 dot org
- Re: Additional filtering of responses Duane at e164 dot org
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Ralf Weber
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Alex Bligh
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane at e164 dot org
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane at e164 dot org
- Re: OFFTOPIC: DNSSEC groupthink versus improving … sthaug
- Re: OFFTOPIC: DNSSEC groupthink versus improving … bert hubert
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane at e164 dot org
- Re: Additional filtering of responses Peter Koch
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane at e164 dot org
- Please stop this thread (was: OFFTOPIC: DNSSEC gr… Andrew Sullivan
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Otmar Lendl
- Re: Please stop this thread (was: OFFTOPIC: DNSSE… Matt Larson
- Re: Please stop this thread (was: OFFTOPIC: DNSSE… David Conrad
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Ben Laurie
- how many angels can dance on the head of a pin? bmanning
- Re: how many angels can dance on the head of a pi… Duane at e164 dot org
- Re: how many angels can dance on the head of a pi… Alex Bligh
- Re: how many angels can dance on the head of a pi… Duane at e164 dot org
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Florian Weimer
- Re: how many angels can dance on the head of a pi… Alex Bligh
- Re: how many angels can dance on the head of a pi… Alex Bligh
- Re: how many angels can dance on the head of a pi… sthaug
- Re: how many angels can dance on the head of a pi… Ben Laurie
- Re: how many angels can dance on the head of a pi… Alex Bligh
- Re: how many angels can dance on the head of a pi… Ben Laurie
- Re: how many angels can dance on the head of a pi… Paul Vixie
- Re: how many angels can dance on the head of a pi… Paul Hoffman
- Re: how many angels can dance on the head of a pi… bmanning
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Havard Eidnes
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Mark Andrews
- DNSSEC on autopilot (was: OFFTOPIC: DNSSEC groupt… Otmar Lendl
- Re: DNSSEC on autopilot (was: OFFTOPIC: DNSSEC gr… Andrew Sullivan
- Re: DNSSEC on autopilot (was: OFFTOPIC: DNSSEC gr… Otmar Lendl
- Re: DNSSEC on autopilot (was: OFFTOPIC: DNSSEC gr… Mark Andrews
- Re: DNSSEC on autopilot (was: OFFTOPIC: DNSSEC gr… Andrew Sullivan