Re: [dnsext] Forgery resilience and meeting in Stockholm
Peter Koch <pk@DENIC.DE> Thu, 21 May 2009 21:55 UTC
Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094D33A6E2A; Thu, 21 May 2009 14:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.048
X-Spam-Level:
X-Spam-Status: No, score=-4.048 tagged_above=-999 required=5 tests=[AWL=-1.668, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_MLH_Stock1=0.87]
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 T+y7wPwB7fx3; Thu, 21 May 2009 14:55:29 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0E5E13A6EE7; Thu, 21 May 2009 14:55:29 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1M7GAx-0000B4-Mx for namedroppers-data0@psg.com; Thu, 21 May 2009 21:51:43 +0000
Received: from [81.91.160.182] (helo=office.denic.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <peter@denic.de>) id 1M7GAk-00006l-RK for namedroppers@ops.ietf.org; Thu, 21 May 2009 21:51:37 +0000
Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1M7GAi-0000rL-SX; Thu, 21 May 2009 23:51:28 +0200
Received: from localhost by x27.adm.denic.de with local id 1M7G7F-0004PU-9R; Thu, 21 May 2009 23:47:53 +0200
Date: Thu, 21 May 2009 23:47:53 +0200
From: Peter Koch <pk@DENIC.DE>
To: IETF DNSEXT WG <namedroppers@ops.ietf.org>
Subject: Re: [dnsext] Forgery resilience and meeting in Stockholm
Message-ID: <20090521214753.GD435@x27.adm.denic.de>
References: <20090508181422.GH2372@shinkuro.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20090508181422.GH2372@shinkuro.com>
User-Agent: Mutt/1.4.2.3i
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
On Fri, May 08, 2009 at 02:14:22PM -0400, Andrew Sullivan wrote: > topic seems not to have inspired consensus. Therefore, we would like > to present five options for consideration: Not sure that these five make the right "partitioning" of the problem space, but it's hard enough already. > 1. Do nothing, and take all energy that might be devoted to this > effort and direct it towards DNSSEC deployment. Essentially this is probably the best option, even though the "energy" in or of this group is likely neither necessary nor sufficient to aid DNSSEC deployment. At some point, one needs to consider a protocol done. If deployment is slow, creating more distraction by presenting a plethora of "alternatives" is not going to accelerate the effort but will rather have a negative effect. > 2. Adopt draft-wijngaards-dnsext-resolver-side-mitigation-01.txt, and > include in it recommendations to do nothing else except what that > document contains. Remove from section 3 any strategies we do not > want to adopt. (Note that this latter condition entails decisions > about the next two options.) Addressing the tactics used in the summer 2008 attack scenarios is an achievable and worthwile goal, so I'd like to see this draft being worked on. However, I believe that some of the tactics(!) presented and documented in the draft have side effects on a global scale and are potentially harmful. As examples, I consider both RTT banding and explicit NS RRSet queries as "challenging", to put it mildly. It is extremely important that the overall architecture and operational environment not be changed lightly. > 3. Adopt draft-vixie-dnsext-dns0x20-00. If we do (2), then perhaps > this gets included in that document, or perhaps it proceeds as part of > a set of documents. Let's leave the editorial process issues out of > the discussion, and just focus on whether we want to include this > strategy in the tool box. With my response to (2), this could and should be postponed to the discussion of the 'resolver side mitigation' draft. Documenting the hack would be nice, but I'm not supportive of deployment of 0x20. > 4. Adopt draft-hubert-ulevitch-edns-ping-01.txt. As in (3), this > might be included as part of (2) or processed individually, but that > doesn't matter. I believe the situation is different from (3) as this is not "resolver side" mitigation only. As I stated in an earlier mail, the draft itself doesn't do much more than "reserve" a code point. Judging from other sources and the list discussion, an EDNS based QID space extension is clear and straightforward. However, the downgrade vector and the general issue of hop-by-hop vs end-to-end security don't let me sympathize here. > are inclined to take option (1), because the WG is supposed to be > sleeping. This is by no means to say that we are prejudiced in favour > of that option. It is rather to say that we are procedurally bound, > by our charter, to a default of "No" for at least some of these > documents. Adding a new standards-track item to the WG work requires Not that this would make much of a difference, but resolver side mitigation might be more of a BCP than a Standards Track document. -Peter PS: I've also responded to the doodle poll, but I am a bit confused by "This is a experiment for the working group to vote w/o posting to mailing list. In particular this is to cut down on +1 and -1 messages" Hopefully the term "vote" was a clerical error. -- 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/>
- [dnsext] Forgery resilience and meeting in Stockh… Andrew Sullivan
- Re: [dnsext] Forgery resilience and meeting in St… Nicholas Weaver
- Re: [dnsext] Forgery resilience and meeting in St… bert hubert
- Re: [dnsext] Forgery resilience and meeting in St… W.C.A. Wijngaards
- Re: [dnsext] Forgery resilience and meeting in St… bert hubert
- Re: [dnsext] Forgery resilience and meeting in St… Florian Weimer
- Re: [dnsext] Forgery resilience and meeting in St… Matthijs Mekking
- Re: [dnsext] Forgery resilience and meeting in St… bert hubert
- Re: [dnsext] Forgery resilience and meeting in St… bmanning
- Re: [dnsext] Forgery resilience and meeting in St… Ondřej Surý
- Re: [dnsext] Forgery resilience and meeting in St… Matthijs Mekking
- Re: [dnsext] Forgery resilience and meeting in St… Roy Arends
- Re: [dnsext] Forgery resilience and meeting in St… bert hubert
- Re: [dnsext] Forgery resilience and meeting in St… Stefan Schmidt
- Re: [dnsext] Forgery resilience and meeting in St… Florian Weimer
- Re: [dnsext] Forgery resilience and meeting in St… Florian Weimer
- Re: [dnsext] Forgery resilience and meeting in St… bmanning
- Re: [dnsext] Forgery resilience and meeting in St… Nicholas Weaver
- Re: [dnsext] Forgery resilience and meeting in St… Florian Weimer
- Re: [dnsext] Forgery resilience and meeting in St… Nicholas Weaver
- Re: [dnsext] Forgery resilience and meeting in St… Florian Weimer
- Re: [dnsext] Forgery resilience and meeting in St… Paul Vixie
- Re: [dnsext] Forgery resilience and meeting in St… Andrew Sullivan
- Re: [dnsext] Forgery resilience and meeting in St… Paul Vixie
- Re: [dnsext] Forgery resilience and meeting in St… Florian Weimer
- Re: [dnsext] Forgery resilience and meeting in St… Nicholas Weaver
- Re: [dnsext] Forgery resilience and meeting in St… Paul Vixie
- Re: [dnsext] Forgery resilience and meeting in St… Olafur Gudmundsson
- Re: [dnsext] Forgery resilience and meeting in St… bmanning
- Re: [dnsext] Forgery resilience and meeting in St… Florian Weimer
- Re: [dnsext] Forgery resilience and meeting in St… Paul Vixie
- Re: [dnsext] Forgery resilience and meeting in St… Matt Larson
- Re: [dnsext] Forgery resilience and meeting in St… Paul Vixie
- Re: [dnsext] Forgery resilience and meeting in St… Mark Andrews
- Re: [dnsext] Forgery resilience and meeting in St… Bert
- Re: [dnsext] Forgery resilience and meeting in St… Joe Abley
- Re: [dnsext] Forgery resilience and meeting in St… Florian Weimer
- Re: [dnsext] Forgery resilience and meeting in St… Joe Abley
- Re: [dnsext] Forgery resilience and meeting in St… Shane Kerr
- Re: [dnsext] Forgery resilience and meeting in St… Florian Weimer
- Desperate plea for 0x20, was Re: [dnsext] Forgery… Shane Kerr
- Re: [dnsext] Forgery resilience and meeting in St… Florian Weimer
- Re: Desperate plea for 0x20, was Re: [dnsext] For… Paul Vixie
- Re: Desperate plea for 0x20, was Re: [dnsext] For… Jeffrey A. Williams
- Re: [dnsext] Forgery resilience and meeting in St… Nicholas Weaver
- RE: Desperate plea for 0x20, was Re: [dnsext] For… Antoin Verschuren
- RE: [dnsext] Forgery resilience and meeting in St… Antoin Verschuren
- Re: Desperate plea for 0x20, was Re: [dnsext] For… Federico Lucifredi
- Re: Desperate plea for 0x20, was Re: [dnsext] For… Florian Weimer
- Re: [dnsext] Forgery resilience and meeting in St… Otmar Lendl
- Re: [dnsext] Forgery resilience and meeting in St… Ólafur Guðmundsson /DNSEXT chair
- Re: [dnsext] Forgery resilience and meeting in St… Paul Vixie
- Re: [dnsext] Forgery resilience and meeting in St… Nicholas Weaver
- Re: [dnsext] Forgery resilience and meeting in St… Federico Lucifredi
- Re: [dnsext] Forgery resilience and meeting in St… Peter Koch
- Re: [dnsext] Forgery resilience and meeting in St… bmanning
- Re: [dnsext] Forgery resilience and meeting in St… Ted Lemon
- Re: [dnsext] Forgery resilience and meeting in St… bmanning
- Re: [dnsext] Forgery resilience and meeting in St… Olafur Gudmundsson