Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption )
"George Barwood" <george.barwood@blueyonder.co.uk> Mon, 20 April 2009 12:17 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 00B4A3A6D7C; Mon, 20 Apr 2009 05:17:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.191
X-Spam-Level: ****
X-Spam-Status: No, score=4.191 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, J_CHICKENPOX_17=0.6, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001]
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 Pe4bo6Ki8PO1; Mon, 20 Apr 2009 05:17:24 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B56123A6A34; Mon, 20 Apr 2009 05:17:23 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1LvsIa-000N1J-2k for namedroppers-data0@psg.com; Mon, 20 Apr 2009 12:08:32 +0000
Received: from [195.188.213.5] (helo=smtp-out2.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <george.barwood@blueyonder.co.uk>) id 1LvsIN-000N0F-9H for namedroppers@ops.ietf.org; Mon, 20 Apr 2009 12:08:25 +0000
Received: from [172.23.170.147] (helo=anti-virus03-10) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1LvsIG-0007VU-6f; Mon, 20 Apr 2009 13:08:12 +0100
Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with esmtpa (Exim 4.52) id 1LvsIF-00033t-9T; Mon, 20 Apr 2009 13:08:11 +0100
Message-ID: <9D43916D3C5846E9B2452967180A5416@localhost>
From: George Barwood <george.barwood@blueyonder.co.uk>
To: Paul Vixie <vixie@isc.org>, namedroppers@ops.ietf.org
References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <p06240829c60ab5c31f3e@10.20.30.158> <a06240801c60b8ef9a2c0@10.31.200.240> <F5CD211A47D7D446A26A92B0808FE56E25402B2923@NA-EXMSG-C115.redmond.corp.microsoft.com> <e90946380904160215v27fe58f4nea60171c03043dc3@mail.gmail.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <e90946380904160414l2668ca06sfa7307a47330c414@mail.gmail.com> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <e90946380904160714r57ace538u3dd4bf59f4efa73@mail.gmail.com> <70202.1239896047@nsa.vix.com>
Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption )
Date: Mon, 20 Apr 2009 13:08:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
----- Original Message ----- From: "Paul Vixie" <vixie@isc.org> To: <namedroppers@ops.ietf.org> Sent: Thursday, April 16, 2009 4:34 PM Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) >> >> You cannot do that without backwards compatibility. And if you keep >> >> backwards compatibility you are prone to downgrade attacks, ie.: >> > >> > Actually, you are NOT prone to downgrade attacks. >> >> True, if you deploy more forgery resistance techniques like n*queries >> (which could be deployed without 128bit ID/EDNS ping). Simple 128bit ID >> won't help here. But thanks for clarification. > > adding more queries brings all kinds of questions of its own like which > one > to use if the answers aren't all the same. also, punishing folks who > don't > upgrade by increasing their load. (dns-0x20 does this also, but the size > of > the punished population is smaller, being limited only to folks who > downcase > or upcase QNAMEs in their responses, which was never prohibited or > required.) There is a trade-off, better security versus more DNS packets. The question of what to do if answers aren't all the same is addressed in my draft https://datatracker.ietf.org/drafts/draft-barwood-dnsext-fr-resolver-mitigations/ > i think that any effort beyond dns-0x20 to secure against off-path > attackers > is misplaced. Can you give reasons? I can think of a few, although I don't think they are valid, there may be more: (i) The actual situation ( provided ISPs use port randomization ), is not too bad. Answer: as an IT manager, I would wish to install software that is as secure as possible, not relying on unknown third parties to operate as securely as possible. (ii) The increased load on DNS servers/networks is unacceptable. Answer: I don't believe this is true. But please state this explicitly if you think this is the case. (iii) FUD : any change carries some risk. Answer: it's true that implementing repetition in a resolver is quite complex. But I think it is doable. (iv) It's better to solve the problem with BGP. Answer: I'm afraid this is somewhat outside my knowledge, but answer is same as for (i). > dns must be secured end to end, which will not only enable a > new class of dnssec-aware applications, but obviate the need to secure dns > hop by hop. The case for DNSSEC, as has been observed by Nicholas Weaver on many occasions, is quite weak/unclear. It is the application that must be secured end to end, and this is a cost/performance trade off. Can you give an example of such a dnssec-aware application? > -- > 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/> > ----- Original Message ----- From: "Paul Vixie" <vixie@isc.org> To: <namedroppers@ops.ietf.org> Sent: Thursday, April 16, 2009 4:34 PM Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) >> >> You cannot do that without backwards compatibility. And if you keep >> >> backwards compatibility you are prone to downgrade attacks, ie.: >> > >> > Actually, you are NOT prone to downgrade attacks. >> >> True, if you deploy more forgery resistance techniques like n*queries >> (which could be deployed without 128bit ID/EDNS ping). Simple 128bit ID >> won't help here. But thanks for clarification. > > adding more queries brings all kinds of questions of its own like which > one > to use if the answers aren't all the same. also, punishing folks who > don't > upgrade by increasing their load. (dns-0x20 does this also, but the size > of > the punished population is smaller, being limited only to folks who > downcase > or upcase QNAMEs in their responses, which was never prohibited or > required.) > > i think that any effort beyond dns-0x20 to secure against off-path > attackers > is misplaced. dns must be secured end to end, which will not only enable > a > new class of dnssec-aware applications, but obviate the need to secure dns > hop by hop. > > -- > 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/> > -- 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] New draft has been posted Basil Dolmatov
- [dnsext] Re: New draft has been posted Basil Dolmatov
- Request for adoption (was: [dnsext] New draft has… Andrew Sullivan
- Re: Request for adoption (was: [dnsext] New draft… Ondřej Surý
- Re: Request for adoption (was: [dnsext] New draft… Paul Hoffman
- RE: Request for adoption (was: [dnsext] New draft… Dan Simon
- Re: Request for adoption (was: [dnsext] New draft… Olafur Gudmundsson
- RE: Request for adoption (was: [dnsext] New draft… Edward Lewis
- Re: Request for adoption (was: [dnsext] New draft… Peter Koch
- RE: Request for adoption (was: [dnsext] New draft… Dan Simon
- Re: Request for adoption (was: [dnsext] New draft… Paul Hoffman
- RE: Request for adoption (was: [dnsext] New draft… Paul Hoffman
- RE: Request for adoption (was: [dnsext] New draft… Dan Simon
- RE: Request for adoption (was: [dnsext] New draft… Paul Hoffman
- RE: Request for adoption (was: [dnsext] New draft… Edward Lewis
- RE: Request for adoption (was: [dnsext] New draft… Dan Simon
- RE: Request for adoption (was: [dnsext] New draft… Edward Lewis
- Re: Request for adoption (was: [dnsext] New draft… Ondřej Surý
- Re: Request for adoption (was: [dnsext] New draft… Jeffrey A. Williams
- [dnsext] Re: Request for adoption Michael Graff
- [dnsext] Re: Request for adoption Ondřej Surý
- [dnsext] Re: Request for adoption Michael Graff
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Nicholas Weaver
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Nicholas Weaver
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… W.C.A. Wijngaards
- Re: [dnsext] Re: Request for adoption Paul Vixie
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Ondřej Surý
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Paul Vixie
- Re: [dnsext] Re: Request for adoption Paul Vixie
- Re: [dnsext] Re: Request for adoption Michael Graff
- Re: [dnsext] Re: Request for adoption Ted Lemon
- [dnsext] Re: EDNS ping mechanisms Florian Weimer
- Re: [dnsext] Re: Request for adoption Jeffrey A. Williams
- [dnsext] Bigger QueryIDs Jim Reid
- [dnsext] handshakes and bigger QueryIDs Jim Reid
- [dnsext] Cookies, for bigger IDs (Was: Request fo… Stephane Bortzmeyer
- Re: [dnsext] Bigger QueryIDs Nicholas Weaver
- Re: [dnsext] Bigger QueryIDs Jim Reid
- Re: [dnsext] Bigger QueryIDs Alex Bligh
- Re: [dnsext] Bigger QueryIDs Nicholas Weaver
- Re: [dnsext] Bigger QueryIDs Alex Bligh
- Re: [dnsext] Bigger QueryIDs Ted Lemon
- Re: [dnsext] Bigger QueryIDs Edward Lewis
- Re: [dnsext] Bigger QueryIDs Jeffrey A. Williams
- Re: [dnsext] Bigger QueryIDs Jeffrey A. Williams
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… George Barwood
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… bert hubert
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Nicholas Weaver
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Paul Vixie
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Paul Vixie
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Paul Vixie
- Re: [dnsext] Re: Request for adoption Tony Finch
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… bert hubert
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Andreas Gustafsson
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… bert hubert
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Edward Lewis
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… bmanning
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Paul Vixie
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Nicholas Weaver
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Edward Lewis
- Re: Request for adoption (was: [dnsext] New draft… Samuel Weiler
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Stephane Bortzmeyer
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Stephane Bortzmeyer
- Securing hop by hop (was Re: EDNS ping mechanisms… Shane Kerr
- RE: Securing hop by hop (was Re: EDNS ping mechan… Aki Tuomi
- [dnsext] Re: Securing hop by hop (was Re: EDNS pi… Stephane Bortzmeyer
- Re: [dnsext] Re: Securing hop by hop (was Re: EDN… Matthew Dempsky
- Re: [dnsext] Re: Securing hop by hop (was Re: EDN… Basil Dolmatov
- Re: [dnsext] Re: Securing hop by hop (was Re: EDN… Basil Dolmatov
- Re: [dnsext] Re: Securing hop by hop Florian Weimer
- [dnsext] Re: Securing hop by hop (was Re: EDNS pi… Stephane Bortzmeyer
- Re: Securing hop by hop (was Re: EDNS ping mechan… Shane Kerr
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Tony Finch
- Re: [dnsext] Re: Securing hop by hop bert hubert
- Re: Securing hop by hop (was Re: EDNS ping mechan… Tony Finch
- Re: [dnsext] Re: Securing hop by hop (was Re: EDN… Nicholas Weaver
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Edward Lewis
- [dnsext] Re: EDNS ping mechanisms Florian Weimer
- Re: [dnsext] Re: Securing hop by hop Edward Lewis
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Paul Vixie
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Nicholas Weaver
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… bert hubert
- Re: Securing hop by hop (was Re: EDNS ping mechan… Jeffrey A. Williams
- DNSSEC-aware applications (was [dnsext] Re: Reque… Danny Mayer
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Francis Dupont
- Re: EDNS ping mechanisms (was [dnsext] Re: Reques… Francis Dupont