From owner-namedroppers@ops.ietf.org Tue Jul 1 02:10:58 2008 Return-Path: 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 38DA03A6939; Tue, 1 Jul 2008 02:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 CtLys6IYvIEI; Tue, 1 Jul 2008 02:10:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 22E673A6847; Tue, 1 Jul 2008 02:10:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDbnW-000OYO-8V for namedroppers-data@psg.com; Tue, 01 Jul 2008 09:05:14 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDbmi-000OPY-Po for namedroppers@ops.ietf.org; Tue, 01 Jul 2008 09:04:37 +0000 Received: from mirre.nlnetlabs.nl (mirre.nlnetlabs.nl [IPv6:2001:7b8:206:1:219:d1ff:fe0b:89f4]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m61948w0073666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jul 2008 11:04:09 +0200 (CEST) (envelope-from jelte@NLnetLabs.nl) Message-ID: <4869F308.4070201@NLnetLabs.nl> Date: Tue, 01 Jul 2008 11:04:08 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.12 (X11/20080414) MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org Subject: Re: Issue for discussion in draft-ietf-dnsext-dnssec-rsasha256 References: <20080616215742.GA66314@commandprompt.com> In-Reply-To: <20080616215742.GA66314@commandprompt.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Tue, 01 Jul 2008 11:04:09 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Sullivan wrote: > > 1. Remove the text. It's not needed. > > 2. Keep the text, and mark the current document as updating RFC4035, > because it is changing the rules of section 5.3.1 of RFC4035. > > 3. Keep the text, and don't do anything else. This text is not > changing the meaning of RFC4035, and there's nothing in RFC4035 or any > of the other DNSSEC RFCs to require validators to follow the trust > chain using every available algorithm they support. > I'll remove the text, thanks for the comments. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhp8wgACgkQ4nZCKsdOncVGgwCfT2BimENPmxiqXmEJDfy7o7Gu /XcAn1ke4th/4igw0HgzfUv722H8cRUA =3AeS -----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: From owner-namedroppers@ops.ietf.org Tue Jul 1 17:44:16 2008 Return-Path: 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 A76603A6845; Tue, 1 Jul 2008 17:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.1 X-Spam-Level: X-Spam-Status: No, score=-99.1 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, 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 9vxxkwCcpnmQ; Tue, 1 Jul 2008 17:44:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1EE103A6837; Tue, 1 Jul 2008 17:44:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDqIj-0006I0-2g for namedroppers-data@psg.com; Wed, 02 Jul 2008 00:34:25 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDqIW-0006Gi-1w for namedroppers@ops.ietf.org; Wed, 02 Jul 2008 00:34:22 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id 7F7F333C2E; Tue, 1 Jul 2008 17:34:11 -0700 (PDT) Date: Tue, 01 Jul 2008 17:34:11 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= /DNSEXT chair Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" In-Reply-To: <200806262033.m5QKXJxA036876@ogud.com> References: <200806262033.m5QKXJxA036876@ogud.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Thu, 26 Jun 2008 16:33:14 -0400, =D3lafur Gu=F0mundsson /DNSEXT chair wrote: > This note starts a Working Group Last Call for this Standards Track docum= ent > ending on noon July 12'th 2006 (Dublin time). >=20 > URL for the document and its history: > http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/ >=20 > This document updates and clarifies RFC1034 in how a resolver should gene= rate > random query ID, how to use multiple ports and possibly addresses to make > it harder to guess the details of a query by a particular resolver. >=20 > Please read the document carefully, in particular section 9. At this point > the chairs would like to know if the current RFC2119 wording in that > section is acceptable or how it can be improved. I basically support this document (although IMO BCP would be better category since it doesn't directly affect interoperability between implementations, I don't much care about that point and won't argue about it), but I have one possibly substantial comment on this draft. I'm afraid if an implementation naively follows this requirement (or suggestion): o Use multiple different source ports simultaneously in case of multiple outstanding queries; (from Section 9) it will open up an additional opportunity for the attacker to cause denial of service. That is, the attacker has the target resolver (caching server) send many queries for domain names controlled by the attacker, and it then drops the queries. The resolver needs to wait for a certain period (depending on implementation details) for each dropped query, keeping the large number of ports (sockets). Since the number of open sockets is often a scarce system resource, it may make the resolver unable to accept further queries. This type of attack scenario is not new: a recursive resolver inherently needs to creates and keep state for outstanding queries, and there is always a possibility of DoS that tries to eat up the maximum limit of such states. But I believe it's worth mentioning explicitly, since this specific case is a direct consequence of this particular suggestion, and as I said above, the number of allowable open sockets can be relatively small. This scenario has another implication: if the implementation strictly follows this requirement, the attacker may be able to limit the possible port numbers that the resolver uses for other meaningful queries to a much smaller set. For example, consider an extreme case where the attacker can cause 65534 outstanding queries, each sent from different port numbers for 10 seconds. Then the attacker can be sure that which port number is used for any other possible queries (although most of them will fail). So, I'd like to suggest introducing the following changes/additions: - add a note of the possibility of DoS attack described above, and warn the implementors to mitigate it - change this bullet of Section 9 o Use multiple different source ports simultaneously in case of multiple outstanding queries; to something like this: o Use a new unpredictable source port for each new outstanding query (note that the same source port could be chosen for multiple different outstanding queries); I also have some other minor comments (I hope these have not been pointed out). I'm referring to an "unpublished version" of the draft, to be very clear obtained at: http://ds9a.nl/tmp/draft-ietf-dnsext-forgery-resilience.txt (as of June 30th, MD5 =3D 33982dfa077df0803e731627e4a94b18) - Section 4.5 If the maximum ports range is utilized, on average, around 32128 source ports would have to be tried before matching the source port of the original question as ports below 1024 may be unavailable for use, leaving 64512 options. I don't understand where the number "32128" came from. If this means (65536 - 1024) / 2, it should be 32256... - Section 9 o Use an unpredictable source port for outgoing queries from the range (53, or > 1024) of available ports that is as large as possible and practicable; I don't understand what "the range (53, or > 1024)" means. Does that mean a set of {53, 1025, ..., 65535}? Besides, I also don't understand why port 1024 seems to be excluded. If this tries to exclude well known port numbers, it should be "> 1023". - Section 10 Most security considerations can be found in Section 5, while proposed countermeasures are described in Section 9. At least in the version I'm looking at, Section 5 is "Birthday attacks", which does not seem to discuss "Most security considerations"...shouldn't this actually mean Section 4 (Detailed Description of Spoofing Scenarios)? --- JINMEI, Tatuya Internet Systems Consortium, Inc. -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 3 11:42:54 2008 Return-Path: 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 CCA7D3A6A53; Thu, 3 Jul 2008 11:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.614 X-Spam-Level: X-Spam-Status: No, score=-0.614 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 FQjF8WgboP6i; Thu, 3 Jul 2008 11:42:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 702583A6807; Thu, 3 Jul 2008 11:42:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KETci-000Csu-2x for namedroppers-data@psg.com; Thu, 03 Jul 2008 18:33:40 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KETcd-000CsL-0L for namedroppers@ops.ietf.org; Thu, 03 Jul 2008 18:33:37 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KETcX-0000kn-Oc for namedroppers@ops.ietf.org; Thu, 03 Jul 2008 20:33:29 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 70D9F4B4C8; Thu, 3 Jul 2008 20:33:43 +0200 (CEST) Date: Thu, 3 Jul 2008 20:33:43 +0200 From: bert hubert To: "JINMEI Tatuya / ?$B?@L@C#:H" Cc: ?lafur Gu?mundsson /DNSEXT chair , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Message-ID: <20080703183343.GB25881@outpost.ds9a.nl> References: <200806262033.m5QKXJxA036876@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jul 01, 2008 at 05:34:11PM -0700, JINMEI Tatuya / ?$B?@L@C#:H wrote: > I basically support this document (although IMO BCP would be better > category since it doesn't directly affect interoperability between Thank you. I've been reading up on the complicated difference between BCP and Standards Track, and it is not clear to me. I do find BCPs to generally be far more descriptive and general, reflecting opinion or even 'ideas', instead of things that you really should be doing. BCP38 is a strong counterexample. In todays harsh internet climate, BCP38 might be better served by being an STD perhaps. But let's concentrate on the content: > o Use multiple different source ports simultaneously in case of > multiple outstanding queries; > it will open up an additional opportunity for the attacker to cause > denial of service. That is, the attacker has the target resolver This is correct. > maximum limit of such states. But I believe it's worth mentioning > explicitly, since this specific case is a direct consequence of this I've added "Additionally, care should be taken to prevent resource exhaustion when using larger amounts of query source ports." > - change this bullet of Section 9 > o Use multiple different source ports simultaneously in case of > multiple outstanding queries; > to something like this: > o Use a new unpredictable source port for each new outstanding > query (note that the same source port could be chosen for > multiple different outstanding queries); This is almost word for word a previous version of this requirement. While I vastly prefer your wording (or, the original original wording), I'm afraid this paragraph is starting to suffer from the aforementioned metal fatigue. It has been tweaked so much it might break. I've added your suggestion as 'alternate wording' so we can chose at a later stage. > of the original question as ports below 1024 may be unavailable for > use, leaving 64512 options. > > I don't understand where the number "32128" came from. If this > means (65536 - 1024) / 2, it should be 32256... Thank you - I also do not understand how this error crept in. > I don't understand what "the range (53, or > 1024)" means. Does that > mean a set of {53, 1025, ..., 65535}? Besides, I also don't > understand why port 1024 seems to be excluded. If this tries to > exclude well known port numbers, it should be "> 1023". I've changed the wording to: Use an unpredictable source port for outgoing queries from the range of available ports (53, or 1024 and above) that is as large as possible and practicable > Most security considerations can be found in Section 5, while > proposed countermeasures are described in Section 9. > > At least in the version I'm looking at, Section 5 is "Birthday > attacks", which does not seem to discuss "Most security > considerations"...shouldn't this actually mean Section 4 (Detailed > Description of Spoofing Scenarios)? Thank you again for your very precise reading. I've added section 4 to the list of reference chapters. Please find my changes based on your suggestions in http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset/30 Kind regards, Bert Hubert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 3 13:50:48 2008 Return-Path: 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 0E1263A68B4; Thu, 3 Jul 2008 13:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.606 X-Spam-Level: X-Spam-Status: No, score=-0.606 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 Lz3moS8ZZm3s; Thu, 3 Jul 2008 13:50:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B39443A6835; Thu, 3 Jul 2008 13:50:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEVeB-0002CI-RS for namedroppers-data@psg.com; Thu, 03 Jul 2008 20:43:19 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEVdt-00028e-22 for namedroppers@ops.ietf.org; Thu, 03 Jul 2008 20:43:11 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KEVdq-0002nm-K7 for namedroppers@ops.ietf.org; Thu, 03 Jul 2008 22:42:58 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id F314A44E3; Thu, 3 Jul 2008 22:43:11 +0200 (CEST) Date: Thu, 3 Jul 2008 22:43:11 +0200 From: bert hubert To: Alex Bligh Cc: Scott Rose , ?lafur Gu?mundsson /DNSEXT chair , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Message-ID: <20080703204310.GC25881@outpost.ds9a.nl> References: <200806262033.m5QKXJxA036876@ogud.com> <4864FF7B.1020300@nist.gov> <20080629114135.GE10892@outpost.ds9a.nl> <745AC98387631EFB03DD402C@Ximines.local> <20080629184104.GA9944@outpost.ds9a.nl> <411C59A066A01E6106DC756B@nimrod.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <411C59A066A01E6106DC756B@nimrod.local> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sun, Jun 29, 2008 at 08:44:47PM +0100, Alex Bligh wrote: > So I suggest: > > "In case these abilities are enabled, the implementation MUST > > minimise the ability of third parties to guess the implementation's > > future choices of source port and query ID remain even where that > > third party has knowledge of both the algorithm > > used by the implementation including its (pseudo-)random > > generator and all previous wire data" Thanks Alex - I mangled this into: In case these abilities are enabled, the implementation MUST minimise the ability of third parties to guess the implementation's future choices of source port and query ID even if the third party has knowledge of the (pseudo-)random generator employed and all previous wire data. I hope this is still correct. http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset/31 Bert. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 3 14:50:34 2008 Return-Path: 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 0D8883A687D; Thu, 3 Jul 2008 14:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 WUdeMdr9V8+4; Thu, 3 Jul 2008 14:50:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 151D23A67FA; Thu, 3 Jul 2008 14:50:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEWb0-0009az-Hw for namedroppers-data@psg.com; Thu, 03 Jul 2008 21:44:06 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KEWaw-0009Yf-Kr for namedroppers@ops.ietf.org; Thu, 03 Jul 2008 21:44:04 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 32C66C2DA7; Thu, 3 Jul 2008 22:43:58 +0100 (BST) Date: Thu, 03 Jul 2008 22:43:56 +0100 From: Alex Bligh Reply-To: Alex Bligh To: bert hubert cc: Scott Rose , "?lafur Gu?mundsson /DNSEXT chair" , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Message-ID: <736D49D21A37C4B56AC6BCCF@Ximines.local> In-Reply-To: <20080703204310.GC25881@outpost.ds9a.nl> References: <200806262033.m5QKXJxA036876@ogud.com> <4864FF7B.1020300@nist.gov> <20080629114135.GE10892@outpost.ds9a.nl> <745AC98387631EFB03DD402C@Ximines.local> <20080629184104.GA9944@outpost.ds9a.nl> <411C59A066A01E6106DC756B@nimrod.local> <20080703204310.GC25881@outpost.ds9a.nl> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 3 July 2008 22:43:11 +0200 bert hubert wrote: > In case these abilities are enabled, the implementation MUST minimise > the ability of third parties to guess the implementation's future > choices of source port and query ID even if the third party has > knowledge of the (pseudo-)random generator [*] employed and all previous > wire data. Looks good, but at risk of nitpicking, perhaps insert "algorithm" at [*] otherwise it can be criticised for exactly the same reason brought up here a few days ago, i.e. if you know its internal state as well as the algorithm (as opposed to just the algorithm) it *is* predictable. Alex -- 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: From cabaex@cabaex.net Sat Jul 5 02:34:27 2008 Return-Path: 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 2A35A3A6B66; Sat, 5 Jul 2008 02:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -50.15 X-Spam-Level: X-Spam-Status: No, score=-50.15 tagged_above=-999 required=5 tests=[FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_IPADDR=2.935, RCVD_IN_BL_SPAMCOP_NET=2.188, RCVD_IN_PBL=0.509, RCVD_IN_SORBS_DUL=1.615, RCVD_IN_XBL=2.896, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, 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 H6xW7xX6H-j4; Sat, 5 Jul 2008 02:34:26 -0700 (PDT) Received: from ppp-124-121-201-18.revip2.asianet.co.th (ppp-124-121-201-18.revip2.asianet.co.th [124.121.201.18]) by core3.amsl.com (Postfix) with SMTP id 229E33A684D; Sat, 5 Jul 2008 02:33:48 -0700 (PDT) X-Originating-IP: 146.144.188.146 by smtp.124.121.201.18; Sat, 05 Jul 2008 05:33:50 -0500 Message-ID: From: "Josef Dodge" Reply-To: "Josef Dodge" To: dix@ietf.org Subject: Best replica watches from IWC at Prestige Replicas Date: Sat, 05 Jul 2008 05:33:50 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Prestige Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://Lilynixof.blogspot.com/ Prestige Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://Lilynixof.blogspot.com/ From c.leclercq@printempsmusicalsilly.be Sun Jul 6 22:45:00 2008 Return-Path: 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 C98CF3A69CA; Sun, 6 Jul 2008 22:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -58.695 X-Spam-Level: X-Spam-Status: No, score=-58.695 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, TVD_RCVD_IP=1.931, 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 qTR3FTp+wObt; Sun, 6 Jul 2008 22:45:00 -0700 (PDT) Received: from 190-82-221-123.adsl.tie.cl (190-82-221-123.adsl.tie.cl [190.82.221.123]) by core3.amsl.com (Postfix) with SMTP id 412733A6932; Sun, 6 Jul 2008 22:44:49 -0700 (PDT) X-Originating-IP: 78.83.52.154 by smtp.190.82.221.123; Mon, 07 Jul 2008 01:44:53 -0500 Message-ID: From: "Coleen Clinton" Reply-To: "Coleen Clinton" To: discuss-bounces@ietf.org Subject: Jaeger-LeCoultre replica watch Luxury isn't a sin Date: Mon, 07 Jul 2008 01:44:53 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Prestige Replicas, the web's most comprehensive collection of brand name replica watches. In Prestige Replicas, any Tag Heuer is available for just over $200. http://johnwalkerblog.blogspot.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Prestige Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Prestige Replicas. http://johnwalkerblog.blogspot.com/ From owner-namedroppers@ops.ietf.org Mon Jul 7 08:33:01 2008 Return-Path: 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 71B033A6AB2; Mon, 7 Jul 2008 08:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 uf2E7CZWpGsL; Mon, 7 Jul 2008 08:33:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CE4D13A6A7C; Mon, 7 Jul 2008 08:32:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFsYb-0002MN-J6 for namedroppers-data@psg.com; Mon, 07 Jul 2008 15:23:13 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFsYW-0002LR-6c for namedroppers@ops.ietf.org; Mon, 07 Jul 2008 15:23:11 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m67FN5DR007146; Mon, 7 Jul 2008 17:23:06 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200807071523.m67FN5DR007146@givry.fdupont.fr> From: Francis Dupont To: Paul Hoffman cc: namedroppers@ops.ietf.org Subject: Re: Logical inconsistencies in draft-ietf-dnsext-tsig-md5-deprecated-00.txt In-reply-to: Your message of Mon, 30 Jun 2008 08:56:16 PDT. Date: Mon, 07 Jul 2008 17:23:05 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: Greetings again. The logic in this document is kind of a mess. => I understand the situation is very frustrating for a cryptographer... It says, in essence: a) MD5 turns out to be weaker than expected for a hash => note the consequences are important, not this fact by itself. b) therefore it should be deprecated and HMAC-SHA1 be mandatory => HMAC-SHA1 and HMAC-SHA256 are already mandatory (cf RFC 4635). The first statement is certainly true, but irrelevant, because TSIG uses HMAC-MD5, not MD5. As the draft admits, there are no known attacks on HMAC-MD5. To the best of my knowledge, there have been no papers published even hinting at it. => I fully agree, this is why the draft explains the real reason of the deprecation of HMAC-MD5 is not a security issue but an operational issue which is based on a not-yet-proved assumption about HMAC-MD5 weakness. So a) doesn't imply b) but the consequences of a), even not well-founded, imply the first part of b). The second statement is short-sighted. The document talks about the desire to have algorithms that can be used in systems that are validated with FIPS 140 for NIST in the US. => yes, there are some environments where you have no choice about what the crypto module includes. You can believe it is limited, etc, but when it is in the regulations you must apply the term "no choice" has a real meaning. However, NIST has already said that SHA-1 will be deprecated in about 2.5 years; see . => I prefer which is clearer about the use. So making SHA-1 mandatory based on wanting to use FIPS algorithms is also not a good idea. => s/making/keeping/. There is a good reason to keep SHA-1 is the mandatory to support algorithms: I am afraid many old implementations propose only MD5 and SHA-1, so to deprecate both HMAC-MD5 and HMAC-SHA1 should lead to more operational issues than to do nothing. Getting rid of TSIG-HMAC-MD5 for NIST-related reasons would also require us to get rid of TSIG-HMAC-SHA1, either now or in 2.5 years from now. => I've tried to get more years but making HMAC-SHA256 recommended. Note: - this is new as no algorithm was recommended before. - it is not based on cryptography because as far as I know nobody has a recognized argument showing that HMAC-SHA256 is stronger than HMAC-SHA1. But I agree in the long term HMAC-SHA1 should be deprecated too... If the only reason for this draft to exist is to deprecate TSIG-HMAC-MD5, then it seems like vast overkill. Instead, a better idea is a simple one-page draft that takes TSIG-HMAC-MD5 from mandatory to optional. That draft doesn't need any questionable cryptography or discussion of NIST. => in the previous version in the RFC 4635 table HMAC-MD5 was moved from mandatory to optional but a comment asked to move it to deprecated. BTW the only defined requirement levels are "mandatory" (MUST implement) and "not mandatory" (MAY implement), so it is just a matter of choice of words... If we come back to the draft in the 4 sub targets: - 1 is about IANA registry; - 2 is exactly what we are talking: move HMAC-MD5 to not mandatory; - 3 is about TKEY and as it uses directly MD5 for keying material derivation I believe you should agree SHA-256 is a better choice; - 4 is the (new) recommendation for HMAC-SHA256. Is something wrong here? Regards Francis.Dupont@fdupont.fr PS: my own target is to provide a DNS tool implementing TSIG, TKEY, etc, which both uses a FIPS 140-2 crypto module in the FIPS mode, and is "RFC compliant". Today it is not possible because HMAC-MD5 is mandatory to support and TKEY specs written last century... -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 7 08:36:39 2008 Return-Path: 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 BA5903A65A6; Mon, 7 Jul 2008 08:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 IqywUjXXTkGM; Mon, 7 Jul 2008 08:36:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 160173A6866; Mon, 7 Jul 2008 08:36:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFsga-0003Q5-JX for namedroppers-data@psg.com; Mon, 07 Jul 2008 15:31:28 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFsgV-0003PH-9P for namedroppers@ops.ietf.org; Mon, 07 Jul 2008 15:31:25 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m67FVGHL007170; Mon, 7 Jul 2008 17:31:17 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200807071531.m67FVGHL007170@givry.fdupont.fr> From: Francis Dupont To: Scott Rose cc: namedroppers@ops.ietf.org Subject: Re: Logical inconsistencies in draft-ietf-dnsext-tsig-md5-deprecated-00.txt In-reply-to: Your message of Mon, 30 Jun 2008 13:07:07 EDT. <486912BB.9030300@nist.gov> Date: Mon, 07 Jul 2008 17:31:16 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: I could also live with moving HMAC-MD5 to optional. It is up to the parties involved to decide with algorithm to use anyway. => I can go back to the word "optional" (BTW both are "not mandatory" so translate to MAY implement). I believe this mailing-list is the right place, or we can wait for Dublin? Thanks Francis.Dupont@fdupont.fr PS: NIST'S POLICY ON HASH FUNCTIONS March 15, 2006: *The SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all applications using secure hash algorithms.* Federal agencies *should* stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010. After 2010, Federal agencies may use SHA-1 only for the following applications: hash-based message authentication codes (HMACs); key derivation functions (KDFs); and random number generators (RNGs). Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols. (from http://csrc.nist.gov/groups/ST/hash/policy.html, I've enclosed emphased words in the original by **) -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 7 12:06:12 2008 Return-Path: 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 21B153A6AAB; Mon, 7 Jul 2008 12:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 hy8fycI0+1Uu; Mon, 7 Jul 2008 12:06:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 15AD33A6824; Mon, 7 Jul 2008 12:06:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFvuj-0006Sp-Hf for namedroppers-data@psg.com; Mon, 07 Jul 2008 18:58:17 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KFvuW-0006Rg-K7 for namedroppers@ops.ietf.org; Mon, 07 Jul 2008 18:58:06 +0000 Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m67Iw096048271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jul 2008 11:58:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200807071523.m67FN5DR007146@givry.fdupont.fr> References: <200807071523.m67FN5DR007146@givry.fdupont.fr> Date: Mon, 7 Jul 2008 11:57:53 -0700 To: Francis Dupont From: Paul Hoffman Subject: Re: Logical inconsistencies in draft-ietf-dnsext-tsig-md5-deprecated-00.txt Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 5:23 PM +0200 7/7/08, Francis Dupont wrote: >=> I fully agree, this is why the draft explains the real reason of >the deprecation of HMAC-MD5 is not a security issue but an operational >issue which is based on a not-yet-proved assumption about HMAC-MD5 >weakness. Not only has a weakness in HMAC-MD5 not been proven, *it hasn't even been proposed*, at least in the cryptographic literature I have seen. I may have missed it, of course. Please note that the HMAC construction has been studied and written about extensively. If it was weak for hashes that have weakened collision resistance, that would probably be noted by now. >=> in the previous version in the RFC 4635 table HMAC-MD5 was moved >from mandatory to optional but a comment asked to move it to >deprecated. I don't see that in RFC 4635. I only see it as mandatory. Could you quote the section you are referring to? >BTW the only defined requirement levels are "mandatory" >(MUST implement) and "not mandatory" (MAY implement), so it is just >a matter of choice of words... It is probably inappropriate to change the terminology when updating a document. The term "not mandatory" does not appear in RFC 4635. Further, if you mean to say "not mandatory" in your draft, why do you instead say: | Deprecated | HMAC-MD5.SIG-ALG.REG.INT | >If we come back to the draft in the 4 sub targets: > - 1 is about IANA registry; Yes. > - 2 is exactly what we are talking: move HMAC-MD5 to not mandatory; Then say that. > - 3 is about TKEY and as it uses directly MD5 for keying material > derivation I believe you should agree SHA-256 is a better choice; Please don't put words in my mouth. I don't agree that SHA-256 is better than MD5 for TKEY keying material. What attack do you see with MD5 for keying material in TKEY. > - 4 is the (new) recommendation for HMAC-SHA256. Fine. >PS: my own target is to provide a DNS tool implementing TSIG, TKEY, etc, >which both uses a FIPS 140-2 crypto module in the FIPS mode, and is >"RFC compliant". Today it is not possible because HMAC-MD5 is mandatory >to support and TKEY specs written last century... So, your crypto module in FIPS mode will not be "RFC compliant": so what? There are lots of examples of IETF protocols that have that property; IKEv1 comes to mind. Your entire app can be RFC compliant and still have a crypto module that can be FIPS validated. --Paul Hoffman, Director --VPN Consortium -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 8 04:14:23 2008 Return-Path: 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 4C48F3A6875; Tue, 8 Jul 2008 04:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] 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 nZhFiu+5pt1y; Tue, 8 Jul 2008 04:14:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E2623A6845; Tue, 8 Jul 2008 04:14:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGB2K-000Pge-OP for namedroppers-data@psg.com; Tue, 08 Jul 2008 11:07:08 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGB24-000PeT-AC for namedroppers@ops.ietf.org; Tue, 08 Jul 2008 11:06:54 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KGB1q-0005pA-Hv; Tue, 08 Jul 2008 13:06:38 +0200 Received: from fweimer by bfk.de with local id 1KGB1w-0000Wk-8E; Tue, 08 Jul 2008 13:06:44 +0200 To: Paul Hoffman Cc: Francis Dupont , namedroppers@ops.ietf.org Subject: Re: Logical inconsistencies in draft-ietf-dnsext-tsig-md5-deprecated-00.txt References: <200807071523.m67FN5DR007146@givry.fdupont.fr> From: Florian Weimer Date: Tue, 08 Jul 2008 13:06:44 +0200 In-Reply-To: (Paul Hoffman's message of "Mon, 7 Jul 2008 11:57:53 -0700") Message-ID: <82y74cvdmj.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Paul Hoffman: > Not only has a weakness in HMAC-MD5 not been proven, *it hasn't even > been proposed*, at least in the cryptographic literature I have > seen. HMAC-MD5 is technically broken because MD5 is broken. In addition to that, there are somewhat plausible attack scenarios involving chosen plaintexts in the DNS context, and the "evil twins" nature of the current MD5 attacks[1] is probably not an obstacle in this application. I don't know why anyone hasn't published anything on HMAC-MD5. Perhaps because it's rather obvious that chosen-plaintext attacks can be successful. On the other hand, Wang et al.'s work doesn't give any insight into how to recover the underlying key. [1] I think there are even better attacks now which move away from the "evil twins" concept, involving exchanged randomly-looking garbage blocks in a different part of the message which compensate for an arbitrary edit in some other part (where both versions are meaningful and not high-entropy gibberish). --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 8 08:14:10 2008 Return-Path: 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 002463A6A7D; Tue, 8 Jul 2008 08:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 vlOT6Q5S+C1o; Tue, 8 Jul 2008 08:14:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0E3C83A6A79; Tue, 8 Jul 2008 08:14:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGEn4-000Nak-Kc for namedroppers-data@psg.com; Tue, 08 Jul 2008 15:07:38 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGEmt-000NZR-Bg for namedroppers@ops.ietf.org; Tue, 08 Jul 2008 15:07:29 +0000 Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m68F7Hd9051642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2008 08:07:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <82y74cvdmj.fsf@mid.bfk.de> References: <200807071523.m67FN5DR007146@givry.fdupont.fr> <82y74cvdmj.fsf@mid.bfk.de> Date: Tue, 8 Jul 2008 08:07:15 -0700 To: Florian Weimer From: Paul Hoffman Subject: Re: Logical inconsistencies in draft-ietf-dnsext-tsig-md5-deprecated-00.txt Cc: Francis Dupont , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 1:06 PM +0200 7/8/08, Florian Weimer wrote: >HMAC-MD5 is technically broken because MD5 is broken. Please define what you mean by "technically". The well-received paper, seems to disagree with this statement >I don't know why anyone hasn't published anything on HMAC-MD5. That is simply untrue. The article above explicitly talks about HMAC-MD5. --Paul Hoffman, Director --VPN Consortium -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 8 08:32:26 2008 Return-Path: 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 60F5B3A693E; Tue, 8 Jul 2008 08:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] 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 3A2SuEJu3nYZ; Tue, 8 Jul 2008 08:32:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 421F73A6909; Tue, 8 Jul 2008 08:32:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGF59-000Pnu-QA for namedroppers-data@psg.com; Tue, 08 Jul 2008 15:26:19 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGF4n-000PlX-6Y for namedroppers@ops.ietf.org; Tue, 08 Jul 2008 15:26:09 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KGF4W-0006Ir-9T; Tue, 08 Jul 2008 17:25:40 +0200 Received: from fweimer by bfk.de with local id 1KGF4c-00086u-2j; Tue, 08 Jul 2008 17:25:46 +0200 To: Paul Hoffman Cc: Francis Dupont , namedroppers@ops.ietf.org Subject: Re: Logical inconsistencies in draft-ietf-dnsext-tsig-md5-deprecated-00.txt References: <200807071523.m67FN5DR007146@givry.fdupont.fr> <82y74cvdmj.fsf@mid.bfk.de> From: Florian Weimer Date: Tue, 08 Jul 2008 17:25:46 +0200 In-Reply-To: (Paul Hoffman's message of "Tue, 8 Jul 2008 08:07:15 -0700") Message-ID: <821w24tn2d.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Paul Hoffman: > At 1:06 PM +0200 7/8/08, Florian Weimer wrote: >>HMAC-MD5 is technically broken because MD5 is broken. > > Please define what you mean by "technically". The well-received paper, > seems to disagree with this > statement The problem is that the traditional threat model for MACs simply does not consider chosen-plaintext attacks. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 8 12:03:09 2008 Return-Path: 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 3EB853A6AE6; Tue, 8 Jul 2008 12:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 XWTXvnz1Z+zl; Tue, 8 Jul 2008 12:03:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DD25F3A6AD4; Tue, 8 Jul 2008 12:03:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGIIi-000L5P-TO for namedroppers-data@psg.com; Tue, 08 Jul 2008 18:52:32 +0000 Received: from [209.85.132.247] (helo=an-out-0708.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGIIW-000L3L-AI for namedroppers@ops.ietf.org; Tue, 08 Jul 2008 18:52:22 +0000 Received: by an-out-0708.google.com with SMTP id c24so760999ana.18 for ; Tue, 08 Jul 2008 11:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=5VwwPQuAFkgOU06+dJiUDu5lq/FFO2Avx560u9wp5B0=; b=TGpulSbKXilJ33XXpJLlohPv4ttz/WNzzo+3Hdx22XeVr4XvJUDtp0uCxIb+LoC1H3 Hu2c/PpymcdLQ1r3b53Vda7Wpa2H9CpMChRNjc45lWRGWZA4pYfaf1IOn9u2yiJ8TH0J wk6QrF7aYw5woBEZA3PHmjfHV1OqbuGDYum8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=ehQdsD7DKG5/XKtDH6ZXtU2j8kKqnWOT/La2C7k1vIRraBgT30zn0RHxypMrSk9hF2 GCPY+s1R4G1zSYcYusYGQWBJgevYBak/5R7kdfo4BDCAVNMvl8r6E3Nxwd+i/lvRUu18 ilv/fCl7/QE2HJ48pGvTAlRPL2yvdC9C5mAJI= Received: by 10.100.152.5 with SMTP id z5mr5477169and.100.1215543139426; Tue, 08 Jul 2008 11:52:19 -0700 (PDT) Received: by 10.100.92.20 with HTTP; Tue, 8 Jul 2008 11:52:19 -0700 (PDT) Message-ID: <1028365c0807081152l22223ce5kebff7913229a9e1b@mail.gmail.com> Date: Tue, 8 Jul 2008 14:52:19 -0400 From: "Donald Eastlake" To: namedroppers@ops.ietf.org Subject: Email change for Donald Eastlake MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7874_9844578.1215543139415" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ------=_Part_7874_9844578.1215543139415 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Sorry for the noise but please note my change of email address to d3e3e3@gmail.com Any mail sent to my motorola.com email address since about noon on June 27th won't get to me. Thanks, Donald ============================= Donald E. Eastlake 3rd 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com ------=_Part_7874_9844578.1215543139415 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

Sorry for the noise but please note my change of email address to

d3e3e3@gmail.com

Any mail sent to my motorola.com email address since about noon on June 27th won't get to me.

Thanks,
Donald
=============================
Donald E. Eastlake 3rd 
155 Beaver Street 
Milford, MA 01757 USA
d3e3e3@gmail.com ------=_Part_7874_9844578.1215543139415-- -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 8 12:47:13 2008 Return-Path: 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 237F83A6895; Tue, 8 Jul 2008 12:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 1vmFCU3JPKBs; Tue, 8 Jul 2008 12:47:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 14D033A67D4; Tue, 8 Jul 2008 12:47:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGJ2C-000024-87 for namedroppers-data@psg.com; Tue, 08 Jul 2008 19:39:32 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGJ21-000PzP-0l for namedroppers@ops.ietf.org; Tue, 08 Jul 2008 19:39:29 +0000 Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m68JdC4d078235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2008 12:39:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <821w24tn2d.fsf@mid.bfk.de> References: <200807071523.m67FN5DR007146@givry.fdupont.fr> <82y74cvdmj.fsf@mid.bfk.de> <821w24tn2d.fsf@mid.bfk.de> Date: Tue, 8 Jul 2008 12:39:10 -0700 To: Florian Weimer From: Paul Hoffman Subject: Re: Logical inconsistencies in draft-ietf-dnsext-tsig-md5-deprecated-00.txt Cc: Francis Dupont , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 5:25 PM +0200 7/8/08, Florian Weimer wrote: >* Paul Hoffman: > >> At 1:06 PM +0200 7/8/08, Florian Weimer wrote: >>>HMAC-MD5 is technically broken because MD5 is broken. >> >> Please define what you mean by "technically". The well-received paper, >> seems to disagree with this >> statement > >The problem is that the traditional threat model for MACs simply does >not consider chosen-plaintext attacks. If you thing that is a problem with the paper in question, you should take that to the author of the paper. It is a well-received paper by a leader in the crypto community. Given the construction of HMACs, and the conclusion of the paper that the collision-resistance of the underlying hash function is actually not needed for the security proof, asserting that chosen-plaintext attacks are somehow relevant would certainly need a fair amount of supporting evidence. --Paul Hoffman, Director --VPN Consortium -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 8 15:14:46 2008 Return-Path: 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 229B728C37C; Tue, 8 Jul 2008 15:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Ghvk+Wnrj2JL; Tue, 8 Jul 2008 15:14:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3F03528C37D; Tue, 8 Jul 2008 15:14:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGLGr-000EPa-FU for namedroppers-data@psg.com; Tue, 08 Jul 2008 22:02:49 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGLGn-000EPC-9z for namedroppers@ops.ietf.org; Tue, 08 Jul 2008 22:02:47 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m68M2fuH016973; Wed, 9 Jul 2008 00:02:43 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200807082202.m68M2fuH016973@givry.fdupont.fr> From: Francis Dupont To: Paul Hoffman cc: namedroppers@ops.ietf.org Subject: Re: Logical inconsistencies in draft-ietf-dnsext-tsig-md5-deprecated-00.txt In-reply-to: Your message of Mon, 07 Jul 2008 11:57:53 PDT. Date: Wed, 09 Jul 2008 00:02:41 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: >=> I fully agree, this is why the draft explains the real reason of >the deprecation of HMAC-MD5 is not a security issue but an operational >issue which is based on a not-yet-proved assumption about HMAC-MD5 >weakness. Not only has a weakness in HMAC-MD5 not been proven, *it hasn't even been proposed*, at least in the cryptographic literature I have seen. => in the cryptographic literature proposed == proved (or it is not good cryptographic literature). I think we agree. >=> in the previous version in the RFC 4635 table HMAC-MD5 was moved >from mandatory to optional but a comment asked to move it to >deprecated. => in the previon version of the I-D (published with my name before it became a WG item). I don't see that in RFC 4635. I only see it as mandatory. Could you quote the section you are referring to? => draft-dupont-dnsext-tsig-md5-deprecated-00.txt should be still available in the I-D repository. >BTW the only defined requirement levels are "mandatory" >(MUST implement) and "not mandatory" (MAY implement), so it is just >a matter of choice of words... It is probably inappropriate to change the terminology when updating a document. The term "not mandatory" does not appear in RFC 4635. => the RFC 4635 doesn't define the requirement levels, again a comment asked to fix this. Further, if you mean to say "not mandatory" in your draft, why do you instead say: | Deprecated | HMAC-MD5.SIG-ALG.REG.INT | => I am open to any idea as soon as there is a consensus about it. >If we come back to the draft in the 4 sub targets: > - 1 is about IANA registry; Yes. > - 2 is exactly what we are talking: move HMAC-MD5 to not mandatory; Then say that. > - 3 is about TKEY and as it uses directly MD5 for keying material > derivation I believe you should agree SHA-256 is a better choice; Please don't put words in my mouth. I don't agree that SHA-256 is better than MD5 for TKEY keying material. What attack do you see with MD5 for keying material in TKEY. => I can see two issues, one operational (MD5 has to be available), one mixed operational/security (a hash producing more bits works better with longer keys). BTW there is no cryptographic analysis of the derivation formula, it just seems to totally stupid... > - 4 is the (new) recommendation for HMAC-SHA256. Fine. >PS: my own target is to provide a DNS tool implementing TSIG, TKEY, etc, >which both uses a FIPS 140-2 crypto module in the FIPS mode, and is >"RFC compliant". Today it is not possible because HMAC-MD5 is mandatory >to support and TKEY specs written last century... So, your crypto module in FIPS mode will not be "RFC compliant": so what? => it is not "mine" crypto module but mine application using a third party crypto module. Perhaps I am influenced by the "Graceful Avoidance of of non-FIPS Algorithms" of http://www.openssl.org/docs/fips/UserGuide-1.1.1.pdf (:-)? Regards Francis.Dupont@fdupont.fr -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 9 00:39:18 2008 Return-Path: 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 32E6D3A68B2; Wed, 9 Jul 2008 00:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.394 X-Spam-Level: X-Spam-Status: No, score=-5.394 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 KvN9L76DweWa; Wed, 9 Jul 2008 00:39:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3D7613A68B1; Wed, 9 Jul 2008 00:39:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGU5O-000FVK-Tu for namedroppers-data@psg.com; Wed, 09 Jul 2008 07:27:34 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGU4x-000FSf-Ki for namedroppers@ops.ietf.org; Wed, 09 Jul 2008 07:27:16 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 7227B1C010A for ; Wed, 9 Jul 2008 09:27:02 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 6D69D1C00D3 for ; Wed, 9 Jul 2008 09:27:02 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 68CD4A1DACB for ; Wed, 9 Jul 2008 09:27:02 +0200 (CEST) Date: Wed, 9 Jul 2008 09:27:02 +0200 From: Stephane Bortzmeyer To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Message-ID: <20080709072702.GA24127@nic.fr> References: <200806262033.m5QKXJxA036876@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200806262033.m5QKXJxA036876@ogud.com> X-Operating-System: Debian GNU/Linux lenny/sid X-Kernel: Linux 2.6.24-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jun 26, 2008 at 04:33:14PM -0400, Ólafur Guðmundsson /DNSEXT chair wrote a message of 28 lines which said: > This note starts a Working Group Last Call for this Standards Track document > ending on noon July 12'th 2006 (Dublin time). > > URL for the document and its history: > http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/ I notice in Cisco's advisory this advice "Administrators may consider configuring the TTL of DNS caches to a relatively short value." But the I-D says "The time to live of the target domain name's RRSETs determines how often a window of opportunity is available, which implies that a short TTL makes spoofing far more viable." So, I believe that the Cisco advisory is broken. Comments? -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 9 00:56:13 2008 Return-Path: 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 55A523A696D; Wed, 9 Jul 2008 00:56:13 -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 y6qV37KjbqO8; Wed, 9 Jul 2008 00:56:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3E84E3A6863; Wed, 9 Jul 2008 00:56:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGUQR-000IIs-Hp for namedroppers-data@psg.com; Wed, 09 Jul 2008 07:49:19 +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 ) id 1KGUQG-000IHB-4D for namedroppers@ops.ietf.org; Wed, 09 Jul 2008 07:49:17 +0000 Received: from jelte (vhe-520087.sshn.net [195.169.221.157]) by sol.nlnetlabs.nl (Postfix) with ESMTP id 2ACBB130016; Wed, 9 Jul 2008 09:49:06 +0200 (CEST) Received: from [192.168.8.11] (dragon [192.168.8.11]) by jelte (Postfix) with ESMTP id 5AB04CF9C2; Wed, 9 Jul 2008 09:49:05 +0200 (CEST) Message-ID: <48746D76.3030606@NLnetLabs.nl> Date: Wed, 09 Jul 2008 09:49:10 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Stephane Bortzmeyer Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" References: <200806262033.m5QKXJxA036876@ogud.com> <20080709072702.GA24127@nic.fr> In-Reply-To: <20080709072702.GA24127@nic.fr> 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: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephane Bortzmeyer wrote: > > I notice in Cisco's advisory > > this advice "Administrators may consider configuring the TTL of DNS > caches to a relatively short value." But the I-D says "The time to > live of the target domain name's RRSETs determines how often a window > of opportunity is available, which implies that a short TTL makes > spoofing far more viable." > > So, I believe that the Cisco advisory is broken. Comments? > I'm not quite sure what they mean with 'TTL of DNS caches'. But I agree that having low TTL values on your RRSETs gives more windows of opportunity and no protection at all, since the spoofed packet will most likely have different TTL values anyway. The next point, turning off caching completely is interesting too; every query could be spoofed, but for reliable spoofing, one would need to spoof every query... but operationally turning off caching completely might not be a good idea anyway Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIdG124nZCKsdOncURArOkAJ4x/yJMwQs7esKRtjfZwq/KT1A77QCfUqxs vxvoNEeyGTFETTIFkAqON4w= =xvw0 -----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: From owner-namedroppers@ops.ietf.org Wed Jul 9 01:16:14 2008 Return-Path: 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 9A8853A6935; Wed, 9 Jul 2008 01:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 BeZIa5LcG9bv; Wed, 9 Jul 2008 01:16:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 252823A686E; Wed, 9 Jul 2008 01:16:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGUmA-000KWN-9B for namedroppers-data@psg.com; Wed, 09 Jul 2008 08:11:46 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGUlt-000KUB-AL for namedroppers@ops.ietf.org; Wed, 09 Jul 2008 08:11:37 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 4073CC2DA3; Wed, 9 Jul 2008 09:11:25 +0100 (BST) Date: Wed, 09 Jul 2008 09:11:21 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Stephane Bortzmeyer , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Message-ID: In-Reply-To: <20080709072702.GA24127@nic.fr> References: <200806262033.m5QKXJxA036876@ogud.com> <20080709072702.GA24127@nic.fr> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 9 July 2008 09:27:02 +0200 Stephane Bortzmeyer wrote: > I notice in Cisco's advisory > > this advice "Administrators may consider configuring the TTL of DNS > caches to a relatively short value." But the I-D says "The time to > live of the target domain name's RRSETs determines how often a window > of opportunity is available, which implies that a short TTL makes > spoofing far more viable." > > So, I believe that the Cisco advisory is broken. Comments? Yes I think so, though with a nit. The Cisco advisory talks about the TTL of "DNS caches" not the TTL of DNS records (or RRSets). I am not sure what that means, but perhaps it means applying a maximum to the actual TTL received. Let's assume they mean "records" not "caches". The draft give advice for a server operator to minimise the number of queries made to it for domain names for which it is authoritative and reduce the incidence of a fake record. The Cisco advisory suggests reducing the TTL of the records in the cache in order (presumably) to minimise the time a poisoned record sticks around, and thus its impact. But any attacker would surely put a large TTL on the spoofed records in order to maximise their effect (assuming they weren't seeking stealth). So the only possible useful interpretation of the Cisco advisory is that they intend for TTL records to be capped in-cache. If the TTL was higher in the first place, that will result in more queries, and thus more opportunities for poisoning. The only question is whether reducing overall cache TTL also reduces the visibility of the entropy pool to a rogue server (for instance by interspersing more valid queries), and whether this effect is greater; if it is, then it's not actually incompatible with what the ID suggests. Alex -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 9 02:39:46 2008 Return-Path: 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 B2DBE3A681D; Wed, 9 Jul 2008 02:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.07 X-Spam-Level: X-Spam-Status: No, score=-5.07 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 9wO9obDQUiLe; Wed, 9 Jul 2008 02:39:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D8AFD3A6906; Wed, 9 Jul 2008 02:39:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGVzX-0002ib-4V for namedroppers-data@psg.com; Wed, 09 Jul 2008 09:29:39 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGVzK-0002h2-Cy for namedroppers@ops.ietf.org; Wed, 09 Jul 2008 09:29:31 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 6125A1C0119; Wed, 9 Jul 2008 11:29:24 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 5C10A1C00FF; Wed, 9 Jul 2008 11:29:24 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 4EFB3A1DACB; Wed, 9 Jul 2008 11:29:24 +0200 (CEST) Date: Wed, 9 Jul 2008 11:29:24 +0200 From: Stephane Bortzmeyer To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= /DNSEXT chair Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Message-ID: <20080709092924.GB24127@nic.fr> References: <200806262033.m5QKXJxA036876@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200806262033.m5QKXJxA036876@ogud.com> X-Operating-System: Debian GNU/Linux lenny/sid X-Kernel: Linux 2.6.24-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jun 26, 2008 at 04:33:14PM -0400, Ólafur Guðmundsson /DNSEXT chair wrote a message of 28 lines which said: > This note starts a Working Group Last Call for this Standards Track > document ending on noon July 12'th 2006 (Dublin time). Shouldn't we postpone the WGLC to integrate in the I-D the current alarm? -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 9 03:15:29 2008 Return-Path: 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 7ED4B3A6A79; Wed, 9 Jul 2008 03:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] 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 zsRqhWoa2Ehc; Wed, 9 Jul 2008 03:15:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9C82C3A6A23; Wed, 9 Jul 2008 03:15:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGWcF-0006RF-28 for namedroppers-data@psg.com; Wed, 09 Jul 2008 10:09:39 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGWbv-0006Os-7F for namedroppers@ops.ietf.org; Wed, 09 Jul 2008 10:09:21 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KGWbk-00059x-CJ; Wed, 09 Jul 2008 12:09:08 +0200 Received: from fweimer by bfk.de with local id 1KGWbq-00038T-4V; Wed, 09 Jul 2008 12:09:14 +0200 To: Stephane Bortzmeyer Cc: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= /DNSEXT chair , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" References: <200806262033.m5QKXJxA036876@ogud.com> <20080709092924.GB24127@nic.fr> From: Florian Weimer Date: Wed, 09 Jul 2008 12:09:14 +0200 In-Reply-To: <20080709092924.GB24127@nic.fr> (Stephane Bortzmeyer's message of "Wed, 9 Jul 2008 11:29:24 +0200") Message-ID: <82skujmks5.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Stephane Bortzmeyer: > Shouldn't we postpone the WGLC to integrate in the I-D the current > alarm? If you'd make that the *cause* of the current alarm, I tend to agree. On the other hand, I think it's unfair to delay the process by yet another month (after which we still have to agree on the exact wording). --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 9 03:37:46 2008 Return-Path: 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 2B6013A6A4F; Wed, 9 Jul 2008 03:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 VBrG6vvdelmP; Wed, 9 Jul 2008 03:37:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 515703A6A23; Wed, 9 Jul 2008 03:37:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGWxf-0008d4-JY for namedroppers-data@psg.com; Wed, 09 Jul 2008 10:31:47 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGWxb-0008cS-J4 for namedroppers@ops.ietf.org; Wed, 09 Jul 2008 10:31:45 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id EC5FAC2DA3; Wed, 9 Jul 2008 11:31:37 +0100 (BST) Date: Wed, 09 Jul 2008 11:31:27 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Florian Weimer , Stephane Bortzmeyer cc: =?UTF-8?Q?=C3=93lafur_Gu=C3=B0mundsson_=2FDNSEXT_chair?= , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Message-ID: <3CF3FED5D9A2C76CACCD3382@Ximines.local> In-Reply-To: <82skujmks5.fsf@mid.bfk.de> References: <200806262033.m5QKXJxA036876@ogud.com> <20080709092924.GB24127@nic.fr> <82skujmks5.fsf@mid.bfk.de> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 9 July 2008 12:09:14 +0200 Florian Weimer wrote: > If you'd make that the *cause* of the current alarm, I tend to agree. > On the other hand, I think it's unfair to delay the process by yet > another month (after which we still have to agree on the exact > wording). As far as I can see, even if the draft does not document the precise threat model illustrated by the current alarm (which are apparently not yet fully public anyway), the recommendations resulting from it are correct in the draft - with the possible exception of the TTL comment which I now understand better. Alex -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 9 05:14:09 2008 Return-Path: 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 E09423A6897; Wed, 9 Jul 2008 05:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 9mfwjif+l12x; Wed, 9 Jul 2008 05:14:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D833C3A6950; Wed, 9 Jul 2008 05:14:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGYSB-000HZe-LY for namedroppers-data@psg.com; Wed, 09 Jul 2008 12:07:23 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGYS6-000HYf-GB for namedroppers@ops.ietf.org; Wed, 09 Jul 2008 12:07:21 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m69C7Efe020196; Wed, 9 Jul 2008 14:07:16 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200807091207.m69C7Efe020196@givry.fdupont.fr> From: Francis Dupont To: Paul Hoffman cc: namedroppers@ops.ietf.org Subject: Re: Logical inconsistencies in draft-ietf-dnsext-tsig-md5-deprecated-00.txt In-reply-to: Your message of Tue, 08 Jul 2008 08:07:15 PDT. Date: Wed, 09 Jul 2008 14:07:13 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: The well-received paper, => if you think it should be a good idea to add a reference to this paper, just ask. IMHO we should avoid the I-D be used to FUD HMAC-MD5, and further HMAC-SHA1... Thanks Francis.Dupont@fdupont.fr -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 9 07:21:59 2008 Return-Path: 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 77ABF3A6AAF; Wed, 9 Jul 2008 07:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 o68jTPxoaF+j; Wed, 9 Jul 2008 07:21:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5E7503A6AB3; Wed, 9 Jul 2008 07:20:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGaN5-0003gP-OB for namedroppers-data@psg.com; Wed, 09 Jul 2008 14:10:15 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGaMl-0003dp-L7 for namedroppers@ops.ietf.org; Wed, 09 Jul 2008 14:10:07 +0000 Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m69E9pAq064321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2008 07:09:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200807091207.m69C7Efe020196@givry.fdupont.fr> References: <200807091207.m69C7Efe020196@givry.fdupont.fr> Date: Wed, 9 Jul 2008 07:09:49 -0700 To: Francis Dupont From: Paul Hoffman Subject: Re: Logical inconsistencies in draft-ietf-dnsext-tsig-md5-deprecated-00.txt Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 2:07 PM +0200 7/9/08, Francis Dupont wrote: > In your previous mail you wrote: > > The well-received paper, > >=> if you think it should be a good idea to add a reference to this paper, >just ask. IMHO we should avoid the I-D be used to FUD HMAC-MD5, and >further HMAC-SHA1... There is no need to reference the paper if we don't try to pretend that HMAC-MD5 has any actual problems. --Paul Hoffman, Director --VPN Consortium -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 9 10:08:43 2008 Return-Path: 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 13BFE28C1E7; Wed, 9 Jul 2008 10:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 p7qh3CipyYBm; Wed, 9 Jul 2008 10:08:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F034D28C1DC; Wed, 9 Jul 2008 10:08:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGcyN-000KPS-NQ for namedroppers-data@psg.com; Wed, 09 Jul 2008 16:56:55 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGcyD-000KOM-4P for namedroppers@ops.ietf.org; Wed, 09 Jul 2008 16:56:53 +0000 Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m69GuePU078608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2008 09:56:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200807091207.m69C7Efe020196@givry.fdupont.fr> References: <200807091207.m69C7Efe020196@givry.fdupont.fr> Date: Wed, 9 Jul 2008 09:56:38 -0700 To: Francis Dupont From: Paul Hoffman Subject: Re: Logical inconsistencies in draft-ietf-dnsext-tsig-md5-deprecated-00.txt Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: The following is a proposed rewording. This is the proposal for the *entire* document. Note the title and document name are changed to correctly reflect the content. --Pal Hoffman Status Change for HMAC-MD5 in DNS TSIG Resource Records draft-ietf-dnsext-tsig-hmac-md5-optional-00.txt Abstract This document changes the status of the use of HMAC-MD5 as an algorithm for the TSIG (secret key transaction authentication) resource record in the DNS (domain name system) from mandatory to optional. 1. Introduction The secret key transaction authentication for DNS (TSIG, [RFC2845]) was defined with the HMAC-MD5 [RFC2104] cryptographic algorithm. [RFC4635] defines new TSIG algorithms based on the HMACs using the SHA family of hash algorithms. This document changes the requirements status of HMAC-MD5 from mandatory to optional. 2. Requirments Status RFC 4635 has the requirements statuses listed as: Mandatory HMAC-MD5.SIG-ALG.REG.INT Optional gss-tsig Mandatory hmac-sha1 Optional hmac-sha224 Mandatory hmac-sha256 Optional hamc-sha384 Optional hmac-sha512 Upon adoption of this document, those statuses change to: Optional HMAC-MD5.SIG-ALG.REG.INT Optional gss-tsig Mandatory hmac-sha1 Optional hmac-sha224 Mandatory hmac-sha256 Optional hamc-sha384 Optional hmac-sha512 3. Security Considerations The HMAC-MD5 algorithm protects the secret key with 128 bits of effective strength. Environments that need more than this level of security, or where the HMAC-MD5 algorithm is not allowed, can use the HMAC-SHA1 or HMAC-SHA256 algorithms, both of which are mandatory to implement for this specification. 8. References 8.1. Normative References [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC4635] Eastlake, D., "HMAC SHA TSIG Algorithm Identifiers", RFC 4635, August 2006. 8.2. Informative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [Boilerplate] -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 9 11:39:42 2008 Return-Path: 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 41C283A680D; Wed, 9 Jul 2008 11:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 Qb1mqxlLMyJb; Wed, 9 Jul 2008 11:39:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 28C8F3A6B36; Wed, 9 Jul 2008 11:39:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGeS2-0004FS-B7 for namedroppers-data@psg.com; Wed, 09 Jul 2008 18:31:38 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGeRw-0004Ea-C5 for namedroppers@ops.ietf.org; Wed, 09 Jul 2008 18:31:36 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KGeRr-0000MU-Io for namedroppers@ops.ietf.org; Wed, 09 Jul 2008 20:31:27 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id C65124044; Wed, 9 Jul 2008 20:31:41 +0200 (CEST) Date: Wed, 9 Jul 2008 20:31:41 +0200 From: bert hubert To: Florian Weimer Cc: Stephane Bortzmeyer , ?lafur Gu?mundsson /DNSEXT chair , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Message-ID: <20080709183141.GG19752@outpost.ds9a.nl> References: <200806262033.m5QKXJxA036876@ogud.com> <20080709092924.GB24127@nic.fr> <82skujmks5.fsf@mid.bfk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82skujmks5.fsf@mid.bfk.de> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jul 09, 2008 at 12:09:14PM +0200, Florian Weimer wrote: > > Shouldn't we postpone the WGLC to integrate in the I-D the current > > alarm? > > If you'd make that the *cause* of the current alarm, I tend to agree. > On the other hand, I think it's unfair to delay the process by yet > another month (after which we still have to agree on the exact > wording). The draft stands on its own merits. I can ammend the formulae with a note that there are tricks that make the math very optimistic, which only strengthens the case. As far as I know, but I don't know everything, there is nothing more specific to be done against Dan's issue than what is already in the draft. I'm aware of the details of what Dan has discovered, but it might be that someone has discovered something even smarter to counteract it. If this is so, that might be reason to stall the draft until after Dan's announcement, and only then incorporate the countermeasures publicly. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 10 05:57:40 2008 Return-Path: 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 50A2C3A67EB; Thu, 10 Jul 2008 05:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] 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 TiXOxxBrbADR; Thu, 10 Jul 2008 05:57:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D537C3A6809; Thu, 10 Jul 2008 05:57:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGvXv-0003Wn-TV for namedroppers-data@psg.com; Thu, 10 Jul 2008 12:46:51 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGvXg-0003UR-My for namedroppers@ops.ietf.org; Thu, 10 Jul 2008 12:46:50 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KGvXO-0004fA-U5; Thu, 10 Jul 2008 14:46:18 +0200 Received: from fweimer by bfk.de with local id 1KGvXU-0006tO-J5; Thu, 10 Jul 2008 14:46:24 +0200 To: Paul Hoffman Cc: Francis Dupont , namedroppers@ops.ietf.org Subject: Re: Logical inconsistencies in draft-ietf-dnsext-tsig-md5-deprecated-00.txt References: <200807071523.m67FN5DR007146@givry.fdupont.fr> <82y74cvdmj.fsf@mid.bfk.de> <821w24tn2d.fsf@mid.bfk.de> From: Florian Weimer Date: Thu, 10 Jul 2008 14:46:24 +0200 In-Reply-To: (Paul Hoffman's message of "Tue, 8 Jul 2008 12:39:10 -0700") Message-ID: <82mykphppb.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Paul Hoffman: >>The problem is that the traditional threat model for MACs simply does >>not consider chosen-plaintext attacks. I think this is still true, but ... > If you thing that is a problem with the paper in question, you should > take that to the author of the paper. It is a well-received paper by a > leader in the crypto community. Given the construction of HMACs, and > the conclusion of the paper that the collision-resistance of the > underlying hash function is actually not needed for the security > proof, asserting that chosen-plaintext attacks are somehow relevant > would certainly need a fair amount of supporting evidence. ... I was mistaken about the strength of the MD5 attacks published so far. D'oh! Given that, I agree that it deprecating HMAC-MD5 is premature, but the three octets "MD5" are unfortunately tainted forever. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 10 08:16:58 2008 Return-Path: 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 4F3053A6A39; Thu, 10 Jul 2008 08:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 YZP5j5-e79Zs; Thu, 10 Jul 2008 08:16:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6BACE3A685A; Thu, 10 Jul 2008 08:15:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGxjQ-000Hz8-F3 for namedroppers-data@psg.com; Thu, 10 Jul 2008 15:06:52 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KGxjM-000Hyb-Jn for namedroppers@ops.ietf.org; Thu, 10 Jul 2008 15:06:50 +0000 Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6AF6bSp096923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jul 2008 08:06:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <82mykphppb.fsf@mid.bfk.de> References: <200807071523.m67FN5DR007146@givry.fdupont.fr> <82y74cvdmj.fsf@mid.bfk.de> <821w24tn2d.fsf@mid.bfk.de> <82mykphppb.fsf@mid.bfk.de> Date: Thu, 10 Jul 2008 07:57:50 -0700 To: Florian Weimer From: Paul Hoffman Subject: Re: Logical inconsistencies in draft-ietf-dnsext-tsig-md5-deprecated-00.txt Cc: Francis Dupont , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 2:46 PM +0200 7/10/08, Florian Weimer wrote: >... I was mistaken about the strength of the MD5 attacks published so >far. D'oh! It is not the strength: it is the type of protection. If you need collision-resistance, you can probably safely assume that MD5 is too weak for anything, and getting weaker all the time. If you need preimage strength, MD5 is still untouched at 128 bits, and there haven't even been strong hints of any preimage weakness even though, post-Wang, there has been a huge amount of effort by people who want to be the first to show an attack. >Given that, I agree that it deprecating HMAC-MD5 is premature, but the >three octets "MD5" are unfortunately tainted forever. Not if we don't spread the FUD. It's really not that hard. Hashes have three properties (there are actually two types of preimages), and only one has been found weak in MD5 and SHA1. Things that don't use that property are not affected by the weakness of the property. --Paul Hoffman, Director --VPN Consortium -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 10 11:14:31 2008 Return-Path: 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 7D9323A6819; Thu, 10 Jul 2008 11:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 xeL6ouQb8xIn; Thu, 10 Jul 2008 11:14:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9DFCB3A67A3; Thu, 10 Jul 2008 11:14:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KH0W4-000A7S-Vg for namedroppers-data@psg.com; Thu, 10 Jul 2008 18:05:16 +0000 Received: from [66.92.146.160] (helo=mail.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KH0Vy-000A6g-AP for namedroppers@ops.ietf.org; Thu, 10 Jul 2008 18:05:15 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by mail.ogud.com (8.13.1/8.13.1) with ESMTP id m6AI57u8003335 for ; Thu, 10 Jul 2008 14:05:07 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id m6AI57u1003334 for namedroppers@ops.ietf.org; Thu, 10 Jul 2008 14:05:07 -0400 (EDT) (envelope-from namedroppers) 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 ) id 1KGb5L-000854-Mp for namedroppers@ops.ietf.org; Wed, 09 Jul 2008 14:56:02 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 86D4CA1049; Wed, 9 Jul 2008 14:55:51 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Stephane Bortzmeyer cc: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= /DNSEXT chair , namedroppers@ops.ietf.org In-Reply-To: Your message of "Wed, 09 Jul 2008 11:29:24 +0200." <20080709092924.GB24127@nic.fr> References: <200806262033.m5QKXJxA036876@ogud.com> <20080709092924.GB24127@nic.fr> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Wed, 09 Jul 2008 14:55:51 +0000 Message-ID: <17430.1215615351@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 86D4CA1049.5D6DA X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] > Shouldn't we postpone the WGLC to integrate in the I-D the current alarm? the recommendations in the draft cover the current alarm, and i say this with some awareness of the underlying cause of that alarm which won't be publically disclosed by dan until blackhat/defcon. i do not think we can add value to this document by delaying or editing it further. however, i had suggested a major replacement of text, based on the desire by some that this document be a STD rather than a BCP. i've seen no resolution there. so, WGLC has stalled or failed, but not because of the current alarm. -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 10 13:39:10 2008 Return-Path: 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 766963A68BD; Thu, 10 Jul 2008 13:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] 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 xZwDnFagUSiG; Thu, 10 Jul 2008 13:39:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8B0ED3A67FE; Thu, 10 Jul 2008 13:39:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KH2li-000OmG-5C for namedroppers-data@psg.com; Thu, 10 Jul 2008 20:29:34 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KH2le-000OlI-5R for namedroppers@ops.ietf.org; Thu, 10 Jul 2008 20:29:32 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KH2lT-0000Yt-HC; Thu, 10 Jul 2008 22:29:19 +0200 Received: from fweimer by bfk.de with local id 1KH2lZ-00054G-CF; Thu, 10 Jul 2008 22:29:25 +0200 To: bert hubert Cc: Stephane Bortzmeyer , ?lafur Gu?mundsson /DNSEXT chair , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" References: <200806262033.m5QKXJxA036876@ogud.com> <20080709092924.GB24127@nic.fr> <82skujmks5.fsf@mid.bfk.de> <20080709183141.GG19752@outpost.ds9a.nl> From: Florian Weimer Date: Thu, 10 Jul 2008 22:29:25 +0200 In-Reply-To: <20080709183141.GG19752@outpost.ds9a.nl> (bert hubert's message of "Wed, 9 Jul 2008 20:31:41 +0200") Message-ID: <82prpleb4q.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * bert hubert: > The draft stands on its own merits. I agree, I think it's really helpful. If you want to proceed, you should. (I'm not familiar with the IETF processes, so I let others to sort out the procedural issue Paul has raised. However, I think it's best to avoid any changes that cause further delays.) --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 10 15:33:47 2008 Return-Path: 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 D30393A6A22; Thu, 10 Jul 2008 15:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] 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 klhqkGwcA33M; Thu, 10 Jul 2008 15:33:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DA9523A69D5; Thu, 10 Jul 2008 15:33:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KH4bm-000AD2-HC for namedroppers-data@psg.com; Thu, 10 Jul 2008 22:27:26 +0000 Received: from [66.92.146.160] (helo=mail.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KH4bQ-000AAy-EQ for namedroppers@ops.ietf.org; Thu, 10 Jul 2008 22:27:15 +0000 Received: from Puki.ogud.com (ns.md.ogud.com [10.20.30.6]) by mail.ogud.com (8.13.1/8.13.1) with ESMTP id m6AMR3BT005560 for ; Thu, 10 Jul 2008 18:27:03 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200807102227.m6AMR3BT005560@mail.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 10 Jul 2008 18:25:14 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: Question on BCP vs Standard (Was Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers") In-Reply-To: <200806262033.m5QKXJxA036876@ogud.com> References: <200806262033.m5QKXJxA036876@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear Colleagues, We seem to have at this point enough reviewers. Minor issue: The draft says it is updating RFC1034 that should be RFC1035. Major issue has been raised: Standards Track or BCP. At this point there is no consensus one way or the other. The overall effect is limited to section 9 (Recommendations) as it is today is written for standards track. http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience-05#section-9 It has been argued that source port selection is not per say a standards issue as it does not affect interoperabilty. Simple Boolean Question: Does the requirement that answer match all of the following warrant a standards action? Background: RFC1035 section 4.2.1 is silent on if the answer should come from the same address and port that the question was sent to. Thus it can argued that any message that matches is all that is needed. Once we have resolved the status question, section 9 can be tuned to the appropriate status. Olafur -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 10 17:28:34 2008 Return-Path: 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 5B7333A6A6A; Thu, 10 Jul 2008 17:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 dUiTjA+6jKFg; Thu, 10 Jul 2008 17:28:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7178F3A6847; Thu, 10 Jul 2008 17:28:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KH6P6-000JTW-Ts for namedroppers-data@psg.com; Fri, 11 Jul 2008 00:22:28 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KH6P2-000JSj-LX for namedroppers@ops.ietf.org; Fri, 11 Jul 2008 00:22:26 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m6B0MHli028658; Fri, 11 Jul 2008 10:22:18 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200807110022.m6B0MHli028658@drugs.dv.isc.org> To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Question on BCP vs Standard (Was Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers") In-reply-to: Your message of "Thu, 10 Jul 2008 18:25:14 -0400." <200807102227.m6AMR3BT005560@mail.ogud.com> Date: Fri, 11 Jul 2008 10:22:17 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > Dear Colleagues, > > We seem to have at this point enough reviewers. > > Minor issue: The draft says it is updating RFC1034 that should be RFC1035. > > Major issue has been raised: Standards Track or BCP. > > At this point there is no consensus one way or the other. > > The overall effect is limited to section 9 (Recommendations) as it > is today is written for standards track. > http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience-05#section-9 > > It has been argued that source port selection is not per say a standards > issue as it does not affect interoperabilty. > > Simple Boolean Question: > Does the requirement that answer match all of the following > > warrant a standards action? > > Background: RFC1035 section 4.2.1 is silent on if the answer should > come from the same > address and port that the question was sent to. Thus it can argued that any > message that matches is all that is needed. Look at the UDP specification. It says that reply traffic should come from the same port and address that the request was sent to. > Once we have resolved the status question, section 9 can be tuned to the > appropriate status. > > Olafur > > > > -- > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 11 06:20:34 2008 Return-Path: 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 8EAB028C0FB; Fri, 11 Jul 2008 06:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] 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 LdCPL2gG-MPy; Fri, 11 Jul 2008 06:20:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC2DB3A69D6; Fri, 11 Jul 2008 06:20:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KHILt-000HUO-01 for namedroppers-data@psg.com; Fri, 11 Jul 2008 13:07:57 +0000 Received: from [83.246.72.252] (helo=gurgel.gson.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KHILp-000HTR-1c for namedroppers@ops.ietf.org; Fri, 11 Jul 2008 13:07:55 +0000 Received: from guava.gson.org (a91-152-79-33.elisa-laajakaista.fi [91.152.79.33]) by gurgel.gson.org (Postfix) with ESMTP id C552C7C8CC; Fri, 11 Jul 2008 13:07:46 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id 3A2D675F69; Fri, 11 Jul 2008 16:07:46 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <18551.23330.217711.376098@guava.gson.org> Date: Fri, 11 Jul 2008 16:07:46 +0300 To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Cc: namedroppers@ops.ietf.org Subject: Question on BCP vs Standard (Was Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers") In-Reply-To: Re: <200807102227.m6AMR3BT005560@mail.ogud.com> References: <200806262033.m5QKXJxA036876@ogud.com> <200807102227.m6AMR3BT005560@mail.ogud.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: gson@araneus.fi (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: =D3lafur Gu=F0mundsson /DNSEXT chair wrote: > Simple Boolean Question: > Does the requirement that answer match all of the following > > warrant a standards action=3F >=20 > Background: RFC1035 section 4.2.1 is silent on if the answer should=20= > come from the same > address and port that the question was sent to. Thus it can argued th= at any > message that matches is all that is neede= d. RFC1035 may be silent, but RFC2181 is loud and clear. Section 4.1: [...] servers when responding to queries using UDP must cause the reply to be sent with the source address field in the= IP header set to the address that was in the destination address field of the IP header of the packet containing the query causing th= e response. Section 4.2: Replies should always be sent from the port to which they were directed. The "should" above is really a MUST because of the somewhat unusual terminology defined in section 3. --=20 Andreas Gustafsson, gson@araneus.fi -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 11 17:52:21 2008 Return-Path: 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 19F8E3A6A36; Fri, 11 Jul 2008 17:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 dpb0ERB-qE8N; Fri, 11 Jul 2008 17:52:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 09F723A6927; Fri, 11 Jul 2008 17:52:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KHTDK-000GOJ-Hy for namedroppers-data@psg.com; Sat, 12 Jul 2008 00:43:50 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KHTDD-000GNZ-FT for namedroppers@ops.ietf.org; Sat, 12 Jul 2008 00:43:48 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 2E4EBFF28E for ; Sat, 12 Jul 2008 10:43:44 +1000 (EST) Message-ID: <4877FDE0.1080706@e164.org> Date: Sat, 12 Jul 2008 10:42:08 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: DNS Encryption 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: I've been trying to get feed back on DNS encryption for months now and nearly all the comments have related to spelling or grammar, some one suggested writing an Internet Draft on it and I'd be more likely to get feed back so I've done just that. Well attempted to anyway, I've never written or submitted anything before so this is all new to me, but I'd very much appreciate any and all feed back on the technical merits of my proposal as I don't know if this is the best way to do it or not and no one else seems to be able to suggest otherwise. http://www.ietf.org/internet-drafts/draft-groth-dns-encryption-00.txt -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 12 04:25:34 2008 Return-Path: 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 B7CBC3A6A91; Sat, 12 Jul 2008 04:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[AWL=-1.450, 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] 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 wBNSrVdYjzbW; Sat, 12 Jul 2008 04:25:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8D5503A6A30; Sat, 12 Jul 2008 04:25:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KHd61-000Nxl-Vq for namedroppers-data@psg.com; Sat, 12 Jul 2008 11:16:57 +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 ) id 1KHd5p-000NwJ-1K for namedroppers@ops.ietf.org; Sat, 12 Jul 2008 11:16:55 +0000 Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1KHd5l-0006EO-VL; Sat, 12 Jul 2008 13:16:42 +0200 Received: from localhost by x27.adm.denic.de with local id 1KHd4h-0006P8-Tg; Sat, 12 Jul 2008 13:15:35 +0200 Date: Sat, 12 Jul 2008 13:15:35 +0200 From: Peter Koch To: IETF DNSEXT WG Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Message-ID: <20080712111535.GA22518@x27.adm.denic.de> References: <200806262033.m5QKXJxA036876@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200806262033.m5QKXJxA036876@ogud.com> User-Agent: Mutt/1.4.2.3i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > This document updates and clarifies RFC1034 in how a resolver should > generate > random query ID, how to use multiple ports and possibly addresses to make > it harder to guess the details of a query by a particular resolver. > > Please read the document carefully, in particular section 9. At this point > the chairs would like to know if the current RFC2119 wording in that > section is acceptable or how it can be improved. I have read version 5 of the forgery resilience draft. The remarks here are follow ups to my review of version -03 . I've also read the WGLC discussion, but did not follow all proposed and/or preliminary changes in the text, so there might be duplications here, with apologies. Generally I support this draft moving forward. I maintain my position that BCP is more appropriate than standards track, because the draft does not change "on-the-wire" behaviour beyond what 1034/5 and the subsequent clarifications in 1123 and 2181 say. Instead it recommends (for the sending side) to exploit a degree of freedom that has always been in the protocol. I see no way elevating this on standrads track based on interoperability tests. I have no issues with the normative language in section 9 though, with one exception (see below). However, the draft has some terminology issues that should be fixed and there are security aspects in the deployment of this recommendation that need to be mentioned (below). ----------------------------------------------------------------------------- doc walk through: Introduction: 1st paragraph, self-reference: s/this RFC/this document/ last paragraph I support changing "For protocol extensions under development" to leave out "under development". NITs: s/RRSET/RRSet/g s/IPSEC/IPsec/g Section 4.1: Forcing a _query_, some other occurences where "question" should be replaced with "query", same in 4.5 Section 5: An attacker can benefit from this exact phenomenon if it can force the target resolver to have multiple equivalent outstanding queries at any one time to the same authoritative server. ... where "equivalent" means that QNAME/QTYPE/QCLASS are identical. Section 6: > 6. Accepting only in-zone records That should be "in-domain", because the resolver can't tell the zone boundaries. If accepted uncritically, the resolver stands the chance of accepting data from an untrusted source. Care must be taken to only accept data if it is known that the originator is authoritative for that data. ... authoritative for the QNAME or a parent of the QNAME. Same reason: zone cuts are invisible. IMHO the document could benefit from an example here (see my earlier posting for a suggestion). Section 7: = 65000 packets, assuming a domain has 2 authoritative nameservers. s/domain/zone/ Section 8: The calculations above indicate the relative ease with which DNS data can be spoofed. For example, using the formula derived earlier on a domain with a 3600 second TTL, an attacker sending 7000 fake response packets/s (a rate of 4.5Mb/s), stands a 10% chance of spoofing a record in the first 24 hours, which rises to 50% after a week. For a domain with a TTL of 60 seconds, the 10% level is hit after 24 minutes, 50% after less than 3 hours, 90% after around 9 hours. Domains don't have TTLs, so s/domain/RRSet/ (in both paragraphs). Section 9: address MUST match the query's source IP address. A mismatch should be considered a format error, and the response invalid. How should the resolver treat an "invalid" response? I'd guess silently dropping it and waiting for the next would be preferrable over sending FORMERR to the querying client? o Use an unpredictable source port for outgoing queries from the range (53, or > 1024) of available ports that is as large as possible and practicable; typo: >= 1024 In case these abilities are enabled, the implementation MUST strive to have its choices of source port and query ID remain unpredictable, That's the normative language I think could be improved - independent of BCP vs. standards track: "MUST strive" implies "nice try". "MUST minimize the predictablity ... " or similar would get rid of these connotations. > 10. Security Considerations The mutual effect of source port randomization on forewalls and NATs has been mentioned before. If nothing more, the security considerations must mention that ... "The effects of source port randomization may be dramatically reduced by NAT devices which either serialize or limit in volume the UDP source ports used by the querying resolver." ----------------------------------------------------------------------------- As said before, sections 7 and 8 are of purely educational nature and would better fit in an appendix. I'd consider it slightly less important for a BCP, though. Finally, since there has been a lot of discussion and a significant number of changes in WGLC, I'd humbly ask the chairs to give reviewers another week after the publication of -06 to check all the changes in context. -Peter -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 12 05:08:28 2008 Return-Path: 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 6FE423A686E; Sat, 12 Jul 2008 05:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.895 X-Spam-Level: X-Spam-Status: No, score=-101.895 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 8zz0Orb-4PMC; Sat, 12 Jul 2008 05:08:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8FB8B3A68AC; Sat, 12 Jul 2008 05:08:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KHdnr-0002EO-0i for namedroppers-data@psg.com; Sat, 12 Jul 2008 12:02:15 +0000 Received: from [2001:14b0:202:1::a7] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KHdnn-0002DV-3o for namedroppers@ops.ietf.org; Sat, 12 Jul 2008 12:02:13 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1KHdnK-0008Si-Qv; Sat, 12 Jul 2008 14:01:42 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1KHdnK-0006Im-C2; Sat, 12 Jul 2008 14:01:42 +0200 From: Florian Weimer To: Duane Cc: namedroppers@ops.ietf.org Subject: Re: DNS Encryption References: <4877FDE0.1080706@e164.org> Date: Sat, 12 Jul 2008 14:01:42 +0200 In-Reply-To: <4877FDE0.1080706@e164.org> (duane@e164.org's message of "Sat, 12 Jul 2008 10:42:08 +1000") Message-ID: <87skufia55.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > I've been trying to get feed back on DNS encryption for months now and > nearly all the comments have related to spelling or grammar, some one > suggested writing an Internet Draft on it and I'd be more likely to get > feed back so I've done just that. Well attempted to anyway, I've never > written or submitted anything before so this is all new to me, but I'd > very much appreciate any and all feed back on the technical merits of my > proposal as I don't know if this is the best way to do it or not and no > one else seems to be able to suggest otherwise. > > http://www.ietf.org/internet-drafts/draft-groth-dns-encryption-00.txt The document lacks a clear threat model and problem statement. As a result, is not possible to check whether the proposed protocol actually solves anything. Sections 2 and 3 do not really describe the on-the-wire protocol. CERT Glue records (section 4) won't work without changing all recursors (and probably authoritative servers, too). This means that this proposal has near zero chance of deployment. As far as I can see, the proposed protocol, if worked out in full, solves two problems (data leaks across the hierarchy and eavesdropping on the wire) but doesn't do anything about enumeration and information leaks from caching resolvers. -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 12 05:43:45 2008 Return-Path: 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 CA9193A6B59; Sat, 12 Jul 2008 05:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.456 X-Spam-Level: X-Spam-Status: No, score=-1.456 tagged_above=-999 required=5 tests=[AWL=-0.961, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 RDGjvdS1M8zD; Sat, 12 Jul 2008 05:43:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AFC9B3A6B4A; Sat, 12 Jul 2008 05:43:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KHeNb-0005wg-TW for namedroppers-data@psg.com; Sat, 12 Jul 2008 12:39:11 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KHeNY-0005w8-3U for namedroppers@ops.ietf.org; Sat, 12 Jul 2008 12:39:09 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id E4503FF26F; Sat, 12 Jul 2008 22:39:06 +1000 (EST) Message-ID: <4878A586.4010403@e164.org> Date: Sat, 12 Jul 2008 22:37:26 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Florian Weimer CC: namedroppers@ops.ietf.org Subject: Re: DNS Encryption References: <4877FDE0.1080706@e164.org> <87skufia55.fsf@mid.deneb.enyo.de> In-Reply-To: <87skufia55.fsf@mid.deneb.enyo.de> 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: Florian Weimer wrote: > The document lacks a clear threat model and problem statement. As a > result, is not possible to check whether the proposed protocol actually > solves anything. I had several things listed but they were removed by suggestion of Paul Vixie as he felt the conversation would be distracted by that rather than the draft or similar proposal. > Sections 2 and 3 do not really describe the on-the-wire protocol. What was lacking? > CERT Glue records (section 4) won't work without changing all recursors > (and probably authoritative servers, too). This means that this > proposal has near zero chance of deployment. With all the changes needed to facilitate DNSsec, and people still pushing ahead trying to get it deployed I fail to see why this would be a sticking point. I've had a rethink on this due to hitting 512 byte boundaries today with mutliple host keys causing issues for cache servers that don't speak EDNS and listing the fingerprint seems to be a better idea, especially since OpenPGP keys can be cached, there will be a small delay the first time a key needs to be found but after that the local keyring could be used. > As far as I can see, the proposed protocol, if worked out in full, > solves two problems (data leaks across the hierarchy and eavesdropping > on the wire) but doesn't do anything about enumeration and information > leaks from caching resolvers. There is no way this would prevent enumeration any more than SMTP-TLS prevents spam, brute force attacks can be dealt with on the server by tracking IPs and/or sequential requests, but this wouldn't prevent a very clever attacker that has a large bot net that does a distributed brute force attack in a non-sequential manner. As for information leaking from caching resolvers, that depends on the programmers of the software in question and how well they implement things to prevent such leaks occurring, and/or local caching implementing something similar for end to end encryption by passing caches in the middle altogether, it really depends on how secure you need to be for your application. Not everything needs to be 100% secure all the time, although that would be nice. Thanks for your feed back. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 14 06:11:01 2008 Return-Path: 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 BFABC3A691A; Mon, 14 Jul 2008 06:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 RisQgrWrGD3U; Mon, 14 Jul 2008 06:11:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 936533A6A04; Mon, 14 Jul 2008 06:10:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KINgH-000AAU-UD for namedroppers-data@psg.com; Mon, 14 Jul 2008 13:01:29 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KINg6-000A86-Fc for namedroppers@ops.ietf.org; Mon, 14 Jul 2008 13:01:24 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m6ED18jj079866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2008 15:01:09 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <487B4E13.9070303@nlnetlabs.nl> Date: Mon, 14 Jul 2008 15:01:07 +0200 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Duane CC: namedroppers@ops.ietf.org Subject: Re: DNS Encryption References: <4877FDE0.1080706@e164.org> In-Reply-To: <4877FDE0.1080706@e164.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 14 Jul 2008 15:01:09 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Duane wrote: | I've been trying to get feed back on DNS encryption for months now and | nearly all the comments have related to spelling or grammar, some one | suggested writing an Internet Draft on it and I'd be more likely to get | feed back so I've done just that. Well attempted to anyway, I've never | written or submitted anything before so this is all new to me, but I'd | very much appreciate any and all feed back on the technical merits of my | proposal as I don't know if this is the best way to do it or not and no | one else seems to be able to suggest otherwise. | | http://www.ietf.org/internet-drafts/draft-groth-dns-encryption-00.txt | A valiant effort. I read vs -01 by the way. Section 7 was unclear how this key is represented on the wire, it starts out with 4 bytes then talks about 16 bytes of padding. You also need to say how an encrypted reply is distinguished from an error, or even noerror reply from a legacy server. I suggest using the same header as before, but QR=1. And from the 4th byte on the encrypted DNS reply message. Attached CERTs in delegations need to be optional for more deployability. If you have the OpenPGP key anyway, you can use it, even if not passed on in the delegation. State the section (authority, additional) for the CERT records. I think that the TLD labels in queries recommendation, if used lower down the tree, could see interoperability problems with current unencrypted software. Tailoring this trick to TLDs only is bad, and gets you into the 'list of registries for browsers' discussion. I think you should do the proposed label trick all the way down the DNS tree, since you need a software upgrade to do the encryption anyways. Having given some constructive comments, I think the technology is interesting, but there does not seem to be interest at this time. Thus, for a workgroup adoption the hard question is if its worth the effort vs. anyone implementing and deploying it. The problem I have is the low certainty of getting trustworthy encryption. Unless you get full deployment of certificates in delegations from parents. But is exactly what keeps DNSSEC. The ERROR opcode for a no-encryption-supported error should be picked out of the EDNS error space. Note that due to the zeroed ID fields, this error is extremely easy to spoof. Fix this by filling the outer ID field for queries and replies. Have you given thought to the size that the openpgp keyring could attain? This could hamper scalability, and some sort of purging of records may be needed. Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkh7ThIACgkQkDLqNwOhpPhEFwCgmD9Zhi6/mpl5+bHc2yEM0J/s o44Anj7RnWJqewxcQg+CQFa1LPP4vYUX =gWUX -----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: From owner-namedroppers@ops.ietf.org Mon Jul 14 09:37:30 2008 Return-Path: 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 2F4DE3A6B56; Mon, 14 Jul 2008 09:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1] 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 2LkSoNe-mpY7; Mon, 14 Jul 2008 09:37:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E07F03A68BB; Mon, 14 Jul 2008 09:37:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIQyF-0007ed-Ep for namedroppers-data@psg.com; Mon, 14 Jul 2008 16:32:15 +0000 Received: from [82.68.198.190] (helo=boo.jadickinson.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIQy9-0007da-UF for namedroppers@ops.ietf.org; Mon, 14 Jul 2008 16:32:12 +0000 Received: from [192.168.1.70] (unknown [192.168.1.70]) by boo.jadickinson.co.uk (Postfix) with ESMTP id CF8AE2C7C; Mon, 14 Jul 2008 17:32:59 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=jadickinson.co.uk; s=default; t=1216053179; bh=gruyGH2whrKcqbMJ/DO8bCyXhuY0llmS6nWtJCn K1Jk=; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References; b=nySktwBYwAI1mwoy2B5X0+ekyhjWgqplqMbSz6lpCTF2ECGAYsY8W1PZluul6BCjM 4KhAMF0PVP0UIucl4ADnlO2tv8EEH99eRudsGJtDUKWCygSxApfcjsxqcmMxTy3R6rS +xBnHjYdi+ez+mXR75iMFW92bRqMPlcFM+jOX9g= Cc: Duane Message-Id: <1A9EF2F1-EE48-4861-B959-6F8BCA0EB110@jadickinson.co.uk> From: John Dickinson To: namedroppers@ops.ietf.org In-Reply-To: <4877FDE0.1080706@e164.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: DNS Encryption Date: Mon, 14 Jul 2008 17:32:08 +0100 References: <4877FDE0.1080706@e164.org> X-Mailer: Apple Mail (2.926) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 12 Jul 2008, at 01:42, Duane wrote: > > I've been trying to get feed back on DNS encryption for months now and > nearly all the comments have related to spelling or grammar, some one > suggested writing an Internet Draft on it and I'd be more likely to > get > feed back so I've done just that. Well attempted to anyway, I've never > written or submitted anything before so this is all new to me, but I'd > very much appreciate any and all feed back on the technical merits > of my > proposal as I don't know if this is the best way to do it or not and > no > one else seems to be able to suggest otherwise. > > http://www.ietf.org/internet-drafts/draft-groth-dns-encryption-00.txt Hi, You say "NAPTR records (RFC 2915, RFC 2916), a subset of DNS services, is the first of possibly many such DNS services which reveal sensitive information about the querying agent when requests are sent, regardless of any replies returned." - can you give some examples. A few of your references need updating RFC2440 Obsoleted by RFC4880 RFC2915 Obsoleted by RFC3401, RFC3402, RFC3403, RFC3404 RFC2916 Obsoleted by RFC3761 RFC3280 Obsoleted by RFC5280 John --- John Dickinson -- 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: From c.wieland@volksfestservice.de Mon Jul 14 10:11:21 2008 Return-Path: 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 CF43C28C0F4; Mon, 14 Jul 2008 10:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.95 X-Spam-Level: X-Spam-Status: No, score=-18.95 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_IPADDR=2.426, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, 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 rOgZlJpPRlZA; Mon, 14 Jul 2008 10:11:20 -0700 (PDT) Received: from pc-179-69-47-190.cm.vtr.net (pc-179-69-47-190.cm.vtr.net [190.47.69.179]) by core3.amsl.com (Postfix) with SMTP id 28D033A69AF; Mon, 14 Jul 2008 10:10:33 -0700 (PDT) X-Originating-IP: 246.64.31.48 by smtp.190.47.69.179; Mon, 14 Jul 2008 13:10:58 -0500 Message-ID: From: "Felix Abbott" Reply-To: "Felix Abbott" To: discuss-bounces@ietf.org Subject: Prestige Replicas startling replica watches for you Date: Mon, 14 Jul 2008 13:10:58 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Prestige Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://www.rrpple.com/ As you are probably aware of, Prestige Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Prestige Replicas today! http://www.rrpple.com/ From owner-namedroppers@ops.ietf.org Mon Jul 14 10:17:58 2008 Return-Path: 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 A31013A6809; Mon, 14 Jul 2008 10:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 vOuqO6UqgWcW; Mon, 14 Jul 2008 10:17:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7949428C1AE; Mon, 14 Jul 2008 10:17:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIRbm-000CVY-Q3 for namedroppers-data@psg.com; Mon, 14 Jul 2008 17:13:06 +0000 Received: from [66.92.146.160] (helo=mail.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIRbj-000CUt-2C for namedroppers@ops.ietf.org; Mon, 14 Jul 2008 17:13:04 +0000 Received: from [10.31.200.219] (mail.md.ogud.com [10.20.30.6]) by mail.ogud.com (8.13.1/8.13.1) with ESMTP id m6EHCnVN021441; Mon, 14 Jul 2008 13:12:50 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <87skufia55.fsf@mid.deneb.enyo.de> References: <4877FDE0.1080706@e164.org> <87skufia55.fsf@mid.deneb.enyo.de> Date: Mon, 14 Jul 2008 13:10:42 -0400 To: Florian Weimer From: Edward Lewis Subject: Out of the blue... Re: DNS Encryption Cc: Duane , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 14:01 +0200 7/12/08, Florian Weimer wrote: Probably quoting something else... >> http://www.ietf.org/internet-drafts/draft-groth-dns-encryption-00.txt This is the first message I've seen on this thread in namedroppers. Either I am missing mail or this is a thread jumping from somewhere else. No matter, except that the URL does not go to a document. Just reacting because a deacde of DNSSEC makes me flinch whenever I think of anyone attempting to, once again, tie crypto to DNS. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 14 10:44:30 2008 Return-Path: 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 3AAC93A6A4A; Mon, 14 Jul 2008 10:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.586 X-Spam-Level: X-Spam-Status: No, score=-0.586 tagged_above=-999 required=5 tests=[AWL=-1.487, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] 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 eRa0Ag+8l67V; Mon, 14 Jul 2008 10:44:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6CA053A6A45; Mon, 14 Jul 2008 10:44:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIS0Q-000Exj-Em for namedroppers-data@psg.com; Mon, 14 Jul 2008 17:38:34 +0000 Received: from [66.92.146.160] (helo=mail.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIS0L-000Ewv-Vl for namedroppers@ops.ietf.org; Mon, 14 Jul 2008 17:38:32 +0000 Received: from [10.31.200.219] (ns.md.ogud.com [10.20.30.6]) by mail.ogud.com (8.13.1/8.13.1) with ESMTP id m6EHcRAP021762; Mon, 14 Jul 2008 13:38:27 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Mon, 14 Jul 2008 13:38:25 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: -09 of AXFR clarify submitted Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: A new version of the AXFR draft has been sent to=20 the ID system. It's gone in as a manual=20 submission. In case I don't have this yet in the=20 acknowledgements section - a lot of the review=20 between -08 and -09 (maybe all) came from Alfred=20 H=91nes (Hoenes). When he gets to Dublin, the WG=20 should get him a beverage or two. Even if I=20 don't always accept his suggestions. ;) -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 14 11:58:30 2008 Return-Path: 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 845983A6875; Mon, 14 Jul 2008 11:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 JQmzvoAZVRgJ; Mon, 14 Jul 2008 11:58:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8246A3A67B7; Mon, 14 Jul 2008 11:58:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIT83-000N1G-E4 for namedroppers-data@psg.com; Mon, 14 Jul 2008 18:50:31 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIT7z-000N0d-LU for namedroppers@ops.ietf.org; Mon, 14 Jul 2008 18:50:29 +0000 Received: from commandprompt.com (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m6EIqf2E009538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 Jul 2008 11:52:44 -0700 Date: Mon, 14 Jul 2008 14:50:23 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Draft agenda for IETF 72 meeting Message-ID: <20080714185023.GR2324@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Mon, 14 Jul 2008 11:52:44 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, This is the current draft of the agenda for the Dublin meeting. It's also at , which is where the latest version will continue to be as I update it. If you asked me for a slot and I have overlooked you, please tell me so that I can fix it. Thanks, Andrew Agenda for the meeting of the DNS Extensions Working Group IETF 72 Dublin, IE 2008-07-31 13:00 IST 1. Minute and Jabber scribes (2 min) 2. Note Well (2 min) 13:02 3. WG status 13:04 3.1 No drafts published (?) (1 min) 3.2 IESG processing: a. draft-ietf-dnsext-2929bis (2 min) 3.3 Documents in WGLC 13:07 a. draft-ietf-dnsext-forgery-resilience (10 min) 3.4 Current WG Documents 13:17 a. draft-ietf-dnsext-dnssec-rsasha256 (10 min) b. draft-ietf-dnsext-rfc2671bis-edns0 (10 min) c. draft-ietf-dnsext-rfc2672bis-dname (10 min) d. draft-ietf-dnsext-tsig-md5-deprecated (10 min) - discuss proposal for alternate text e. draft-ietf-dnsext-axfr-clarify (10 min) f. draft-ietf-dnsext-dns-protocol-profile (see below) 3.5 Expired WG Documents 14:07 a. draft-ietf-dnsext-dnssec-bis-updates (10 min) - discuss clarification on TA handling 4. Proposed WG work 14:17 4.1 draft-crocker-dnssec-algo-signal (5 min) 4.2 dynamic zones and DNSSEC (M. Andrews) (5 min) 5. Protocol profile (15 min) 14:32 6. A.O.B 14:47 7. Close 15:57 -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 14 12:07:41 2008 Return-Path: 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 123D53A6ADF; Mon, 14 Jul 2008 12:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.207 X-Spam-Level: X-Spam-Status: No, score=-102.207 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 gsAhuxpeOcuo; Mon, 14 Jul 2008 12:07:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4536B28C26B; Mon, 14 Jul 2008 12:07:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KITHm-000O5U-8S for namedroppers-data@psg.com; Mon, 14 Jul 2008 19:00:34 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KITHh-000O4h-Sk for namedroppers@ops.ietf.org; Mon, 14 Jul 2008 19:00:31 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 7AC6A3A6AD0; Mon, 14 Jul 2008 12:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-axfr-clarify-09.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714190002.7AC6A3A6AD0@core3.amsl.com> Date: Mon, 14 Jul 2008 12:00:02 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Zone Transfer Protocol (AXFR) Author(s) : E. Lewis Filename : draft-ietf-dnsext-axfr-clarify-09.txt Pages : 14 Date : 2008-7-14 The Domain Name System standard mechanisms for maintaining coherent servers for a zone consist of three elements. One mechanism is the Authoritative Transfer (AXFR) is defined in RFC 1034 and RFC 1035. The definition of AXFR, has proven insufficient in detail, forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of the AXFR, new in the sense that is it recording an accurate definition of an interoperable AXFR mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-axfr-clarify-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-7-14115848.I-D@ietf.org> --NextPart-- -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 14 12:25:09 2008 Return-Path: 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 0EDB128C410; Mon, 14 Jul 2008 12:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.21 X-Spam-Level: X-Spam-Status: No, score=-102.21 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 u51y1zOj5FD7; Mon, 14 Jul 2008 12:25:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B2D228C36E; Mon, 14 Jul 2008 12:22:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KITWP-000PnP-CA for namedroppers-data@psg.com; Mon, 14 Jul 2008 19:15:41 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KITWD-000Ply-Mp for namedroppers@ops.ietf.org; Mon, 14 Jul 2008 19:15:31 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id EA0AF28C372; Mon, 14 Jul 2008 12:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-2929bis-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714191501.EA0AF28C372@core3.amsl.com> Date: Mon, 14 Jul 2008 12:15:01 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Domain Name System (DNS) IANA Considerations Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-2929bis-07.txt Pages : 21 Date : 2008-7-14 Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-2929bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-7-14120532.I-D@ietf.org> --NextPart-- -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 14 12:49:35 2008 Return-Path: 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 361743A6BDF; Mon, 14 Jul 2008 12:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.212 X-Spam-Level: X-Spam-Status: No, score=-102.212 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 UBluBwovZDfa; Mon, 14 Jul 2008 12:49:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 20BA63A6BDA; Mon, 14 Jul 2008 12:49:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KITzJ-0003Jb-NV for namedroppers-data@psg.com; Mon, 14 Jul 2008 19:45:33 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KITzG-0003J3-17 for namedroppers@ops.ietf.org; Mon, 14 Jul 2008 19:45:31 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 0EF7C3A6B06; Mon, 14 Jul 2008 12:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D Action:draft-ietf-dnsext-dnssec-bis-updates-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714194502.0EF7C3A6B06@core3.amsl.com> Date: Mon, 14 Jul 2008 12:45:01 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Clarifications and Implementation Notes for DNSSECbis Author(s) : S. Weiler, D. Blacka Filename : draft-ietf-dnsext-dnssec-bis-updates-07.txt Pages : 11 Date : 2008-07-14 This document is a collection of minor technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as an interim repository of DNSSECbis errata. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-bis-updates-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-14123306.I-D@ietf.org> --NextPart-- -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 14 13:20:18 2008 Return-Path: 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 951EF3A6BFA; Mon, 14 Jul 2008 13:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.214 X-Spam-Level: X-Spam-Status: No, score=-102.214 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 imM4XHJa16Bj; Mon, 14 Jul 2008 13:20:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A25743A6BEA; Mon, 14 Jul 2008 13:20:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIUSO-0006pK-E3 for namedroppers-data@psg.com; Mon, 14 Jul 2008 20:15:36 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIUSH-0006od-4e for namedroppers@ops.ietf.org; Mon, 14 Jul 2008 20:15:34 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id A5C7928C1E1; Mon, 14 Jul 2008 13:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D Action:draft-ietf-dnsext-dnssec-trans-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714201501.A5C7928C1E1@core3.amsl.com> Date: Mon, 14 Jul 2008 13:15:01 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Evaluating DNSSEC Transition Mechanisms Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-trans-06.txt Pages : 16 Date : 2008-07-14 This document collects and summarizes different proposals for alternative and additional strategies for authenticated denial in DNS responses, evaluates these proposals and gives a recommendation for a way forward. It is a snapshot of the DNSEXT working group discussion of June 2004. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-trans-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-14130049.I-D@ietf.org> --NextPart-- -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 14 13:35:16 2008 Return-Path: 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 935923A6BFF; Mon, 14 Jul 2008 13:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.081 X-Spam-Level: X-Spam-Status: No, score=-1.081 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 6-yLhEx2tld8; Mon, 14 Jul 2008 13:35:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D508028C335; Mon, 14 Jul 2008 13:32:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIUdU-0007zt-33 for namedroppers-data@psg.com; Mon, 14 Jul 2008 20:27:04 +0000 Received: from [64.233.178.247] (helo=hs-out-0708.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIUdP-0007zE-Rv for namedroppers@ops.ietf.org; Mon, 14 Jul 2008 20:27:02 +0000 Received: by hs-out-0708.google.com with SMTP id z77so1627578hsz.9 for ; Mon, 14 Jul 2008 13:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=zKo8+CHCGyJMaOcAz/uSLDDL5ojpXW4eiNodi3Mfo1k=; b=vgqIGbHrFTQsLYGjPn7hlYfERJEWXdnKWy5CGb3ZCQ0OO9m3cXsSV6D+IPAGF8RYx3 XcDli9I6CnVqN2zJ0w81GXTNqEHeDo42jvBesy9/o9gg3rRCuk3ta37wWOnl/W+FxnWF erc5VERIoShmznqc1+C3+2K0KcuBUnBK29yS4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=xiOsJ+68IIOljozP0NZYFQU77T72pjU9vjGktayuan0KIC+KdxWbELuM1ZjEup+2WW ExbcErHZVWUhoLEzojx5hlZobs7jqra5moyj/iAXcvnFs4e7E4A6BxfRcXIyD/4/b2oX /DGjKzNvjR1cd7XDg8ZPfrV8bzYCvQunyIU+I= Received: by 10.100.42.4 with SMTP id p4mr10707190anp.76.1216067219082; Mon, 14 Jul 2008 13:26:59 -0700 (PDT) Received: by 10.100.92.20 with HTTP; Mon, 14 Jul 2008 13:26:59 -0700 (PDT) Message-ID: <1028365c0807141326y5f62e9acg4292f6560efeca1@mail.gmail.com> Date: Mon, 14 Jul 2008 16:26:59 -0400 From: "Donald Eastlake" To: namedroppers@ops.ietf.org Subject: Fwd: I-D ACTION:draft-ietf-dnsext-2929bis-07.txt In-Reply-To: <20080714191501.EA0AF28C372@core3.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_101049_14862078.1216067219104" References: <20080714191501.EA0AF28C372@core3.amsl.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ------=_Part_101049_14862078.1216067219104 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, This draft is based on feedback from the IETF LC, IESG and IANA comments. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com ---------- Forwarded message ---------- From: Date: 2008/7/14 Subject: I-D ACTION:draft-ietf-dnsext-2929bis-07.txt To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Domain Name System (DNS) IANA Considerations Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-2929bis-07.txt Pages : 21 Date : 2008-7-14 Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_Part_101049_14862078.1216067219104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

This draft is based on feedback from the IETF LC, IESG and IANA comments.

Thanks,
Donald
=============================
Donald E. Eastlake 3rd +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3@gmail.com

---------- Forwarded message ----------
From: <Internet-Drafts@ietf.org>
Date: 2008/7/14
Subject: I-D ACTION:draft-ietf-dnsext-2929bis-07.txt
To: i-d-announce@ietf.org
Cc: namedroppers@ops.ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

       Title           : Domain Name System (DNS) IANA Considerations
       Author(s)       : D. Eastlake 3rd
       Filename        : draft-ietf-dnsext-2929bis-07.txt
       Pages           : 21
       Date            : 2008-7-14

Internet Assigned Number Authority (IANA) parameter assignment
  considerations are specified for the allocation of Domain Name System
  (DNS) resource record types, CLASSes, operation codes, error codes,
  DNS protocol message header bits, and AFSDB resource record subtypes

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------=_Part_101049_14862078.1216067219104-- -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 14 19:25:26 2008 Return-Path: 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 E76FC3A67D9; Mon, 14 Jul 2008 19:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 k283tJCii-wN; Mon, 14 Jul 2008 19:25:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 205C33A6995; Mon, 14 Jul 2008 19:25:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIa88-000NTk-53 for namedroppers-data@psg.com; Tue, 15 Jul 2008 02:19:04 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIa84-000NTH-EN for namedroppers@ops.ietf.org; Tue, 15 Jul 2008 02:19:02 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 2466EFF33A; Tue, 15 Jul 2008 12:18:59 +1000 (EST) Message-ID: <487C0891.8080508@e164.org> Date: Tue, 15 Jul 2008 12:16:49 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: John Dickinson CC: namedroppers@ops.ietf.org Subject: Re: DNS Encryption References: <4877FDE0.1080706@e164.org> <1A9EF2F1-EE48-4861-B959-6F8BCA0EB110@jadickinson.co.uk> In-Reply-To: <1A9EF2F1-EE48-4861-B959-6F8BCA0EB110@jadickinson.co.uk> 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: John Dickinson wrote: > You say "NAPTR records (RFC 2915, RFC 2916), a subset of DNS services, > is the first of possibly many such DNS services which reveal sensitive > information about the querying agent when requests are sent, regardless > of any replies returned." - can you give some examples. At the advice of Paul Vixie I was trying to avoid commenting on this, however All NAPTR requests sent contain the full phone number you are attempting to call. There has been news reports in the US of telcos collecting the same type of information in the past. > A few of your references need updating Ok, will update those now, although I intentionally mentioned those for historical reasons, not just technical. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 14 19:25:35 2008 Return-Path: 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 4B4853A67D9; Mon, 14 Jul 2008 19:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[AWL=-0.860, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 0vCO1S6-OMbc; Mon, 14 Jul 2008 19:25:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 758D43A6995; Mon, 14 Jul 2008 19:25:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIa8g-000NXQ-6s for namedroppers-data@psg.com; Tue, 15 Jul 2008 02:19:38 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIa8c-000NWg-SK for namedroppers@ops.ietf.org; Tue, 15 Jul 2008 02:19:36 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 75F21FF33C; Tue, 15 Jul 2008 12:19:35 +1000 (EST) Message-ID: <487C08B4.6030007@e164.org> Date: Tue, 15 Jul 2008 12:17:24 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Edward Lewis CC: Florian Weimer , namedroppers@ops.ietf.org Subject: Re: Out of the blue... Re: DNS Encryption References: <4877FDE0.1080706@e164.org> <87skufia55.fsf@mid.deneb.enyo.de> In-Reply-To: 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: Edward Lewis wrote: > This is the first message I've seen on this thread in namedroppers. > Either I am missing mail or this is a thread jumping from somewhere > else. No matter, except that the URL does not go to a document. > > Just reacting because a deacde of DNSSEC makes me flinch whenever I > think of anyone attempting to, once again, tie crypto to DNS. I'm not trying to use DNSSEC info for crypto, although with all the ENUM stuff neustar is doing I would have thought you would have welcomed encryption, or are you using VPNs to accomplish this? -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 14 19:26:18 2008 Return-Path: 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 E06413A67D9; Mon, 14 Jul 2008 19:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[AWL=-0.860, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 6BXkqqSAbuKg; Mon, 14 Jul 2008 19:26:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9BFAC3A66B4; Mon, 14 Jul 2008 19:26:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIa8F-000NUT-W4 for namedroppers-data@psg.com; Tue, 15 Jul 2008 02:19:11 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIa8C-000NTu-LI for namedroppers@ops.ietf.org; Tue, 15 Jul 2008 02:19:10 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 831AAFF33A; Tue, 15 Jul 2008 12:19:09 +1000 (EST) Message-ID: <487C089A.5090301@e164.org> Date: Tue, 15 Jul 2008 12:16:58 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Edward Lewis CC: Florian Weimer , namedroppers@ops.ietf.org Subject: Re: Out of the blue... Re: DNS Encryption References: <4877FDE0.1080706@e164.org> <87skufia55.fsf@mid.deneb.enyo.de> In-Reply-To: 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: Edward Lewis wrote: > This is the first message I've seen on this thread in namedroppers. > Either I am missing mail or this is a thread jumping from somewhere > else. No matter, except that the URL does not go to a document. > > Just reacting because a deacde of DNSSEC makes me flinch whenever I > think of anyone attempting to, once again, tie crypto to DNS. I'm not trying to use DNSSEC info for crypto, although with all the ENUM stuff neustar is doing I would have thought you would have welcomed encryption, or are you using VPNs to accomplish this? -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 14 19:30:23 2008 Return-Path: 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 EB68A3A6A95; Mon, 14 Jul 2008 19:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, NORMAL_HTTP_TO_IP=0.001, RDNS_NONE=0.1] 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 3IIKZHvgu1dP; Mon, 14 Jul 2008 19:30:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 47CDF3A67D9; Mon, 14 Jul 2008 19:30:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIaET-000O5m-5x for namedroppers-data@psg.com; Tue, 15 Jul 2008 02:25:37 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIaEA-000O3g-CW for namedroppers@ops.ietf.org; Tue, 15 Jul 2008 02:25:35 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id D5170FF33D; Tue, 15 Jul 2008 12:25:19 +1000 (EST) Message-ID: <487C0A0C.3060801@e164.org> Date: Tue, 15 Jul 2008 12:23:08 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Wouter Wijngaards CC: namedroppers@ops.ietf.org Subject: Re: DNS Encryption References: <4877FDE0.1080706@e164.org> <487B4E13.9070303@nlnetlabs.nl> In-Reply-To: <487B4E13.9070303@nlnetlabs.nl> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD33BF323365E521670A4A850" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD33BF323365E521670A4A850 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Wouter Wijngaards wrote: > A valiant effort. I read vs -01 by the way. I must apologise for -01 it was a little rushed, I was trying to update it in a hurry before bed to add PKA like records into the additional section instead of the CERT records, this prevents going over 512 bytes in most cases that I've tested so far with 3 host names. > Section 7 was unclear how this key is represented on the wire, it start= s > out with 4 bytes then talks about 16 bytes of padding. Sorry about that, I think I have it much more clear about the key size and so on. > You also need to say how an encrypted reply is distinguished from an > error, or even noerror reply from a legacy server. I suggest using the > same header as before, but QR=3D1. And from the 4th byte on the encrypt= ed > DNS reply message. I incorporated this suggestion into the next revision. > Attached CERTs in delegations need to be optional for more > deployability. If you have the OpenPGP key anyway, you can use it, even= > if not passed on in the delegation. State the section (authority, > additional) for the CERT records. Yes that was a mistake, using key fingerprints only is sufficient. > I think that the TLD labels in queries recommendation, if used lower > down the tree, could see interoperability problems with current > unencrypted software. Tailoring this trick to TLDs only is bad, and get= s > you into the 'list of registries for browsers' discussion. I think you= > should do the proposed label trick all the way down the DNS tree, since= > you need a software upgrade to do the encryption anyways. If you do that you risk making unnecessary DNS lookups, which could be quite a lot in the case of NAPTR records, the ITU standard for e.164 allows up to 15 digits including the country code, and if you include the infrastructure stuff that's an extra segment, eg; 1.2.3.4.5.6.7.8.9.0.1.2.3.i.4.5.e164.arpa So there is a trade off between efficiency and confidentiality, although this could be optional, but I'm not entirely sure that would be wise. > Having given some constructive comments, I think the technology is > interesting, but there does not seem to be interest at this time. Thus,= > for a workgroup adoption the hard question is if its worth the effort > vs. anyone implementing and deploying it. Before sending out the draft I made sure it was technically feasible by making code to prove it could be done, I also plan to submit some patches to others such as www.freepbx.org in the future once the details are refined to the point that things are unlikely to change any further. > The problem I have is the low certainty of getting trustworthy > encryption. Unless you get full deployment of certificates in > delegations from parents. But is exactly what keeps DNSSEC. OpenPGP is already widely used in some circles so this is one reason why I went down this path, and there is a number of things that can easily be leveraged such as www.cacert.org and www.gswot.org rather than trying to build completely new infrastructure. > The ERROR opcode for a no-encryption-supported error should be picked > out of the EDNS error space. Note that due to the zeroed ID fields, thi= s > error is extremely easy to spoof. Fix this by filling the outer ID fiel= d > for queries and replies. I didn't consider the error aspect being spoofed, thanks for pointing that out to me, I'll fix up the next revision of the draft accordingly, yes, only the encrypted DNS packet opcode needs to be in the 3rd byte, the rest can be in the EDNS error space, I'll add some details to clarify that in the new revision. > Have you given thought to the size that the openpgp keyring could > attain? This could hamper scalability, and some sort of purging of > records may be needed. The method of storing OpenPGP keys in DNS strips all information from the key before adding it, the rest of the meta information needs to come from PGP key servers, although now that I think about it I should probably add some notes about this. I'm hoping to have a new revision published in the next few hours incorporating all the wonderful suggestions and feed back, I appreciate all the comments. --=20 Best regards, Duane --------------enigD33BF323365E521670A4A850 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIfAoMEpWoZMmo/c8RAqC0AJ9Idt8BOMxIsBVG/JLceIGv30UZogCeKbcW hsny1zBHACbpyPiQTvCzyVw= =5C2N -----END PGP SIGNATURE----- --------------enigD33BF323365E521670A4A850-- -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 14 20:28:29 2008 Return-Path: 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 6E2323A6A88; Mon, 14 Jul 2008 20:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599] 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 I2qSOcj0fRFn; Mon, 14 Jul 2008 20:28:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8D5063A6961; Mon, 14 Jul 2008 20:28:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIb8k-00048U-G0 for namedroppers-data@psg.com; Tue, 15 Jul 2008 03:23:46 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIb8g-00048D-P6 for namedroppers@ops.ietf.org; Tue, 15 Jul 2008 03:23:44 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m6F3NVSU099309; Tue, 15 Jul 2008 13:23:31 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200807150323.m6F3NVSU099309@drugs.dv.isc.org> To: Duane Cc: John Dickinson , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: DNS Encryption In-reply-to: Your message of "Tue, 15 Jul 2008 12:16:49 +1000." <487C0891.8080508@e164.org> Date: Tue, 15 Jul 2008 13:23:31 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > John Dickinson wrote: > > > You say "NAPTR records (RFC 2915, RFC 2916), a subset of DNS services, > > is the first of possibly many such DNS services which reveal sensitive > > information about the querying agent when requests are sent, regardless > > of any replies returned." - can you give some examples. > > At the advice of Paul Vixie I was trying to avoid commenting on this, > however All NAPTR requests sent contain the full phone number you are > attempting to call. There has been news reports in the US of telcos > collecting the same type of information in the past. > > > A few of your references need updating > > Ok, will update those now, although I intentionally mentioned those for > historical reasons, not just technical. > > -- > > Best regards, > Duane Just start looking up random phone numbers at random time intervals. Use the numbering plans so that you can't distingish between the random numbers and the real numbers. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 14 20:41:49 2008 Return-Path: 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 BEF9A3A67A4; Mon, 14 Jul 2008 20:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 JEuHg9C3oUUq; Mon, 14 Jul 2008 20:41:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CFC323A65A6; Mon, 14 Jul 2008 20:41:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIbMs-0005bj-5l for namedroppers-data@psg.com; Tue, 15 Jul 2008 03:38:22 +0000 Received: from [128.220.13.173] (helo=foobar.cs.jhu.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIbMo-0005b0-FV for namedroppers@ops.ietf.org; Tue, 15 Jul 2008 03:38:20 +0000 Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m6F3cFk30769; Mon, 14 Jul 2008 23:38:15 -0400 Received: from [172.24.84.28] (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with ESMTP id m6F3cBbB011808; Mon, 14 Jul 2008 23:38:11 -0400 Cc: namedroppers@ops.ietf.org Message-Id: <733AFF16-AACB-43D3-9C93-2630ACA966DC@jabberwocky.com> From: David Shaw To: Duane In-Reply-To: <487C0A0C.3060801@e164.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: DNS Encryption Date: Mon, 14 Jul 2008 23:38:11 -0400 References: <4877FDE0.1080706@e164.org> <487B4E13.9070303@nlnetlabs.nl> <487C0A0C.3060801@e164.org> X-Mailer: Apple Mail (2.926) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 14, 2008, at 10:23 PM, Duane wrote: >> Have you given thought to the size that the openpgp keyring could >> attain? This could hamper scalability, and some sort of purging of >> records may be needed. > > The method of storing OpenPGP keys in DNS strips all information from > the key before adding it, the rest of the meta information needs to > come > from PGP key servers, although now that I think about it I should > probably add some notes about this. OpenPGP keys stored in CERT records can be a bare packet (just a public key with no metadata), a revocation signature (just enough information to kill an active key) or a "transferable public key", which is specified in 2440 (and 4880) as the full public key, including user IDs, self-signatures, etc. So you have a choice whether you want to store the whole thing or not. There isn't an explanation or citation for the PKA TXT record format in the document. I also wonder what PKA gives you that the IPGP variation of CERT (which is standardized) doesn't give you? David -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 14 20:57:53 2008 Return-Path: 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 33AB63A67DD; Mon, 14 Jul 2008 20:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.285 X-Spam-Level: X-Spam-Status: No, score=-1.285 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 j3WvAbRcEMNK; Mon, 14 Jul 2008 20:57:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5CF363A67D1; Mon, 14 Jul 2008 20:57:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIbbs-0007EG-Gq for namedroppers-data@psg.com; Tue, 15 Jul 2008 03:53:52 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIbbp-0007Dm-1E for namedroppers@ops.ietf.org; Tue, 15 Jul 2008 03:53:50 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 07D26FF33D; Tue, 15 Jul 2008 13:53:50 +1000 (EST) Message-ID: <487C1EC8.20406@e164.org> Date: Tue, 15 Jul 2008 13:51:36 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: David Shaw CC: namedroppers@ops.ietf.org Subject: Re: DNS Encryption References: <4877FDE0.1080706@e164.org> <487B4E13.9070303@nlnetlabs.nl> <487C0A0C.3060801@e164.org> <733AFF16-AACB-43D3-9C93-2630ACA966DC@jabberwocky.com> In-Reply-To: <733AFF16-AACB-43D3-9C93-2630ACA966DC@jabberwocky.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: David Shaw wrote: > There isn't an explanation or citation for the PKA TXT record format in > the document. I also wonder what PKA gives you that the IPGP variation > of CERT (which is standardized) doesn't give you? Again my apologise for that, I was in a rush and I should have updated it properly before submitting a new revision, I've done that just now and it hopefully explains everything in detail. http://www.ietf.org/internet-drafts/draft-groth-dns-encryption-02.txt http://www.ietf.org/internet-drafts/draft-groth-dns-encryption-02.pdf -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 14 21:00:11 2008 Return-Path: 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 805513A6AC6; Mon, 14 Jul 2008 21:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[AWL=-0.756, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 HnSM5WM-YVNJ; Mon, 14 Jul 2008 21:00:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9C6353A6A88; Mon, 14 Jul 2008 21:00:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIbe4-0007UO-Rj for namedroppers-data@psg.com; Tue, 15 Jul 2008 03:56:08 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIbe1-0007Tx-Hw for namedroppers@ops.ietf.org; Tue, 15 Jul 2008 03:56:07 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 820FCFF33D; Tue, 15 Jul 2008 13:56:07 +1000 (EST) Message-ID: <487C1F53.4040307@e164.org> Date: Tue, 15 Jul 2008 13:53:55 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Mark Andrews CC: John Dickinson , namedroppers@ops.ietf.org Subject: Re: DNS Encryption References: <200807150323.m6F3NVSU099309@drugs.dv.isc.org> In-Reply-To: <200807150323.m6F3NVSU099309@drugs.dv.isc.org> 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: Mark Andrews wrote: > Just start looking up random phone numbers at random time > intervals. Use the numbering plans so that you can't > distingish between the random numbers and the real numbers. White noise is ok, but we are creatures of habit, and any entity capable of being in a position to monitor such things should be able to pull out repetitive numbers. There may also be consequences with false positives as well. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 14 22:24:58 2008 Return-Path: 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 D123F28C20F; Mon, 14 Jul 2008 22:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599] 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 I3WH9qUMlvrU; Mon, 14 Jul 2008 22:24:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F112528C1CA; Mon, 14 Jul 2008 22:24:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIcx9-000H2M-RN for namedroppers-data@psg.com; Tue, 15 Jul 2008 05:19:55 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIcx5-000H1f-FS for namedroppers@ops.ietf.org; Tue, 15 Jul 2008 05:19:54 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m6F5JnHh003509 for ; Tue, 15 Jul 2008 15:19:49 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200807150519.m6F5JnHh003509@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: I-D ACTION:draft-ietf-dnsext-axfr-clarify-09.txt In-reply-to: Your message of "Mon, 14 Jul 2008 12:00:02 MST." <20080714190002.7AC6A3A6AD0@core3.amsl.com> Date: Tue, 15 Jul 2008 15:19:49 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: "An AXFR client might receive a number of AXFR response messages free of an error condition before the message indicating an error is received. But once an error is reported, the AXFR client can assume that the error reporting message is the last." Last what? * message in the axfr response stream? * message on the TCP connection? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 15 07:24:32 2008 Return-Path: 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 7E4BA3A6A51; Tue, 15 Jul 2008 07:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.986 X-Spam-Level: X-Spam-Status: No, score=-0.986 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 2hKCCForRsFR; Tue, 15 Jul 2008 07:24:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 49A0F3A6995; Tue, 15 Jul 2008 07:24:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIlKG-000LHn-Ni for namedroppers-data@psg.com; Tue, 15 Jul 2008 14:16:20 +0000 Received: from [66.92.146.160] (helo=mail.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIlKB-000LGv-P6 for namedroppers@ops.ietf.org; Tue, 15 Jul 2008 14:16:17 +0000 Received: from [10.31.200.219] (gatt.md.ogud.com [10.20.30.6]) by mail.ogud.com (8.13.1/8.13.1) with ESMTP id m6FEGC28033270; Tue, 15 Jul 2008 10:16:13 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200807150519.m6F5JnHh003509@drugs.dv.isc.org> References: <200807150519.m6F5JnHh003509@drugs.dv.isc.org> Date: Tue, 15 Jul 2008 10:10:06 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: I-D ACTION:draft-ietf-dnsext-axfr-clarify-09.txt Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 15:19 +1000 7/15/08, Mark Andrews wrote: > "An AXFR client might receive a number of AXFR response messages > free of an error condition before the message indicating an error > is received. But once an error is reported, the AXFR client can > assume that the error reporting message is the last." > > Last what? > * message in the axfr response stream? > * message on the TCP connection? What do you suggest? I am just the editor. Should the connection be ended? Or just the AXFR session? I suppose that in either case, it is the last message in the AXFR session, but it is open whether the connection is to be torn down. The wording above came from the observation of one WG member that an error condition might develop over the life of the session. Some errors will occur at the beginning - like saying "I don't have the zone" and some errors (could?) happen part way through the transfer. In either case, the "last" message sent would indicate the error. The question is, is the TCP connection ended when the session is (because of the reported error) ended? Perhaps the answer is error dependent? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 15 07:56:07 2008 Return-Path: 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 7DFB33A6ACF; Tue, 15 Jul 2008 07:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599] 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 dUrWJpDsY2wH; Tue, 15 Jul 2008 07:56:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7A4313A68F2; Tue, 15 Jul 2008 07:56:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIlpt-000OcT-9o for namedroppers-data@psg.com; Tue, 15 Jul 2008 14:49:01 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIlpl-000Obb-Dl for namedroppers@ops.ietf.org; Tue, 15 Jul 2008 14:48:59 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m6FEmlDD013595; Wed, 16 Jul 2008 00:48:47 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200807151448.m6FEmlDD013595@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: I-D ACTION:draft-ietf-dnsext-axfr-clarify-09.txt In-reply-to: Your message of "Tue, 15 Jul 2008 10:10:06 -0400." Date: Wed, 16 Jul 2008 00:48:47 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > At 15:19 +1000 7/15/08, Mark Andrews wrote: > > "An AXFR client might receive a number of AXFR response messages > > free of an error condition before the message indicating an error > > is received. But once an error is reported, the AXFR client can > > assume that the error reporting message is the last." > > > > Last what? > > * message in the axfr response stream? > > * message on the TCP connection? > > What do you suggest? I am just the editor. > > Should the connection be ended? Or just the AXFR session? Just the AXFR session would be my call. I just commented because it could be read either way. > I suppose that in either case, it is the last message in the AXFR > session, but it is open whether the connection is to be torn down. > > The wording above came from the observation of one WG member that an > error condition might develop over the life of the session. Some > errors will occur at the beginning - like saying "I don't have the > zone" and some errors (could?) happen part way through the transfer. > In either case, the "last" message sent would indicate the error. > The question is, is the TCP connection ended when the session is > (because of the reported error) ended? Perhaps the answer is error > dependent? > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > Never confuse activity with progress. Activity pays more. > > -- > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 15 08:00:11 2008 Return-Path: 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 5C2813A6B2D; Tue, 15 Jul 2008 08:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599] 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 0v8-j+pl+jLw; Tue, 15 Jul 2008 08:00:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 647AD3A6B80; Tue, 15 Jul 2008 08:00:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIlvn-000P8w-Nd for namedroppers-data@psg.com; Tue, 15 Jul 2008 14:55:07 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIlvX-000P6e-IR for namedroppers@ops.ietf.org; Tue, 15 Jul 2008 14:55:01 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m6FEskno013640; Wed, 16 Jul 2008 00:54:46 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200807151454.m6FEskno013640@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: I-D ACTION:draft-ietf-dnsext-axfr-clarify-09.txt In-reply-to: Your message of "Tue, 15 Jul 2008 10:10:06 -0400." Date: Wed, 16 Jul 2008 00:54:46 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: The defaults on whether to allow a transfer or not are problematic. They sound nice but are impractical. I would suggest that they remain unspecified. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 15 08:13:18 2008 Return-Path: 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 283E73A699F; Tue, 15 Jul 2008 08:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.605 X-Spam-Level: X-Spam-Status: No, score=-0.605 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_25=0.6, RDNS_NONE=0.1] 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 SCCNtdLgs3Aj; Tue, 15 Jul 2008 08:13:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4CFC73A68ED; Tue, 15 Jul 2008 08:13:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIm5h-0000Fv-St for namedroppers-data@psg.com; Tue, 15 Jul 2008 15:05:21 +0000 Received: from [66.92.146.160] (helo=mail.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KIm5a-0000EY-CP for namedroppers@ops.ietf.org; Tue, 15 Jul 2008 15:05:16 +0000 Received: from [10.31.200.219] (ns.md.ogud.com [10.20.30.6]) by mail.ogud.com (8.13.1/8.13.1) with ESMTP id m6FF51MQ033627; Tue, 15 Jul 2008 11:05:02 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200807151448.m6FEmlDD013595@drugs.dv.isc.org> References: <200807151448.m6FEmlDD013595@drugs.dv.isc.org> Date: Tue, 15 Jul 2008 11:04:54 -0400 To: Mark Andrews From: Edward Lewis Subject: Re: I-D ACTION:draft-ietf-dnsext-axfr-clarify-09.txt Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 0:48 +1000 7/16/08, Mark Andrews wrote: >I said: >> Should the connection be ended? Or just the AXFR session? > > Just the AXFR session would be my call. I just commented > because it could be read either way. > Cool, barring a flood of other comments, I'll clean that up in the next go'round. Speaking to implementers, in regards to dealing with bugs, etc., has there been a situation in which, mid zone transfer (AXFR or not), a problem arose that caused the connection to be corrupted enough that it had to be torn down? As opposed to being torn down as a matter of cleaning up an ended (in failure) transfer session. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 16 07:50:22 2008 Return-Path: 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 5C2A13A67E1; Wed, 16 Jul 2008 07:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.232 X-Spam-Level: X-Spam-Status: No, score=-102.232 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 P1YtreZQUqVR; Wed, 16 Jul 2008 07:50:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6D4513A68D0; Wed, 16 Jul 2008 07:50:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJ8GC-000828-25 for namedroppers-data@psg.com; Wed, 16 Jul 2008 14:45:40 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJ8G4-000819-Np for namedroppers@ops.ietf.org; Wed, 16 Jul 2008 14:45:37 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id C0F233A681A; Wed, 16 Jul 2008 07:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D Action:draft-ietf-dnsext-rfc2672bis-dname-14.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080716144501.C0F233A681A@core3.amsl.com> Date: Wed, 16 Jul 2008 07:45:01 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Update to DNAME Redirection in the DNS Author(s) : S. Rose, W. Wijngaards Filename : draft-ietf-dnsext-rfc2672bis-dname-14.txt Pages : 17 Date : 2008-07-16 The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is a revision of the original specification in RFC 2672, also aligning RFC 3363 and RFC 4294 with this revision.Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2672bis-dname-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-16073300.I-D@ietf.org> --NextPart-- -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 16 07:51:00 2008 Return-Path: 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 521663A68D0; Wed, 16 Jul 2008 07:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 pTSezhBK4OMq; Wed, 16 Jul 2008 07:50:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF30D3A67E1; Wed, 16 Jul 2008 07:50:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJ8Dv-0007m3-DO for namedroppers-data@psg.com; Wed, 16 Jul 2008 14:43:19 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJ8Dp-0007je-6r for namedroppers@ops.ietf.org; Wed, 16 Jul 2008 14:43:17 +0000 Received: from 98-140.antd.nist.gov (98-140.antd.nist.gov [129.6.140.98]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m6GEgJj1027089; Wed, 16 Jul 2008 10:42:20 -0400 Message-ID: <487E08CD.60508@nist.gov> Date: Wed, 16 Jul 2008 10:42:21 -0400 From: Scott Rose Organization: NIST User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: IETF DNSEXT WG , Wouter Wijngaards CC: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= , Andrew Sullivan Subject: New version of draft-ietf-dnsext-rfc2672bis-dname available Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I know we missed the deadline (my fault). But the -14 version of the DNAMEbis draft is available here: http://www.dnsops.gov/draft-ietf-dnsext-rfc2672bis-dname-14.html http://www.dnsops.gov/draft-ietf-dnsext-rfc2672bis-dname-14.txt Scott (and Wouter) -- ---------------------------------------- Scott Rose Computer Scientist NIST ph: +1 301-975-8439 scott.rose@nist.gov http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ ----------------------------------------- -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 16 08:38:32 2008 Return-Path: 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 3A16A3A680C; Wed, 16 Jul 2008 08:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 EAq1PWmMZsT9; Wed, 16 Jul 2008 08:38:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 54FCD3A67B5; Wed, 16 Jul 2008 08:38:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJ90d-000Eet-7N for namedroppers-data@psg.com; Wed, 16 Jul 2008 15:33:39 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJ90Y-000Ee9-Gi for namedroppers@ops.ietf.org; Wed, 16 Jul 2008 15:33:37 +0000 Received: from commandprompt.com (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m6GFZB5O026931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jul 2008 08:35:14 -0700 Date: Wed, 16 Jul 2008 11:32:51 -0400 From: Andrew Sullivan To: Scott Rose Cc: IETF DNSEXT WG , Wouter Wijngaards , =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= Subject: Re: New version of draft-ietf-dnsext-rfc2672bis-dname available Message-ID: <20080716153250.GL5261@commandprompt.com> References: <487E08CD.60508@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <487E08CD.60508@nist.gov> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Wed, 16 Jul 2008 08:35:15 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jul 16, 2008 at 10:42:21AM -0400, Scott Rose wrote: > I know we missed the deadline (my fault). But the -14 version of the > DNAMEbis draft is available here: Looks like you made it anyway. A -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 17 15:32:28 2008 Return-Path: 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 344E33A692C; Thu, 17 Jul 2008 15:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[AWL=-0.781, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 T385e14iy1ZG; Thu, 17 Jul 2008 15:32:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5B3283A6831; Thu, 17 Jul 2008 15:32:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJbtq-0001bx-NV for namedroppers-data@psg.com; Thu, 17 Jul 2008 22:24:34 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJbtm-0001ZV-Tc for namedroppers@ops.ietf.org; Thu, 17 Jul 2008 22:24:32 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id B41F3FF292 for ; Fri, 18 Jul 2008 08:24:30 +1000 (EST) Message-ID: <487FC5FC.7090804@e164.org> Date: Fri, 18 Jul 2008 08:21:48 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Updated draft-groth-dns-encryption 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: I'm unable to publish on the IETF site due to the cut off so I've put it on ours for the time being until submissions are accepted again. http://www.e164.org/docs/draft-groth-dns-encryption-03.txt http://www.e164.org/docs/draft-groth-dns-encryption-03.pdf There is a lot of differences with this draft compared to previous ones, hopefully this one is a lot more suitable, but this is the first submission I've been involved with the learning curve has been straight up. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 18 06:13:38 2008 Return-Path: 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 981903A6985; Fri, 18 Jul 2008 06:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.966 X-Spam-Level: X-Spam-Status: No, score=-101.966 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 HENR6JN-IP3C; Fri, 18 Jul 2008 06:13:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 913133A6831; Fri, 18 Jul 2008 06:13:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJpcp-000B3i-92 for namedroppers-data@psg.com; Fri, 18 Jul 2008 13:03:55 +0000 Received: from [2001:14b0:202:1::a7] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJpcl-000B31-0R for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 13:03:53 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1KJpcS-0007Cl-3B; Fri, 18 Jul 2008 15:03:32 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1KJpcR-00046a-Ji; Fri, 18 Jul 2008 15:03:31 +0200 From: Florian Weimer To: Duane Cc: namedroppers@ops.ietf.org Subject: Re: DNS Encryption References: <4877FDE0.1080706@e164.org> <87skufia55.fsf@mid.deneb.enyo.de> <4878A586.4010403@e164.org> Date: Fri, 18 Jul 2008 15:03:31 +0200 In-Reply-To: <4878A586.4010403@e164.org> (duane@e164.org's message of "Sat, 12 Jul 2008 22:37:26 +1000") Message-ID: <87ej5rl4yk.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: >> As far as I can see, the proposed protocol, if worked out in full, >> solves two problems (data leaks across the hierarchy and eavesdropping >> on the wire) but doesn't do anything about enumeration and information >> leaks from caching resolvers. > > There is no way this would prevent enumeration any more than SMTP-TLS > prevents spam, brute force attacks can be dealt with on the server by > tracking IPs and/or sequential requests, but this wouldn't prevent a > very clever attacker that has a large bot net that does a distributed > brute force attack in a non-sequential manner. The reason why I'm raising this is that you're tweaking a core protocol, and I think there should be a sound rationale for that. My impression (correct me if I'm wrong) is something like this: You want to use DNS for non-carrier ENUM. You note that ENUM requests and responses may contain data assumed to be sensitive in the PSTN context. You want to do something about it, and this is the motivation behind your draft. In contrast, I strongly believe that your goal is unattainable in a DNS context because DNS is inherently leaky. -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 18 06:13:51 2008 Return-Path: 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 6B77C3A6A4B; Fri, 18 Jul 2008 06:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.013 X-Spam-Level: X-Spam-Status: No, score=-102.013 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 vFJXzYchuEQQ; Fri, 18 Jul 2008 06:13:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D8A23A6985; Fri, 18 Jul 2008 06:13:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJpcF-000B02-0a for namedroppers-data@psg.com; Fri, 18 Jul 2008 13:03:19 +0000 Received: from [2001:14b0:202:1::a7] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJpcA-000Ayz-Gx for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 13:03:17 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1KJpc8-0007CI-6e for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 15:03:12 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1KJpc7-00046K-Tf for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 15:03:11 +0200 From: Florian Weimer To: namedroppers@ops.ietf.org Subject: Re: NSEC design question wrt synthesized RCODE 3 (NXDOMAIN) References: <48608.1214756465@sa.vix.com> Date: Fri, 18 Jul 2008 15:03:11 +0200 In-Reply-To: <48608.1214756465@sa.vix.com> (Paul Vixie's message of "Sun, 29 Jun 2008 16:21:05 +0000") Message-ID: <87fxq7l4z4.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Paul Vixie: > second, root name service. There's also E164.ARPA, for which you should secure a delegation to name servers under your own jurisdiction, to prevent call data record leaks. NXDOMAIN synthesis would mostly fix this problem. -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 18 06:14:15 2008 Return-Path: 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 513343A6869; Fri, 18 Jul 2008 06:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.257 X-Spam-Level: X-Spam-Status: No, score=-1.257 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 b9VupibB6Cke; Fri, 18 Jul 2008 06:14:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7A4803A6831; Fri, 18 Jul 2008 06:14:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJpj5-000C5I-GI for namedroppers-data@psg.com; Fri, 18 Jul 2008 13:10:23 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJpj1-000C4w-Ja for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 13:10:21 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id BB696FF270; Fri, 18 Jul 2008 23:10:16 +1000 (EST) Message-ID: <48809590.9020507@e164.org> Date: Fri, 18 Jul 2008 23:07:28 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Florian Weimer CC: namedroppers@ops.ietf.org Subject: Re: DNS Encryption References: <4877FDE0.1080706@e164.org> <87skufia55.fsf@mid.deneb.enyo.de> <4878A586.4010403@e164.org> <87ej5rl4yk.fsf@mid.deneb.enyo.de> In-Reply-To: <87ej5rl4yk.fsf@mid.deneb.enyo.de> 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: Florian Weimer wrote: > My impression (correct me if I'm wrong) is something like this: You want > to use DNS for non-carrier ENUM. You note that ENUM requests and > responses may contain data assumed to be sensitive in the PSTN context. > You want to do something about it, and this is the motivation behind > your draft. That's only one leak, someone else brought up another, but I won't repeat it publicly, there is any number of reasons why people want to hide their queries and/or responses, as others pointed out to me, I'm not the first to attempt this. > In contrast, I strongly believe that your goal is unattainable in a DNS > context because DNS is inherently leaky. So is HTTP which is why they plug up the XSS exploits in browsers, where as the site owners are really to blame. I don't think secrecy is impossible at least to some degree, I think if there was a common stable starting point for everyone that any holes that sprang leaks could be worked on a solved over time. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 18 09:38:14 2008 Return-Path: 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 029693A67EC; Fri, 18 Jul 2008 09:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.104 X-Spam-Level: X-Spam-Status: No, score=-4.104 tagged_above=-999 required=5 tests=[AWL=-1.449, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] 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 DAitkQVeCFL7; Fri, 18 Jul 2008 09:38:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB57B28C1CE; Fri, 18 Jul 2008 09:38:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJsqp-000DW0-NO for namedroppers-data@psg.com; Fri, 18 Jul 2008 16:30:35 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJsql-000DVO-LW for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 16:30:33 +0000 X-IronPort-AV: E=Sophos;i="4.31,211,1215388800"; d="scan'208";a="14789335" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Jul 2008 16:30:30 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6IGUUlE026442; Fri, 18 Jul 2008 18:30:30 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6IGUUdh018209; Fri, 18 Jul 2008 16:30:30 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jul 2008 18:30:30 +0200 Received: from Townsley-MacBook.local ([10.61.66.3]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jul 2008 18:30:29 +0200 Message-ID: <4880C50D.9070901@cisco.com> Date: Fri, 18 Jul 2008 18:30:05 +0200 From: Mark Townsley Reply-To: Internet Area User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: softwires@ietf.org, ipv6@ietf.org, IETF DNSEXT WG Subject: IPv4 and IPv6 Co-existence discussions in Dublin Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2008 16:30:29.0482 (UTC) FILETIME=[97664CA0:01C8E8F3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4103; t=1216398630; x=1217262630; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20IPv4=20and=20IPv6=20Co-existence=20discussions= 20in=20Dublin |Sender:=20; bh=y2lj12IqlR1NdLdp1AFiSlorfiyMNb3uW9OetmfmgJc=; b=A4MVm125TccsD+OZ1wv/F9Jgf3h95dKX4/LA34dTjzAHWjSLIvYR9kBJ30 8qJzbX9plox+Ewl0Vm76dXrcFF+mzMoTIqhSJsKHfYf+QIwc8iykrwGxAa0U ieeDLLLVXk; Authentication-Results: ams-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Apologies for cross-posting, please reply only to int-area@ietf.org All, Recent discussions in the IETF indicate that the IPv4 and IPv6 co-existence solutions we have available will not be sufficient for all deployment scenarios which we expect to be necessary in the face of pressures due to upcoming IPv4 address space exhaustion (or "completion"). The INT, TSV and OPS ADs would like to discuss with the community the best way to proceed in chartering this work, with particular focus on solutions which seem both readily tractable and for which provide identifiable benefit. Specifically, two initial steps appear as potential work items: 1. The ability to employ an IPv6-only network infrastructure by, say a cable or DSL operator, and still be able to serve subscriber networks that run on IPv4. This scenario was described in the Vancouver IETF V6OPS meeting [4], and it could be helpful in large networks where private RFC1918 IPv4 space is not sufficient to address all devices without resorting to overlays or NAT of the private space itself. We believe that this is something that can be implemented through the use of tunneling of IPv4 over IPv6. If the subscribers are in turn given private IPv4 address space, the tunnels would be connected to an IPv4 NAT device that serves multiple subscribers, potentially requiring a device that serves a very large number of translations as well as tunnels. It is suggested that this is a work item that fits the SOFTWIRE WG, and the INT ADs will be sending off a recharter proposal for this WG to examine this particular problem space and develop a solution accordingly. 2. NAT-PT was deprecated for reasons described in RFC 4966. However, there are scenarios where some forms of translation may be necessary. In particular, the IAB noted in [1] that scenarios involving servers without public IPv4 addresses cannot be adequately handled with the existing mechanisms. Requirements on this issue have been discussed in V6OPS, and a problem statement document written [2]. One possible translation design with reduced scope from NAT-PT as defined in RFC 2766 has been discussed recently in the BEHAVE WG [3], but there are other possible designs as well [5]. In essence, these designs attempt to reduce the problems present in NAT-PT by various techniques, including limiting themselves to a simpler part of the overall problem, allowing some changes in IPv6 hosts, and generally being designed with a better knowledge of the issues in RFC 4966. We believe that, on balance, the benefits outweigh the costs on developing a standard method for translation of IPv4 and IPv6. This will likely have a smaller scope, at least in the short term, than the original NAT-PT though it will inevitably share some of the same limitations. We will discuss this design in two places at the upcoming meeting: BEHAVE and INTAREA (two separate places because we feel it necessary to involve both the IP experts and people with a history of building address translators). For the moment, general architectural discussion should happen on the int-area@ietf.org list. We would like to focus our discussions on whether the requirements scenario and architectural direction is sufficiently ready so that the work can be given to the protocol WGs. If the answer to these questions is yes, after the Dublin IETF the ADs will recharter the relevant working groups to do the work. V6OPS is already working on the requirements. We expect that the behave WG would be the primary solution discussion forum and produce the base translation specification. 6MAN and DNSEXT would in turn handle any IPv6 stack or DNS protocol impacts (including a DNS ALG, if needed). - INT, OPS, and TSV ADs [1] http://www.ietf.org/mail-archive/web/ietf/current/msg48436.html [2] http://tools.ietf.org/html/draft-ietf-v6ops-nat64-pb-statement-req [3] http://tools.ietf.org/id/draft-bagnulo-behave-nat64 [4] http://www.ietf.org/proceedings/07dec/slides/v6ops-5/sld1.htm [5] http://tools.ietf.org/id/draft-xli-behave-ivi -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 18 11:44:19 2008 Return-Path: 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 0D26728C0FD; Fri, 18 Jul 2008 11:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.038 X-Spam-Level: X-Spam-Status: No, score=-0.038 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] 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 emha9P6E60wL; Fri, 18 Jul 2008 11:44:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2EE273A68FB; Fri, 18 Jul 2008 11:44:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJumI-0004eG-RI for namedroppers-data@psg.com; Fri, 18 Jul 2008 18:34:02 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJumE-0004dZ-CH for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 18:34:00 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6IIXt2P014757 for ; Fri, 18 Jul 2008 14:33:55 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6IIXtgG014756 for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 14:33:55 -0400 (EDT) (envelope-from namedroppers) 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 ) id 1KJscK-000BQ3-VB for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 16:15:39 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id C4A89A1107 for ; Fri, 18 Jul 2008 16:15:28 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: transaction security in the last mile X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 18 Jul 2008 16:15:28 +0000 Message-ID: <5721.1216397728@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: C4A89A1107.1D51D X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] whereas XQID or anything like it would either rely on EDNS and would have to fall back to less security if an attacker could spoof a non-EDNS reply, or would bypass EDNS and do its own feature negotiation where the fallback would be something like "repeat the whole transaction several times using newly randomized QID and UDP.PORT (and maybe QNAME 0x20) each time", and whereas TSIG relies on a pre-shared secret key involving out of band key exchange (such as "sneaker-net") which is expected to scale badly in large installations and be useless in ISP or ASP situations, and whereas GSS-TSIG relies on a working GSS (think kerberos 5) installation that encompasses both RDNS and its client stubs, which is known to be rare in the world and never present in ISP or ASP situations, and whereas SIG(0) (or is it RRSIG(0) now?) relies on a working Secure DNS system containing a TKEY RR at the RDNS's hostname, which has proven elusive due to the extreme duration of Secure DNS's development and the lack of general interest among anybody other than technology vendors and a few CCTLDs, and whereas BCP38 deployment has utterly stalled in recent years and is likely to never be complete enough to make IP source addresses generally repudiable and even if we somehow did reach universal BCP38 deployment the sense of security this would give us would be false since backsliding could happen at any instant and would be mostly transparent at first, and whereas we have now randomized everything we can (QID, UDP port, QNAME 0x20) and this gives us only stant statistical protection against DNS forgeries involving injection of packets having spoofed IP source addresses, yet we have no cause for confidence in our continued safety in a world full of smart ambitious security researchers (some good, many evil) whose computers and networks get faster every year, ... .. .. i think it's time for a new debate on the nature of the relationship between the stub and the RDNS. i wish to leave aside the relationship between the RDNS and ADNS, since these are far more numerous, and the kinds of negotiations or state that are practical in the stub/RDNS relationship might be completely impractical in the RDNS/ADNS relationship. in this discussion, a "stub" refers to either an initiator with no DNS-layer cache, or to an RDNS configured to use a "forwarder". in both cases, the number of relationships a given initiator is in, or that a given responder is in, is finite and manageable. here are some possible roads, and the reasons they're each hard to follow. 1. always use tcp. with random initial sequence numbers now the standard, we generally consider tcp sessions unspoofable unless the ISO-L2 is insecure near either endpoint, or unless the routing layer is attacked. for many stub/RDNS deployments, the number of stubs simultaneously doing DNS will be lower than the number of tcp protocol control blocks or socket descriptors available on the RDNS host and application. however, in many ISP deployments there can be millions or tens of millions of stubs for every RDNS, and not even anycasting or load balancing will make that fit, so we'd be contemplating a very short (subsecond) timeout for idle DNS TCP sessions, which calls for some modelling to find out what the packet count and RTT cost would be for the average stub in that environment. also, stubs would have to funnel their queries through shared local protocol agents, and these agents may become a new target for injection attackers. 2. diffie-hellman. it is possible, with the exchange of several random numbers used as encryption and decryption keys, for two endpoints with no shared secret to establish a trust relationship. this takes measureable time and effort, so the existence of this trust relationship is usually remembered by the endpoints, creating "session state" which can be used to generate nonces or shared keys. RFC 2930 is an example of such a method, whereby the TKEY meta-RR is used to carry keying information for the TSIG meta-RR. no known large deployment currently uses TKEY to create trust and then TSIG to protect query transactions, so while this approach may be practical, its error modes remain unmeasured. because such relationships are not held in protocol control blocks and/or socket descriptors, it may be possible for an RDNS to relate to millions of stubs in this way. however, the stubs will probably require additional processes or files to hold the trust state for each RDNS, and this state may become a new target for injection attackers. there's also a lurking downgrade attack involving spoofed ICMP-Port-Unreach, since the D-H and key data won't be in the first 64 octets of the payload, which ICMP uses as a nonce. 3. IPv6 multiplicity. in IPv6, most LANs will have 64-bit netmasks, leaving 64 bits for host addressing, which are expected to be sparsely allocated. it is possible that a stub host could allocate a few dozen addresses, and choose one at random as a source for requests to RDNS. there is a tension between having enough source addresses to matter from a security nonce point of view, vs. having too many to manage in the exit gateways who must maintain ARP state for each address, mapping back to each stub's MAC address. it's unlikely that the number of additional random bits we need can be accomodated by this layer of the IPv6 architecture, and furthermore, IPv6 isn't here yet. 4. new port. most of the constraints are due to backward compatibility problems, and if we simply allocate a new UDP port, other than 53, then we can make new rules. it's easy to design a completely stateless replacement for stub DNS that involves 128-bit random nonces. while there would be some delay while IETF debates which part of the kitchen sink to leave in or remove, it's safe to say that there would be no authority or additional data section, no RD bit, very few options in general, and that we could avoid having this turn into a replacement for the current global DNS protocol used for the RDNS/ADNS relationship. what's less clear is how the fallback strategy would be secure, since a "new-stub" would have to fall back to standard UDP/53 if it could not get an answer on the new UDP port from any of its RDNS's. could we put the nonce near the front of the UDP payload so that ICMP-PortUnreach (which uses the first 64 bytes of the datagram) would be hard enough to forge that we could confidently assume that there was never a downgrade attack? i know that's a paltry list. others here should be able to think of more alternatives. i'd like to avoid a re-debate over XQID, though, so if that's your position i ask that you hold off on elucidating it here to let this topic be explored on the basis that XQID, TSIG, SIG(0), and BCP38 are nonstarters. i'd really like to know whether always-tcp, diffie-hellman, ipv6-multiplicity, or new-port are practical or not, and whether there are other ideas lurking. of the ideas above, i dislike the new-port idea the least, and that's very depressing, since from a deployment perspective, SIG(0) would be about the same total cost. (the largest part of the cost is touching all or most of the stubs, not in the specific complexities added by that touch.) -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 18 12:21:45 2008 Return-Path: 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 6B44428C1FF; Fri, 18 Jul 2008 12:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 LmcaS-yHxwTu; Fri, 18 Jul 2008 12:21:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EF79F28C22E; Fri, 18 Jul 2008 12:21:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJvSY-000AOu-6i for namedroppers-data@psg.com; Fri, 18 Jul 2008 19:17:42 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJvSU-000AOX-Mq for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 19:17:40 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 34CD7C2DA5; Fri, 18 Jul 2008 20:17:37 +0100 (BST) Date: Fri, 18 Jul 2008 20:17:35 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: transaction security in the last mile Message-ID: In-Reply-To: <5721.1216397728@nsa.vix.com> References: <5721.1216397728@nsa.vix.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 18 July 2008 16:15:28 +0000 Paul Vixie wrote: > .. i think it's time for a new debate on the nature of the relationship > between the stub and the RDNS. i wish to leave aside the relationship > between the RDNS and ADNS, since these are far more numerous, and the > kinds of negotiations or state that are practical in the stub/RDNS > relationship might be completely impractical in the RDNS/ADNS > relationship. Question: most of the attack modes these seem to address would also be avoided by DNSSEC, which wasn't in your "whereas" list. I presume that is on the basis of an estimate of DNSSEC deployment times exceeding the deployment time of the changes to stub resolvers to implement 1-4. If so, and if quick deployment is the necessity, are there not existing protocols that might help? For instance, 2 (diffie-helman) proposes key exchange etc. Are there not bits of IPsec we could pull (without encryption) which would do the job? Alex -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 18 13:08:39 2008 Return-Path: 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 00E4B28C28D; Fri, 18 Jul 2008 13:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 SsSaVd7TnVcR; Fri, 18 Jul 2008 13:08:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A004E28C289; Fri, 18 Jul 2008 13:08:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJwAT-000Hch-Ul for namedroppers-data@psg.com; Fri, 18 Jul 2008 20:03:05 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJwAP-000HaA-J3 for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 20:03:03 +0000 Received: from commandprompt.com (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m6IK4wlU029040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Jul 2008 13:05:01 -0700 Date: Fri, 18 Jul 2008 16:02:35 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: WGLC summary for draft-ietf-dnsext-forgery-resilience Message-ID: <20080718200235.GG73459@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Fri, 18 Jul 2008 13:05:01 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, The WGLC has concluded. Many thanks to the reviewers. There was lively discussion during the last call, with a number of good comments. There is a strong WG consensus to advance the document, but there was interesting debate about which track the document should follow -- standards or BCP. The chairs sense that most WG members, while preferring one track over the other, are on record as being able to live with either track. This document is in real strange position, it is "not strictly" required for interoperabilty but it is "strictly" needed for the safe(r) behavior of implementations. The IETF standards track documents do not explicitly address what kind of document this is. In order to make the strongest possible statement to the non DNS community that this work is important the chairs will advance this document as Standards Track. Current draft states that it updates 1034, this is incorrect it actually updates 2181. Editor please change that. Major change: During the last call some people thought section 9 needed tuning. After going through the discussion the chairs are proposing the following replacement of section 9. (need to check Replacement of section 9: 9. Forgery Countermeasures 9.1 Query matching rules A resolver implementation MUST match responses to the all of following attributes of the query: o Source address against query destination address o Destination address against query source address o Destination port against query source port o Query ID o Question name o Question class and type before applying DNS trustworthiness rules (see [RFC2181], section 5.4.1). A mismatch and the response MUST be considered invalid. 9.2 Extending the Q-ID space by using ports and addresses Resolver implementations MUST: o Use an unpredictable source port for outgoing queries from the range (53, or > 1024) of available ports that is as large as possible and practicable; o Use multiple different source ports simultaneously in case of multiple outstanding queries; o Use an unpredictable query ID for outgoing queries, utilizing the full range available (0-65535) Resolvers that have multiple IP addresses SHOULD use them in an unpredictable manner for outgoing queries. Resolvers SHOULD favour authoritative nameservers with which a trust relation has been established; Stub-resolvers SHOULD be able to use TSIG ([RFC2845]) or IPSEC ([RFC4301]) when communicating with their recursive resolver. In case a cryptographic verification of response validity is available (TSIG, SIG(0)), resolver implementations MAY waive above rules, and rely on this guarantee instead. Proper unpredictability can be achieved by employing a high quality random generator, as described in [RFC4086]. 9.2.1 Justification and Discussion Since an attacker can force a full DNS resolver to send queries to the attacker's own name servers, any constant or sequential state held by such a resolver can be measured, and it must not be trivially easy to reverse engineer the resolver's internal state in a way that allows low-cost high-accuracy prediction of future state. A full DNS resolver with only one or a small number of upstream- facing endpoints is effectively using constants for IP source address and UDP port number, and these are very predictable by potential attackers, and must therefore be avoided. A full DNS resolver who uses a simple increment to get its next DNS ID is likewise very predictable and so very spoof able. Finally, weak random number generators have been shown to expose their internal state, such that an attacker who witnesses several sequential "random" values can easily predict the next ones. A crypto-strength random number generator is one whose output cannot be predicted no matter how many successive values are witnessed. 9.3 Spoof detection and countermeasure If a resolver detects that an attempt is being made to spoof it, perhaps by discovering that many packets fail the criteria as outlined above, it MAY abandon the UDP query and re-issue it over TCP. TCP, by the nature of its use of sequence numbers, is far more resilient against forgery by third parties. Minor changes: Apply nits that number of people have brought up including Jelte Jansen, Paul Hoffman, Paul Vixie, Peter Koch, Alex Brown, Andreas Gustafsson, Jimmei Tatuya. The editor will post a new version for the working group members to check if their nits/comments have been addressed. Week after the document is reposed the chairs will advance the document to the IESG. Olafur & Andrew -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 18 13:20:25 2008 Return-Path: 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 BE61C3A6AF0; Fri, 18 Jul 2008 13:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.047 X-Spam-Level: X-Spam-Status: No, score=-102.047 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 EhYQfy28wl-R; Fri, 18 Jul 2008 13:20:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CEB593A6A56; Fri, 18 Jul 2008 13:20:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJwNf-000JZA-0e for namedroppers-data@psg.com; Fri, 18 Jul 2008 20:16:43 +0000 Received: from [2001:14b0:202:1::a7] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJwNa-000JYQ-KG for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 20:16:40 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1KJwNP-0005S3-LK; Fri, 18 Jul 2008 22:16:27 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1KJwNP-0006vm-B0; Fri, 18 Jul 2008 22:16:27 +0200 From: Florian Weimer To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> Date: Fri, 18 Jul 2008 22:16:27 +0200 In-Reply-To: <5721.1216397728@nsa.vix.com> (Paul Vixie's message of "Fri, 18 Jul 2008 16:15:28 +0000") Message-ID: <87abgfosmc.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Paul Vixie: > .. ... whereas the last mile (on the IP layer) is no longer transparent for 53/UDP packets, which significantly limits further protocol evolution, > here are some possible roads, and the reasons they're each hard to > follow. First of all, I think it's mostly pointless to protect stub to local ISP resolver communications. This only requires local source address validation, so it's something the ISP can and should implement today. However, there are at least two applications for a DNS last mile that does not end at the customer ISP: external DNS services with enhanced data (new roots etc.), and DNS forwarders which are DNSSEC-transparent and suitable for end-to-end validation. There's an incentive for ISPs to stop the first application, by some sort of DNS proxy. The port number does not really matter: If it's well-known. it will be proxied. Unfortunately, this type of proxy will not be DNSSEC-transparent, so the second application is affected as well. So we need crypto. And crypto for connection-less services means DTLS. It could be that DTLS requires too much server-side state (to avoid running the relatively expensive private RSA operation too often), or that a really good cipher suite hasn't been specified, but these things should be fixable. Diffie-Hellman is probably too expensive for key agreement (and the ECC variants too encumbered by patents). (Just a few thoughts -- I'm really interested in this topic because we need to solve it before we can enable some form of DNSSEC validation on mobile devices.) -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 18 13:41:34 2008 Return-Path: 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 29EB83A6A56; Fri, 18 Jul 2008 13:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 RSBHhntbFIoS; Fri, 18 Jul 2008 13:41:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F2AE43A687F; Fri, 18 Jul 2008 13:41:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJwht-000Mlp-0s for namedroppers-data@psg.com; Fri, 18 Jul 2008 20:37:37 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJwhm-000Mks-T6 for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 20:37:34 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KJwhk-0003As-Fz for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 22:37:28 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 4A0F23F7A; Fri, 18 Jul 2008 22:37:43 +0200 (CEST) Date: Fri, 18 Jul 2008 22:37:43 +0200 From: bert hubert To: Florian Weimer Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: transaction security in the last mile Message-ID: <20080718203743.GA1293@outpost.ds9a.nl> References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87abgfosmc.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jul 18, 2008 at 10:16:27PM +0200, Florian Weimer wrote: > Diffie-Hellman is probably too expensive for key agreement (and the ECC > variants too encumbered by patents). CURVE25519 perhaps? I'm no crypto expert, but to my eyes it looks nice. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 18 13:55:50 2008 Return-Path: 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 445CB3A6B7D; Fri, 18 Jul 2008 13:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.299 X-Spam-Level: ** X-Spam-Status: No, score=2.299 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] 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 6jT9P+fL0+Hw; Fri, 18 Jul 2008 13:55:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 72F013A6B78; Fri, 18 Jul 2008 13:55:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJwvz-000OqC-3p for namedroppers-data@psg.com; Fri, 18 Jul 2008 20:52:11 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJwvv-000Ope-5G for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 20:52:08 +0000 Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.8570906; Fri, 18 Jul 2008 16:51:42 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Jul 2008 16:51:40 -0400 Received: from 71.192.55.85 ([71.192.55.85]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Fri, 18 Jul 2008 20:51:30 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Fri, 18 Jul 2008 16:51:29 -0400 Subject: Re: IPv4 and IPv6 Co-existence discussions in Dublin From: Alain Durand To: Internet Area , , , IETF DNSEXT WG Message-ID: Thread-Topic: IPv4 and IPv6 Co-existence discussions in Dublin Thread-Index: AcjpGA0zYuu/DCKZBEGqEyQjav9dTg== In-Reply-To: <4880C50D.9070901@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Jul 2008 20:51:40.0615 (UTC) FILETIME=[141F6D70:01C8E918] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 7/18/08 12:30 PM, "Mark Townsley" wrote: > [4] http://www.ietf.org/proceedings/07dec/slides/v6ops-5/sld1.htm For a more up to date reference, I would suggest to read: http://www.ietf.org/internet-drafts/draft-durand-dual-stack-lite-00.txt - Alain. -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 18 13:55:52 2008 Return-Path: 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 5EC043A6B7E; Fri, 18 Jul 2008 13:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.072 X-Spam-Level: X-Spam-Status: No, score=-102.072 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 IhRFD5jDjO75; Fri, 18 Jul 2008 13:55:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 806F33A6B78; Fri, 18 Jul 2008 13:55:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJwws-000P8Y-UP for namedroppers-data@psg.com; Fri, 18 Jul 2008 20:53:06 +0000 Received: from [2001:14b0:202:1::a7] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJwwo-000P7Z-Ns for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 20:53:04 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1KJwwh-0007nK-OE; Fri, 18 Jul 2008 22:52:55 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1KJwwh-00078E-D8; Fri, 18 Jul 2008 22:52:55 +0200 From: Florian Weimer To: bert hubert Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <20080718203743.GA1293@outpost.ds9a.nl> Date: Fri, 18 Jul 2008 22:52:55 +0200 In-Reply-To: <20080718203743.GA1293@outpost.ds9a.nl> (bert hubert's message of "Fri, 18 Jul 2008 22:37:43 +0200") Message-ID: <87od4uoqxk.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * bert hubert: > On Fri, Jul 18, 2008 at 10:16:27PM +0200, Florian Weimer wrote: >> Diffie-Hellman is probably too expensive for key agreement (and the ECC >> variants too encumbered by patents). > > CURVE25519 perhaps? I'm no crypto expert, but to my eyes it looks nice. Could be, indeed. But my DTLS comment remains valid: you should get it into DTLS use that protocol. -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 18 14:21:31 2008 Return-Path: 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 B76253A6853; Fri, 18 Jul 2008 14:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 OR86Pzqa7eX8; Fri, 18 Jul 2008 14:21:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D8A463A6811; Fri, 18 Jul 2008 14:21:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJxJl-00036A-KK for namedroppers-data@psg.com; Fri, 18 Jul 2008 21:16:45 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJxJi-00035l-7e for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 21:16:43 +0000 Received: from [10.0.1.198] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id C3E38291F65; Fri, 18 Jul 2008 14:16:41 -0700 (PDT) Cc: namedroppers@ops.ietf.org Message-Id: <314E9DEF-DA6F-477D-9DC5-F4F5A8C079DC@virtualized.org> From: David Conrad To: Paul Vixie In-Reply-To: <5721.1216397728@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: transaction security in the last mile Date: Fri, 18 Jul 2008 14:16:40 -0700 References: <5721.1216397728@nsa.vix.com> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 18, 2008, at 9:15 AM, Paul Vixie wrote: > .. i think it's time for a new debate on the nature of the > relationship > between the stub and the RDNS. Long past time, actually. > 1. always use tcp. > 2. diffie-hellman. > 3. IPv6 multiplicity. > 4. new port. 5. if you feel there could be a risk, run a local (validating) RDNS. Regards, -drc -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 18 14:38:45 2008 Return-Path: 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 DBD853A68D2; Fri, 18 Jul 2008 14:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 kvXqdMeueWIi; Fri, 18 Jul 2008 14:38:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E87433A680E; Fri, 18 Jul 2008 14:38:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJxba-0005oJ-HS for namedroppers-data@psg.com; Fri, 18 Jul 2008 21:35:10 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJxbW-0005nN-0d for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 21:35:08 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=ca.afilias.info; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=JV0tuLP39J7obyJ28NuMVV9cUSwW7zdgPjmMS8k3WaL2IWuNaf6I6bCpbXYA0ENNKl/xrRsCCI5WF+MFHOLVCDLYQ6lrb1zVdbfuVFnpb51JlF5BrVaBBjxlr6o4G6kY; Received: from [199.212.90.27] (helo=yxu1b27.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJxaH-000HdI-Dw; Fri, 18 Jul 2008 21:33:49 +0000 Cc: namedroppers@ops.ietf.org Message-Id: <0D0F144A-8822-47CC-94F1-5BCB4D0D256F@ca.afilias.info> From: Joe Abley To: Paul Vixie In-Reply-To: <5721.1216397728@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: transaction security in the last mile Date: Fri, 18 Jul 2008 17:33:48 -0400 References: <5721.1216397728@nsa.vix.com> X-Mailer: Apple Mail (2.926) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 18 Jul 2008, at 12:15, Paul Vixie wrote: > whereas TSIG relies on a pre-shared secret key involving out of band > key > exchange (such as "sneaker-net") which is expected to scale badly in > large > installations and be useless in ISP or ASP situations, and ... and synchronised clocks, lack of which is likely to cause an even greater support headache than the problem of sharing a TSIG key amongst a community of customers... Joe -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 18 15:02:21 2008 Return-Path: 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 E0B893A68DF; Fri, 18 Jul 2008 15:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 5c+91zWhCF5s; Fri, 18 Jul 2008 15:02:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F2DC73A67FD; Fri, 18 Jul 2008 15:02:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJxwO-0009Wf-JQ for namedroppers-data@psg.com; Fri, 18 Jul 2008 21:56:40 +0000 Received: from [64.18.2.171] (helo=exprod7og109.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJxwK-0009WD-Q2 for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 21:56:38 +0000 Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Fri, 18 Jul 2008 14:56:33 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id 183561A8209; Fri, 18 Jul 2008 14:56:33 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.0.252] (66.93.162.128) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.278.0; Fri, 18 Jul 2008 14:56:32 -0700 CC: Paul Vixie , "namedroppers@ops.ietf.org" Message-ID: <69079541-3324-4DD8-87B9-30F8F150CAE1@nominum.com> From: Ted Lemon To: Florian Weimer In-Reply-To: <87abgfosmc.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v928.1) Subject: Re: transaction security in the last mile Date: Fri, 18 Jul 2008 14:56:30 -0700 References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 18, 2008, at 1:16 PM, Florian Weimer wrote: > First of all, I think it's mostly pointless to protect stub to local > ISP > resolver communications. This only requires local source address > validation, so it's something the ISP can and should implement today. You may think you're talking to your ISP when you are not... -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 18 15:33:52 2008 Return-Path: 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 962BC3A68DC; Fri, 18 Jul 2008 15:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 mCzwQKJi4ZYo; Fri, 18 Jul 2008 15:33:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 23D273A68A6; Fri, 18 Jul 2008 15:33:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJyRG-000Dvw-V9 for namedroppers-data@psg.com; Fri, 18 Jul 2008 22:28:34 +0000 Received: from [64.158.219.15] (helo=secure.perfectemail.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KJyRD-000DvV-7A for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 22:28:33 +0000 Received: (qmail 21639 invoked from network); 18 Jul 2008 22:28:30 -0000 Received: from unknown (HELO Zion.local) (38.99.21.47) by secure.perfectemail.net with SMTP; 18 Jul 2008 22:28:30 -0000 Message-ID: <4881190E.8020008@everydns.net> Date: Fri, 18 Jul 2008 15:28:30 -0700 From: David Ulevitch User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Ted Lemon CC: Florian Weimer , Paul Vixie , "namedroppers@ops.ietf.org" Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <69079541-3324-4DD8-87B9-30F8F150CAE1@nominum.com> In-Reply-To: <69079541-3324-4DD8-87B9-30F8F150CAE1@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ted Lemon wrote: > On Jul 18, 2008, at 1:16 PM, Florian Weimer wrote: >> First of all, I think it's mostly pointless to protect stub to local ISP >> resolver communications. This only requires local source address >> validation, so it's something the ISP can and should implement today. > > You may think you're talking to your ISP when you are not... These days it feels like it's more likely the case that you think you ARE NOT talking to your ISP when you in fact really ARE, thanks to their new high-speed packet manglers. Regardless, improving the integrity between the stub resolver and the recursor is long overdue regardless of the vector. -David -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 18 20:37:56 2008 Return-Path: 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 CFCBB3A67BD; Fri, 18 Jul 2008 20:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 VBRXZLXlusLe; Fri, 18 Jul 2008 20:37:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D83C93A67B1; Fri, 18 Jul 2008 20:37:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK3A9-0000uG-E1 for namedroppers-data@psg.com; Sat, 19 Jul 2008 03:31:13 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK3A5-0000tW-A2 for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 03:31:11 +0000 Received: from [10.0.1.198] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id E378E29272B; Fri, 18 Jul 2008 20:31:07 -0700 (PDT) Cc: namedroppers@ops.ietf.org Message-Id: <8EA6740D-8C20-449F-949F-2A7692D3B748@virtualized.org> From: David Conrad To: Paul Vixie In-Reply-To: <61245.1216437051@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: transaction security in the last mile Date: Fri, 18 Jul 2008 20:31:06 -0700 References: <5721.1216397728@nsa.vix.com> <314E9DEF-DA6F-477D-9DC5-F4F5A8C079DC@virtualized.org> <61245.1216437051@nsa.vix.com> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul, On Jul 18, 2008, at 8:10 PM, Paul Vixie wrote: >> 5. if you feel there could be a risk, run a local (validating) RDNS. > after august 6 there will always be a risk, 100% of the time, for > ever and > ever or until Secure DNS is fully implemented end to end (which is > the same > thing). If I have confidence in my firewalls that the bad guys won't be able to spew at my stub resolver, I would feel the risk is mitigated. If I have an IPSEC VPN between me and my caching server, I would feel the risk is mitigated and wouldn't worry about the stub resolver IPC. If I've configured SIG(0), TSIG, GSS-TSIG, etc., I would feel the risk is mitigated. Etc. In all other cases, I'd run a local validating caching server. > do we want to say, stub is dead, stop using it, everybody needs to > run RDNS, including PDAs, IPv6-enabled home appliances, no > exceptions, for > the lifetime of the internet? Personally, if the device is ever going to be open to the Internet, I think this is the right answer. Smart devices, stupid network. And devices are only going to get smarter. Regards, -drc -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 18 22:53:01 2008 Return-Path: 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 1BBF728C0DC; Fri, 18 Jul 2008 22:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 PNOHkA5TGwwC; Fri, 18 Jul 2008 22:53:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ED4D628C0D9; Fri, 18 Jul 2008 22:52:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK5IY-000ImW-Lq for namedroppers-data@psg.com; Sat, 19 Jul 2008 05:48:02 +0000 Received: from [202.28.99.196] (helo=jade.coe.psu.ac.th) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK5IU-000ImA-IP for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 05:48:00 +0000 Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m6J5kC5G003496 for ; Sat, 19 Jul 2008 12:46:34 +0700 (ICT) Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by epsilon.noi.kre.to (8.14.2/8.14.2) with ESMTP id m6J5jDQA019371 for ; Sat, 19 Jul 2008 12:45:52 +0700 (ICT) From: Robert Elz To: namedroppers@ops.ietf.org Subject: Re: transaction security in the last mile In-Reply-To: <5721.1216397728@nsa.vix.com> References: <5721.1216397728@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Jul 2008 12:45:13 +0700 Message-ID: <7344.1216446313@epsilon.noi.kre.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: If the aim is to solve this for the v4 world, because "and furthermore, IPv6 isn't here yet", then there cannot be any solution that really works. v4 is being kept functional (ie: enough address space, the rest of v4 works fine) by more and more addressing hacks, and they are coming to absolutely require DNS hacks along the way to keep things operational. That is, DNS packets MUST be "spoofed" these days in order to keep many parts of the v4 network alive. I put spoofed in quotes, as this isn't being done in any kind of harmful way (except to purity), and the only part of the packet that needs to be altered for this is the RDATA part of A records. That is, all the anti-forgery type techniques in the other draft (and even that foul qname 0x20 hack, in its own draft) are not a problem at all, as alterations to A RDATA aren't affected by any of that - but any kind of crypto integrity mechanism will be, those things are designed to prevent tampering, whereas "tampering" is what is required to keep v4 hobblingalong. Much the same consideration makes Paul's #4 even harder than he suspected, in that these days it isn't really the stub resolver that is really hard to upgrade (and I don't mean to imply that's any easier than Paul suggested) but that the stub server (the thing the resolvers talk to, beats me what current terminology for that is these days) tends to be embedded in off the shelf ADSL routers and such (along with NAT DHCP, and all kinds of address hacking weirdness), and getting those things upgraded is even harder. After all, uSoft can just release a "security patch" and a large fraction of the end systems will get upgraded within weeks, nothing similar exists for those other systems, they're commodity, and more or less untouchable. So, back to the assumption that started this message, "IPv6 isn't here yet". That's really only true in the sense that the incentive to deploy it still doesn't really exist, all those hacks that are keeping v4 working (kind of) are allowing people to defer making v6 really available, with the undoubted (particularly staff education) costs involved. Perhaps DNS security could be the issue that actually provides the impetus to overcome the "no benefit for me that I can see" objections, as in v6 there's no problem using encryption if that turns out to be the solution (that's at least available as an option), and the vast per LAN address space makes other things, like Paul's #3, available as alternatives. That is, maybe this is the time to actually stand up and say that we simply cannot really solve this with v4, and simply give up trying. kre -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 02:10:48 2008 Return-Path: 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 685A53A6942; Sat, 19 Jul 2008 02:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.092 X-Spam-Level: X-Spam-Status: No, score=-102.092 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 iK5YZhL5d3GF; Sat, 19 Jul 2008 02:10:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5DDDB3A6864; Sat, 19 Jul 2008 02:10:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK8Lm-000JNW-TR for namedroppers-data@psg.com; Sat, 19 Jul 2008 09:03:34 +0000 Received: from [2001:14b0:202:1::a7] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK8Lh-000JMs-BN for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 09:03:32 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1KK8LL-0002Zt-GR; Sat, 19 Jul 2008 11:03:07 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1KK8LL-00030P-5f; Sat, 19 Jul 2008 11:03:07 +0200 From: Florian Weimer To: Ted Lemon Cc: Paul Vixie , "namedroppers\@ops.ietf.org" Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <69079541-3324-4DD8-87B9-30F8F150CAE1@nominum.com> Date: Sat, 19 Jul 2008 11:03:07 +0200 Message-ID: <87vdz28cvo.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Ted Lemon: > On Jul 18, 2008, at 1:16 PM, Florian Weimer wrote: >> First of all, I think it's mostly pointless to protect stub to local >> ISP resolver communications. This only requires local source address >> validation, so it's something the ISP can and should implement today. > > You may think you're talking to your ISP when you are not... If you're alluding to malware, that's outside the WG scope. If the ISP is not able to protect traffic to and from his own address space (because customers are connected directly to a layer 2 switch cloud, for instance), this is not really a DNS problem, either. I think the problem is in the opposite direction (i.e. talking to the ISP when you don't want to). -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 02:11:08 2008 Return-Path: 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 792213A6974; Sat, 19 Jul 2008 02:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.107 X-Spam-Level: X-Spam-Status: No, score=-102.107 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 DrY+AJ6SZx2P; Sat, 19 Jul 2008 02:11:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 874773A6942; Sat, 19 Jul 2008 02:11:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK8Nd-000Je1-M8 for namedroppers-data@psg.com; Sat, 19 Jul 2008 09:05:29 +0000 Received: from [2001:14b0:202:1::a7] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KK8Na-000JdV-0n for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 09:05:27 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1KK8NS-0002pE-52; Sat, 19 Jul 2008 11:05:18 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1KK8NR-00031C-1I; Sat, 19 Jul 2008 11:05:17 +0200 From: Florian Weimer To: David Conrad Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <314E9DEF-DA6F-477D-9DC5-F4F5A8C079DC@virtualized.org> Date: Sat, 19 Jul 2008 11:05:17 +0200 In-Reply-To: <314E9DEF-DA6F-477D-9DC5-F4F5A8C079DC@virtualized.org> (David Conrad's message of "Fri, 18 Jul 2008 14:16:40 -0700") Message-ID: <87r69q8cs2.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * David Conrad: > 5. if you feel there could be a risk, run a local (validating) RDNS. Does this really work? Often, when I'm in a hotel room, I get AA=0 RA=1 answers from all authoritative servers (actually, from almost all IP addresses). Somehow I doubt that I can run DNSSEC over this construction. End-to-end DNSSEC validation for mobile devices is currently an unsolved problem. -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 06:30:08 2008 Return-Path: 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 DDDEC28C0F9; Sat, 19 Jul 2008 06:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.109 X-Spam-Level: X-Spam-Status: No, score=-0.109 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] 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 SBuI1bycIGZA; Sat, 19 Jul 2008 06:30:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A702D3A67D4; Sat, 19 Jul 2008 06:30:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKCNp-00043Y-9U for namedroppers-data@psg.com; Sat, 19 Jul 2008 13:21:57 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKCNd-00042U-J0 for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 13:21:55 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6JDLiXU022528 for ; Sat, 19 Jul 2008 09:21:44 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6JDLihe022527 for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 09:21:44 -0400 (EDT) (envelope-from namedroppers) 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 ) id 1KK4ye-000Fyz-HD for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 05:27:31 +0000 Received: by nsa.vix.com (Postfix, from userid 716) id 0455EA10CA; Sat, 19 Jul 2008 05:27:15 +0000 (UTC) To: namedroppers@ops.ietf.org Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> From: Paul Vixie Date: Sat, 19 Jul 2008 05:27:14 +0000 In-Reply-To: (bert hubert's message of "Fri\, 18 Jul 2008 22\:37\:43 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 0455EA10CA.682A4 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@isc.org X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] bert hubert writes: > On Fri, Jul 18, 2008 at 10:16:27PM +0200, Florian Weimer wrote: >> Diffie-Hellman is probably too expensive for key agreement (and the ECC >> variants too encumbered by patents). > > CURVE25519 perhaps? I'm no crypto expert, but to my eyes it looks nice. d-h is very expensive to set up. it's even a tiny bit worse than tcp. it would, as i said at the outset, be important for both stubs and RDNS' to keep state. however, since it's application layer state, rather than kernel state, it's reasonable to consider it for an RDNS serving millions of stubs. which bitswizzler is used in the various one-way transforms inside the D-H is just a detail at this stage of the discussion. wrt DTLS (http://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security or http://crypto.stanford.edu/~nagendra/projects/dtls/dtls.html have background and http://tools.ietf.org/html/draft-rescorla-dtls-05 has the details), i'm concerned about two elements of that protocol. first, it appears that the handshake can be made to fail using spoofed ICMP-Unreach messages, which may not be a problem for most protocols, but in our case the fallback is UDP/53 and so this is a downgrade vector. this is because the first 64 octets of the IP payload, which means the UDP headers and the start of the UDP payload, do not include the randomized bits (so, DTLS' nonce is not within ICMP's nonce). second, and less troubling, DTLS has message secrecy as a goal, which is a red herring that will cause huge debates if we try to standardize on DTLS for stub/RDNS transactions. i'd like it very much if a DTLS expert could show me how the initial handshake messages put highly random content into the part of the IP datagram that must be present in an ICMP-Unreach message. if not, then the fact that stub/RDNS will fallback to UDP/53 on DTLS failure means that some other handshake will have to be designed to carry the D-H exchange. -- Paul Vixie -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 06:32:09 2008 Return-Path: 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 7621A3A6864; Sat, 19 Jul 2008 06:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 OBTlrx60LlJ7; Sat, 19 Jul 2008 06:32:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A3E183A685C; Sat, 19 Jul 2008 06:32:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKCN0-0003v3-69 for namedroppers-data@psg.com; Sat, 19 Jul 2008 13:21:06 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKCMP-0003rx-Q2 for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 13:20:32 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6JDKPWV022494 for ; Sat, 19 Jul 2008 09:20:25 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6JDKPbT022493 for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 09:20:25 -0400 (EDT) (envelope-from namedroppers) 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 ) id 1KJwa5-000LXV-GN for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 20:29:36 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 0DD96A10DA; Fri, 18 Jul 2008 20:29:25 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Florian Weimer cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 18 Jul 2008 22:16:27 +0200." <87abgfosmc.fsf@mid.deneb.enyo.de> References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 18 Jul 2008 20:29:25 +0000 Message-ID: <30271.1216412965@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 0DD96A10DA.81E7C X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: transaction security in the last mile X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] > First of all, I think it's mostly pointless to protect stub to local ISP > resolver communications. This only requires local source address > validation, so it's something the ISP can and should implement today. not all stubs use their ISP for RDNS, and this is an accelerating trend as more and more ISP's deploy nxdomain-remapping to turn errors into ads. -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 06:33:46 2008 Return-Path: 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 E325D3A685C; Sat, 19 Jul 2008 06:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 Z76+3cQiKTGm; Sat, 19 Jul 2008 06:33:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E522E3A6963; Sat, 19 Jul 2008 06:33:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKCMv-0003uU-30 for namedroppers-data@psg.com; Sat, 19 Jul 2008 13:21:01 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKCM0-0003lw-QE for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 13:20:23 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6JDK2aY022484 for ; Sat, 19 Jul 2008 09:20:02 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6JDK2w6022483 for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 09:20:02 -0400 (EDT) (envelope-from namedroppers) 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 ) id 1KJvdV-000BtL-MV for namedroppers@ops.ietf.org; Fri, 18 Jul 2008 19:29:03 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 32062A110F; Fri, 18 Jul 2008 19:28:55 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Alex Bligh cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 18 Jul 2008 20:17:35 +0100." References: <5721.1216397728@nsa.vix.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 18 Jul 2008 19:28:55 +0000 Message-ID: <24965.1216409335@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 32062A110F.CD69B X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: transaction security in the last mile X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] > Question: most of the attack modes these seem to address would also be > avoided by DNSSEC, which wasn't in your "whereas" list. yes, it was: whereas SIG(0) (or is it RRSIG(0) now?) relies on a working Secure DNS system containing a TKEY RR at the RDNS's hostname, which has proven elusive due to the extreme duration of Secure DNS's development and the lack of general interest among anybody other than technology vendors and a few CCTLDs, and > I presume that is on the basis of an estimate of DNSSEC deployment times > exceeding the deployment time of the changes to stub resolvers to > implement 1-4. unless you believe that the tooth fairy is going to touch her golden wand to the head of the U. S. Gov't and make them either set ICANN free or give ICANN permission to sign the root zone, then the deployment of the things SIG(0) depends on is much longer than just the time it will take to touch all of the DNS endpoints in the world. i do not believe in the tooth fairy, though i'd like it if none of you told that to my youngest children. > If so, and if quick deployment is the necessity, are there not existing > protocols that might help? For instance, 2 (diffie-helman) proposes > key exchange etc. Are there not bits of IPsec we could pull (without > encryption) which would do the job? i love the D-H approach except for the downgrade attack (ICMP spoofing) due to the TKEY and TSIG data not being within the first 64 bytes of the payload (which is what ICMP uses for its nonce). and if we're going to change the protocol to put the randomness first, then we wouldn't bother with D-H since it has some state setup and maint costs. if we're inventing a new protocol for the stub/RDNS relationship, we'd invent a stateless one. -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 06:34:17 2008 Return-Path: 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 3AB703A6864; Sat, 19 Jul 2008 06:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.29 X-Spam-Level: X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 d2gN0AquyuJR; Sat, 19 Jul 2008 06:34:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5BFE73A685C; Sat, 19 Jul 2008 06:34:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKCNC-00040V-8L for namedroppers-data@psg.com; Sat, 19 Jul 2008 13:21:18 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKCN8-0003y0-5i for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 13:21:16 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6JDLC2v022516 for ; Sat, 19 Jul 2008 09:21:12 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6JDLCDx022515 for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 09:21:12 -0400 (EDT) (envelope-from namedroppers) 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 ) id 1KK2qY-000OOF-JD for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 03:11:00 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 3FC01A1022; Sat, 19 Jul 2008 03:10:51 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: David Conrad cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 18 Jul 2008 14:16:40 MST." <314E9DEF-DA6F-477D-9DC5-F4F5A8C079DC@virtualized.org> References: <5721.1216397728@nsa.vix.com> <314E9DEF-DA6F-477D-9DC5-F4F5A8C079DC@virtualized.org> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sat, 19 Jul 2008 03:10:51 +0000 Message-ID: <61245.1216437051@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 3FC01A1022.6FD32 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: transaction security in the last mile X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] > 5. if you feel there could be a risk, run a local (validating) RDNS. after august 6 there will always be a risk, 100% of the time, for ever and ever or until Secure DNS is fully implemented end to end (which is the same thing). do we want to say, stub is dead, stop using it, everybody needs to run RDNS, including PDAs, IPv6-enabled home appliances, no exceptions, for the lifetime of the internet? i was thinking we needed to preserve the stub/RDNS relationship. maybe not? -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 12:10:26 2008 Return-Path: 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 ACDC93A6A28; Sat, 19 Jul 2008 12:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 eAGfgVnKWkoc; Sat, 19 Jul 2008 12:10:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B34BF3A6870; Sat, 19 Jul 2008 12:10:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKHf3-0003MF-Eo for namedroppers-data@psg.com; Sat, 19 Jul 2008 19:00:05 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKHez-0003LW-Ue for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 19:00:03 +0000 Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6JIwi1I080124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 19 Jul 2008 11:58:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <5721.1216397728@nsa.vix.com> References: <5721.1216397728@nsa.vix.com> Date: Sat, 19 Jul 2008 11:58:42 -0700 To: namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: transaction security in the last mile Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 4:15 PM +0000 7/18/08, Paul Vixie wrote: >2. diffie-hellman. it is possible, with the exchange of several random >numbers used as encryption and decryption keys, for two endpoints with no >shared secret to establish a trust relationship. Naked Diffie-Hellman results in the two parties having a channel with integrity and privacy, and *no authentication of either party*. If the initiator (stub) wants authentication of the responder (RDNS), then you need to add some sort of authentication to the naked DH. DTLS (and numerous other IETF protocols) does this. > this takes measureable >time and effort, so the existence of this trust relationship is usually >remembered by the endpoints, creating "session state" which can be used to >generate nonces or shared keys. What you have shifted into describing is an establishment protocol for a long-lived, strong mutual key. You don't need Diffie-Hellman to do this: there are lots of other protocols as well. Once you have a long-lived, strong mutual key, you can either use that to integrity-protect the communication stream between the stub and the RDNS, or you can use it to integrity-protect the messages from the RDNS to the stub (such as with an HMAC). The RDNS needs to remember this key for a long time in order to prevent re-establishing the key by mutual re-authentication. >4. new port. most of the constraints are due to backward compatibility >problems, and if we simply allocate a new UDP port, other than 53, then we >can make new rules. it's easy to design a completely stateless replacement >for stub DNS that involves 128-bit random nonces. Note that this does *not* prevent man-in-the-middle attacks such as an intermediate ISP who wants to do their own answering of your queries. It only prevents offline spoofing. If you want to prevent ISP-in-the-middle attacks, you need to add strong authentication for the responder to your protocol. If you want mutual authentication, you need to design that in. --Paul Hoffman, Director --VPN Consortium -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 13:19:02 2008 Return-Path: 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 739FE3A6A31; Sat, 19 Jul 2008 13:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 nMxOpsDW8I1h; Sat, 19 Jul 2008 13:19:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 61E633A6989; Sat, 19 Jul 2008 13:19:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKImW-000E85-1U for namedroppers-data@psg.com; Sat, 19 Jul 2008 20:11:52 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKImS-000E7m-2I for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 20:11:50 +0000 Received: from [10.0.1.198] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id 4777D293ABD; Sat, 19 Jul 2008 13:11:47 -0700 (PDT) Cc: namedroppers@ops.ietf.org Message-Id: <5EFAA1FF-4CAD-44F1-82C6-977DB6BA5F8E@virtualized.org> From: David Conrad To: Florian Weimer In-Reply-To: <87r69q8cs2.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: transaction security in the last mile Date: Sat, 19 Jul 2008 13:11:45 -0700 References: <5721.1216397728@nsa.vix.com> <314E9DEF-DA6F-477D-9DC5-F4F5A8C079DC@virtualized.org> <87r69q8cs2.fsf@mid.deneb.enyo.de> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 19, 2008, at 2:05 AM, Florian Weimer wrote: > * David Conrad: >> 5. if you feel there could be a risk, run a local (validating) RDNS. > Does this really work? Like everything, it depends on how broken the network you're on is. > Often, when I'm in a hotel room, I get AA=0 RA=1 > answers from all authoritative servers (actually, from almost all IP > addresses). Yeah, it is pretty stunning what vendors for hotels (in particular) think is acceptable. And they'll continue to muck things up until their customers, the hotels, scream for them to stop. > Somehow I doubt that I can run DNSSEC over this construction. Actually, if you try, DNSSEC will likely work exactly as advertised -- it'll drop answers due to validation failures as clearly somebody is mucking with the data in transit. > End-to-end DNSSEC validation for mobile devices is currently an > unsolved problem. No. End-to-end DNSSEC validation for mobile devices works fine. End- to-end DNSSEC validation in the face of deliberate byzantine screwage is an unsolved problem and will likely always be. You can get around this screwage the exact same way you get around folks who (say) block all ports except port 80 (also seen at hotels), you figure out what does get through and tunnel somewhere that isn't broken. If you're worried about stuff working in broken hotel walled gardens, then the new port approach is a waste of time, as is the forced TCP approach (since the same walled gardens will almost certainly block TCP port 53) and IPv6 (haven't seen a hotel yet that supports IPv6). Maybe DH will work? Regards, -drc -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 13:29:04 2008 Return-Path: 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 CA4F63A692A; Sat, 19 Jul 2008 13:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.12 X-Spam-Level: X-Spam-Status: No, score=-102.12 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 hnKrHDMWBoM6; Sat, 19 Jul 2008 13:29:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 99EFF3A687C; Sat, 19 Jul 2008 13:29:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKIwA-000Fbh-DI for namedroppers-data@psg.com; Sat, 19 Jul 2008 20:21:50 +0000 Received: from [2001:14b0:202:1::a7] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKIw3-000FaZ-MB for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 20:21:48 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1KKIvz-0000qI-Bu for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 22:21:39 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1KKIvz-00066B-3E for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 22:21:39 +0200 From: Florian Weimer To: namedroppers@ops.ietf.org Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> Date: Sat, 19 Jul 2008 22:21:39 +0200 In-Reply-To: (Paul Vixie's message of "Sat, 19 Jul 2008 05:27:14 +0000") Message-ID: <87iqv1sjzg.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Paul Vixie: > wrt DTLS (http://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security or > http://crypto.stanford.edu/~nagendra/projects/dtls/dtls.html have background > and http://tools.ietf.org/html/draft-rescorla-dtls-05 has the details), i'm > concerned about two elements of that protocol. first, it appears that the > handshake can be made to fail using spoofed ICMP-Unreach messages, which may > not be a problem for most protocols, but in our case the fallback is UDP/53 > and so this is a downgrade vector. You don't downgrade. There's a place from which you get your DNS resolvers, and that place tells you to use the new protocol. > second, and less troubling, DTLS has message secrecy as a goal, which > is a red herring that will cause huge debates if we try to standardize > on DTLS for stub/RDNS transactions. Hmm. I fear we may need message secrecy to get clean resolutions (or any data at all). However, DTLS also supports the NULL cipher. BTW, there's a strange footer at the end of your messages, see . I don't know if it is intended. -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 13:58:04 2008 Return-Path: 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 1A6EA3A697A; Sat, 19 Jul 2008 13:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.486 X-Spam-Level: X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5 tests=[AWL=-0.991, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 5gKX5lGQk5VQ; Sat, 19 Jul 2008 13:58:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 389EC3A688F; Sat, 19 Jul 2008 13:58:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKJOY-000LTr-Mv for namedroppers-data@psg.com; Sat, 19 Jul 2008 20:51:10 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKJOV-000LTT-7A for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 20:51:08 +0000 Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6JKmUR5085950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jul 2008 13:48:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <5EFAA1FF-4CAD-44F1-82C6-977DB6BA5F8E@virtualized.org> References: <5721.1216397728@nsa.vix.com> <314E9DEF-DA6F-477D-9DC5-F4F5A8C079DC@virtualized.org> <87r69q8cs2.fsf@mid.deneb.enyo.de> <5EFAA1FF-4CAD-44F1-82C6-977DB6BA5F8E@virtualized.org> Date: Sat, 19 Jul 2008 13:48:28 -0700 To: David Conrad , Florian Weimer From: Paul Hoffman Subject: Re: transaction security in the last mile Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 1:11 PM -0700 7/19/08, David Conrad wrote: >End-to-end DNSSEC validation for mobile devices works fine. Right. "Mobile" is irrelevant for DNSSEC, fortunately. >End-to-end DNSSEC validation in the face of deliberate byzantine >screwage is an unsolved problem and will likely always be. It *has* to be, by definition. DNSSEC provides integrity. Screwage breaks the one security feature of DNSSEC. If you want your integrity policy to be less than all-or-none, you are begging for creative screwage and then changing your policy to react to it, and so on. >You can get around this screwage the exact same way you get around >folks who (say) block all ports except port 80 (also seen at >hotels), you figure out what does get through and tunnel somewhere >that isn't broken. And then you don't need the integrity protection of DNSSEC, and you can turn it off. >If you're worried about stuff working in broken hotel walled >gardens, then the new port approach is a waste of time, as is the >forced TCP approach (since the same walled gardens will almost >certainly block TCP port 53) and IPv6 (haven't seen a hotel yet that >supports IPv6). >Maybe DH will work? Until the hotel intercepts it, sure. --Paul Hoffman, Director --VPN Consortium -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 14:29:03 2008 Return-Path: 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 453883A68B9; Sat, 19 Jul 2008 14:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 pVh7kIzB4OWi; Sat, 19 Jul 2008 14:29:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7E47D3A6853; Sat, 19 Jul 2008 14:29:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKJtw-0000Qj-TU for namedroppers-data@psg.com; Sat, 19 Jul 2008 21:23:36 +0000 Received: from [64.158.219.15] (helo=secure.perfectemail.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKJtt-0000QF-FC for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 21:23:35 +0000 Received: (qmail 11959 invoked from network); 19 Jul 2008 21:23:22 -0000 Received: from c-71-202-44-149.hsd1.ca.comcast.net (HELO Zion.local) (71.202.44.149) by secure.perfectemail.net with SMTP; 19 Jul 2008 21:23:22 -0000 Message-ID: <48825B49.8070508@everydns.net> Date: Sat, 19 Jul 2008 14:23:21 -0700 From: David Ulevitch User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Florian Weimer CC: Ted Lemon , Paul Vixie , "namedroppers@ops.ietf.org" Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <69079541-3324-4DD8-87B9-30F8F150CAE1@nominum.com> <87vdz28cvo.fsf@mid.deneb.enyo.de> In-Reply-To: <87vdz28cvo.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Florian Weimer wrote: >> * Ted Lemon: > > You may think you're talking to your ISP when you are not... > I think the problem is in the opposite direction (i.e. talking to the > ISP when you don't want to). That is the correct problem statement. -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 16:17:27 2008 Return-Path: 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 5FE243A69A5; Sat, 19 Jul 2008 16:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 pBpAVqkQ6Xni; Sat, 19 Jul 2008 16:17:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 60F5A3A69A3; Sat, 19 Jul 2008 16:17:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKLa2-000FZQ-EP for namedroppers-data@psg.com; Sat, 19 Jul 2008 23:11:10 +0000 Received: from [64.158.219.15] (helo=secure.perfectemail.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKLZy-000FYw-KC for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 23:11:08 +0000 Received: (qmail 23014 invoked from network); 19 Jul 2008 23:11:05 -0000 Received: from c-71-202-44-149.hsd1.ca.comcast.net (HELO Zion.local) (71.202.44.149) by secure.perfectemail.net with SMTP; 19 Jul 2008 23:11:05 -0000 Message-ID: <48827489.6000509@everydns.net> Date: Sat, 19 Jul 2008 16:11:05 -0700 From: David Ulevitch User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Paul Vixie CC: Florian Weimer , Ted Lemon , "namedroppers@ops.ietf.org" Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <69079541-3324-4DD8-87B9-30F8F150CAE1@nominum.com> <87vdz28cvo.fsf@mid.deneb.enyo.de> <48825B49.8070508@everydns.net> <68941.1216508643@nsa.vix.com> In-Reply-To: <68941.1216508643@nsa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: >>> I think the problem is in the opposite direction (i.e. talking to the >>> ISP when you don't want to). >> That is the correct problem statement. > > end users who really just can't tolerate provider-in-the-middle attacks will > use VPN to reach an RDNS they trust, or will run an RDNS of their own using > a VPN through some trusted relay point for their RDNS/ADNS traffic. Agreed. > i therefore reject that problem statement. It was in the context if Ted's view of that specific issue. Perhaps it was off-topic for namedroppers. What is not off-topic, is that people should be able to securely resolve names from the provider of their choice regardless of who their pipe provider is. -David -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 16:35:23 2008 Return-Path: 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 51AE03A6940; Sat, 19 Jul 2008 16:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, SARE_MILLIONSOF=0.315] 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 HiKRcUBUzAd3; Sat, 19 Jul 2008 16:35:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5CCD93A688B; Sat, 19 Jul 2008 16:35:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKLsc-000I75-FV for namedroppers-data@psg.com; Sat, 19 Jul 2008 23:30:22 +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 ) id 1KKLsX-000I6g-S4 for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 23:30:20 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 34806A1049; Sat, 19 Jul 2008 23:30:10 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Florian Weimer cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Sat, 19 Jul 2008 22:21:39 +0200." <87iqv1sjzg.fsf@mid.deneb.enyo.de> References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <87iqv1sjzg.fsf@mid.deneb.enyo.de> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sat, 19 Jul 2008 23:30:10 +0000 Message-ID: <70862.1216510210@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 34806A1049.81B12 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: transaction security in the last mile Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > wrt DTLS ... first, it appears that the handshake can be made to fail > > using spoofed ICMP-Unreach messages, which may not be a problem for > > most protocols, but in our case the fallback is UDP/53 and so this is a > > downgrade vector. > > You don't downgrade. There's a place from which you get your DNS > resolvers, and that place tells you to use the new protocol. in mail to ben laurie cc'ing this list, which the moderators have not yet approved, i spake thusly: in my deployment scenario, we have hundreds of millions of stubs talking to millions of RDNS', and if we require preshared keys we lose, and if we require changes to the DHCP lease options we lose, and if we require that a stub user know whether to expect a given RDNS to support DTLS or not we lose. therefore, whatever new stub/RDNS protocol we put in will have to be opportunistic, such that if it works it gets used and if it doesn't get used then cleartext UDP/53 gets used. therefore, there must not be a trivial way to make the protocol negotiation fail, forcing fallback, or else we've got ourselves a downgrade attack vector (like in EDNS, though please note, i do not regard this as a failing of EDNS.) if DTLS can be forced to fail by sending well timed trivially spoofed ICMP, then it's no protection over what the stub will fall back to. all forms of the "tells you to use the new protocol" are equally impractical due to the extreme size of the installed base, many of which are laptops. either static, or DHCP, or rendezvous, there's no way to roll out a new stub/RDNS fabric that lacks fallback to UDP/53 for its first 20 years of use. but let's turn that around -- do you agree that DTLS is subject to induced failure via spoofed ICMP? and, if so, can we work around it by running the session setup multiple times with unpredictable delays, and then caching the session state for some random period of time of at least several hours? because if so, then fallback can't be forced under those circumstances, and folks who don't want fallback (like you, florian) can just turn it off. > BTW, there's a strange footer at the end of your messages, see > . I don't know if it > is intended. it's not. i'm working on getting rid of that. -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 16:48:22 2008 Return-Path: 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 0E9483A6832; Sat, 19 Jul 2008 16:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599] 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 IqXCJG1galTh; Sat, 19 Jul 2008 16:48:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9C1AA3A6940; Sat, 19 Jul 2008 16:48:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKM3P-000JmL-6a for namedroppers-data@psg.com; Sat, 19 Jul 2008 23:41:31 +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 ) id 1KKM3L-000Jlo-8k for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 23:41:29 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 5C3A4A1022; Sat, 19 Jul 2008 23:41:16 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: David Ulevitch cc: "namedroppers@ops.ietf.org" In-Reply-To: Your message of "Sat, 19 Jul 2008 16:11:05 MST." <48827489.6000509@everydns.net> References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <69079541-3324-4DD8-87B9-30F8F150CAE1@nominum.com> <87vdz28cvo.fsf@mid.deneb.enyo.de> <48825B49.8070508@everydns.net> <68941.1216508643@nsa.vix.com> <48827489.6000509@everydns.net> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sat, 19 Jul 2008 23:41:16 +0000 Message-ID: <71755.1216510876@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 5C3A4A1022.5B630 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: transaction security in the last mile Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > What is not off-topic, is that people should be able to securely resolve > names from the provider of their choice regardless of who their pipe > provider is. > > -David i can think of a huge number of ISP's who would vigorously disagree with that assertion. so while i happen to agree with it, i won't try to defend it in the face of low-margin ISP's who monetize their NXDOMAIN traffic to try to stay alive or be profitable. and while it may be on-topic for namedroppers, it's off-topic in this thread, since my goal is to prevent cache poisoning by true third parties. i don't want to prevent it from being done by an ISP, or by opendns/dnsadvantage, or paxfire. (i mean, i do, but not today.) those are not true third parties since there is an intended relationship between the enduser and each of them. there was not an intended relationship between affected endusers and eugene kashpureff, nor between endusers and drive-by DNS configuration resetters, or between endusers and those who will weaponize dan kaminsky's current exploit once it becomes public. for this thread i want to avoid the debate about whether opendns/dnsadvantage, or an ISP using nominum or paxfire, ought to win their coming war of eyeballs. i just want to talk about attacks by true third parties at the moment. -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 17:12:00 2008 Return-Path: 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 D77813A6890; Sat, 19 Jul 2008 17:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599] 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 BbVQc7Egfv3O; Sat, 19 Jul 2008 17:12:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C5F783A6821; Sat, 19 Jul 2008 17:11:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKMPn-000Muc-W2 for namedroppers-data@psg.com; Sun, 20 Jul 2008 00:04:40 +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 ) id 1KKMPg-000Mqr-Au for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 00:04:37 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 76211A1038; Sun, 20 Jul 2008 00:04:27 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Paul Hoffman cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Sat, 19 Jul 2008 11:58:42 MST." References: <5721.1216397728@nsa.vix.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sun, 20 Jul 2008 00:04:27 +0000 Message-ID: <73445.1216512267@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 76211A1038.90BA1 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: transaction security in the last mile Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Naked Diffie-Hellman results in the two parties having a channel with > integrity and privacy, and *no authentication of either party*. "no"? i think if you can complete that exchange, then it means the agent you then share a channel with persistently has the IP address you used to communicate with them. i say "persistently" since it could be that they really have it and should have it, or that some kind of ARP or routing attack allows them to both send packets from and receive packets to that address even though they shouldn't be allowed to. i can live with that as a difference-without-distinction. if someone really has the IP address i think i should be using for my RDNS, then that's good enough for most purposes. for other purposes, i'll use IPSEC or a VPN with enough pre-shared keying information to guaranty that i'm talking to the actual agent i want to talk to, and not just to someone who can persistently use the IP address i've been told to use. > If the initiator (stub) wants authentication of the responder (RDNS), > then you need to add some sort of authentication to the naked DH. DTLS > (and numerous other IETF protocols) does this. that's a solved problem, as any hotel visitor who IPSEC||VPN's back to their corporate network can tell you. we do not have to handle that as a special case for stub/RDNS communications, because the people who have this problem have it for ALL protocols not just DNS. > What you have shifted into describing is an establishment protocol for a > long-lived, strong mutual key. You don't need Diffie-Hellman to do this: > there are lots of other protocols as well. Once you have a long-lived, > strong mutual key, you can either use that to integrity-protect the > communication stream between the stub and the RDNS, or you can use it to > integrity-protect the messages from the RDNS to the stub (such as with an > HMAC). The RDNS needs to remember this key for a long time in order to > prevent re-establishing the key by mutual re-authentication. fine by me. > Note that this does *not* prevent man-in-the-middle attacks such as an > intermediate ISP who wants to do their own answering of your queries. It > only prevents offline spoofing. > > If you want to prevent ISP-in-the-middle attacks, you need to add strong > authentication for the responder to your protocol. If you want mutual > authentication, you need to design that in. authentication is out of scope for me, anyone motivated enough to want it, can get it, no matter what their ISP or hotel tries to do to them, using IPSEC or VPN. most corporate and government travellers only use the local wired or wireless network as a bearer channel for their VPN. i'm not going to start trying to solve MiTM for DNS as though it was a distinct problem from MiTM in general. i'm only trying to secure a communications path from stub to RDNS against true third parties who want me to believe that www.paypal.com's A RR is some botted web server somewhere -- not the ones who want me to believe that wwww.paypall.comm is their advertising server. -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 20:15:21 2008 Return-Path: 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 27B5B3A69B5; Sat, 19 Jul 2008 20:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[AWL=-0.741, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 XbPiM+Q-gR4m; Sat, 19 Jul 2008 20:15:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5128D3A698C; Sat, 19 Jul 2008 20:15:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKPIL-000MOW-Jq for namedroppers-data@psg.com; Sun, 20 Jul 2008 03:09:09 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKPIH-000MO6-VL for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 03:09:07 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 64012FF26C; Sun, 20 Jul 2008 13:09:07 +1000 (EST) Message-ID: <4882AB94.9050301@e164.org> Date: Sun, 20 Jul 2008 13:05:56 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Paul Vixie CC: Paul Hoffman , namedroppers@ops.ietf.org Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <73445.1216512267@nsa.vix.com> In-Reply-To: <73445.1216512267@nsa.vix.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: Paul Vixie wrote: >> Naked Diffie-Hellman results in the two parties having a channel with >> integrity and privacy, and *no authentication of either party*. > > "no"? i think if you can complete that exchange, then it means the agent > you then share a channel with persistently has the IP address you used to > communicate with them. i say "persistently" since it could be that they > really have it and should have it, or that some kind of ARP or routing > attack allows them to both send packets from and receive packets to that > address even though they shouldn't be allowed to. The point he was trying to make about no authentication is the requests can be intercepted and proxied, just because you have a secure channel, doesn't mean you know who it's to. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 20:50:52 2008 Return-Path: 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 04B6B3A699E; Sat, 19 Jul 2008 20:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.453 X-Spam-Level: X-Spam-Status: No, score=-1.453 tagged_above=-999 required=5 tests=[AWL=-0.958, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 HyP3hab2fUhs; Sat, 19 Jul 2008 20:50:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 773403A6964; Sat, 19 Jul 2008 20:50:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKPso-0001NK-G0 for namedroppers-data@psg.com; Sun, 20 Jul 2008 03:46:50 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKPsk-0001Mu-WF for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 03:46:48 +0000 Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6K3jTHS006188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jul 2008 20:45:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <73445.1216512267@nsa.vix.com> References: <5721.1216397728@nsa.vix.com> <73445.1216512267@nsa.vix.com> Date: Sat, 19 Jul 2008 20:45:23 -0700 To: Paul Vixie From: Paul Hoffman Subject: Re: transaction security in the last mile Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 12:04 AM +0000 7/20/08, Paul Vixie wrote: > > Naked Diffie-Hellman results in the two parties having a channel with >> integrity and privacy, and *no authentication of either party*. > >"no"? Correct: no. >i think if you can complete that exchange, then it means the agent >you then share a channel with persistently has the IP address you used to >communicate with them. Wrong. A man-in-the-middle can do the Diffie-Hellman exchange with you, and then do a different Diffie-Hellman exchange with the host at the IP address you intended to go to, and neither of you will know it. >i say "persistently" since it could be that they >really have it and should have it, or that some kind of ARP or routing >attack allows them to both send packets from and receive packets to that >address even though they shouldn't be allowed to. True, but if you don't care who "they" are. Your long list of whereas' sounded like you cared that you were talking to your RDNS. >i can live with that as a difference-without-distinction. Except that there is a distinction. You have no idea if the system at the IP address when you started the Diffie-Hellman is actually the system you wanted to communicate with. You need authentication in order to know that. >authentication is out of scope for me, You could have said that initially. What you did say, in a thread that has the word "security" in the title, was: >.. i think it's time for a new debate on the nature of the relationship >between the stub and the RDNS. Please forgive those of us had the mistaken impression that this was a debate, not a restricted mandate. --Paul Hoffman, Director --VPN Consortium -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 20:51:40 2008 Return-Path: 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 8505C3A68BC; Sat, 19 Jul 2008 20:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599] 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 TajDLadeS3QH; Sat, 19 Jul 2008 20:51:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0327D3A68C1; Sat, 19 Jul 2008 20:51:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKPpb-0000yO-D6 for namedroppers-data@psg.com; Sun, 20 Jul 2008 03:43:31 +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 ) id 1KKPpX-0000xw-Fs for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 03:43:29 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 74F27A1105; Sun, 20 Jul 2008 03:43:18 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Duane cc: Paul Hoffman , namedroppers@ops.ietf.org In-Reply-To: Your message of "Sun, 20 Jul 2008 13:05:56 +1000." <4882AB94.9050301@e164.org> References: <5721.1216397728@nsa.vix.com> <73445.1216512267@nsa.vix.com> <4882AB94.9050301@e164.org> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sun, 20 Jul 2008 03:43:18 +0000 Message-ID: <90383.1216525398@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 74F27A1105.1DA47 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: transaction security in the last mile Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: From: Duane > The point he was trying to make about no authentication is the requests > can be intercepted and proxied, just because you have a secure channel, > doesn't mean you know who it's to. i understood that perfectly. my counter response was that this is fine for the purpose of stub/RDNS relationships as long as they are SSH-like in that there is an expensive setup involving a generated shared secret and another expensive randomly periodic key rollover. these will have to be retriable in the event of possibly-spoofed ICMP based failures, and any UDP/53 fallback has to be configurably turn-off-able. under those conditions, an instruction from DHCP of "use RDNS a.b.c.d" is sufficient since "who i think it is" is a.b.c.d and that is indeed who it will be to. if an ISP wants to launch a provider-in-the-middle attack, they will have to be able to spoof the address i wanted to reach, persistently, in order to do the secret-exchange dance, both initially and at rollovers. the case i'm guarding against is when i think i'm talking to a.b.c.d and i'm really not. an ISP who can spoof a.b.c.d persistently is dangerous and annoying, but not so dangerous as someone who isn't my ISP spoofing it in a flood of QID-guessed responses as was demonstrated last year by amit klein. again, i really don't care to change the method by which a stub learns to use a given RDNS, and that method is, "use a.b.c.d". no keys, no secrets, no identity information. but with sufficient state, this can be made more secure than it is now. (fallback in a hotel room is interesting. if the prospective new protocol does not work, would a hotel visitor prefer no internet service at all, or would they drag out their VPN machinery, or would they just send their DNS queries in UDP/53 and be mightily suspicious about what came back? this is interesting in like of KRE's observation that DNS spoofery may be necessary to preserve the illusion of IPv4 reachability when we run out of new IPv4 addresses but want to keep growing with IPv4.) -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 20:51:53 2008 Return-Path: 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 692D73A68B3; Sat, 19 Jul 2008 20:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.215 X-Spam-Level: X-Spam-Status: No, score=-1.215 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 mNXBUFik68jX; Sat, 19 Jul 2008 20:51:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 76DEA3A68BC; Sat, 19 Jul 2008 20:51:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKPut-0001cx-Pi for namedroppers-data@psg.com; Sun, 20 Jul 2008 03:48:59 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKPuq-0001cj-Dg for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 03:48:58 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 2812BFF26C; Sun, 20 Jul 2008 13:48:57 +1000 (EST) Message-ID: <4882B4ED.4060304@e164.org> Date: Sun, 20 Jul 2008 13:45:49 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Paul Vixie CC: Paul Hoffman , namedroppers@ops.ietf.org Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <73445.1216512267@nsa.vix.com> <4882AB94.9050301@e164.org> <90383.1216525398@nsa.vix.com> In-Reply-To: <90383.1216525398@nsa.vix.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: Paul Vixie wrote: > i understood that perfectly. my counter response was that this is fine for > the purpose of stub/RDNS relationships as long as they are SSH-like in that > there is an expensive setup involving a generated shared secret and another > expensive randomly periodic key rollover. these will have to be retriable > in the event of possibly-spoofed ICMP based failures, and any UDP/53 fallback > has to be configurably turn-off-able. I realise what you are getting at when you say SSH-like, but SSH uses public key cryptography which is why you get the message about fingerprints, but I'm all for that :) -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 23:23:42 2008 Return-Path: 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 BCF4928C0CF; Sat, 19 Jul 2008 23:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] 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 m9QYLFDLp2d0; Sat, 19 Jul 2008 23:23:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F6DD3A6908; Sat, 19 Jul 2008 23:23:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKSBH-000JTO-RZ for namedroppers-data@psg.com; Sun, 20 Jul 2008 06:14:03 +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 ) id 1KKSBD-000JT1-Rh for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 06:14:01 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 4D5D3A1031; Sun, 20 Jul 2008 06:13:48 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Paul Hoffman cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Sat, 19 Jul 2008 20:45:23 MST." References: <5721.1216397728@nsa.vix.com> <73445.1216512267@nsa.vix.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sun, 20 Jul 2008 06:13:48 +0000 Message-ID: <1482.1216534428@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 4D5D3A1031.88926 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: transaction security in the last mile Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > >i think if you can complete that exchange, then it means the agent you > >then share a channel with persistently has the IP address you used to > >communicate with them. > > Wrong. A man-in-the-middle can do the Diffie-Hellman exchange with you, > and then do a different Diffie-Hellman exchange with the host at the IP > address you intended to go to, and neither of you will know it. that's a danger i'd like to have the luxury of worrying about, but since solving it would require that a stub be told more than just an IP address as a way to reach its RDNS, i consider it out of scope. besides which, it is again not the kind of attack i'm worried about. the next time someone like amit klein breaks a PRNG and wants to inject spoofed-source responses i would like to be able to ignore them at the outset. > ... Your long list of whereas' sounded like you cared that you were > talking to your RDNS. i should have explained my problem statement better. if someone can take over the ip address i'm trying to use as my RDNS, then nothing will save me except DNSSEC. after all, they could also just take over the RDNS server itself; who am i to judge which of those two similar sounding problems is worthy, and which is not? > >i can live with that as a difference-without-distinction. > > Except that there is a distinction. You have no idea if the system at the > IP address when you started the Diffie-Hellman is actually the system you > wanted to communicate with. You need authentication in order to know that. so you'd like this to be like SSH, where there's a binding between the host key used by the responder, and the expected value maintained by the initiator, and either a new key or a rolled key would require out-of-band config? this is the scary stuff, for me, since if we need a new DHCP element to carry the expected host key, it'll take years longer to roll this out. and if we have a popup window to ask if some new key is OK, then most users will just click OK so they can get back to their work. i'm currently exploring a "no new config elements" and "if your RDNS or its IP address gets pwned, then you shoulda used DNSSEC" path forward, because we have an installed base rather than a blank slate to work within, and if we can't deploy this for several years, then we should just push DNSSEC. > >authentication is out of scope for me, > > You could have said that initially. What you did say, in a thread that has > the word "security" in the title, was: > > >.. i think it's time for a new debate on the nature of the relationship > >between the stub and the RDNS. > > Please forgive those of us had the mistaken impression that this was a > debate, not a restricted mandate. if you have ideas in this area which you want to explore publically, don't let me stand in your way. it's not my place to mandate topics here. i am just trying to learn what's possible within some narrow constraints. if those constraints rule out this problem space then i'm sorry to have wasted your time. it's just that we already solved the authenticated stub/RDNS relationship problem, five times. IPSEC, GSS-TSIG, TKEY/TSIG, TSIG, and SIG(0). anyone willing to configure shared secrets before doing RDNS has that power. we could even define a DTLS profile for DNS on UDP/253. but i don't know if we can get apple and microsoft to implement that on their clients if it makes the user experience more complex, especially if there are no servers answering with it right away, and no DHCP servers capable of carrying the keying info, and that's assuming we trust DHCP to carry the keying info. -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 19 23:52:07 2008 Return-Path: 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 564813A6962; Sat, 19 Jul 2008 23:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.205 X-Spam-Level: X-Spam-Status: No, score=-1.205 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 bI-iU1SWtcwZ; Sat, 19 Jul 2008 23:52:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 508D63A6858; Sat, 19 Jul 2008 23:52:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKShk-000O1h-BZ for namedroppers-data@psg.com; Sun, 20 Jul 2008 06:47:36 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKShg-000O1F-Si for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 06:47:34 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 1E3F9FF26C; Sun, 20 Jul 2008 16:47:34 +1000 (EST) Message-ID: <4882DEC6.5000902@e164.org> Date: Sun, 20 Jul 2008 16:44:22 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Paul Vixie CC: Paul Hoffman , namedroppers@ops.ietf.org Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <73445.1216512267@nsa.vix.com> <1482.1216534428@nsa.vix.com> In-Reply-To: <1482.1216534428@nsa.vix.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: Paul Vixie wrote: > so you'd like this to be like SSH, where there's a binding between the host > key used by the responder, and the expected value maintained by the > initiator, and either a new key or a rolled key would require out-of-band > config? this is the scary stuff, for me, since if we need a new DHCP > element to carry the expected host key, it'll take years longer to roll > this out. and if we have a popup window to ask if some new key is OK, then > most users will just click OK so they can get back to their work. Actually the draft I'm trying to get comments on the at the moment does just this minus the pop-ups which generally serve no useful purpose as you pointed out. SMTP-TLS is humming away just fine for the most part and can be hop-by-hop or end to end depending if you run your own mail server or use someone else's etc. Prolonged man in the middle attacks by the 3rd parties you are thinking of are usually expensive to some degree to keep them going, so as long as you track the keys used to communicate with and only throw up warnings when things change all should be well usually. The alternative is just as you wrote about hotels with broken resolvers, you would have to fall back, tunnel or ... to be able to resolve hostnames. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 07:12:50 2008 Return-Path: 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 776503A69B8; Sun, 20 Jul 2008 07:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 0lqzSkKtFEaK; Sun, 20 Jul 2008 07:12:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 865AE3A68E7; Sun, 20 Jul 2008 07:12:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKZV2-000CCf-VM for namedroppers-data@psg.com; Sun, 20 Jul 2008 14:02:56 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKZUz-000CBs-9Q for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 14:02:55 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id AE6F0C2DA3; Sun, 20 Jul 2008 15:02:48 +0100 (BST) Date: Sun, 20 Jul 2008 15:02:46 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , Paul Hoffman cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: transaction security in the last mile Message-ID: <95C54B750BB6CF6CCD3478B9@Ximines.local> In-Reply-To: <1482.1216534428@nsa.vix.com> References: <5721.1216397728@nsa.vix.com> <73445.1216512267@nsa.vix.com> <1482.1216534428@nsa.vix.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 20 July 2008 06:13:48 +0000 Paul Vixie wrote: >> Wrong. A man-in-the-middle can do the Diffie-Hellman exchange with you, >> and then do a different Diffie-Hellman exchange with the host at the IP >> address you intended to go to, and neither of you will know it. > > that's a danger i'd like to have the luxury of worrying about, but since > solving it would require that a stub be told more than just an IP address > as a way to reach its RDNS, i consider it out of scope. besides which, it > is again not the kind of attack i'm worried about. the next time someone > like amit klein breaks a PRNG and wants to inject spoofed-source responses > i would like to be able to ignore them at the outset. A better reason not to worry about authentication is as follows: If we are worried about authentication at all, we should be worried about authentication of the RDNS to the stub resolver, and not vice versa (I haven't seen reasons for anyone to care if a "fake" stub queries a resolver besides the DoS amplification routes). However, if we are worried about the stub authenticating the RDNS (to avoid an MITM attack), the stub would (as Paul Vixie says) need some info about the real RDNS (such as a public key) to ensure it is the real DNS. Where did it get this information from, in an environment where the stub is mobile? The answer, invariably, is BOOTP/DHCP, which is just as susceptible to MITM attacks. Rather than work out how to insert a MITM on some form of DH protected link between the stub resolver and the RDNS, wouldn't an attacker just fake the DHCP response and give an entirely bogus set of DNS server results? Far easier, and (I would suggest) far more effective. If you are worried about threats like the above, the answer is to IPsec to something with a trusted RDNS behind it, or run your own RDNS (though I note this itself is vulnerable to MITM attacks by the simple expedient of intercepting every DNS query to the root servers). Alex -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 09:18:25 2008 Return-Path: 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 3747D3A6999; Sun, 20 Jul 2008 09:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[AWL=-0.927, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 Kefdo1yoJn1k; Sun, 20 Jul 2008 09:18:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 40B7B3A6841; Sun, 20 Jul 2008 09:18:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKbX6-0009DG-PB for namedroppers-data@psg.com; Sun, 20 Jul 2008 16:13:12 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKbX2-0009Ca-Vw for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 16:13:10 +0000 Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6KGBpDF047793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jul 2008 09:11:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1482.1216534428@nsa.vix.com> References: <5721.1216397728@nsa.vix.com> <73445.1216512267@nsa.vix.com> <1482.1216534428@nsa.vix.com> Date: Sun, 20 Jul 2008 09:11:48 -0700 To: Paul Vixie From: Paul Hoffman Subject: Re: transaction security in the last mile Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 6:13 AM +0000 7/20/08, Paul Vixie wrote: >i should have explained my problem statement better. +1 >if someone can take >over the ip address i'm trying to use as my RDNS, then nothing will save >me except DNSSEC. Not true, but not relevant for what I think your problem statement is. >after all, they could also just take over the RDNS >server itself; who am i to judge which of those two similar sounding >problems is worthy, and which is not? For many attackers, it is much easier to "take over the IP address" of a host than to take control of the host itself. Man-in-the-middle attacks act like taking over the IP address. (I only bring those two up because they are myths that might come back on the list later.) So, let's go back to your problem. I hate it when people put words in my mouth, but I'm going to try to do that to you in a way where you can correct me. To make that clearer, I won't yell out my proposed solution until I'm sure we have a complete and correct problem statement. 1) The attack being defended against is an off-path attacker flooding the stub with guesses at responses to queries so that the attacker can spoof an answer to an expected query. 2) Stub has gotten the IP address of the RDNS in a possibly-untrusted fashion such as DHCP. 3) Stub and RDNS don't have a long-term preshared secret because managing those out of band is difficult. 4) Stub doesn't have the signing key of the RDNS. 5) Man-in-the-middle attacks are not of interest. If there is a smart man-in-the-middle, they win. 6) There is a strong desire to minimize expensive calculations (D-H and/or signatures), particularly those that would expose the RDNS to CPU exhaustion attacks. Paul: is that complete and correct? If not, please edit. --Paul Hoffman, Director --VPN Consortium -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 09:25:14 2008 Return-Path: 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 786043A6A27; Sun, 20 Jul 2008 09:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 rS1iB89cie2q; Sun, 20 Jul 2008 09:25:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B4343A6A00; Sun, 20 Jul 2008 09:25:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKbdt-000BkU-Op for namedroppers-data@psg.com; Sun, 20 Jul 2008 16:20:13 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKbdp-000Bjo-Lt for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 16:20:11 +0000 Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6KGIW8r048132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jul 2008 09:18:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <95C54B750BB6CF6CCD3478B9@Ximines.local> References: <5721.1216397728@nsa.vix.com> <73445.1216512267@nsa.vix.com> <1482.1216534428@nsa.vix.com> <95C54B750BB6CF6CCD3478B9@Ximines.local> Date: Sun, 20 Jul 2008 09:18:30 -0700 To: Alex Bligh From: Paul Hoffman Subject: Re: transaction security in the last mile Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 3:02 PM +0100 7/20/08, Alex Bligh wrote: >However, if we are worried about the stub authenticating the RDNS (to avoid >an MITM attack), the stub would (as Paul Vixie says) need some info about >the real RDNS (such as a public key) to ensure it is the real DNS. Where >did it get this information from, in an environment where the stub is >mobile? The answer, invariably, is BOOTP/DHCP, which is just as susceptible >to MITM attacks. Good question. The answer you give is true for most deployments today, but there are other possible answers for different potential protocol changes in the future. If this is a problem we want to deal with (and that's not clear; it's not one that is in scope for Paul Vixie's thread), there is plenty we can do other than throw up our hands. >If you are worried about threats like the above, the answer is to IPsec s/the/an/ There are many others. --Paul Hoffman, Director --VPN Consortium -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 10:23:32 2008 Return-Path: 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 84DCE3A6975; Sun, 20 Jul 2008 10:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] 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 41W0s-BBGIgE; Sun, 20 Jul 2008 10:23:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 41F9D3A6841; Sun, 20 Jul 2008 10:23:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKcVy-000L69-OH for namedroppers-data@psg.com; Sun, 20 Jul 2008 17:16:06 +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 ) id 1KKcVs-000L5K-PK for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 17:16:04 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 5A648A1108 for ; Sun, 20 Jul 2008 17:15:45 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: dns hop by hop transaction security for queries X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sun, 20 Jul 2008 17:15:45 +0000 Message-ID: <55957.1216574145@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 5A648A1108.3BCB4 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: i have learned quite a lot about what's possible and how things work from the recent thread "transaction security in the last mile" and i now have a proposal to float. i'm sorry i won't be in dublin to discuss this in the hallways, but hopefully discussions will occur and i will hear about them through this mailing list. problem statement: BCP38 can never be nonfalsifiably universally deployed, so any given IP datagram's source address must always remain suspect. the basic DNS query transaction uses two-packet UDP (request and response), and each side (initiator and responder) is vulnerable to spoofed-source attacks, where the initiator can be poisoned by untrue DNS data sent by an attacker and the responder can be made to amplify a DDoS against innocent parties. background: DNSSEC offers both end to end data authenticity through its DNSKEY, RRSIG, and NSEC{3} records, and stub/RDNS data authenticity through its {RR}SIG(0) protocol. deployment of DNSSEC in the root and COM zones is stalled for political and economic reasons (respectively), and there is no path forward involving private right of action by interested subsets of the community. (leaving aside DLV, which is such a way, but is shrouded in controversy.) GSS-TSIG offers stub/RDNS transaction authenticity but requires that the stub and RDNS both be inside a fully functioning Kerberos realm, which is not practical outside the enterprise (for example, in ISPs or hotel rooms.) TSIG offers stub/RDNS transaction authenticity but requires that a shared secret be installed by some out of band method, which is impractical for query relationships due to the number of stub/RDNS relationships. TSIG is very successful for zone transfer and update relationships, which are fewer. TKEY offers a way to establish a TSIG shared secret where the only starting configuration data is that the initiator must know the responder's IP address (which is true in the case of stubs and their RDNS'.) DHCP could be made to carry an additional configuration element, "TSIG key", to be associated with a given responder. this follows from the fact that if DHCP is spoofable, then the entire DHCP response is suspect, including the elements for "RDNS IP". as long as responder-side TSIGs were kept longer than the DHCP lease time, this would work. however, it's known that many DNS initiators do not use DHCP at all, so this solution would be incomplete. IPSEC and VPN's in general can be used to protect stub/RDNS transactions at a higher configuration cost which is unjustifiable for the average DNS client and which generally requires greater than average technical expertise. be it noted, ICMP is also subject to spoofed-source attacks, and any UDP flow even of short two-packet duration can be interrupted and made to fail. this is true but to a lesser extent for TCP flows. parameters: a solution here would be opportunistic and pairwise deployable, requiring no flag days; it would require no new technical expertise for end users; it would have only graceful failure modes; it would not be subject to downgrade attacks; and ideally, it would require no new protocol development work. proposal: stubs, and caching forwarding servers, when acting as initiators, should use TKEY over TCP/53 to try to set up a shared secret with their responders. if successful, this secret should be used for UDP/53 queries to that responder. if TKEY over TCP/53 is successful for some responders but not others, then the successful ones will be used exclusively. if at least one TSIG signed query transaction succeeds to a responder, and then later transactions fail with TSIG errors (BADSIG) then TKEY over TCP/53 should be repeated. if no TSIG signed query ever succeeds, then after some small number of retries, the TKEY should be discarded and no longer used. in cases where there is TKEY over TCP/53 fails, or where a TKEY was acquired but then discarded, then TSIG must not be used on transactions to that responder. discussion: there would be no protocol changes and no API changes. this uses only DNS protocol elements which are already defined, requiring only implementation and deployment. there is no reason for an API change since applications are not expected to behave differently based on the degree of certainty in the stub/RDNS transaction. this could be argued as applicable to RDNS/ADNS relationships as well, perhaps even when the RDNS contains a DNSSEC validator, but whereas the number of TKEY over TCP/53 transactions is manageable, the amount of state that both RDNS and ADNS would have to store and access, may not be. initiators who implement the logic described in this proposal may have an additional configuration knob, "TKEY and TSIG must succeed", either on a per-responder basis, or globally. this would disable fallback to UDP/53 and would render that endsystem unusable if the last mile DNS is not secure. note that initiators with that knob would experience "flag day" behaviour, rather than the softer opportunistic behaviour experienced otherwise. that's all. -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 11:13:03 2008 Return-Path: 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 7DA553A6A4D; Sun, 20 Jul 2008 11:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] 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 xvEgkna-j4e7; Sun, 20 Jul 2008 11:13:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9FD353A6A03; Sun, 20 Jul 2008 11:13:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKdIz-0003aX-PC for namedroppers-data@psg.com; Sun, 20 Jul 2008 18:06:45 +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 ) id 1KKdIv-0003aD-Rk for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 18:06:43 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id F15DEA1049; Sun, 20 Jul 2008 18:06:36 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Paul Hoffman cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Sun, 20 Jul 2008 09:11:48 MST." References: <5721.1216397728@nsa.vix.com> <73445.1216512267@nsa.vix.com> <1482.1216534428@nsa.vix.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sun, 20 Jul 2008 18:06:36 +0000 Message-ID: <60233.1216577196@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: F15DEA1049.56FA3 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: transaction security in the last mile Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > ... To make that clearer, I won't yell out my proposed solution > until I'm sure we have a complete and correct problem statement. i've just issued a problem statement, analysis, and proposed solution, under the title, "dns hop by hop transaction security for queries". > ... > Paul: is that complete and correct? If not, please edit. yes. fortunately for all of us, donald eastlake got here years ago, and this can most likely be done without protocol or API changes, just some work by DNS implementors and integrators and operators. -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 11:26:39 2008 Return-Path: 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 5DB7C3A6A03; Sun, 20 Jul 2008 11:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] 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 8CBwIyZMLKXk; Sun, 20 Jul 2008 11:26:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D1453A6903; Sun, 20 Jul 2008 11:26:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKdXD-0006Cw-Mh for namedroppers-data@psg.com; Sun, 20 Jul 2008 18:21:27 +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 ) id 1KKdX9-0006CP-5N for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 18:21:25 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 2AE98A1038; Sun, 20 Jul 2008 18:21:18 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Ben Laurie cc: Duane , Paul Hoffman , namedroppers@ops.ietf.org In-Reply-To: Your message of "Sun, 20 Jul 2008 18:19:05 +0100." <48837389.6050600@links.org> References: <5721.1216397728@nsa.vix.com> <73445.1216512267@nsa.vix.com> <4882AB94.9050301@e164.org> <90383.1216525398@nsa.vix.com> <48837389.6050600@links.org> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sun, 20 Jul 2008 18:21:18 +0000 Message-ID: <61332.1216578078@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 2AE98A1038.EE5D2 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: transaction security in the last mile Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Ben Laurie > > Paul Vixie wrote: > > under those conditions, an instruction from DHCP of "use RDNS a.b.c.d" > > is sufficient since "who i think it is" is a.b.c.d and that is indeed > > who it will be to. if an ISP wants to launch a provider-in-the-middle > > attack, they will have to be able to spoof the address i wanted to > > reach, persistently, in order to do the secret-exchange dance, both > > initially and at rollovers. > > Not quite getting this. If the address came from DHCP, then who you think > it is is irrelevant. You are talking to whomever the ISP wanted you to > talk to. i must have said it in the wrong order, thus conveying undue meaning. if you're going to trust DHCP, then you are at the mercy of your L2/L3 provider, one way or the other. if on the other hand you prefer to use opendns or dnsadvantage, or you are still using a static open resolver from three ISP's ago, then you are still at the mercy of your L2/L3 provider. if you do not want to be at the mercy of your L2/L3 provider, then you have to use some kind of VPN, not just to protect your DNS against eyeball thieves but to protect your HTTP against eyeball thieves. note that right now, the average ISP or hotel has a hands-off approach to VPN, because it's rare and because the people who want to use it are mostly high-end corpies and govvies. but if ever VPN became ubiquitous, then the hotels and ISPs of the world would start fighting back, since there would be too much revenue loss, and because the average VPN user would become less powerful (a fatter target). we'll call this "the eyeball wars" in the history books. i'd like DNS to remain neutral but sell arms to all sides of the conflict. > From: Ben Laurie > > Paul Vixie wrote: > > (fallback in a hotel room is interesting. if the prospective new > > protocol does not work, would a hotel visitor prefer no internet > > service at all, or would they drag out their VPN machinery, or would > > they just send their DNS queries in UDP/53 and be mightily suspicious > > about what came back? this is interesting in like of KRE's observation > > that DNS spoofery may be necessary to preserve the illusion of IPv4 > > reachability when we run out of new IPv4 addresses but want to keep > > growing with IPv4.) > > This is crazy talk. then you should argue with Message-ID: <7344.1216446313@epsilon.noi.kre.to> rather than with me. i take most of what robert elz says without a grain of salt. -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 11:47:37 2008 Return-Path: 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 283023A6968; Sun, 20 Jul 2008 11:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[AWL=-2.087, BAYES_00=-2.599, FRT_STOCK2=3.988, SARE_WEOFFER=0.3] 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 dV7xX5VTJRsO; Sun, 20 Jul 2008 11:47:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C73613A6A74; Sun, 20 Jul 2008 11:47:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKdsQ-000AFL-NQ for namedroppers-data@psg.com; Sun, 20 Jul 2008 18:43:22 +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 ) id 1KKdsM-000AAa-5f for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 18:43:20 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 0C65AA1108; Sun, 20 Jul 2008 18:43:10 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Eric Rescorla cc: Ben Laurie , namedroppers@ops.ietf.org In-Reply-To: Your message of "Sun, 20 Jul 2008 10:23:47 MST." <20080720172348.CC45050846@romeo.rtfm.com> References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <48832197.80603@links.org> <46510.1216569565@nsa.vix.com> <20080720172348.CC45050846@romeo.rtfm.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sun, 20 Jul 2008 18:43:10 +0000 Message-ID: <63353.1216579390@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 0C65AA1108.B3EAC X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: transaction security in the last mile Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Eric Rescorla > > Paul Vixie wrote: > > so, either there can be no fallback, or there must be additional > > configuration information for the stub/RDNS relationship (beyond the > > RDNS's IP address; for example it could include a TSIG shared-secret.) > > True. Though it could also just contain the one bit of information > that the server will do a secure channel, right? in for a dime, in for a dollar. it's not the number of new bits, it's that the number of new bits is zero or not. > > TCP however is not subject to this kind of spoofed-ICMP induced failure. > > Because the ISN is in the first 64 bits and ISNs are hard to predict? that's my hope, but since i thought it was bytes not bits, it could be that the ISN isn't in the first 64 quatloos, and TCP can be shot in the head by spoofed ICMP just as easily as UCP can. > > so perhaps i've been overthinking this. what if ... > > > > be it noted, there is still no authentication here. ... > > Without taking a position on this particular design, I think there's a > high order question about whether you'd like to authenticate the server > of just get continuity, right? there is no question that all i care about here is continuity, since the larger problem of endpoint authentication already has plenty of solutions and all of them have high cost and most of that high cost is due to the fact that there are a nonzero number of new bits of configuration data. > If you do, then you should do the initial key establishment via some > public key authentication mechanism, at minimum SSH-style leap of faith. i don't see microsoft or apple adopting that approach for their stubs. it is not reasonable to present an end user with a popup that asks them for input they know they are not qualified to give. so, that's why i'm not trying to do an SSH-style leap of faith on this. > On a slightly different note, wouldn't another possibility be to simply > ignore ICMP unreachables and rely on timeouts? that tends to be a kernel change rather than an application change. there may even be a setsockopt() that does this on some BSD-like or Linux-like operating systems, or on WIN32-like operating systems, but not on all of them. if we offer a new mechanism that's only secure after a change to the kernel's UDP stack, then we'll never be sure what got deployed, but we can safely bet that it won't be universal. note, i have posted a new problem statement, analysis, and proposal, under the name, "dns hop by hop transaction security for queries", Message-ID: <55957.1216574145@nsa.vix.com>. if you're not on namedroppers, i can send you a copy, just ask. -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 12:16:29 2008 Return-Path: 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 95F123A6A89; Sun, 20 Jul 2008 12:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 nQdS0FR0RaII; Sun, 20 Jul 2008 12:16:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A3C1F3A6A06; Sun, 20 Jul 2008 12:16:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKeKy-000FWm-OM for namedroppers-data@psg.com; Sun, 20 Jul 2008 19:12:52 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKeKu-000FWC-Sn for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 19:12:50 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 83B62C2DA3; Sun, 20 Jul 2008 20:12:45 +0100 (BST) Date: Sun, 20 Jul 2008 20:12:41 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: dns hop by hop transaction security for queries Message-ID: In-Reply-To: <55957.1216574145@nsa.vix.com> References: <55957.1216574145@nsa.vix.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 20 July 2008 17:15:45 +0000 Paul Vixie wrote: > stubs, and caching forwarding servers, when acting as initiators, should > use TKEY over TCP/53 to try to set up a shared secret with their > responders. if successful, this secret should be used for UDP/53 queries > to that responder. if TKEY over TCP/53 is successful for some responders > but not others, then the successful ones will be used exclusively. if at > least one TSIG signed query transaction succeeds to a responder, and then > later transactions fail with TSIG errors (BADSIG) then TKEY over TCP/53 > should be repeated. if no TSIG signed query ever succeeds, then after > some small number of retries, the TKEY should be discarded and no longer > used. in cases where there is TKEY over TCP/53 fails, or where a TKEY was > acquired but then discarded, then TSIG must not be used on transactions to > that responder. Data point: several reasonably large deployments use UDP only RDNS configured in an anycast manner. A typical configuration for a dial ISP many years ago and a DSL ISP now might be several DNS servers sharing the same pair of IP addresses at each POP. This means there are only 2 IP addresses to present at a tech support level. As far as I know, most implementations either don't do TCP at all or just hope it works over short session periods. The above proposal would require (I think) that they all somehow shared state (or at least that state was shared at the POP, or that the same IP address was always mapped to the same RDNS, at least by hashing). That doesn't make this undoable, but complicates it if the idea is to avoid fallback in such scenarios. Alex -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 12:23:22 2008 Return-Path: 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 8AB033A69CA; Sun, 20 Jul 2008 12:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599] 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 ZHjSNo9n7nDa; Sun, 20 Jul 2008 12:23:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 424633A6A83; Sun, 20 Jul 2008 12:23:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKeRz-000GnU-KF for namedroppers-data@psg.com; Sun, 20 Jul 2008 19:20:07 +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 ) id 1KKeRv-000Gmq-Ii for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 19:20:05 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id CB4C3A10CA; Sun, 20 Jul 2008 19:19:59 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Ben Laurie cc: namedroppers@ops.ietf.org, Eric Rescorla In-Reply-To: Your message of "Sun, 20 Jul 2008 20:09:00 +0100." <48838D4C.6060306@links.org> References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <48832197.80603@links.org> <46510.1216569565@nsa.vix.com> <488369D1.7010507@links.org> <60426.1216577373@nsa.vix.com> <48838D4C.6060306@links.org> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sun, 20 Jul 2008 19:19:59 +0000 Message-ID: <66932.1216581599@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: CB4C3A10CA.C2117 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: transaction security in the last mile Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > >> So why not DTLS-over-UDP/53 falling back to plain-over-UDP/53? > > > > because TKEY already exists. see RFC 2930. > > I think it would be fair to say that DTLS already exists, too, and provides > properties TKEY does not. DTLS would be a new protocol for stubs and RDNS to speak, but i'll ask, features does DTLS have that TKEY doesn't have and do we need those? -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 12:30:41 2008 Return-Path: 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 604783A69CC; Sun, 20 Jul 2008 12:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] 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 hInGgin2ZGZl; Sun, 20 Jul 2008 12:30:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6835E3A69CA; Sun, 20 Jul 2008 12:30:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKeX5-000Hfv-8K for namedroppers-data@psg.com; Sun, 20 Jul 2008 19:25:23 +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 ) id 1KKeX1-000HdY-3p for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 19:25:21 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id DBA5AA1031; Sun, 20 Jul 2008 19:25:14 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Alex Bligh cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Sun, 20 Jul 2008 20:12:41 +0100." References: <55957.1216574145@nsa.vix.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sun, 20 Jul 2008 19:25:14 +0000 Message-ID: <67546.1216581914@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: DBA5AA1031.3293B X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: dns hop by hop transaction security for queries Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Alex Bligh > > Data point: several reasonably large deployments use UDP only RDNS > configured in an anycast manner. A typical configuration for a dial ISP > many years ago and a DSL ISP now might be several DNS servers sharing the > same pair of IP addresses at each POP. This means there are only 2 IP > addresses to present at a tech support level. As far as I know, most > implementations either don't do TCP at all or just hope it works over > short session periods. The above proposal would require (I think) that > they all somehow shared state (or at least that state was shared at the > POP, or that the same IP address was always mapped to the same RDNS, at > least by hashing). That doesn't make this undoable, but complicates it if > the idea is to avoid fallback in such scenarios. if there's a routing change so that the RDNS you did TKEY with moves away and you become close to a different anycast instance (same IP new host) then TSIG will start failing and you'll go back and do a new TKEY. this strikes me as a better model than state-sharing in wide area anycast. for local area anycast ("load balancing") i agree that state sharing would be required among all members of a local anycast cluster. i'm sure that RDNS vendors who implement TKEY would happily compete on their anycast usability. -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 14:31:11 2008 Return-Path: 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 9F0433A68C9; Sun, 20 Jul 2008 14:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.187 X-Spam-Level: X-Spam-Status: No, score=-1.187 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 LGmPG8YcDg0a; Sun, 20 Jul 2008 14:31:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C4A133A6778; Sun, 20 Jul 2008 14:31:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKgPO-000BDp-Uq for namedroppers-data@psg.com; Sun, 20 Jul 2008 21:25:34 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKgPL-000BDB-FD for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 21:25:33 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 1132AFF26D; Mon, 21 Jul 2008 07:25:28 +1000 (EST) Message-ID: <4883AC81.1080008@e164.org> Date: Mon, 21 Jul 2008 07:22:09 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: dns hop by hop transaction security for queries References: <55957.1216574145@nsa.vix.com> In-Reply-To: <55957.1216574145@nsa.vix.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4FFF6B4BC793E82EA4B4210B" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4FFF6B4BC793E82EA4B4210B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Paul Vixie wrote: > TKEY offers a way to establish a TSIG shared secret where the only star= ting > configuration data is that the initiator must know the responder's IP > address (which is true in the case of stubs and their RDNS'.) I see at least a few major flaws with TKEY because most of the information is sent plain text, so to speak, and could easily be tampered with by anyone doing a man in the middle attack. It was suggested I use this for my draft but the more I think about it the more I come to the conclusion it's poorly thought out from a security perspective as it will only defend against spoofed packets. --=20 Best regards, Duane --------------enig4FFF6B4BC793E82EA4B4210B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIg6yCEpWoZMmo/c8RAvyZAJ4h+mlkjnhqIcKdC9yG08PMAmIMrACdEuIz NmvEfeX5g4dxSmGmNiUrpgQ= =C9Sz -----END PGP SIGNATURE----- --------------enig4FFF6B4BC793E82EA4B4210B-- -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 16:18:03 2008 Return-Path: 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 5C77528C0FA; Sun, 20 Jul 2008 16:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599] 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 wTFbOA3Ek6gC; Sun, 20 Jul 2008 16:18:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7369728C0F7; Sun, 20 Jul 2008 16:18:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKi4N-0002kr-AB for namedroppers-data@psg.com; Sun, 20 Jul 2008 23:11:59 +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 ) id 1KKi4J-0002kS-N7 for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 23:11:57 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 0CE3EA1031; Sun, 20 Jul 2008 23:11:48 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Duane cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Mon, 21 Jul 2008 07:22:09 +1000." <4883AC81.1080008@e164.org> References: <55957.1216574145@nsa.vix.com> <4883AC81.1080008@e164.org> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sun, 20 Jul 2008 23:11:48 +0000 Message-ID: <87989.1216595508@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 0CE3EA1031.5ACF9 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: dns hop by hop transaction security for queries Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Duane > > I see at least a few major flaws with TKEY because most of the > information is sent plain text, so to speak, and could easily be > tampered with by anyone doing a man in the middle attack. a persistent MiTM who can both send and receive packets from/to an IP is not part of my current problem statement. (in that case one might also ask why we expect non-DNSSEC transactions between RDNS/ADNS to work, or why we think that UDP port randomization or DNS-0x30 or even XQID would help.) > It was suggested I use this for my draft but the more I think about it > the more I come to the conclusion it's poorly thought out from a > security perspective as it will only defend against spoofed packets. since spoofed packets are the problem statement i've got, i'll quibble with "poor... security". spoofed packets are far more commonly available as a tool for attackers than persistent MiTM (send and receive from/to an IP.) i am especially attracted to any proposal that can be developed and implemented without new protocol or API development, and which can be deployed pairwise without any action at a distance by unknown parties. -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 16:43:21 2008 Return-Path: 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 359363A67CE; Sun, 20 Jul 2008 16:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.169 X-Spam-Level: X-Spam-Status: No, score=-1.169 tagged_above=-999 required=5 tests=[AWL=-0.674, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 gzBW7satbu5A; Sun, 20 Jul 2008 16:43:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 50B2E3A677C; Sun, 20 Jul 2008 16:43:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKiUs-00088W-I1 for namedroppers-data@psg.com; Sun, 20 Jul 2008 23:39:22 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKiUp-000881-3s for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 23:39:20 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 8C65E5AC5AF; Mon, 21 Jul 2008 09:39:17 +1000 (EST) Message-ID: <4883CBDF.2010902@e164.org> Date: Mon, 21 Jul 2008 09:35:59 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: dns hop by hop transaction security for queries References: <55957.1216574145@nsa.vix.com> <4883AC81.1080008@e164.org> <87989.1216595508@nsa.vix.com> In-Reply-To: <87989.1216595508@nsa.vix.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: Paul Vixie wrote: > i am especially attracted to any proposal that can be developed and > implemented without new protocol or API development, and which can be > deployed pairwise without any action at a distance by unknown parties. Ok if spoofing is the problem you wish to solve, the simple solution would be to increase the number of random bits to the point that it is statistically improbable to be successful with such an attack, because really 2^17 as best case is really really small, and based on what everyone is implying what the recent patching is supposed to fix I'm guessing up until recently most resolvers must be coming up with a much smaller pool of numbers than that. A trivial solution that wouldn't break anything might be just to prefix something to the front of all hostnames that both ends strip before processing them, 63 octets will give you 504 bits. This doesn't require DH or any kind encryption or what not, it does require a good source of entropy and/or a good cryptography hashing algorithm to change the prefix for every request, the requests/replies could still be cached after stripping the randomness from the front etc. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 17:01:38 2008 Return-Path: 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 8681D3A6951; Sun, 20 Jul 2008 17:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.153 X-Spam-Level: X-Spam-Status: No, score=-1.153 tagged_above=-999 required=5 tests=[AWL=-0.658, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 v+K6QdH13MvU; Sun, 20 Jul 2008 17:01:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B86263A6AA0; Sun, 20 Jul 2008 17:01:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKimU-000BGy-9t for namedroppers-data@psg.com; Sun, 20 Jul 2008 23:57:34 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKimQ-000BGX-Ui for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 23:57:32 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 3A1C9FF26F; Mon, 21 Jul 2008 09:57:31 +1000 (EST) Message-ID: <4883D026.3030908@e164.org> Date: Mon, 21 Jul 2008 09:54:14 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: dns hop by hop transaction security for queries References: <55957.1216574145@nsa.vix.com> <4883AC81.1080008@e164.org> <87989.1216595508@nsa.vix.com> <4883CBDF.2010902@e164.org> In-Reply-To: <4883CBDF.2010902@e164.org> 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: Duane wrote: > A trivial solution that wouldn't break anything might be just to prefix > something to the front of all hostnames that both ends strip before > processing them, 63 octets will give you 504 bits. This was assuming only hexadecimal was used, if you use the full range of characters allowed for hostnames you get almost 2400 bits. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 17:54:05 2008 Return-Path: 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 A70703A6A0C; Sun, 20 Jul 2008 17:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.366 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 zCCq4xn7WWMq; Sun, 20 Jul 2008 17:54:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C42F73A69B1; Sun, 20 Jul 2008 17:54:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKjaA-000KUx-Gq for namedroppers-data@psg.com; Mon, 21 Jul 2008 00:48:54 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKja7-000KUW-1s for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 00:48:52 +0000 Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6L0lWPa075866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jul 2008 17:47:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4883CBDF.2010902@e164.org> References: <55957.1216574145@nsa.vix.com> <4883AC81.1080008@e164.org> <87989.1216595508@nsa.vix.com> <4883CBDF.2010902@e164.org> Date: Sun, 20 Jul 2008 17:47:30 -0700 To: Duane From: Paul Hoffman Subject: Re: dns hop by hop transaction security for queries Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 9:35 AM +1000 7/21/08, Duane wrote: >A trivial solution that wouldn't break anything might be just to prefix >something to the front of all hostnames that both ends strip before >processing them I'm confused. How would a responder know to strip them without a change of the protocol? --Paul Hoffman, Director --VPN Consortium -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 18:07:33 2008 Return-Path: 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 1EF553A6A0C; Sun, 20 Jul 2008 18:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 r3qs9ouRavaX; Sun, 20 Jul 2008 18:07:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4880B3A68F2; Sun, 20 Jul 2008 18:07:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKjok-000N55-Lr for namedroppers-data@psg.com; Mon, 21 Jul 2008 01:03:58 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKjoh-000N4W-8r for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 01:03:56 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 8816F5AC5BA; Mon, 21 Jul 2008 11:03:56 +1000 (EST) Message-ID: <4883DFB5.6010403@e164.org> Date: Mon, 21 Jul 2008 11:00:37 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: dns hop by hop transaction security for queries References: <55957.1216574145@nsa.vix.com> <4883AC81.1080008@e164.org> <87989.1216595508@nsa.vix.com> <4883CBDF.2010902@e164.org> <4883D026.3030908@e164.org> In-Reply-To: <4883D026.3030908@e164.org> 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: Duane wrote: > Duane wrote: > >> A trivial solution that wouldn't break anything might be just to prefix >> something to the front of all hostnames that both ends strip before >> processing them, 63 octets will give you 504 bits. > > This was assuming only hexadecimal was used, if you use the full range > of characters allowed for hostnames you get almost 2400 bits. Actually I'm having a bad math day all round. 64 bytes of hex is 2^256, so 63 bytes of hex would be 2^252, using a 38 character set instead would give you 2^441. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 18:15:08 2008 Return-Path: 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 C8F1A3A6AC8; Sun, 20 Jul 2008 18:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 Gv71pVCn-oeP; Sun, 20 Jul 2008 18:15:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DEDE33A6A8C; Sun, 20 Jul 2008 18:15:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKjwE-000OTW-GN for namedroppers-data@psg.com; Mon, 21 Jul 2008 01:11:42 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKjwA-000OT7-U4 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 01:11:40 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 7B4975AC5BF; Mon, 21 Jul 2008 11:11:40 +1000 (EST) Message-ID: <4883E186.1040900@e164.org> Date: Mon, 21 Jul 2008 11:08:22 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Paul Hoffman CC: namedroppers@ops.ietf.org Subject: Re: dns hop by hop transaction security for queries References: <55957.1216574145@nsa.vix.com> <4883AC81.1080008@e164.org> <87989.1216595508@nsa.vix.com> <4883CBDF.2010902@e164.org> In-Reply-To: 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: Paul Hoffman wrote: > At 9:35 AM +1000 7/21/08, Duane wrote: >> A trivial solution that wouldn't break anything might be just to prefix >> something to the front of all hostnames that both ends strip before >> processing them > > I'm confused. How would a responder know to strip them without a change > of the protocol? I don't know what the best way to implement such a method would be, which is why I didn't want to suggest anything, in any case if the goal is simply to prevent spoofing, rather than protecting against man in the middle attacks you need to increase the Query ID size significantly. If I was going to take a stab at this maybe something along the lines of what most binary file types use, some kind of a 2-3 byte header, so if the first 3 characters of such a prefix were _XID that still leaves 59 other characters to expand the number of bits, if you get a nonsense reply back you know that the host doesn't support such queries, but the reply should still have the complete "hostname" so that should prevent a downgrade attack. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 19:23:32 2008 Return-Path: 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 16FAD3A680A; Sun, 20 Jul 2008 19:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] 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 fzutoI7Sap42; Sun, 20 Jul 2008 19:23:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 018E03A67EF; Sun, 20 Jul 2008 19:23:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKkzI-000ArW-4v for namedroppers-data@psg.com; Mon, 21 Jul 2008 02:18:56 +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 ) id 1KKkzD-000Anz-PG for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 02:18:53 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 3410CA1031; Mon, 21 Jul 2008 02:18:40 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Duane cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Mon, 21 Jul 2008 09:35:59 +1000." <4883CBDF.2010902@e164.org> References: <55957.1216574145@nsa.vix.com> <4883AC81.1080008@e164.org> <87989.1216595508@nsa.vix.com> <4883CBDF.2010902@e164.org> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Mon, 21 Jul 2008 02:18:40 +0000 Message-ID: <1942.1216606720@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 3410CA1031.3C339 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: dns hop by hop transaction security for queries Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Duane > > Paul Vixie wrote: > > i am especially attracted to any proposal that can be developed and > > implemented without new protocol or API development, and which can be > > deployed pairwise without any action at a distance by unknown parties. > > ... > > A trivial solution that wouldn't break anything might be just to prefix > something to the front of all hostnames that both ends strip before > processing them, 63 octets will give you 504 bits. forget for a moment all your bad math (note, i can't count quatloos either.) if we wanted to use the question section to hold more nonce bits, we'd set QDCOUNT=2 and the second question would be for .ECHO and the RFC on this topic would just say, if QDCOUNT is 2 and the TLD of the second question is ECHO, then this must be copied into the response along with the rest of the question section (bit for bit, to accomodate DNS-0x20), and will not affect the processing of the response in any other way. fallback would mean the server did not answer or sends a FORMERR or ignores the second question. since an of those can be spoofed by a downgrade attack, this approach would require a more-than-two-packet negotiation sequence. your approach of adding another label to the front of the QNAME of QDCOUNT=1 is also subject to downgrade attacks, and would require more-than-two-packet negotiation as well. if we're going to negotiate, then that means either DTLS or TKEY-over-TCP. and if we're going to do TKEY-over-TCP then we should just use TSIG for the queries. whereas if we're going to use DTLS to negotiate then we should use DTLS to protect the queries. so, i can't find a case in which we would use either an extra label in the question, or an extra question, to encode extra bits. -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 19:33:37 2008 Return-Path: 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 3BF653A6837; Sun, 20 Jul 2008 19:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 1ZliHE8O5xYL; Sun, 20 Jul 2008 19:33:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 26D6F3A67EF; Sun, 20 Jul 2008 19:33:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKl8Z-000CR4-KH for namedroppers-data@psg.com; Mon, 21 Jul 2008 02:28:31 +0000 Received: from [209.85.132.243] (helo=an-out-0708.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKl8U-000CQW-Pb for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 02:28:29 +0000 Received: by an-out-0708.google.com with SMTP id c24so442215ana.18 for ; Sun, 20 Jul 2008 19:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=DKRna0P7rvcGPgsCFdzbX33pmy4DP6VUTI5oVRQRWv8=; b=Ag2QT9Gr6/TZ4A8LlbB/9X0R7AlvwLpg1JwVEshXhZHqWgrjaeksoR5oftOluZOFeI p5y70D3Y04idrtwP1at3PWRmNRFWA4fLHRbvaCu3jmjpI3NVbULzW08VPt97XphV6Qp0 NjUf/YOWMKooTou7P++sIqGlBsfZSqxO3Ndmc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=NHgiB6Ntq2scIyybVgjVfi8RLUcDKvu5q1rTGtDF9TRKnE/afMfJ8wvZXJNzeeIWew o2oJCkbCWbs3USYLLqPt+5hYnVzKVAe4lADdl10xNLh3DcmRnShojYd0GIiQaYm9HS0E Ki9Iv3xbBC45eP4pdaR5ITLd/iFOFzRvUvoZA= Received: by 10.100.119.12 with SMTP id r12mr1529236anc.73.1216607303745; Sun, 20 Jul 2008 19:28:23 -0700 (PDT) Received: by 10.100.92.20 with HTTP; Sun, 20 Jul 2008 19:28:23 -0700 (PDT) Message-ID: <1028365c0807201928l39b592dcoa5d49b3857979233@mail.gmail.com> Date: Sun, 20 Jul 2008 22:28:23 -0400 From: "Donald Eastlake" To: Duane Subject: Re: dns hop by hop transaction security for queries Cc: namedroppers@ops.ietf.org In-Reply-To: <4883E186.1040900@e164.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_102993_1526227.1216607303716" References: <55957.1216574145@nsa.vix.com> <4883AC81.1080008@e164.org> <87989.1216595508@nsa.vix.com> <4883CBDF.2010902@e164.org> <4883E186.1040900@e164.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ------=_Part_102993_1526227.1216607303716 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline If you are going to have to teach DNS implementations to strip these funny name prefixes, why not teach them to use cookies or something like them: http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-03.txt. Donald On Sun, Jul 20, 2008 at 9:08 PM, Duane wrote: > Paul Hoffman wrote: > > At 9:35 AM +1000 7/21/08, Duane wrote: > >> A trivial solution that wouldn't break anything might be just to prefix > >> something to the front of all hostnames that both ends strip before > >> processing them > > > > I'm confused. How would a responder know to strip them without a change > > of the protocol? > > I don't know what the best way to implement such a method would be, > which is why I didn't want to suggest anything, in any case if the goal > is simply to prevent spoofing, rather than protecting against man in the > middle attacks you need to increase the Query ID size significantly. > > If I was going to take a stab at this maybe something along the lines of > what most binary file types use, some kind of a 2-3 byte header, so if > the first 3 characters of such a prefix were _XID that still leaves 59 > other characters to expand the number of bits, if you get a nonsense > reply back you know that the host doesn't support such queries, but the > reply should still have the complete "hostname" so that should prevent a > downgrade attack. > > -- > > Best regards, > Duane > > -- > 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: > -- ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com ------=_Part_102993_1526227.1216607303716 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
If you are going to have to teach DNS implementations to strip these funny name prefixes, why not teach them to use cookies or something like them: http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-03.txt.

Donald

On Sun, Jul 20, 2008 at 9:08 PM, Duane <duane@e164.org> wrote:
Paul Hoffman wrote:
> At 9:35 AM +1000 7/21/08, Duane wrote:
>> A trivial solution that wouldn't break anything might be just to prefix
>> something to the front of all hostnames that both ends strip before
>> processing them
>
> I'm confused. How would a responder know to strip them without a change
> of the protocol?

I don't know what the best way to implement such a method would be,
which is why I didn't want to suggest anything, in any case if the goal
is simply to prevent spoofing, rather than protecting against man in the
middle attacks you need to increase the Query ID size significantly.

If I was going to take a stab at this maybe something along the lines of
what most binary file types use, some kind of a 2-3 byte header, so if
the first 3 characters of such a prefix were _XID that still leaves 59
other characters to expand the number of bits, if you get a nonsense
reply back you know that the host doesn't support such queries, but the
reply should still have the complete "hostname" so that should prevent a
downgrade attack.

--

Best regards,
 Duane

--
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/>



--
=============================
Donald E. Eastlake 3rd +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3@gmail.com
------=_Part_102993_1526227.1216607303716-- -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 19:44:04 2008 Return-Path: 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 9695A3A685A; Sun, 20 Jul 2008 19:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 uA3ii2W0vPye; Sun, 20 Jul 2008 19:44:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6B2943A6837; Sun, 20 Jul 2008 19:44:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKlI9-000EHb-KK for namedroppers-data@psg.com; Mon, 21 Jul 2008 02:38:25 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKlI5-000EGt-LC for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 02:38:23 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id B86C1FF26F; Mon, 21 Jul 2008 12:38:22 +1000 (EST) Message-ID: <4883F5D6.8030505@e164.org> Date: Mon, 21 Jul 2008 12:35:02 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Donald Eastlake CC: namedroppers@ops.ietf.org Subject: Re: dns hop by hop transaction security for queries References: <55957.1216574145@nsa.vix.com> <4883AC81.1080008@e164.org> <87989.1216595508@nsa.vix.com> <4883CBDF.2010902@e164.org> <4883E186.1040900@e164.org> <1028365c0807201928l39b592dcoa5d49b3857979233@mail.gmail.com> In-Reply-To: <1028365c0807201928l39b592dcoa5d49b3857979233@mail.gmail.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: Donald Eastlake wrote: > If you are going to have to teach DNS implementations to strip these > funny name prefixes, why not teach them to use cookies or something like > them: http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-03.txt. Session IDs in cookies is exactly the thing I was thinking of actually, how many languages that use Session ID on websites of only 2^17 combinations? (answer: none) Although if you have already solved this I'll stop making guesses. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 19:47:42 2008 Return-Path: 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 368B63A68EC; Sun, 20 Jul 2008 19:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.338 X-Spam-Level: X-Spam-Status: No, score=-1.338 tagged_above=-999 required=5 tests=[AWL=-0.843, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 YaUp02MHobVN; Sun, 20 Jul 2008 19:47:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5912B3A67FC; Sun, 20 Jul 2008 19:47:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKlNn-000FQ4-5l for namedroppers-data@psg.com; Mon, 21 Jul 2008 02:44:15 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKlNj-000FPc-8s for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 02:44:13 +0000 Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6L2gnJ7081063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jul 2008 19:42:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4883E186.1040900@e164.org> References: <55957.1216574145@nsa.vix.com> <4883AC81.1080008@e164.org> <87989.1216595508@nsa.vix.com> <4883CBDF.2010902@e164.org> <4883E186.1040900@e164.org> Date: Sun, 20 Jul 2008 19:42:48 -0700 To: Duane From: Paul Hoffman Subject: Re: dns hop by hop transaction security for queries Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 11:08 AM +1000 7/21/08, Duane wrote: >Paul Hoffman wrote: >> At 9:35 AM +1000 7/21/08, Duane wrote: >>> A trivial solution that wouldn't break anything might be just to prefix >>> something to the front of all hostnames that both ends strip before >>> processing them >> >> I'm confused. How would a responder know to strip them without a change >> of the protocol? > >I don't know what the best way to implement such a method would be, >which is why I didn't want to suggest anything, in any case if the goal >is simply to prevent spoofing, rather than protecting against man in the >middle attacks you need to increase the Query ID size significantly. > >If I was going to take a stab at this maybe something along the lines of >what most binary file types use, some kind of a 2-3 byte header, so if >the first 3 characters of such a prefix were _XID that still leaves 59 >other characters to expand the number of bits, if you get a nonsense >reply back you know that the host doesn't support such queries, but the >reply should still have the complete "hostname" so that should prevent a >downgrade attack. Let me try again. Paul wants a method that is an operational change, not a protocol change. Your suggestions seem like protocol changes to me. Is that correct, or am I missing something? --Paul Hoffman, Director --VPN Consortium -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 20:42:58 2008 Return-Path: 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 577963A695D; Sun, 20 Jul 2008 20:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.157 X-Spam-Level: X-Spam-Status: No, score=-1.157 tagged_above=-999 required=5 tests=[AWL=-0.662, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 kh5uIdTAKL6H; Sun, 20 Jul 2008 20:42:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 107A13A68F4; Sun, 20 Jul 2008 20:42:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKmDU-000P6i-TC for namedroppers-data@psg.com; Mon, 21 Jul 2008 03:37:40 +0000 Received: from [74.95.2.169] (helo=kilo.rtfm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKmDJ-000P5b-6h for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 03:37:31 +0000 Received: from kilo.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id A0BCF4978EE; Sun, 20 Jul 2008 20:37:28 -0700 (PDT) Date: Sun, 20 Jul 2008 20:37:28 -0700 From: Eric Rescorla To: Duane Cc: Donald Eastlake , namedroppers@ops.ietf.org Subject: Re: dns hop by hop transaction security for queries In-Reply-To: <4883F5D6.8030505@e164.org> References: <55957.1216574145@nsa.vix.com> <4883AC81.1080008@e164.org> <87989.1216595508@nsa.vix.com> <4883CBDF.2010902@e164.org> <4883E186.1040900@e164.org> <1028365c0807201928l39b592dcoa5d49b3857979233@mail.gmail.com> <4883F5D6.8030505@e164.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080721033728.A0BCF4978EE@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Mon, 21 Jul 2008 12:35:02 +1000, Duane wrote: > > Donald Eastlake wrote: > > If you are going to have to teach DNS implementations to strip these > > funny name prefixes, why not teach them to use cookies or something like > > them: http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-03.txt. > > Session IDs in cookies is exactly the thing I was thinking of actually, > how many languages that use Session ID on websites of only 2^17 > combinations? (answer: none) > > Although if you have already solved this I'll stop making guesses. I'm trying to come up to speed here, so apologies if what I'm about to say is confused or if I'm using the wrong terminology. As I understand the situation, it's pretty well agreed that there's no approach that provides the requisite level of entropy without enhancing both the client and the server. Moreover, it's straightforward to design a system with acceptable security where we change both client and server. The only issue is how best to pack the entropy into the protocol. So, the tricky issue is how to construct a system which doesn't allow off-path attackers to convince the client that the server doesn't speak the new, stronger version. In order for this to happen, even an unenhanced server needs to echo back the entropy value provided by the client. Otherwise, an offpath attacker can forge a negative response. It seems like Duane's suggested name mangling scheme has this property, no? -Ekr -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 21:17:22 2008 Return-Path: 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 811653A6ABB; Sun, 20 Jul 2008 21:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_31=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 hkpg60tDz-31; Sun, 20 Jul 2008 21:17:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 867333A6AB8; Sun, 20 Jul 2008 21:17:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKmkZ-0004cj-34 for namedroppers-data@psg.com; Mon, 21 Jul 2008 04:11:51 +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 ) id 1KKmkV-0004cJ-30 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 04:11:49 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 500A1A10CA; Mon, 21 Jul 2008 04:11:35 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Eric Rescorla cc: Duane , Donald Eastlake , namedroppers@ops.ietf.org In-Reply-To: Your message of "Sun, 20 Jul 2008 20:37:28 MST." <20080721033728.A0BCF4978EE@kilo.rtfm.com> References: <55957.1216574145@nsa.vix.com> <4883AC81.1080008@e164.org> <87989.1216595508@nsa.vix.com> <4883CBDF.2010902@e164.org> <4883E186.1040900@e164.org> <1028365c0807201928l39b592dcoa5d49b3857979233@mail.gmail.com> <4883F5D6.8030505@e164.org> <20080721033728.A0BCF4978EE@kilo.rtfm.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Mon, 21 Jul 2008 04:11:35 +0000 Message-ID: <10949.1216613495@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 500A1A10CA.B7073 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: dns hop by hop transaction security for queries Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Donald Eastlake wrote: > If you are going to have to teach DNS implementations to strip these > funny name prefixes, why not teach them to use cookies or something like > them: > > http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-03.txt. i prefer donald's previous work (TKEY) which, with TCP transport, is not subject to downgrade attacks as XQID, cookies, and EDNS all are. > From: Eric Rescorla > > ... > As I understand the situation, it's pretty well agreed that there's no > approach that provides the requisite level of entropy without enhancing > both the client and the server. Moreover, it's straightforward to design > a system with acceptable security where we change both client and server. > The only issue is how best to pack the entropy into the protocol. this is close, but subtly incorrect on a factual basis. it is easy to think about and propose and discuss protocol changes that would add entropy, but it is very hard (where difficulty is measured in number of years before wide public use of the new mechanism) to standardize, implement, and deploy such. > So, the tricky issue is how to construct a system which doesn't allow > off-path attackers to convince the client that the server doesn't speak > the new, stronger version. In order for this to happen, even an > unenhanced server needs to echo back the entropy value provided by the > client. Otherwise, an offpath attacker can forge a negative response. It > seems like Duane's suggested name mangling scheme has this property, no? again, this is close, but there are wheels within wheels. the thing we have to prevent a forger from doing is convincing us (erroneously) that the new higher-strength mechanism did not work, and it's nec'y to go back to normal DNS without the additional protections. one way to do that is, as you say, to have even unenhanced responders echo back the new entropy. that's what draft-forgery-resilience does, and that's what draft-0x20 does. it's not what draft-xqid or draft-cookies or any form of RFC-TSIG does, and it's not what "add an extra label to the QNAME" or "add an extra question" would do and it's not what anything based on EDNS would do. those things all require changes to the responder in order to get new entropy echoed, so the responder in those proposals would be "enhanced" rather than "unenhanced." but, the other way to prevent forgers from convincing an initiator to fall back to lower-strength mechanisms, is to negotiate the use of new higher strength mechanisms using a negotiation protocol, such as TKEY over TCP, which is really "nontrivial" if not outright "damned difficult" to interfere with from off-path, even if an attacker has the ability to spoof IP source addresses, and time their packets perfectly well. that's what i proposed in my message here yesterday which is at the top of this thread ("dns hop by hop transaction security for queries"). -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 21:59:58 2008 Return-Path: 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 615FF3A698C; Sun, 20 Jul 2008 21:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 oMcChOqHvcgx; Sun, 20 Jul 2008 21:59:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3E69B3A696B; Sun, 20 Jul 2008 21:59:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKnQx-000CX9-UR for namedroppers-data@psg.com; Mon, 21 Jul 2008 04:55:39 +0000 Received: from [74.95.2.169] (helo=kilo.rtfm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKnQu-000CWp-A1 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 04:55:38 +0000 Received: from kilo.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id BA391498162; Sun, 20 Jul 2008 21:48:32 -0700 (PDT) Date: Sun, 20 Jul 2008 21:48:32 -0700 From: Eric Rescorla To: Ben Laurie Cc: Eric Rescorla , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: transaction security in the last mile In-Reply-To: <48841429.6050905@links.org> References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <48832197.80603@links.org> <46510.1216569565@nsa.vix.com> <20080720172348.CC45050846@romeo.rtfm.com> <63353.1216579390@nsa.vix.com> <20080720224723.A215850846@romeo.rtfm.com> <48841429.6050905@links.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080721044832.BA391498162@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Mon, 21 Jul 2008 05:44:25 +0100, Ben Laurie wrote: > > Eric Rescorla wrote: > > At Sun, 20 Jul 2008 18:43:10 +0000, > > Paul Vixie wrote: > >>> From: Eric Rescorla > >>> > >>> Paul Vixie wrote: > >>>> so, either there can be no fallback, or there must be additional > >>>> configuration information for the stub/RDNS relationship (beyond the > >>>> RDNS's IP address; for example it could include a TSIG shared-secret.) > >>> True. Though it could also just contain the one bit of information > >>> that the server will do a secure channel, right? > >> in for a dime, in for a dollar. it's not the number of new bits, it's > >> that the number of new bits is zero or not. > > > > Well, I agree that there's a qualitative difference between 0 and 1, > > but I think there's still a pretty big difference between 1 and 160. > > > > > >>> If you do, then you should do the initial key establishment via some > >>> public key authentication mechanism, at minimum SSH-style leap of faith. > >> i don't see microsoft or apple adopting that approach for their stubs. it > >> is not reasonable to present an end user with a popup that asks them for > >> input they know they are not qualified to give. so, that's why i'm not > >> trying to do an SSH-style leap of faith on this. > > > > So, I'm not saying that l-o-f will necessarily work here, but > > I don't think it's necessary to prompt the user. Rather, you > > can just accept the first key you see... > > And prompt them when it changes? Good question. Probably retry via the original channel. I agree it's not a real adequate answer... -Ekr -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 20 22:35:31 2008 Return-Path: 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 ED22528B23E; Sun, 20 Jul 2008 22:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599] 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 pJqvc2oTNgBa; Sun, 20 Jul 2008 22:35:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BBCF53A68DE; Sun, 20 Jul 2008 22:35:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKnxr-000IFJ-B7 for namedroppers-data@psg.com; Mon, 21 Jul 2008 05:29:39 +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 ) id 1KKnxn-000IEo-LX for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 05:29:37 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 0DEE8A1107; Mon, 21 Jul 2008 05:29:25 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Eric Rescorla cc: Ben Laurie , namedroppers@ops.ietf.org In-Reply-To: Your message of "Sun, 20 Jul 2008 21:48:32 MST." <20080721044832.BA391498162@kilo.rtfm.com> References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <48832197.80603@links.org> <46510.1216569565@nsa.vix.com> <20080720172348.CC45050846@romeo.rtfm.com> <63353.1216579390@nsa.vix.com> <20080720224723.A215850846@romeo.rtfm.com> <48841429.6050905@links.org> <20080721044832.BA391498162@kilo.rtfm.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Mon, 21 Jul 2008 05:29:25 +0000 Message-ID: <16908.1216618165@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 0DEE8A1107.B2C06 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: transaction security in the last mile Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > And prompt them when it changes? > > Good question. Probably retry via the original channel. I agree it's not > a real adequate answer... in Message-ID: <55957.1216574145@nsa.vix.com> which is the top of the thread whose subject is "dns hop by hop transaction security for queries", i wrote: ... if at least one TSIG signed query transaction succeeds to a responder, and then later transactions fail with TSIG errors (BADSIG) then TKEY over TCP/53 should be repeated. if no TSIG signed query ever succeeds, then after some small number of retries, the TKEY should be discarded and no longer used. ... in case this wasn't clear, there is no great answer, but my proposal is that if a key stops working, you renegotiate a new key with whoever now operates the internet radio station at the address you're trying to use as your RDNS. this points up an obvious but inevitable and necessary weakness, which is that an on-path MiTM can insert himself into your trust with no barriers. i'm not worried about this, since off-path IP spoofing attacks are the problem i'm trying to solve, and on-path MiTM already has so many non-DNS powers that i really think anyone worried about on-path MiTM is already going to be using one of the authenticated protocols like DNSSEC, SIG(0), GSS-TSIG, or some kind of VPN. -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 04:30:08 2008 Return-Path: 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 075B03A69CC; Mon, 21 Jul 2008 04:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 ZbrcnCd2-Cz3; Mon, 21 Jul 2008 04:30:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D20EB3A698E; Mon, 21 Jul 2008 04:30:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKtPx-000NXw-1O for namedroppers-data@psg.com; Mon, 21 Jul 2008 11:19:01 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKtPt-000NXc-3e for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 11:18:59 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:To:Cc:Subject:MIME-Version: X-Mailer:Message-ID:From:Date:X-MIMETrack:Content-Type; b=AZuI+bFEzYk7RQKno9Dz6JQBHBhqbKeCSOOX5IUzo+wLdiibv04Jj/Sl ZNViylDEYPc8OzMsUNL8oT/Q/mqyl/GrydhWxVOamk/raKOeEd2pM883R XBpXL9y6eL4A1xy; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1216639137; x=1248175137; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Roy=20Arends"=20|Subject: =20increasing=20DNS=20message=20entropy,=20a=20solution =20for=20NATs|Date:=20Mon,=2021=20Jul=202008=2013:17:55 =20+0200|Message-ID:=20|To:=20namedroppe rs@ops.ietf.org|Cc:=20Alessandro.Linari@nominet.org.uk |MIME-Version:=201.0; bh=cPDxi1fHn1Lo+LJ9aWp+LPt21cy8Jqxm8S4T3c5/ycE=; b=bMIbZ/gVJ6y8e+SXXqM+vG70fdt5MFkHRDXAuC4r0WXRji6v3e2CAMEu ZBNvPcMkw2DiNVagC/PiHELw3xx+fq1YmNslw/xfFwvF8gUuhzubYkZKg uYZVzv+eVXxhodJ; X-IronPort-AV: E=Sophos;i="4.31,223,1215385200"; d="scan'208";a="4267491" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 21 Jul 2008 12:17:57 +0100 To: namedroppers@ops.ietf.org Cc: Alessandro.Linari@nominet.org.uk Subject: increasing DNS message entropy, a solution for NATs MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: "Roy Arends" Date: Mon, 21 Jul 2008 13:17:55 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 21/07/2008 12:17:56 PM, Serialize complete at 21/07/2008 12:17:56 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: The proposed solution to solve the problem highlighted by Dan Kaminsky is randomizing source ports. As some have mentioned, NAT/PAT scenarios do not benefit from this solution. A while back, Alessandro Linari (Oxford Brookes, working in our advanced projects team), mentioned this alternative solution: A simple, straightforward method to increase entropy in DNS message transaction, is to query for the same name twice (or N times for even more increased entropy) and require that the answers be the same. This does require a change to the resolver, but not to the authoritative server. There are a few things to consider, such as auth-servers not agreeing on zone content (or other protocol violations), or avoiding birthday paradox when sending two queries to the same server, but overall, this solution is an alternative for those deployments that are not capable of making use of source port randomization. Roy Arends Nominet UK -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 05:25:51 2008 Return-Path: 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 76B6E3A69D3; Mon, 21 Jul 2008 05:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.465 X-Spam-Level: X-Spam-Status: No, score=-4.465 tagged_above=-999 required=5 tests=[AWL=-2.134, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, URI_HEX=0.368] 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 OpcTXkPPdPDS; Mon, 21 Jul 2008 05:25:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 41FF53A69E4; Mon, 21 Jul 2008 05:25:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKuNW-00093G-9M for namedroppers-data@psg.com; Mon, 21 Jul 2008 12:20:34 +0000 Received: from [131.111.8.137] (helo=ppsw-7.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKuNS-00092t-8h for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 12:20:32 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:57428) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1KKuNJ-0005eF-PV (Exim 4.67) (return-path ); Mon, 21 Jul 2008 13:20:21 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1KKuNJ-0004vR-Sl (Exim 4.67) (return-path ); Mon, 21 Jul 2008 13:20:21 +0100 Date: Mon, 21 Jul 2008 13:20:21 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Paul Hoffman cc: Duane , namedroppers@ops.ietf.org Subject: Re: dns hop by hop transaction security for queries In-Reply-To: Message-ID: References: <55957.1216574145@nsa.vix.com> <4883AC81.1080008@e164.org> <87989.1216595508@nsa.vix.com> <4883CBDF.2010902@e164.org> User-Agent: Alpine 1.10 (LSU 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sun, 20 Jul 2008, Paul Hoffman wrote: > At 9:35 AM +1000 7/21/08, Duane wrote: > > > > A trivial solution that wouldn't break anything might be just to > > prefix something to the front of all hostnames that both ends strip > > before processing them > > I'm confused. How would a responder know to strip them without a change > of the protocol? If you append the cookie to the end of the domainname, e.g. cyan.csi.cam.ac.uk.d41d8cd98f00b204e9800998ecf8427e.xqid.arpa, then an old resolver doesn't need to be changed to strip the extra labels so long as there's an AS112-alike handling queries to xqid.arpa. However the nonce doesn't appear early in the packet so Paul Vixie's worries about ICMP still apply. It's also a disgusting hack. Tony. -- f.anthony.n.finch http://dotat.at/ SOUTH UTSIRE: NORTHWESTERLY 5 TO 7. ROUGH OR VERY ROUGH DECREASING MODERATE OR ROUGH. SHOWERS. MODERATE OR GOOD. -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 06:14:18 2008 Return-Path: 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 0B6103A6997; Mon, 21 Jul 2008 06:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.341 X-Spam-Level: X-Spam-Status: No, score=-0.341 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 a5jwyxPD4dnW; Mon, 21 Jul 2008 06:14:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2019928C0E5; Mon, 21 Jul 2008 06:14:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvAN-000IiT-JS for namedroppers-data@psg.com; Mon, 21 Jul 2008 13:11:03 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvAJ-000IhV-GZ for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 13:11:01 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6LDAwnU041705 for ; Mon, 21 Jul 2008 09:10:58 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6LDAwpU041704 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 09:10:58 -0400 (EDT) (envelope-from namedroppers) 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 ) id 1KKbJv-0006nm-Cx for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 15:59:37 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 796DFA1108; Sun, 20 Jul 2008 15:59:25 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Ben Laurie cc: namedroppers@ops.ietf.org, Eric Rescorla In-Reply-To: Your message of "Sun, 20 Jul 2008 12:29:27 +0100." <48832197.80603@links.org> References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <48832197.80603@links.org> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sun, 20 Jul 2008 15:59:25 +0000 Message-ID: <46510.1216569565@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 796DFA1108.3152B X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: transaction security in the last mile X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] > a) The ICMP unreachable message includes 64 _bits_ of the payload, > according to RFC 792, not 64 bytes, so only the UDP header is covered, > and so all UDP protocols have this issue. oops. my apologies, as usual, for displaying my ignorance so readily. so, either there can be no fallback, or there must be additional configuration information for the stub/RDNS relationship (beyond the RDNS's IP address; for example it could include a TSIG shared-secret.) all forms of complex setup including DTLS and TKEY are subject to the same spoofed-ICMP downgrade attack, if there is a fallback. TCP however is not subject to this kind of spoofed-ICMP induced failure. so perhaps i've been overthinking this. what if we use TKEY-over-TCP/53 to set up the trust relationship, and then TSIG-over-UDP/53 for queries thereafter, and go back and do a new TKEY-over-TCP/53 if the TSIG ever stops working? be it noted, there is still no authentication here. the stub won't know what actual entity is speaking from its RDNS' IP address. but the stub could be certain that it was the same entity from setup onward throughout. that's my bugaboo. -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 06:14:21 2008 Return-Path: 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 4D97B28C0EF; Mon, 21 Jul 2008 06:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.085 X-Spam-Level: X-Spam-Status: No, score=-1.085 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 zQSxzeBiUYax; Mon, 21 Jul 2008 06:14:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6D70228C0E5; Mon, 21 Jul 2008 06:14:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKv9Z-000IUi-Bc for namedroppers-data@psg.com; Mon, 21 Jul 2008 13:10:13 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKv9V-000IS2-7c for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 13:10:11 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6LDA8OQ041683 for ; Mon, 21 Jul 2008 09:10:08 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6LDA8aV041682 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 09:10:08 -0400 (EDT) (envelope-from namedroppers) Received: from [2001:14b0:202:1::a7] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKUqM-000GfA-K7 for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 09:04:41 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1KKUpq-0006Dt-S6; Sun, 20 Jul 2008 11:04:06 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1KKUpq-0002Pj-Cl; Sun, 20 Jul 2008 11:04:06 +0200 From: Florian Weimer To: Paul Vixie Cc: David Ulevitch , Ted Lemon , "namedroppers\@ops.ietf.org" Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <69079541-3324-4DD8-87B9-30F8F150CAE1@nominum.com> <87vdz28cvo.fsf@mid.deneb.enyo.de> <48825B49.8070508@everydns.net> <68941.1216508643@nsa.vix.com> Date: Sun, 20 Jul 2008 11:04:06 +0200 In-Reply-To: <68941.1216508643@nsa.vix.com> (Paul Vixie's message of "Sat, 19 Jul 2008 23:04:03 +0000") Message-ID: <87wsjhorjt.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] * Paul Vixie: > end users who really just can't tolerate provider-in-the-middle attacks will > use VPN to reach an RDNS they trust, or will run an RDNS of their own using > a VPN through some trusted relay point for their RDNS/ADNS traffic. Speaking as a vendor, I want to standardize the VPN infrastructure, so that our users are not tied into the VPN infrastructure we provide. I want interoperability at the protocol level, too, so that the software at the endpoints is interchangeable. It would be really neat if we could use official DNS protocols for that. If we can't, it's not a showstopper, but it means that the approach will be proprietary, no matter how much source code we release. On the other hand, I'm not sure if the underlying problem is of sufficient general interest to justify IETF involvement. -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 06:14:28 2008 Return-Path: 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 95F8C28C0F8; Mon, 21 Jul 2008 06:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 zQ7MC4VDYiNT; Mon, 21 Jul 2008 06:14:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4C08828C0EF; Mon, 21 Jul 2008 06:14:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvAr-000IuA-D6 for namedroppers-data@psg.com; Mon, 21 Jul 2008 13:11:33 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvAn-000Ite-DW for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 13:11:31 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6LDBRkE041737 for ; Mon, 21 Jul 2008 09:11:27 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6LDBROX041736 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 09:11:27 -0400 (EDT) (envelope-from namedroppers) Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKcYn-000LaH-F2 for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 17:19:03 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id D68A833C1D; Sun, 20 Jul 2008 18:18:59 +0100 (BST) Message-ID: <48837389.6050600@links.org> Date: Sun, 20 Jul 2008 18:19:05 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Paul Vixie CC: Duane , Paul Hoffman , namedroppers@ops.ietf.org Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <73445.1216512267@nsa.vix.com> <4882AB94.9050301@e164.org> <90383.1216525398@nsa.vix.com> In-Reply-To: <90383.1216525398@nsa.vix.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Paul Vixie wrote: > From: Duane >> The point he was trying to make about no authentication is the requests >> can be intercepted and proxied, just because you have a secure channel, >> doesn't mean you know who it's to. > > i understood that perfectly. my counter response was that this is fine for > the purpose of stub/RDNS relationships as long as they are SSH-like in that > there is an expensive setup involving a generated shared secret and another > expensive randomly periodic key rollover. these will have to be retriable > in the event of possibly-spoofed ICMP based failures, and any UDP/53 fallback > has to be configurably turn-off-able. > > under those conditions, an instruction from DHCP of "use RDNS a.b.c.d" is > sufficient since "who i think it is" is a.b.c.d and that is indeed who it > will be to. if an ISP wants to launch a provider-in-the-middle attack, they > will have to be able to spoof the address i wanted to reach, persistently, > in order to do the secret-exchange dance, both initially and at rollovers. Not quite getting this. If the address came from DHCP, then who you think it is is irrelevant. You are talking to whomever the ISP wanted you to talk to. > the case i'm guarding against is when i think i'm talking to a.b.c.d and i'm > really not. an ISP who can spoof a.b.c.d persistently is dangerous and > annoying, but not so dangerous as someone who isn't my ISP spoofing it in a > flood of QID-guessed responses as was demonstrated last year by amit klein. > > again, i really don't care to change the method by which a stub learns to > use a given RDNS, and that method is, "use a.b.c.d". no keys, no secrets, > no identity information. but with sufficient state, this can be made more > secure than it is now. > > (fallback in a hotel room is interesting. if the prospective new protocol > does not work, would a hotel visitor prefer no internet service at all, or > would they drag out their VPN machinery, or would they just send their DNS > queries in UDP/53 and be mightily suspicious about what came back? this is > interesting in like of KRE's observation that DNS spoofery may be necessary > to preserve the illusion of IPv4 reachability when we run out of new IPv4 > addresses but want to keep growing with IPv4.) This is crazy talk. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 06:14:52 2008 Return-Path: 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 9EB7428C0F6; Mon, 21 Jul 2008 06:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.372 X-Spam-Level: X-Spam-Status: No, score=-0.372 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 GeD9lUZEb1Ut; Mon, 21 Jul 2008 06:14:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B818728C0E5; Mon, 21 Jul 2008 06:14:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvBG-000Iyz-Ji for namedroppers-data@psg.com; Mon, 21 Jul 2008 13:11:58 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvBC-000Ixc-Np for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 13:11:56 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6LDBbIa041768 for ; Mon, 21 Jul 2008 09:11:37 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6LDBbCb041767 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 09:11:37 -0400 (EDT) (envelope-from namedroppers) 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 ) id 1KKd1d-0000s3-M3 for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 17:48:51 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 9D7BCA1049; Sun, 20 Jul 2008 17:48:40 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Florian Weimer cc: David Ulevitch , Ted Lemon , "namedroppers\@ops.ietf.org" In-Reply-To: Your message of "Sun, 20 Jul 2008 11:04:06 +0200." <87wsjhorjt.fsf@mid.deneb.enyo.de> References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <69079541-3324-4DD8-87B9-30F8F150CAE1@nominum.com> <87vdz28cvo.fsf@mid.deneb.enyo.de> <48825B49.8070508@everydns.net> <68941.1216508643@nsa.vix.com> <87wsjhorjt.fsf@mid.deneb.enyo.de> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sun, 20 Jul 2008 17:48:40 +0000 Message-ID: <58771.1216576120@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 9D7BCA1049.D6981 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: transaction security in the last mile X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] > From: Florian Weimer > > * Paul Vixie: > > end users who really just can't tolerate provider-in-the-middle attacks > > will use VPN to reach an RDNS they trust, or will run an RDNS of their > > own using a VPN through some trusted relay point for their RDNS/ADNS > > traffic. > > Speaking as a vendor, I want to standardize the VPN infrastructure, so > that our users are not tied into the VPN infrastructure we provide. I > want interoperability at the protocol level, too, so that the software > at the endpoints is interchangeable. > > It would be really neat if we could use official DNS protocols for that. i believe that the proposal i just sent out does that. -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 06:15:31 2008 Return-Path: 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 DF9E03A688D; Mon, 21 Jul 2008 06:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.235 X-Spam-Level: X-Spam-Status: No, score=-0.235 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] 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 pScYPWIyu+86; Mon, 21 Jul 2008 06:15:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DAEE33A69F6; Mon, 21 Jul 2008 06:15:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKv99-000IG3-0s for namedroppers-data@psg.com; Mon, 21 Jul 2008 13:09:47 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKv94-000IFF-Fu for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 13:09:45 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6LD9elf041664 for ; Mon, 21 Jul 2008 09:09:40 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6LD9eih041663 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 09:09:40 -0400 (EDT) (envelope-from namedroppers) 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 ) id 1KKHet-0003KZ-KR for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 18:59:57 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id B7830A110A; Sat, 19 Jul 2008 18:59:45 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Ben Laurie cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Sat, 19 Jul 2008 18:25:18 +0100." <4882237E.2030509@links.org> References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <4882237E.2030509@links.org> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sat, 19 Jul 2008 18:59:45 +0000 Message-ID: <49075.1216493985@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: B7830A110A.88EFC X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: transaction security in the last mile X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] > > ... i'm concerned about two elements of that protocol. first, it > > appears that the handshake can be made to fail using spoofed > > ICMP-Unreach messages, which may not be a problem for most protocols, > > but in our case the fallback is UDP/53 and so this is a downgrade > > vector. > > Eh? If you're using DTLS you are already on UDP. Do you mean the > fallback is to plaintext UDP? If so, why? in my deployment scenario, we have hundreds of millions of stubs talking to millions of RDNS', and if we require preshared keys we lose, and if we require changes to the DHCP lease options we lose, and if we require that a stub user know whether to expect a given RDNS to support DTLS or not we lose. therefore, whatever new stub/RDNS protocol we put in will have to be opportunistic, such that if it works it gets used and if it doesn't get used then cleartext UDP/53 gets used. therefore, there must not be a trivial way to make the protocol negotiation fail, forcing fallback, or else we've got ourselves a downgrade attack vector (like in EDNS, though please note, i do not regard this as a failing of EDNS.) if DTLS can be forced to fail by sending well timed trivially spoofed ICMP, then it's no protection over what the stub will fall back to. > All of your possible roads appear to me to be susceptible to [MiTM] > attacks. If we're going to fix this, let's fix it properly. i think hotel-in-the-middle and provider-in-the-middle are inevitable, for economic reasons (NXDOMAIN remapping) and technical ones (as told here by KRE this morning, involving IPv4 longevity measures.) there's a credible "first-meeting" trust model, like in SSH, where the identities and secrets of the parties are established at some high cost when they first meet, after which any change in those identities or secrets only at some higher cost, by which these MiTM "attacks" would be much harder to launch. however, i did say that my list was paltry, and if you have a suggestion, i'd be grateful to you for sharing it. -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 06:15:39 2008 Return-Path: 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 C672D28C0EF; Mon, 21 Jul 2008 06:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 YeTb--32KFko; Mon, 21 Jul 2008 06:15:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EE35F3A688D; Mon, 21 Jul 2008 06:15:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvBN-000J0X-2z for namedroppers-data@psg.com; Mon, 21 Jul 2008 13:12:05 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvBI-000IzA-G9 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 13:12:03 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6LDBuYL041804 for ; Mon, 21 Jul 2008 09:11:56 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6LDBuYK041803 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 09:11:56 -0400 (EDT) (envelope-from namedroppers) Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKeHa-000Eze-Oa for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 19:09:25 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 5047433C1C; Sun, 20 Jul 2008 20:08:55 +0100 (BST) Message-ID: <48838D4C.6060306@links.org> Date: Sun, 20 Jul 2008 20:09:00 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org, Eric Rescorla Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <48832197.80603@links.org> <46510.1216569565@nsa.vix.com> <488369D1.7010507@links.org> <60426.1216577373@nsa.vix.com> In-Reply-To: <60426.1216577373@nsa.vix.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Paul Vixie wrote: >> So why not DTLS-over-UDP/53 falling back to plain-over-UDP/53? > > because TKEY already exists. see RFC 2930. I think it would be fair to say that DTLS already exists, too, and provides properties TKEY does not. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 06:15:40 2008 Return-Path: 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 28DF83A688D; Mon, 21 Jul 2008 06:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.437 X-Spam-Level: X-Spam-Status: No, score=-103.437 tagged_above=-999 required=5 tests=[AWL=3.162, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 i9lZxOzNFCQW; Mon, 21 Jul 2008 06:15:39 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 51FD028C0E5; Mon, 21 Jul 2008 06:15:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvBm-000JDP-Ne for namedroppers-data@psg.com; Mon, 21 Jul 2008 13:12:30 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvBi-000JC4-FC for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 13:12:28 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6LDCFCr041817 for ; Mon, 21 Jul 2008 09:12:15 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6LDCFeF041816 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 09:12:15 -0400 (EDT) (envelope-from namedroppers) 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 ) id 1KKhvi-0001Qb-GL for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 23:03:04 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id E90CEA1038; Sun, 20 Jul 2008 23:02:52 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Eric Rescorla cc: Ben Laurie , namedroppers@ops.ietf.org In-Reply-To: Your message of "Sun, 20 Jul 2008 15:47:23 MST." <20080720224723.A215850846@romeo.rtfm.com> References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <48832197.80603@links.org> <46510.1216569565@nsa.vix.com> <20080720172348.CC45050846@romeo.rtfm.com> <63353.1216579390@nsa.vix.com> <20080720224723.A215850846@romeo.rtfm.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sun, 20 Jul 2008 23:02:52 +0000 Message-ID: <87484.1216594972@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: E90CEA1038.20AF8 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: transaction security in the last mile X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] > From: Eric Rescorla > > ... Rather, you can just accept the first key you see... yes, that's what i'm proposing. we're ensuring identity continuity between the entity who could hear and speak from an IP at session initialization time and the entity who can later transmit responses from that IP. > Maybe I'm missing something, but why do you need to change the kernel? > As I recall, UDP sockets, unlike TCP sockets, don't die just because an > ICMP message is received. Can't the application just ignore the error? if the socket is connected, then read() will show an error if an ICMP arrives that was putatively due to a previous write(). it's a mess. yes, you can ignore all ICMP-causable errors from read() or write() (or sendto() or recvfrom(), etc). or you can just not bother to connect() the socket in which case you should never see ICMP-causable errno values. but i'm only speaking from a BSD sockets perspective, i don't know how STREAMS does it, or WIN32 sockets, or linux sockets, or embedded system sockets. is it safe to design with application-layer ignore-ICMP as an implementation requirement? (i really don't know if these errors are ever sticky on some platforms.) ignoring ICMP during TKEY is testable, but is not necessary for interoperability, so it's a strange kind of requirement to specify. but if it means we could forget the TCP requirement for TKEY, it means we were even closer to already having a working solution than i'd thought we were. note, we're already designing with the assumption that ICMP redirect will be ignored by the kernel, since that kind of spoofing has already been done and unlike ARP spoofing it's a spoofable protocol element we could afford to declare to be a bad idea in general and stop honouring it, which we did. -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 06:15:51 2008 Return-Path: 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 1239A28C0F5; Mon, 21 Jul 2008 06:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 wSbCeNdxBBA7; Mon, 21 Jul 2008 06:15:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2165B3A688D; Mon, 21 Jul 2008 06:15:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvAZ-000IkK-I0 for namedroppers-data@psg.com; Mon, 21 Jul 2008 13:11:15 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvAR-000Ij9-Ip for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 13:11:13 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6LDB6hR041725 for ; Mon, 21 Jul 2008 09:11:06 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6LDB66i041724 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 09:11:06 -0400 (EDT) (envelope-from namedroppers) Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKbuj-000Eu9-2k for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 16:37:39 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id B783333C1D; Sun, 20 Jul 2008 17:37:32 +0100 (BST) Message-ID: <488369D1.7010507@links.org> Date: Sun, 20 Jul 2008 17:37:37 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org, Eric Rescorla Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <48832197.80603@links.org> <46510.1216569565@nsa.vix.com> In-Reply-To: <46510.1216569565@nsa.vix.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Paul Vixie wrote: >> a) The ICMP unreachable message includes 64 _bits_ of the payload, >> according to RFC 792, not 64 bytes, so only the UDP header is covered, >> and so all UDP protocols have this issue. > > oops. my apologies, as usual, for displaying my ignorance so readily. > > so, either there can be no fallback, or there must be additional configuration > information for the stub/RDNS relationship (beyond the RDNS's IP address; for > example it could include a TSIG shared-secret.) There can be fallback, it just has to use the same port. > all forms of complex setup including DTLS and TKEY are subject to the same > spoofed-ICMP downgrade attack, if there is a fallback. > > TCP however is not subject to this kind of spoofed-ICMP induced failure. so > perhaps i've been overthinking this. what if we use TKEY-over-TCP/53 to set > up the trust relationship, and then TSIG-over-UDP/53 for queries thereafter, > and go back and do a new TKEY-over-TCP/53 if the TSIG ever stops working? So why not DTLS-over-UDP/53 falling back to plain-over-UDP/53? > be it noted, there is still no authentication here. the stub won't know what > actual entity is speaking from its RDNS' IP address. but the stub could be > certain that it was the same entity from setup onward throughout. that's my > bugaboo. > -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 06:15:51 2008 Return-Path: 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 59D9A28C0E5; Mon, 21 Jul 2008 06:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.39 X-Spam-Level: X-Spam-Status: No, score=-103.39 tagged_above=-999 required=5 tests=[AWL=2.894, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, 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 bvwO0XQwY8Hn; Mon, 21 Jul 2008 06:15:50 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 2C9963A6A18; Mon, 21 Jul 2008 06:15:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKv9o-000Icj-F7 for namedroppers-data@psg.com; Mon, 21 Jul 2008 13:10:28 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKv9j-000Ibq-Tg for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 13:10:26 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6LDAMbi041689 for ; Mon, 21 Jul 2008 09:10:22 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6LDAMw5041688 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 09:10:22 -0400 (EDT) (envelope-from namedroppers) Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKX6T-000BK9-Vf for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 11:29:30 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 0946433C1D; Sun, 20 Jul 2008 12:29:23 +0100 (BST) Message-ID: <48832197.80603@links.org> Date: Sun, 20 Jul 2008 12:29:27 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org, Eric Rescorla Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Paul Vixie wrote: > [ Moderators note: Post was moderated, either because it was posted by > a non-subscriber, or because it was over 20K. > With the massive amount of spam, it is easy to miss and therefore > delete relevant posts by non-subscribers. > Please fix your subscription addresses. ] > > bert hubert writes: > >> On Fri, Jul 18, 2008 at 10:16:27PM +0200, Florian Weimer wrote: >>> Diffie-Hellman is probably too expensive for key agreement (and the ECC >>> variants too encumbered by patents). >> CURVE25519 perhaps? I'm no crypto expert, but to my eyes it looks nice. > > d-h is very expensive to set up. it's even a tiny bit worse than tcp. it > would, as i said at the outset, be important for both stubs and RDNS' to keep > state. however, since it's application layer state, rather than kernel state, > it's reasonable to consider it for an RDNS serving millions of stubs. which > bitswizzler is used in the various one-way transforms inside the D-H is just a > detail at this stage of the discussion. > > wrt DTLS (http://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security or > http://crypto.stanford.edu/~nagendra/projects/dtls/dtls.html have background > and http://tools.ietf.org/html/draft-rescorla-dtls-05 has the details), i'm > concerned about two elements of that protocol. first, it appears that the > handshake can be made to fail using spoofed ICMP-Unreach messages, which may > not be a problem for most protocols, but in our case the fallback is UDP/53 > and so this is a downgrade vector. this is because the first 64 octets of > the IP payload, which means the UDP headers and the start of the UDP payload, > do not include the randomized bits (so, DTLS' nonce is not within ICMP's > nonce). second, and less troubling, DTLS has message secrecy as a goal, > which is a red herring that will cause huge debates if we try to standardize > on DTLS for stub/RDNS transactions. So, I asked Eric Rescorla about this (copied) and he responds that: a) The ICMP unreachable message includes 64 _bits_ of the payload, according to RFC 792, not 64 bytes, so only the UDP header is covered, and so all UDP protocols have this issue. b) TLS and DTLS support non-confidential modes, e.g. TLS_RSA_WITH_NULL_SHA. > i'd like it very much if a DTLS expert could show me how the initial handshake > messages put highly random content into the part of the IP datagram that must > be present in an ICMP-Unreach message. if not, then the fact that stub/RDNS > will fallback to UDP/53 on DTLS failure means that some other handshake will > have to be designed to carry the D-H exchange. If RFC 792 is wrong and you are right, then Eric informs me that DTLS has randomness at byte 33 in the payload (i.e. byte 41 in IP payload) so its covered. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 06:15:59 2008 Return-Path: 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 E8DF928C0E5; Mon, 21 Jul 2008 06:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.532 X-Spam-Level: X-Spam-Status: No, score=-103.532 tagged_above=-999 required=5 tests=[AWL=2.467, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, 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 2w4DRM2MH2lY; Mon, 21 Jul 2008 06:15:59 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 1A0683A69F6; Mon, 21 Jul 2008 06:15:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKv9P-000IR1-Vg for namedroppers-data@psg.com; Mon, 21 Jul 2008 13:10:03 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKv9L-000IPZ-TG for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 13:10:01 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6LD9ws7041670 for ; Mon, 21 Jul 2008 09:09:58 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6LD9wB9041669 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 09:09:58 -0400 (EDT) (envelope-from namedroppers) 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 ) id 1KKLTI-000EUA-CI for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 23:04:14 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 5BB9DA10CA; Sat, 19 Jul 2008 23:04:03 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: David Ulevitch cc: Florian Weimer , Ted Lemon , "namedroppers@ops.ietf.org" In-Reply-To: Your message of "Sat, 19 Jul 2008 14:23:21 MST." <48825B49.8070508@everydns.net> References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <69079541-3324-4DD8-87B9-30F8F150CAE1@nominum.com> <87vdz28cvo.fsf@mid.deneb.enyo.de> <48825B49.8070508@everydns.net> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sat, 19 Jul 2008 23:04:03 +0000 Message-ID: <68941.1216508643@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 5BB9DA10CA.1A703 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: transaction security in the last mile X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] > > I think the problem is in the opposite direction (i.e. talking to the > > ISP when you don't want to). > > That is the correct problem statement. according to KRE, whose opinion i do not lightly discount, this is nec'y for various IPv4 prolongment tricks, and unless the world is ready to move en masse to IPv6, we won't succeed in trying to stop provider-in-the-middle attacks. end users who really just can't tolerate provider-in-the-middle attacks will use VPN to reach an RDNS they trust, or will run an RDNS of their own using a VPN through some trusted relay point for their RDNS/ADNS traffic. providers of advanced DNS services, such as opendns, have always been on shaky ground, since they are fighting for a chance to be the MiTM, and their opponents in that fight own the last mile L2/L3. but while that's bad for these advanced DNS service providers, it's not clear that the users benefit or suffer more based on who their provider-in-the-middle turns out to be. in other words there's a fix to provider-in-the-middle for motivated end users, and no way to outlaw them altogether unless we can abandon IPv4, and the greatest remainder of suffering is by dnsadvantage, opendns, and similar. i therefore reject that problem statement. -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 06:16:09 2008 Return-Path: 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 2D75228C0F6; Mon, 21 Jul 2008 06:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.271 X-Spam-Level: X-Spam-Status: No, score=-104.271 tagged_above=-999 required=5 tests=[AWL=2.328, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 V0bXyCig4zb3; Mon, 21 Jul 2008 06:16:08 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 45E7F3A6A37; Mon, 21 Jul 2008 06:16:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvC9-000JHG-VL for namedroppers-data@psg.com; Mon, 21 Jul 2008 13:12:53 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvC5-000JGX-Jn for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 13:12:51 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6LDCd4h041823 for ; Mon, 21 Jul 2008 09:12:39 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6LDCdZM041822 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 09:12:39 -0400 (EDT) (envelope-from namedroppers) Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKnGU-000AjH-DM for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 04:44:54 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 4080F33C1D; Mon, 21 Jul 2008 05:44:33 +0100 (BST) Message-ID: <48841429.6050905@links.org> Date: Mon, 21 Jul 2008 05:44:25 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Eric Rescorla CC: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <48832197.80603@links.org> <46510.1216569565@nsa.vix.com> <20080720172348.CC45050846@romeo.rtfm.com> <63353.1216579390@nsa.vix.com> <20080720224723.A215850846@romeo.rtfm.com> In-Reply-To: <20080720224723.A215850846@romeo.rtfm.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Eric Rescorla wrote: > At Sun, 20 Jul 2008 18:43:10 +0000, > Paul Vixie wrote: >>> From: Eric Rescorla >>> >>> Paul Vixie wrote: >>>> so, either there can be no fallback, or there must be additional >>>> configuration information for the stub/RDNS relationship (beyond the >>>> RDNS's IP address; for example it could include a TSIG shared-secret.) >>> True. Though it could also just contain the one bit of information >>> that the server will do a secure channel, right? >> in for a dime, in for a dollar. it's not the number of new bits, it's >> that the number of new bits is zero or not. > > Well, I agree that there's a qualitative difference between 0 and 1, > but I think there's still a pretty big difference between 1 and 160. > > >>> If you do, then you should do the initial key establishment via some >>> public key authentication mechanism, at minimum SSH-style leap of faith. >> i don't see microsoft or apple adopting that approach for their stubs. it >> is not reasonable to present an end user with a popup that asks them for >> input they know they are not qualified to give. so, that's why i'm not >> trying to do an SSH-style leap of faith on this. > > So, I'm not saying that l-o-f will necessarily work here, but > I don't think it's necessary to prompt the user. Rather, you > can just accept the first key you see... And prompt them when it changes? -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 06:16:57 2008 Return-Path: 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 64A7828C0EF; Mon, 21 Jul 2008 06:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[AWL=-1.189, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 3PsYqKQPXd+a; Mon, 21 Jul 2008 06:16:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 71F523A688D; Mon, 21 Jul 2008 06:16:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvCJ-000JJZ-NR for namedroppers-data@psg.com; Mon, 21 Jul 2008 13:13:03 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvCE-000JHm-FQ for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 13:13:01 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6LDCmvS041829 for ; Mon, 21 Jul 2008 09:12:48 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6LDClPL041828 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 09:12:47 -0400 (EDT) (envelope-from namedroppers) Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKrzU-0008eY-Dd for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 09:47:39 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 65F3033C1D; Mon, 21 Jul 2008 10:38:23 +0100 (BST) Message-ID: <48845915.1040700@links.org> Date: Mon, 21 Jul 2008 10:38:29 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org, Eric Rescorla Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <48832197.80603@links.org> <46510.1216569565@nsa.vix.com> <488369D1.7010507@links.org> <60426.1216577373@nsa.vix.com> <48838D4C.6060306@links.org> <66932.1216581599@nsa.vix.com> In-Reply-To: <66932.1216581599@nsa.vix.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Paul Vixie wrote: >>>> So why not DTLS-over-UDP/53 falling back to plain-over-UDP/53? >>> because TKEY already exists. see RFC 2930. >> I think it would be fair to say that DTLS already exists, too, and provides >> properties TKEY does not. > > DTLS would be a new protocol for stubs and RDNS to speak, but i'll ask, > features does DTLS have that TKEY doesn't have and do we need those? Obviously the main one is for certificate hierarchies. Whether we need those is another question - they sounds like a useful optional extra to me :-) I haven't studied TKEY in detail - there may be others. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 06:17:13 2008 Return-Path: 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 AFD2628C100; Mon, 21 Jul 2008 06:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.329 X-Spam-Level: X-Spam-Status: No, score=-1.329 tagged_above=-999 required=5 tests=[AWL=-1.149, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] 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 DV9uqJ3g96oX; Mon, 21 Jul 2008 06:17:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF2E928C0FF; Mon, 21 Jul 2008 06:17:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvA2-000Iel-Vn for namedroppers-data@psg.com; Mon, 21 Jul 2008 13:10:42 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKv9y-000Ie0-9e for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 13:10:40 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6LDAbSH041699 for ; Mon, 21 Jul 2008 09:10:37 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6LDAbLn041698 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 09:10:37 -0400 (EDT) (envelope-from namedroppers) Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKX9v-000Bne-4b for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 11:33:01 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 990D833C1A; Sun, 20 Jul 2008 12:32:57 +0100 (BST) Message-ID: <4883226E.1080506@links.org> Date: Sun, 20 Jul 2008 12:33:02 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Paul Vixie wrote: > [ Moderators note: Post was moderated, either because it was posted by > a non-subscriber, or because it was over 20K. > With the massive amount of spam, it is easy to miss and therefore > delete relevant posts by non-subscribers. > Please fix your subscription addresses. ] > > bert hubert writes: > >> On Fri, Jul 18, 2008 at 10:16:27PM +0200, Florian Weimer wrote: >>> Diffie-Hellman is probably too expensive for key agreement (and the ECC >>> variants too encumbered by patents). >> CURVE25519 perhaps? I'm no crypto expert, but to my eyes it looks nice. > > d-h is very expensive to set up. it's even a tiny bit worse than tcp. it > would, as i said at the outset, be important for both stubs and RDNS' to keep > state. however, since it's application layer state, rather than kernel state, > it's reasonable to consider it for an RDNS serving millions of stubs. which > bitswizzler is used in the various one-way transforms inside the D-H is just a > detail at this stage of the discussion. > > wrt DTLS (http://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security or > http://crypto.stanford.edu/~nagendra/projects/dtls/dtls.html have background > and http://tools.ietf.org/html/draft-rescorla-dtls-05 has the details), i'm > concerned about two elements of that protocol. first, it appears that the > handshake can be made to fail using spoofed ICMP-Unreach messages, which may > not be a problem for most protocols, but in our case the fallback is UDP/53 > and so this is a downgrade vector. this is because the first 64 octets of > the IP payload, which means the UDP headers and the start of the UDP payload, > do not include the randomized bits (so, DTLS' nonce is not within ICMP's > nonce). BTW, the obvious (I think!) defence against this would be to operate DTLS over the same port, so unreachable causes complete failure. A downgrade attack would still potentially be possible by a MitM, but not by spoofing. However, you have argued elsewhere that MitM is actually a design feature (not sure I agree!). Also, a knowledgeable user should be able to insist on DTLS if they know the properties of their resolver. > second, and less troubling, DTLS has message secrecy as a goal, > which is a red herring that will cause huge debates if we try to standardize > on DTLS for stub/RDNS transactions. > > i'd like it very much if a DTLS expert could show me how the initial handshake > messages put highly random content into the part of the IP datagram that must > be present in an ICMP-Unreach message. if not, then the fact that stub/RDNS > will fallback to UDP/53 on DTLS failure means that some other handshake will > have to be designed to carry the D-H exchange. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 06:17:39 2008 Return-Path: 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 CB5683A6A2D; Mon, 21 Jul 2008 06:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.165 X-Spam-Level: X-Spam-Status: No, score=-1.165 tagged_above=-999 required=5 tests=[AWL=-0.985, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] 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 eqIGck7ZlQCN; Mon, 21 Jul 2008 06:17:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE9B73A6A1D; Mon, 21 Jul 2008 06:17:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKv8a-000I4z-WB for namedroppers-data@psg.com; Mon, 21 Jul 2008 13:09:13 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKv8T-000I4G-QD for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 13:09:11 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6LD94OA041648 for ; Mon, 21 Jul 2008 09:09:04 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6LD94PS041647 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 09:09:04 -0400 (EDT) (envelope-from namedroppers) Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKGBJ-000Fwk-DP for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 17:25:19 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 9506733C1D; Sat, 19 Jul 2008 18:25:14 +0100 (BST) Message-ID: <4882237E.2030509@links.org> Date: Sat, 19 Jul 2008 18:25:18 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Paul Vixie wrote: > [ Moderators note: Post was moderated, either because it was posted by > a non-subscriber, or because it was over 20K. > With the massive amount of spam, it is easy to miss and therefore > delete relevant posts by non-subscribers. > Please fix your subscription addresses. ] > > bert hubert writes: > >> On Fri, Jul 18, 2008 at 10:16:27PM +0200, Florian Weimer wrote: >>> Diffie-Hellman is probably too expensive for key agreement (and the ECC >>> variants too encumbered by patents). >> CURVE25519 perhaps? I'm no crypto expert, but to my eyes it looks nice. > > d-h is very expensive to set up. it's even a tiny bit worse than tcp. it > would, as i said at the outset, be important for both stubs and RDNS' to keep > state. however, since it's application layer state, rather than kernel state, > it's reasonable to consider it for an RDNS serving millions of stubs. which > bitswizzler is used in the various one-way transforms inside the D-H is just a > detail at this stage of the discussion. > > wrt DTLS (http://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security or > http://crypto.stanford.edu/~nagendra/projects/dtls/dtls.html have background > and http://tools.ietf.org/html/draft-rescorla-dtls-05 has the details), i'm > concerned about two elements of that protocol. first, it appears that the > handshake can be made to fail using spoofed ICMP-Unreach messages, which may > not be a problem for most protocols, but in our case the fallback is UDP/53 > and so this is a downgrade vector. Eh? If you're using DTLS you are already on UDP. Do you mean the fallback is to plaintext UDP? If so, why? > this is because the first 64 octets of > the IP payload, which means the UDP headers and the start of the UDP payload, > do not include the randomized bits (so, DTLS' nonce is not within ICMP's > nonce). second, and less troubling, DTLS has message secrecy as a goal, > which is a red herring that will cause huge debates if we try to standardize > on DTLS for stub/RDNS transactions. > > i'd like it very much if a DTLS expert could show me how the initial handshake > messages put highly random content into the part of the IP datagram that must > be present in an ICMP-Unreach message. if not, then the fact that stub/RDNS > will fallback to UDP/53 on DTLS failure means that some other handshake will > have to be designed to carry the D-H exchange. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 06:19:20 2008 Return-Path: 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 A1CEC28C100; Mon, 21 Jul 2008 06:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.081 X-Spam-Level: * X-Spam-Status: No, score=1.081 tagged_above=-999 required=5 tests=[AWL=-2.712, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_STOCK2=3.988, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_WEOFFER=0.3] 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 5hCgW1sEv97C; Mon, 21 Jul 2008 06:19:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A8F4728C0F8; Mon, 21 Jul 2008 06:19:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvBV-000J2V-H4 for namedroppers-data@psg.com; Mon, 21 Jul 2008 13:12:13 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvBR-000J13-2L for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 13:12:11 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6LDC7fC041811 for ; Mon, 21 Jul 2008 09:12:07 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6LDC7Y4041810 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 09:12:07 -0400 (EDT) (envelope-from namedroppers) Received: from [74.95.2.173] (helo=romeo.rtfm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKhXf-000NL7-RN for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 22:38:13 +0000 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id A215850846; Sun, 20 Jul 2008 15:47:23 -0700 (PDT) Date: Sun, 20 Jul 2008 15:47:23 -0700 From: Eric Rescorla To: Paul Vixie Cc: Eric Rescorla , Ben Laurie , namedroppers@ops.ietf.org Subject: Re: transaction security in the last mile In-Reply-To: <63353.1216579390@nsa.vix.com> References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <48832197.80603@links.org> <46510.1216569565@nsa.vix.com> <20080720172348.CC45050846@romeo.rtfm.com> <63353.1216579390@nsa.vix.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080720224723.A215850846@romeo.rtfm.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] At Sun, 20 Jul 2008 18:43:10 +0000, Paul Vixie wrote: > > > From: Eric Rescorla > > > > Paul Vixie wrote: > > > so, either there can be no fallback, or there must be additional > > > configuration information for the stub/RDNS relationship (beyond the > > > RDNS's IP address; for example it could include a TSIG shared-secret.) > > > > True. Though it could also just contain the one bit of information > > that the server will do a secure channel, right? > > in for a dime, in for a dollar. it's not the number of new bits, it's > that the number of new bits is zero or not. Well, I agree that there's a qualitative difference between 0 and 1, but I think there's still a pretty big difference between 1 and 160. > > If you do, then you should do the initial key establishment via some > > public key authentication mechanism, at minimum SSH-style leap of faith. > > i don't see microsoft or apple adopting that approach for their stubs. it > is not reasonable to present an end user with a popup that asks them for > input they know they are not qualified to give. so, that's why i'm not > trying to do an SSH-style leap of faith on this. So, I'm not saying that l-o-f will necessarily work here, but I don't think it's necessary to prompt the user. Rather, you can just accept the first key you see... > > On a slightly different note, wouldn't another possibility be to simply > > ignore ICMP unreachables and rely on timeouts? > > that tends to be a kernel change rather than an application change. there > may even be a setsockopt() that does this on some BSD-like or Linux-like > operating systems, or on WIN32-like operating systems, but not on all of > them. if we offer a new mechanism that's only secure after a change to > the kernel's UDP stack, then we'll never be sure what got deployed, but we > can safely bet that it won't be universal. Maybe I'm missing something, but why do you need to change the kernel? As I recall, UDP sockets, unlike TCP sockets, don't die just because an ICMP message is received. Can't the application just ignore the error? -Ekr -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 06:20:46 2008 Return-Path: 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 AB3E93A6941; Mon, 21 Jul 2008 06:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.054 X-Spam-Level: X-Spam-Status: No, score=-1.054 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 6l21Vpakaamo; Mon, 21 Jul 2008 06:20:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CB67428C102; Mon, 21 Jul 2008 06:20:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvBB-000IxW-9q for namedroppers-data@psg.com; Mon, 21 Jul 2008 13:11:53 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvB7-000Iwg-Ls for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 13:11:51 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6LDBmYD041774 for ; Mon, 21 Jul 2008 09:11:48 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6LDBmRn041773 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 09:11:48 -0400 (EDT) (envelope-from namedroppers) 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 ) id 1KKdLj-00045g-RA for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 18:09:37 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 5D869A1031; Sun, 20 Jul 2008 18:09:33 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Ben Laurie cc: namedroppers@ops.ietf.org, Eric Rescorla In-Reply-To: Your message of "Sun, 20 Jul 2008 17:37:37 +0100." <488369D1.7010507@links.org> References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <48832197.80603@links.org> <46510.1216569565@nsa.vix.com> <488369D1.7010507@links.org> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sun, 20 Jul 2008 18:09:33 +0000 Message-ID: <60426.1216577373@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 5D869A1031.41382 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: transaction security in the last mile X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] > So why not DTLS-over-UDP/53 falling back to plain-over-UDP/53? because TKEY already exists. see RFC 2930. -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 06:20:52 2008 Return-Path: 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 D6DE128C100; Mon, 21 Jul 2008 06:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.041 X-Spam-Level: X-Spam-Status: No, score=-1.041 tagged_above=-999 required=5 tests=[AWL=-0.861, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] 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 n32khndtB4lD; Mon, 21 Jul 2008 06:20:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 65A653A6941; Mon, 21 Jul 2008 06:20:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKv8j-000IDN-RS for namedroppers-data@psg.com; Mon, 21 Jul 2008 13:09:21 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKv8e-000I98-QZ for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 13:09:19 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6LD9Fji041655 for ; Mon, 21 Jul 2008 09:09:15 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6LD9F3A041654 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 09:09:15 -0400 (EDT) (envelope-from namedroppers) Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKGBY-000Fxz-N4 for namedroppers@ops.ietf.org; Sat, 19 Jul 2008 17:25:34 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 36CF133C1A; Sat, 19 Jul 2008 18:25:31 +0100 (BST) Message-ID: <4882238F.6070200@links.org> Date: Sat, 19 Jul 2008 18:25:35 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> In-Reply-To: <5721.1216397728@nsa.vix.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Paul Vixie wrote: > .. i think it's time for a new debate on the nature of the relationship > between the stub and the RDNS. i wish to leave aside the relationship > between the RDNS and ADNS, since these are far more numerous, and the kinds > of negotiations or state that are practical in the stub/RDNS relationship > might be completely impractical in the RDNS/ADNS relationship. in this > discussion, a "stub" refers to either an initiator with no DNS-layer cache, > or to an RDNS configured to use a "forwarder". in both cases, the number > of relationships a given initiator is in, or that a given responder is in, > is finite and manageable. All of your possible roads appear to me to be susceptible to man-in-the-middle attacks. If we're going to fix this, let's fix it properly. > here are some possible roads, and the reasons they're each hard to follow. > > 1. always use tcp. with random initial sequence numbers now the standard, > we generally consider tcp sessions unspoofable unless the ISO-L2 is > insecure near either endpoint, or unless the routing layer is attacked. > for many stub/RDNS deployments, the number of stubs simultaneously doing > DNS will be lower than the number of tcp protocol control blocks or socket > descriptors available on the RDNS host and application. however, in many > ISP deployments there can be millions or tens of millions of stubs for > every RDNS, and not even anycasting or load balancing will make that fit, > so we'd be contemplating a very short (subsecond) timeout for idle DNS TCP > sessions, which calls for some modelling to find out what the packet count > and RTT cost would be for the average stub in that environment. also, stubs > would have to funnel their queries through shared local protocol agents, > and these agents may become a new target for injection attackers. > > 2. diffie-hellman. it is possible, with the exchange of several random > numbers used as encryption and decryption keys, for two endpoints with no > shared secret to establish a trust relationship. this takes measureable > time and effort, so the existence of this trust relationship is usually > remembered by the endpoints, creating "session state" which can be used to > generate nonces or shared keys. RFC 2930 is an example of such a method, > whereby the TKEY meta-RR is used to carry keying information for the TSIG > meta-RR. no known large deployment currently uses TKEY to create trust and > then TSIG to protect query transactions, so while this approach may be > practical, its error modes remain unmeasured. because such relationships > are not held in protocol control blocks and/or socket descriptors, it may > be possible for an RDNS to relate to millions of stubs in this way. > however, the stubs will probably require additional processes or files to > hold the trust state for each RDNS, and this state may become a new target > for injection attackers. there's also a lurking downgrade attack involving > spoofed ICMP-Port-Unreach, since the D-H and key data won't be in the first > 64 octets of the payload, which ICMP uses as a nonce. > > 3. IPv6 multiplicity. in IPv6, most LANs will have 64-bit netmasks, leaving > 64 bits for host addressing, which are expected to be sparsely allocated. > it is possible that a stub host could allocate a few dozen addresses, and > choose one at random as a source for requests to RDNS. there is a tension > between having enough source addresses to matter from a security nonce point > of view, vs. having too many to manage in the exit gateways who must maintain > ARP state for each address, mapping back to each stub's MAC address. it's > unlikely that the number of additional random bits we need can be accomodated > by this layer of the IPv6 architecture, and furthermore, IPv6 isn't here yet. > > 4. new port. most of the constraints are due to backward compatibility > problems, and if we simply allocate a new UDP port, other than 53, then we > can make new rules. it's easy to design a completely stateless replacement > for stub DNS that involves 128-bit random nonces. while there would be some > delay while IETF debates which part of the kitchen sink to leave in or remove, > it's safe to say that there would be no authority or additional data section, > no RD bit, very few options in general, and that we could avoid having this > turn into a replacement for the current global DNS protocol used for the > RDNS/ADNS relationship. what's less clear is how the fallback strategy would > be secure, since a "new-stub" would have to fall back to standard UDP/53 if > it could not get an answer on the new UDP port from any of its RDNS's. could > we put the nonce near the front of the UDP payload so that ICMP-PortUnreach > (which uses the first 64 bytes of the datagram) would be hard enough to forge > that we could confidently assume that there was never a downgrade attack? > > i know that's a paltry list. others here should be able to think of more > alternatives. i'd like to avoid a re-debate over XQID, though, so if that's > your position i ask that you hold off on elucidating it here to let this topic > be explored on the basis that XQID, TSIG, SIG(0), and BCP38 are nonstarters. > i'd really like to know whether always-tcp, diffie-hellman, ipv6-multiplicity, > or new-port are practical or not, and whether there are other ideas lurking. > > of the ideas above, i dislike the new-port idea the least, and that's very > depressing, since from a deployment perspective, SIG(0) would be about the > same total cost. (the largest part of the cost is touching all or most of > the stubs, not in the specific complexities added by that touch.) > -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 06:21:02 2008 Return-Path: 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 232EC3A68A0; Mon, 21 Jul 2008 06:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.882 X-Spam-Level: X-Spam-Status: No, score=-0.882 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 8HFvwTszarAE; Mon, 21 Jul 2008 06:21:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 106D13A6975; Mon, 21 Jul 2008 06:21:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvB0-000IvW-NS for namedroppers-data@psg.com; Mon, 21 Jul 2008 13:11:42 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvAw-000Iui-QU for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 13:11:40 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6LDBFGS041731 for ; Mon, 21 Jul 2008 09:11:15 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6LDBFk1041730 for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 09:11:15 -0400 (EDT) (envelope-from namedroppers) Received: from [74.95.2.173] (helo=romeo.rtfm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKcUX-000Ksf-HJ for namedroppers@ops.ietf.org; Sun, 20 Jul 2008 17:14:39 +0000 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id CC45050846; Sun, 20 Jul 2008 10:23:48 -0700 (PDT) Date: Sun, 20 Jul 2008 10:23:47 -0700 From: Eric Rescorla To: Paul Vixie Cc: Ben Laurie , namedroppers@ops.ietf.org, Eric Rescorla Subject: Re: transaction security in the last mile In-Reply-To: <46510.1216569565@nsa.vix.com> References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <48832197.80603@links.org> <46510.1216569565@nsa.vix.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080720172348.CC45050846@romeo.rtfm.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] At Sun, 20 Jul 2008 15:59:25 +0000, Paul Vixie wrote: > > > a) The ICMP unreachable message includes 64 _bits_ of the payload, > > according to RFC 792, not 64 bytes, so only the UDP header is covered, > > and so all UDP protocols have this issue. > > oops. my apologies, as usual, for displaying my ignorance so readily. > > so, either there can be no fallback, or there must be additional configuration > information for the stub/RDNS relationship (beyond the RDNS's IP address; for > example it could include a TSIG shared-secret.) True. Though it could also just contain the one bit of information that the server will do a secure channel, right? > all forms of complex setup including DTLS and TKEY are subject to the same > spoofed-ICMP downgrade attack, if there is a fallback. > > TCP however is not subject to this kind of spoofed-ICMP induced failure. Because the ISN is in the first 64 bits and ISNs are hard to predict? > so > perhaps i've been overthinking this. what if we use TKEY-over-TCP/53 to set > up the trust relationship, and then TSIG-over-UDP/53 for queries thereafter, > and go back and do a new TKEY-over-TCP/53 if the TSIG ever stops working? > > be it noted, there is still no authentication here. the stub won't know what > actual entity is speaking from its RDNS' IP address. but the stub could be > certain that it was the same entity from setup onward throughout. that's my > bugaboo. Without taking a position on this particular design, I think there's a high order question about whether you'd like to authenticate the server of just get continuity, right? If you do, then you should do the initial key establishment via some public key authentication mechanism, at minimum SSH-style leap of faith. On a slightly different note, wouldn't another possibility be to simply ignore ICMP unreachables and rely on timeouts? As you know, enough firewalls and NATs block ICMP that you can't trust them anyway, so you have to be prepared to fall back to timeout. And if you were to cache the initial information that the server was/wasn't prepared to do the new security protocol (a la SSH), then you would only have timeout issues when you contacted a new server. (You could reprobe periodically...) -Ekr -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 07:03:26 2008 Return-Path: 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 6BCA028C118; Mon, 21 Jul 2008 07:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 qTdwVcfPswdC; Mon, 21 Jul 2008 07:03:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7989C28C0F8; Mon, 21 Jul 2008 07:03:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvtU-0003vQ-PC for namedroppers-data@psg.com; Mon, 21 Jul 2008 13:57:40 +0000 Received: from [68.142.225.234] (helo=smtp118.rog.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKvtQ-0003uz-2a for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 13:57:38 +0000 Received: (qmail 22307 invoked from network); 21 Jul 2008 13:57:28 -0000 Received: from unknown (HELO connotech.com) (t2i6@rogers.com@209.148.165.15 with plain) by smtp118.rog.mail.re2.yahoo.com with SMTP; 21 Jul 2008 13:57:28 -0000 X-YMail-OSG: Vkbur4QVM1lugJ.jQKUU5xbovZoVpGfHkaA2Bjpl_sBlCOLsR0gN2bwo.bPlZE_vNg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4884966D.2070801@connotech.com> Date: Mon, 21 Jul 2008 09:00:13 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Rescorla , namedroppers@ops.ietf.org Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <48832197.80603@links.org> <46510.1216569565@nsa.vix.com> <20080720172348.CC45050846@romeo.rtfm.com> <63353.1216579390@nsa.vix.com> <20080720224723.A215850846@romeo.rtfm.com> <48841429.6050905@links.org> <20080721044832.BA391498162@kilo.rtfm.com> In-Reply-To: <20080721044832.BA391498162@kilo.rtfm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Eric Rescorla wrote: > At Mon, 21 Jul 2008 05:44:25 +0100, > Ben Laurie wrote: > >>Eric Rescorla wrote: >> >>> >>>So, I'm not saying that l-o-f will necessarily work here, but >>>I don't think it's necessary to prompt the user. Rather, you >>>can just accept the first key you see... >> >>And prompt them when it changes? > > > Good question. Probably retry via the original channel. I agree it's > not a real adequate answer... > This is the pervasive question for almost all security schemes. How does a client system establish, and then "maintain", trust in a remote party which you (the designer, with your opinion perhaps reflected reflected in a "policy") assume equiped with more skills in IT security management. DNSEXT revisits this question because ... because what, I don't know. Actually the question belongs to the IT security community of experts which never addressed the question for what it is, i.e. pervasive for almost all security schemes. Thanks to Eric for joining the discussion and bringing it to this point. -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 07:43:48 2008 Return-Path: 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 5C21E3A69F6; Mon, 21 Jul 2008 07:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RDNS_NONE=0.1, URI_HEX=0.368] 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 usKvLBN+W+Uw; Mon, 21 Jul 2008 07:43:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 21D543A6924; Mon, 21 Jul 2008 07:43:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKwY1-000Cse-5p for namedroppers-data@psg.com; Mon, 21 Jul 2008 14:39:33 +0000 Received: from [209.85.132.244] (helo=an-out-0708.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKwXw-000Cs5-Nh for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 14:39:31 +0000 Received: by an-out-0708.google.com with SMTP id c24so484984ana.18 for ; Mon, 21 Jul 2008 07:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=penNJ/ICp4Go19cewGXV3CDNqJwcFYAcW7rh9HnjrWU=; b=EQ+iZDI0bG/WbzV0SQ7xiEJXLipDVKLrSm4eOeiTho+G5nBgwfqCKmgL7QV8qhsVV3 +2dpJCMtYwvp2OHYMj7DNwCFfNMnPjGfuW0A64UUlY1UY1OjgSgxNkZWsYgFO2rv9r84 fHdCb3oJyxeRI+oT3z3UohpoHQEhJ9Ke97nl8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=hWuH8xmf065D4kqh6TRs4upDZ43IRd7hmZva+bq7TUqI1SK0KoNBFr90XUT7u4wXfb 3a6cQ3yA9S1z2hRVLISRdN3HXRkanP1Ag6H1f4pLL3Eu34DZeroxdP13/Rv7EB6o1gIT RODeZatjdNiyEN7g8FfKx+9CKLu2NS/vhzp34= Received: by 10.100.31.3 with SMTP id e3mr1773404ane.64.1216651167600; Mon, 21 Jul 2008 07:39:27 -0700 (PDT) Received: by 10.100.92.20 with HTTP; Mon, 21 Jul 2008 07:39:27 -0700 (PDT) Message-ID: <1028365c0807210739red0bc3cs92f7bcc34a09f36e@mail.gmail.com> Date: Mon, 21 Jul 2008 10:39:27 -0400 From: "Donald Eastlake" To: namedroppers@ops.ietf.org Subject: Re: dns hop by hop transaction security for queries In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_111033_8735497.1216651167582" References: <55957.1216574145@nsa.vix.com> <4883AC81.1080008@e164.org> <87989.1216595508@nsa.vix.com> <4883CBDF.2010902@e164.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ------=_Part_111033_8735497.1216651167582 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Jul 21, 2008 at 8:20 AM, Tony Finch wrote: > On Sun, 20 Jul 2008, Paul Hoffman wrote: > > At 9:35 AM +1000 7/21/08, Duane wrote: > > > > > > A trivial solution that wouldn't break anything might be just to > > > prefix something to the front of all hostnames that both ends strip > > > before processing them > > > > I'm confused. How would a responder know to strip them without a change > > of the protocol? > > If you append the cookie to the end of the domainname, e.g. > cyan.csi.cam.ac.uk.d41d8cd98f00b204e9800998ecf8427e.xqid.arpa, > then an old resolver doesn't need to be changed to strip the > extra labels so long as there's an AS112-alike handling queries > to xqid.arpa. However the nonce doesn't appear early in the > packet so Paul Vixie's worries about ICMP still apply. It's > also a disgusting hack. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > SOUTH UTSIRE: NORTHWESTERLY 5 TO 7. ROUGH OR VERY ROUGH DECREASING MODERATE > OR > ROUGH. SHOWERS. MODERATE OR GOOD. > And if you ever had names at or approaching the name length limit, you can't use it. Donald > > ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com ------=_Part_111033_8735497.1216651167582 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On Mon, Jul 21, 2008 at 8:20 AM, Tony Finch <dot@dotat.at> wrote:
On Sun, 20 Jul 2008, Paul Hoffman wrote:
> At 9:35 AM +1000 7/21/08, Duane wrote:
> >
> > A trivial solution that wouldn't break anything might be just to
> > prefix something to the front of all hostnames that both ends strip
> > before processing them
>
> I'm confused. How would a responder know to strip them without a change
> of the protocol?

If you append the cookie to the end of the domainname, e.g.
cyan.csi.cam.ac.uk.d41d8cd98f00b204e9800998ecf8427e.xqid.arpa,
then an old resolver doesn't need to be changed to strip the
extra labels so long as there's an AS112-alike handling queries
to xqid.arpa. However the nonce doesn't appear early in the
packet so Paul Vixie's worries about ICMP still apply. It's
also a disgusting hack.

Tony.
--
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
SOUTH UTSIRE: NORTHWESTERLY 5 TO 7. ROUGH OR VERY ROUGH DECREASING MODERATE OR
ROUGH. SHOWERS. MODERATE OR GOOD.
 
And if you ever had names at or approaching the name length limit, you can't use it.

Donald

=============================
Donald E. Eastlake 3rd +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3@gmail.com
------=_Part_111033_8735497.1216651167582-- -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 09:04:21 2008 Return-Path: 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 B7F763A6ABE; Mon, 21 Jul 2008 09:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 YXnXbgI96OgM; Mon, 21 Jul 2008 09:04:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A9FF33A6AB5; Mon, 21 Jul 2008 09:04:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKxmq-0004Kt-DO for namedroppers-data@psg.com; Mon, 21 Jul 2008 15:58:56 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKxml-0004JX-HF for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 15:58:54 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=ca.afilias.info; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=fhqFgcqEVhwbITVBDdrP1z45+PaL8+5Wym8yISBpsP0/D9zA5Zp0LsAr7UXJW0JvBJH6AZe98lvMzmT7rr6/emwu445psQjo6m4spbN6fym+MBZvA5V63bDoNOV/AuRg; Received: from [199.212.90.27] (helo=yxu1b27.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKxlP-0002OF-5g; Mon, 21 Jul 2008 15:57:27 +0000 Cc: namedroppers@ops.ietf.org, Alessandro.Linari@nominet.org.uk Message-Id: From: Joe Abley To: Roy Arends In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: increasing DNS message entropy, a solution for NATs Date: Mon, 21 Jul 2008 11:57:25 -0400 References: X-Mailer: Apple Mail (2.926) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 21 Jul 2008, at 07:17, Roy Arends wrote: > A simple, straightforward method to increase entropy in DNS message > transaction, is to query for the same name twice (or N times for > even more > increased entropy) and require that the answers be the same. This does > require a change to the resolver, but not to the authoritative server. This will lead to trouble if the query is ever answered by one of a cluster of servers, where there is the potential for some servers in the cluster to be slightly more up-to-date than others. It also might lead to trouble if the query is ever answered by a single-source server which updates between query i and query j for some j>i. > There are a few things to consider, such as auth-servers not > agreeing on > zone content (or other protocol violations), or avoiding birthday > paradox > when sending two queries to the same server, but overall, this > solution is > an alternative for those deployments that are not capable of making > use of > source port randomization. Joe -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 09:28:09 2008 Return-Path: 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 D2EBF28C102; Mon, 21 Jul 2008 09:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 nfcps7fNsRFb; Mon, 21 Jul 2008 09:28:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D230628C0F8; Mon, 21 Jul 2008 09:28:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKyB1-00082n-VC for namedroppers-data@psg.com; Mon, 21 Jul 2008 16:23:55 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKyAw-0007vH-SQ for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 16:23:54 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m6LGM4FT008242; Mon, 21 Jul 2008 16:22:05 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m6LGM4jG008241; Mon, 21 Jul 2008 16:22:04 GMT Date: Mon, 21 Jul 2008 16:22:04 +0000 From: bmanning@vacation.karoshi.com To: Joe Abley Cc: Roy Arends , namedroppers@ops.ietf.org, Alessandro.Linari@nominet.org.uk Subject: Re: increasing DNS message entropy, a solution for NATs Message-ID: <20080721162204.GC7918@vacation.karoshi.com.> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jul 21, 2008 at 11:57:25AM -0400, Joe Abley wrote: > > On 21 Jul 2008, at 07:17, Roy Arends wrote: > > >A simple, straightforward method to increase entropy in DNS message > >transaction, is to query for the same name twice (or N times for > >even more > >increased entropy) and require that the answers be the same. This does > >require a change to the resolver, but not to the authoritative server. > > This will lead to trouble if the query is ever answered by one of a > cluster of servers, where there is the potential for some servers in > the cluster to be slightly more up-to-date than others. > > It also might lead to trouble if the query is ever answered by a > single-source server which updates between query i and query j for > some j>i. > > Joe welcome to the loose coherency feature of the DNS. --bill -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 09:52:13 2008 Return-Path: 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 E5BDF3A6AD8; Mon, 21 Jul 2008 09:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599] 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 7QYboKxppZlH; Mon, 21 Jul 2008 09:52:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6C4E53A6ADB; Mon, 21 Jul 2008 09:51:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKyYi-000BoY-CF for namedroppers-data@psg.com; Mon, 21 Jul 2008 16:48:24 +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 ) id 1KKyYd-000Bnz-Tq for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 16:48:22 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 773C6A110B; Mon, 21 Jul 2008 16:48:11 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "Roy Arends" cc: namedroppers@ops.ietf.org, Alessandro.Linari@nominet.org.uk In-Reply-To: Your message of "Mon, 21 Jul 2008 13:17:55 +0200." References: X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Mon, 21 Jul 2008 16:48:11 +0000 Message-ID: <82371.1216658891@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 773C6A110B.D1348 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: increasing DNS message entropy, a solution for NATs Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: "Roy Arends" > > ... > > A while back, Alessandro Linari (Oxford Brookes, working in our advanced > projects team), mentioned this alternative solution: > > A simple, straightforward method to increase entropy in DNS message > transaction, is to query for the same name twice (or N times for even more > increased entropy) and require that the answers be the same. This does > require a change to the resolver, but not to the authoritative server. with all respect to alessandro, i can think of three reasons why this is a terrible idea. but first i'll comment on your reasons: > There are a few things to consider, such as auth-servers not agreeing on > zone content (or other protocol violations), or avoiding birthday paradox > when sending two queries to the same server, ... so, this means: 1. the fact that the SOA will not always be present in responses means that differences in responses due to serial number slippage will look the same as an attack. 2. with or without an SOA present in responses, differences for load balancing or traffic redirection purposes will look the same as an attack. 3. a server, which may be a load balancing cluster, or which may be a multihomed server using separate NS RRs rather than one NS RR with multiple A RRs (which is a form of undetectable server aliasing) may have reason to rate-limit the apparently-duplicate requests, which could look the same as a DDoS. but i have three more reasons which i consider much more damning: 4. at the point in the topology where this action ("send N queries") must be done, there is no way to determine that it needs to be done. therefore the configuration for it will not be automatic, and will be set blindly. history teaches us that it will usually be set when it should not be, or not be set when it should be, and that it will not be changed when it needs to be changed (when the NAT/PAT device gets upgraded or downgraded.) 5. we have no way to know whether some future guessing attack will come along that only takes five packets for success. (amit klein's took 11 queries.) there is therefore no reason to expect that making the same query N times will make you safer, in real measurable terms, than making that query 1 time. 6. unlike the EDNS transition, the extra traffic implied by this proposal has no finishing date. it's not a transition at all. the additional traffic isn't just sent until the other end upgrades, but rather, forever. so, even when our grandchildren are grandparents, this extra traffic would still be in the system. so: > ... but overall, this solution is an alternative for those deployments > that are not capable of making use of source port randomization. i really don't agree that this is a solution or an alternative. we can all contemplate duplicating the upstream query whenever there is a mismatch in only the QID or only the UDP port or only the 0x20 bits or only the Q-tuple, but in that case one is likely better off just retrying with TCP. note that mismatches in only the UDP port are usually not application-visible, so it would be very hard to implement that portably on most operating systems. -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 10:00:55 2008 Return-Path: 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 049053A6AD9; Mon, 21 Jul 2008 10:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.882 X-Spam-Level: X-Spam-Status: No, score=-3.882 tagged_above=-999 required=5 tests=[AWL=-0.583, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 BNrc3ZtszlVs; Mon, 21 Jul 2008 10:00:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 967053A68A0; Mon, 21 Jul 2008 10:00:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKyh4-000DJZ-W4 for namedroppers-data@psg.com; Mon, 21 Jul 2008 16:57:02 +0000 Received: from [131.111.8.131] (helo=ppsw-1.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KKyh0-000DGX-5X for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 16:57:00 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:35773) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1KKygp-0006QJ-4s (Exim 4.67) (return-path ); Mon, 21 Jul 2008 17:56:47 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1KKygp-0004YK-Fq (Exim 4.67) (return-path ); Mon, 21 Jul 2008 17:56:47 +0100 Date: Mon, 21 Jul 2008 17:56:47 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Ben Laurie cc: Paul Vixie , namedroppers@ops.ietf.org, Eric Rescorla Subject: Re: transaction security in the last mile In-Reply-To: <48832197.80603@links.org> Message-ID: References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <48832197.80603@links.org> User-Agent: Alpine 1.10 (LSU 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sun, 20 Jul 2008, Ben Laurie wrote: > > So, I asked Eric Rescorla about this (copied) and he responds that: > > a) The ICMP unreachable message includes 64 _bits_ of the payload, according > to RFC 792, not 64 bytes, so only the UDP header is covered, and so all UDP > protocols have this issue. It's the IP header (20 bytes) plus 64 bits (8 bytes) of the IP payload, which is just enough to cover the whole UDP header, or the port numbers and sequence number from the TCP header. RFC 4884 allows the amount of payload to be greater than this minimum. Tony. -- f.anthony.n.finch http://dotat.at/ FISHER: NORTH OR NORTHWEST 5 TO 7. ROUGH OR VERY ROUGH DECREASING MODERATE OR ROUGH. SHOWERS. MODERATE OR GOOD. -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 13:48:25 2008 Return-Path: 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 5FE6E3A68C2; Mon, 21 Jul 2008 13:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 65Mn3exi0eK7; Mon, 21 Jul 2008 13:48:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D5D443A6978; Mon, 21 Jul 2008 13:48:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL28B-000BhL-Qd for namedroppers-data@psg.com; Mon, 21 Jul 2008 20:37:15 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL283-000Bgd-6O for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 20:37:09 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=w3Ounu4spuLs5TrMx3HW6A+a7T7Qob3rIteZJVT2gSEqfgj0Y3YIK3sr RHC6Rj4EIe9Y6bJyARsSxv7HIjpD9u9U5HVcFDZyknwFmprEXWAza+AAn bxRrAfScJ4/569D; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1216672627; x=1248208627; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Roy=20Arends"=20|Subject: =20Re:=20increasing=20DNS=20message=20entropy,=20a=20solu tion=20for=20NATs|Date:=20Mon,=2021=20Jul=202008=2022:36: 59=20+0200|Message-ID:=20|To:=20Joe=20Ab ley=20|Cc:=20Alessandro.Linari@no minet.org.uk,=0D=0A=09namedroppers@ops.ietf.org |MIME-Version:=201.0|In-Reply-To:=20|References:=20=20; bh=CdmFOIiuB72zUTz+mzxi8ON8s9373HK/E3CxvQ6AldY=; b=jt2CvSQI7uJ6nmHbVRgpQAOLknpvGx4qlh8K7FJJd9VwgaDEwVzAqCtw Kw3MmgChcFPiB/m1nrFVy57iMk0meOhjxk0mzxL5uKw45T47inlo38Tqf VqYf3dHZQWzJsDw; X-IronPort-AV: E=Sophos;i="4.31,225,1215385200"; d="scan'208";a="4274806" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 21 Jul 2008 21:37:02 +0100 In-Reply-To: References: To: Joe Abley Cc: Alessandro.Linari@nominet.org.uk, namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: "Roy Arends" Date: Mon, 21 Jul 2008 22:36:59 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 21/07/2008 09:37:01 PM, Serialize complete at 21/07/2008 09:37:01 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Joe Abley wrote on 07/21/2008 05:57:25 PM: > On 21 Jul 2008, at 07:17, Roy Arends wrote: > > > A simple, straightforward method to increase entropy in DNS message > > transaction, is to query for the same name twice (or N times for > > even more > > increased entropy) and require that the answers be the same. This does > > require a change to the resolver, but not to the authoritative server. > > This will lead to trouble if the query is ever answered by one of a > cluster of servers, where there is the potential for some servers in > the cluster to be slightly more up-to-date than others. > > It also might lead to trouble if the query is ever answered by a > single-source server which updates between query i and query j for > some j>i. Make j-i zero, use one server. Roy -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 14:10:23 2008 Return-Path: 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 55DB228C1A6; Mon, 21 Jul 2008 14:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, RDNS_NONE=0.1] 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 WGNaiVNF6Upa; Mon, 21 Jul 2008 14:10:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6719528C1A0; Mon, 21 Jul 2008 14:10:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL2Yt-000Hv9-Gj for namedroppers-data@psg.com; Mon, 21 Jul 2008 21:04:51 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL2Yp-000Hub-Se for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 21:04:49 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 354FFC2DA3; Mon, 21 Jul 2008 22:04:43 +0100 (BST) Date: Mon, 21 Jul 2008 22:04:41 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Roy Arends , Joe Abley cc: Alessandro.Linari@nominet.org.uk, namedroppers@ops.ietf.org, Alex Bligh Subject: Re: increasing DNS message entropy, a solution for NATs Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 21 July 2008 22:36:59 +0200 Roy Arends wrote: >> It also might lead to trouble if the query is ever answered by a >> single-source server which updates between query i and query j for >> some j>i. > > Make j-i zero I presume the notation meant the i'th query and the j'th query made by the stub. If j-i=0, then i=j and there is only one query made! > use one server. Difficult to achieve with unicast. Alex -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 14:14:51 2008 Return-Path: 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 AAAEC28C1B9; Mon, 21 Jul 2008 14:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 I7q0OJIUvEee; Mon, 21 Jul 2008 14:14:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3467728C1B8; Mon, 21 Jul 2008 14:14:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL2e3-000JES-0j for namedroppers-data@psg.com; Mon, 21 Jul 2008 21:10:11 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL2dr-000JBJ-Jc for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 21:10:01 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=gdhJ6HdjDX4Fl5JuZyAXTXEx0YFlFlymssURdIvCfDS23sdi97e8IwZD 7g49L08Pxed3r4irifQvO/0IlLGfdD7if19C2tcaqsF6lW9d8imvze8tK koewTOZTkULbwPS; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1216674599; x=1248210599; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Roy=20Arends"=20|Subject: =20Re:=20increasing=20DNS=20message=20entropy,=20a=20solu tion=20for=20NATs|Date:=20Mon,=2021=20Jul=202008=2023:09: 54=20+0200|Message-ID:=20|To:=20Alex=20B ligh=20|Cc:=20Alessandro.Linari@nominet .org.uk,=0D=0A=09Alex=20Bligh=20,=0D=0A =09Joe=20Abley=20,=0D=0A=09namedr oppers@ops.ietf.org|MIME-Version:=201.0|In-Reply-To:=20|References:=20=20=20=20=20; bh=c6QGUWJFzFqCPUddK10y2gxx6BJnwjKEJt7avmC1QkE=; b=L5Rzn4WWIKBxZZRzoZCTLxFsarhQALhpYayqUTMqgv4gAqi6Sd6hSmUy GsTKh6VS67qk0PWLdS6Pc/f71xOvft9xhtobJSD+DDZCfbjQPAEYNNCgj WMUSEMbVMQFvhQJ; X-IronPort-AV: E=Sophos;i="4.31,225,1215385200"; d="scan'208";a="4275076" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 21 Jul 2008 22:09:58 +0100 In-Reply-To: References: To: Alex Bligh Cc: Alessandro.Linari@nominet.org.uk, Alex Bligh , Joe Abley , namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: "Roy Arends" Date: Mon, 21 Jul 2008 23:09:54 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 21/07/2008 10:09:57 PM, Serialize complete at 21/07/2008 10:09:57 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Alex Bligh wrote on 07/21/2008 11:04:41 PM: > --On 21 July 2008 22:36:59 +0200 Roy Arends wrote: > > >> It also might lead to trouble if the query is ever answered by a > >> single-source server which updates between query i and query j for > >> some j>i. > > > > Make j-i zero > > I presume the notation meant the i'th query and the j'th query made by > the stub. No, this discussion is about resolvers talking to authoritative servers. Not about stubs talking to resolvers. > If j-i=0, then i=j and there is only one query made! At a single point in time, issue two queries with the same question section. For more entropy, randomize everything else: source address, destination address, query ID, source port. Roy -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 14:26:31 2008 Return-Path: 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 008C43A6896; Mon, 21 Jul 2008 14:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.145 X-Spam-Level: X-Spam-Status: No, score=-0.145 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, RDNS_NONE=0.1] 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 LutaksWvLADV; Mon, 21 Jul 2008 14:26:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1FF523A63D3; Mon, 21 Jul 2008 14:26:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL2qb-000M4r-38 for namedroppers-data@psg.com; Mon, 21 Jul 2008 21:23:09 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL2qW-000M40-Fb for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 21:23:06 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id A06D1C2DA3; Mon, 21 Jul 2008 22:23:01 +0100 (BST) Date: Mon, 21 Jul 2008 22:22:55 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Roy Arends cc: Alessandro.Linari@nominet.org.uk, Joe Abley , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: increasing DNS message entropy, a solution for NATs Message-ID: <1B1D5BFC0958F599EFFD496A@Ximines.local> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Roy, --On 21 July 2008 23:09:54 +0200 Roy Arends wrote: >> I presume the notation meant the i'th query and the j'th query made by >> the stub. > > No, this discussion is about resolvers talking to authoritative servers. > > Not about stubs talking to resolvers. What's talking to what is I think irrelevant. >> If j-i=0, then i=j and there is only one query made! > > At a single point in time, issue two queries with the same question > section. For more entropy, randomize everything else: source address, > destination address, query ID, source port. Perhaps I am being more than usually thick here. At a single point in time (well, obviously a marginal difference as packets obviously get into one order or another on the wire), you send 2 queries (I and J) either to 2 different IP addresses, or both to the same address. Assume in both case QID, source port, source address are randomised. Now take the two cases. Different IP addresses: one server is out of sync with the other, as the zone has been modified. The replies are different. False positive for spoofing. Same IP address: unbeknownst to you, the two packets do not reach the same server due to loadbalancing / local unicast. The servers are out of sync as an update has not yet been processed on one. The replies are different, false positive for spoofing. Less likely but possible: no unicast, single server, in the fraction of a second between the arrival of queries I and J, the server updates; same result. Alex -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 14:36:39 2008 Return-Path: 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 A567F3A6808; Mon, 21 Jul 2008 14:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 EMP0z57EgpzB; Mon, 21 Jul 2008 14:36:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 82D113A67F2; Mon, 21 Jul 2008 14:36:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL30E-000Ob1-0S for namedroppers-data@psg.com; Mon, 21 Jul 2008 21:33:06 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL309-000OaU-VK for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 21:33:04 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=UF6ABhoZdXVPUTOBz3MEmQvsUGeTFwPCS/z16u2ZXMocTLIxOmObmAwi Yg1kzFnKeQEn3d3uQIq1NRT2x/IoBeYLd5MCCf+03VoKWYIA0gyvlyYH7 bpD9E/2sbvdm2yv; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1216675982; x=1248211982; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Roy=20Arends"=20|Subject: =20Re:=20increasing=20DNS=20message=20entropy,=20a=20solu tion=20for=20NATs|Date:=20Mon,=2021=20Jul=202008=2023:32: 44=20+0200|Message-ID:=20|To:=20Joe=20Ab ley=20|Cc:=20Alessandro.Linari@no minet.org.uk,=0D=0A=09Alex=20Bligh=20, =0D=0A=09namedroppers@ops.ietf.org|MIME-Version:=201.0 |In-Reply-To:=20|References:=20=20=20=20=20=20 =20; bh=xrmT3ti46M52WkNwCTmSfIyyDQ199N38WXm/B+VWs3Q=; b=obLTKyNCqd8mMHQ//kwc8+NicXm9UBfix0WF9+BeXohm7BA5H5kmyJFg 0JoDD+HYGBF0EOSBDxti7bmqDhyG72zqpPyi6BCxXoG+VxgtBIVsPhvam 5Vv4b5qKr7gjHm2; X-IronPort-AV: E=Sophos;i="4.31,225,1215385200"; d="scan'208";a="5315977" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 21 Jul 2008 22:32:47 +0100 In-Reply-To: References: To: Joe Abley Cc: Alessandro.Linari@nominet.org.uk, Alex Bligh , namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: "Roy Arends" Date: Mon, 21 Jul 2008 23:32:44 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 21/07/2008 10:32:47 PM, Serialize complete at 21/07/2008 10:32:47 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Joe Abley wrote on 07/21/2008 11:16:07 PM: > On 21 Jul 2008, at 17:09, Roy Arends wrote: > > > At a single point in time, > > There is no single point of time to do two things, in practice (at > least, in general). Joe, you're splitting hairs here. > > issue two queries with the same question > > section. For more entropy, randomize everything else: source address, > > destination address, query ID, source port. > > So, considering there are well-documented examples of TLD, root, and > other DNS infrastructure which will, by design, respond with different > answers to these two queries, what conclusions should such a resolver > draw from the observed incoherence? if different, use either, cache neither. Roy -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 15:16:52 2008 Return-Path: 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 CDD233A67F5; Mon, 21 Jul 2008 15:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_12=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 pDYFouduNh5H; Mon, 21 Jul 2008 15:16:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B6EC3A6AE3; Mon, 21 Jul 2008 15:16:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL3bR-00073c-J0 for namedroppers-data@psg.com; Mon, 21 Jul 2008 22:11:33 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL3bH-00072V-RH for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 22:11:30 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KL3bD-0002dv-1I for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 00:11:19 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id DF4D03F78; Tue, 22 Jul 2008 00:11:33 +0200 (CEST) Date: Tue, 22 Jul 2008 00:11:33 +0200 From: bert hubert To: namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs Message-ID: <20080721221133.GB19153@outpost.ds9a.nl> References: <1B1D5BFC0958F599EFFD496A@Ximines.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1B1D5BFC0958F599EFFD496A@Ximines.local> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: How about: http://lists.oarci.net/pipermail/dns-operations/2008-July/002972.html Which discusses adding some DNS message entropy, by some means, detailed below. > Lutz, (...) > But you may be right. I haven't heard of any TCP/IP hijacks lately, the > famed 'Mitnick-attacks' of the past. However, TCP/IP has around 16+32+32=80 > bits of entropy to play with. Some bits are lost because of window size etc, > and to other things, so give it a good 70 bits. > If we get DNS to the same level of entropy, we should be safe, or at least > as safe as TCP which I hear no worries about. > DNS is now at 16 (source port) + 16 (id) + 1 (nameserver), so indeed the 16 > extra bits I mentioned above would only get us to 49. > So adding 32 bits or even 48 bits of additional random would be best. > The algorithm might in fact be quite simple: > 1) See if a remote nameserver talks extended query id. > 2) If it doesn't fall back to TCP and get the bits from there. > 3) If that doesn't work, wait for people to fix their firewalls. > What do you think? Move to DNSEXT? There has already been extended query id > discussion there. I implemented the server part of this, using EDNS option number 4 ('EDNS PING'), and added support for the addition of EDNS PINGS to outgoing questions from the resolver. These appear not to cause problems, but of course nobody pings back yet. An EDNS PING is nothing but an EDNS option containing a blob of data (or arbitrary lengt) we expect to see back in the answer. I've given this some thoughts over the past week, it might be doable to slowly turn this on. First try the ping and use it if available, and keep state ("this IP address pings back to us, don't believe any answers where it doesn't"), but don't fall back to TCP. A year from now we turn on fall back to TCP if you don't EDNS-ping back. People who are afraid they will be overwhelmed by TCP queries make sure they have EDNS-pingback ability. A little bird tells me a scheme like this is already in use between stubs and certain resolvers, using EDNS option number 4 no less, but it works slightly differently, so we might have to use EDNS option 5. What do you think? The idea itself was thought up by Paul Vixie I think, the details about 'fallback to TCP otherwise' and the keep-state are my tiny addition. Bert On Mon, Jul 21, 2008 at 10:22:55PM +0100, Alex Bligh wrote: > Roy, > > --On 21 July 2008 23:09:54 +0200 Roy Arends wrote: > > >>I presume the notation meant the i'th query and the j'th query made by > >>the stub. > > > >No, this discussion is about resolvers talking to authoritative servers. > > > >Not about stubs talking to resolvers. > > What's talking to what is I think irrelevant. > > >>If j-i=0, then i=j and there is only one query made! > > > >At a single point in time, issue two queries with the same question > >section. For more entropy, randomize everything else: source address, > >destination address, query ID, source port. > > Perhaps I am being more than usually thick here. > > At a single point in time (well, obviously a marginal difference as packets > obviously get into one order or another on the wire), you send 2 queries (I > and J) either to 2 different IP addresses, or both to the same address. > Assume in both case QID, source port, source address are randomised. Now > take the two cases. > > Different IP addresses: one server is out of sync with the other, as the > zone has been modified. The replies are different. False positive for > spoofing. > > Same IP address: unbeknownst to you, the two packets do not reach the same > server due to loadbalancing / local unicast. The servers are out of sync > as an update has not yet been processed on one. The replies are different, > false positive for spoofing. Less likely but possible: no unicast, single > server, in the fraction of a second between the arrival of queries I and J, > the server updates; same result. > > Alex > > -- > 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: > > > !DSPAM:48850135193055702515455! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 16:18:03 2008 Return-Path: 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 A208F3A69B4; Mon, 21 Jul 2008 16:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] 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 oKhf8Iz-VncW; Mon, 21 Jul 2008 16:18:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA63B3A68E4; Mon, 21 Jul 2008 16:18:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL4Ye-000Kpg-EY for namedroppers-data@psg.com; Mon, 21 Jul 2008 23:12:44 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL4Ya-000Kp0-Si for namedroppers@ops.ietf.org; Mon, 21 Jul 2008 23:12:42 +0000 Received: (qmail 43511 invoked from network); 21 Jul 2008 23:56:09 -0000 Received: from softbank219001188017.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.17) by necom830.hpcl.titech.ac.jp with SMTP; 21 Jul 2008 23:56:09 -0000 Message-ID: <488517CE.6060404@necom830.hpcl.titech.ac.jp> Date: Tue, 22 Jul 2008 08:12:14 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Roy Arends CC: namedroppers@ops.ietf.org, Alessandro.Linari@nominet.org.uk Subject: Re: increasing DNS message entropy, a solution for NATs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Roy Arends wrote: > The proposed solution to solve the problem highlighted by Dan Kaminsky is The proper reference is section 2.2 of RFC3833 published in 2004. > randomizing source ports. As some have mentioned, NAT/PAT scenarios do not > benefit from this solution. > No, this discussion is about resolvers talking to authoritative servers. What? Resolvers behind NAT/PAT are directly talking to authoritative servers? You should first document all the possible senarios to combine DNS and NAT/PAT. > This does > require a change to the resolver, but not to the authoritative server. Given possible chaching on NAT/PAT and everywhere, you must update entire resolver chains between stub resolvers and authoritative servers, which is practically impossible. Masataka Ohta -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 19:21:20 2008 Return-Path: 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 EF1143A68A6; Mon, 21 Jul 2008 19:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.094 X-Spam-Level: X-Spam-Status: No, score=-1.094 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 C1ZtTq9x0xCg; Mon, 21 Jul 2008 19:21:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 14EE23A65A6; Mon, 21 Jul 2008 19:21:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL7OD-0005Qn-G5 for namedroppers-data@psg.com; Tue, 22 Jul 2008 02:14:09 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL7O9-0005QF-EX for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 02:14:07 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 20B5CFF26F; Tue, 22 Jul 2008 12:14:02 +1000 (EST) Message-ID: <48854197.70704@e164.org> Date: Tue, 22 Jul 2008 12:10:31 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs References: <82371.1216658891@nsa.vix.com> In-Reply-To: <82371.1216658891@nsa.vix.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: Paul Vixie wrote: > i really don't agree that this is a solution or an alternative. we can all > contemplate duplicating the upstream query whenever there is a mismatch in > only the QID or only the UDP port or only the 0x20 bits or only the Q-tuple, > but in that case one is likely better off just retrying with TCP. note that > mismatches in only the UDP port are usually not application-visible, so it > would be very hard to implement that portably on most operating systems. This is where SSLv2 failed, they used ICMP to pass messages about connection closure, SSLv3 onwards ignore the ICMP messages for the most part. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 19:23:14 2008 Return-Path: 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 B38E13A67A4; Mon, 21 Jul 2008 19:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 p18bYH+5fTM5; Mon, 21 Jul 2008 19:23:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 862FF3A65A6; Mon, 21 Jul 2008 19:23:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL7TO-0006b4-5h for namedroppers-data@psg.com; Tue, 22 Jul 2008 02:19:30 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL7TJ-0006aZ-FB for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 02:19:28 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=ca.afilias.info; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=RJGhMq6aA5QnjBBrZ4el6taMHe424MrQdggBlZORhp6kokcBolwENPMNtUn3DqLT+pnF6q3aIR+ArfOyRYCsJAj0dDw79jPAOr2i3ucO7KL8LmyZFvRGimJaIQTrHb57; Received: from [199.212.90.27] (helo=yxu1b27.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL35Z-00060C-IA; Mon, 21 Jul 2008 21:38:45 +0000 Cc: Alessandro.Linari@nominet.org.uk, Alex Bligh , namedroppers@ops.ietf.org Message-Id: From: Joe Abley To: "Roy Arends" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: increasing DNS message entropy, a solution for NATs Date: Mon, 21 Jul 2008 17:38:34 -0400 References: X-Mailer: Apple Mail (2.926) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 21 Jul 2008, at 17:32, Roy Arends wrote: > Joe Abley wrote on 07/21/2008 11:16:07 PM: > >> On 21 Jul 2008, at 17:09, Roy Arends wrote: >> >>> At a single point in time, >> >> There is no single point of time to do two things, in practice (at >> least, in general). > > Joe, you're splitting hairs here. Yeah. My intent was to reinforce the point that two queries, no matter how rapidly they are sent in succession to one another, are going to be handled autonomously and quite possibly by different servers. >>> issue two queries with the same question >>> section. For more entropy, randomize everything else: source >>> address, >>> destination address, query ID, source port. >> >> So, considering there are well-documented examples of TLD, root, and >> other DNS infrastructure which will, by design, respond with >> different >> answers to these two queries, what conclusions should such a resolver >> draw from the observed incoherence? > > if different, use either, cache neither. Thanks. It would be interesting to consider what class of queries or nameserver deployment scenarios might result in such observed incoherence regularly, and to further consider the impact if the answers relating to those queries wind up not being cached, most of the time. I haven't done such thinking, on the grounds that it is Monday. But it seems worth worrying about. Joe -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 19:23:47 2008 Return-Path: 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 9FD753A67A4; Mon, 21 Jul 2008 19:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=-0.591, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 5NcsrOUZagGS; Mon, 21 Jul 2008 19:23:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B6B03A68A6; Mon, 21 Jul 2008 19:23:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL7TK-0006ag-Gz for namedroppers-data@psg.com; Tue, 22 Jul 2008 02:19:26 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL7TF-0006aH-GG for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 02:19:24 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=ca.afilias.info; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=l4Q74Znsurqsg+r9I8As/mqYnqD8IR8/RPkEKmxAQyEWncQGGX8bU0uyTS5h/VW+nTlq1IBAjBAD6kLtGwkaA87/xfLSfzIhH+tFZdlplGhvFkmSnT1sCtA+B2coPuNZ; Received: from [199.212.90.27] (helo=yxu1b27.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL2jn-0005f9-Jw; Mon, 21 Jul 2008 21:16:07 +0000 Cc: Alex Bligh , Alessandro.Linari@nominet.org.uk, namedroppers@ops.ietf.org Message-Id: From: Joe Abley To: Roy Arends In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: increasing DNS message entropy, a solution for NATs Date: Mon, 21 Jul 2008 17:16:07 -0400 References: X-Mailer: Apple Mail (2.926) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 21 Jul 2008, at 17:09, Roy Arends wrote: > At a single point in time, There is no single point of time to do two things, in practice (at least, in general). > issue two queries with the same question > section. For more entropy, randomize everything else: source address, > destination address, query ID, source port. So, considering there are well-documented examples of TLD, root, and other DNS infrastructure which will, by design, respond with different answers to these two queries, what conclusions should such a resolver draw from the observed incoherence? Joe -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 19:24:29 2008 Return-Path: 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 AFA163A65A6; Mon, 21 Jul 2008 19:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.571 X-Spam-Level: X-Spam-Status: No, score=-1.571 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 XYBKJs1IFcXW; Mon, 21 Jul 2008 19:24:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB7983A67A4; Mon, 21 Jul 2008 19:24:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL7TU-0006bZ-Ky for namedroppers-data@psg.com; Tue, 22 Jul 2008 02:19:36 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL7TQ-0006bB-22 for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 02:19:34 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=ca.afilias.info; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=fkNCNIXwBs0WABtNIvXVSAHERDlECRoyKONjZ1oyZ7wQdFQT8jFCY2LjnGdOFJiPvdPe3VOoeXtOrcXcSyVAh7etqcQC8bcp9gBpCbA2D98qhqP7vgq9xUhsINeThcSN; Received: from [199.212.90.27] (helo=yxu1b27.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL2E8-0005R2-RE; Mon, 21 Jul 2008 20:43:25 +0000 Cc: Alessandro.Linari@nominet.org.uk, namedroppers@ops.ietf.org Message-Id: <0E387FE8-EB3F-46C1-8529-22AF97A17879@ca.afilias.info> From: Joe Abley To: Roy Arends In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: increasing DNS message entropy, a solution for NATs Date: Mon, 21 Jul 2008 16:43:24 -0400 References: X-Mailer: Apple Mail (2.926) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 21 Jul 2008, at 16:36, Roy Arends wrote: >> It also might lead to trouble if the query is ever answered by a >> single-source server which updates between query i and query j for >> some j>i. > > Make j-i zero, use one server. j-i can't be zero if the client is repeating queries. Using a single server is certainly an option, but the semantics of loose coherency have led some of us to deploy service somewhat differently. I think it's reasonable to acknowledge the practical consideration that a client that expects subsequent (near-adjacent) queries to be answered identically in all cases might run into problems talking to many servers responsible for zones at and near the root of the namespace. More generally, if we change the basic semantics of the protocol, I think it's fair to assume there will be unexpected consequences. Joe -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 20:40:01 2008 Return-Path: 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 BD2CD3A6985; Mon, 21 Jul 2008 20:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599] 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 eKeaaDXm40nJ; Mon, 21 Jul 2008 20:40:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4FB163A68D1; Mon, 21 Jul 2008 20:40:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL8eq-000L3y-RT for namedroppers-data@psg.com; Tue, 22 Jul 2008 03:35:24 +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 ) id 1KL8em-000L3e-DF for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 03:35:22 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 69CBFA1038 for ; Tue, 22 Jul 2008 03:35:06 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Mon, 21 Jul 2008 23:32:44 +0200." References: X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Tue, 22 Jul 2008 03:35:06 +0000 Message-ID: <52078.1216697706@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 69CBFA1038.AED42 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: increasing DNS message entropy, a solution for NATs Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: there are negative replies to two different branches of this thread below. > From: "Roy Arends" > > Joe Abley wrote on 07/21/2008 11:16:07 PM: > > > So, considering there are well-documented examples of TLD, root, and > > other DNS infrastructure which will, by design, respond with different > > answers to these two queries, what conclusions should such a resolver > > draw from the observed incoherence? > > if different, use either, cache neither. since the verb "use" in this case just means "to cache", since many RDNS cache and regenerate all data passing through them from ADNS to stub, this is a meaningless suggestion in response to an absolutely fatal observation. > From: bert hubert > > How about: > > http://lists.oarci.net/pipermail/dns-operations/2008-July/002972.html > Which discusses adding some DNS message entropy, by some means, detailed > below. > > > The algorithm might in fact be quite simple: > > 1) See if a remote nameserver talks extended query id. > > 2) If it doesn't fall back to TCP and get the bits from there. > > 3) If that doesn't work, wait for people to fix their firewalls. this is completely undeployable. tcp is blocked in way too many places, and the large commercial stub vendors would never implement #3 above, which turns this into the same basic downgrade vector all versions of XQID or cookies have ever had. -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 21:42:59 2008 Return-Path: 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 3C6C33A6816; Mon, 21 Jul 2008 21:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 OoFna-GWJmOh; Mon, 21 Jul 2008 21:42:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CECC93A67FF; Mon, 21 Jul 2008 21:42:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL9cx-0007Uz-Ve for namedroppers-data@psg.com; Tue, 22 Jul 2008 04:37:31 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL9cu-0007Uc-GR for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 04:37:30 +0000 Received: from [10.0.1.199] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id 3F3F8297E67; Mon, 21 Jul 2008 21:37:24 -0700 (PDT) Cc: namedroppers@ops.ietf.org Message-Id: From: David Conrad To: Paul Vixie In-Reply-To: <55957.1216574145@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: dns hop by hop transaction security for queries Date: Mon, 21 Jul 2008 21:37:22 -0700 References: <55957.1216574145@nsa.vix.com> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 20, 2008, at 10:15 AM, Paul Vixie wrote: > proposal: > > stubs, and caching forwarding servers, when acting as initiators, > should > use TKEY over TCP/53 to try to set up a shared secret with their > responders. if successful, this secret should be used for UDP/53 > queries > to that responder. if TKEY over TCP/53 is successful for some > responders > but not others, then the successful ones will be used exclusively. > if at > least one TSIG signed query transaction succeeds to a responder, and > then > later transactions fail with TSIG errors (BADSIG) then TKEY over TCP/ > 53 > should be repeated. if no TSIG signed query ever succeeds, then > after some > small number of retries, the TKEY should be discarded and no longer > used. > in cases where there is TKEY over TCP/53 fails, or where a TKEY was > acquired but then discarded, then TSIG must not be used on > transactions to > that responder. Oh. I get it. You're trying to make deploying DNSSEC look easy in comparison. :-) Regards, -drc -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 22:04:37 2008 Return-Path: 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 C1E3E3A67FF; Mon, 21 Jul 2008 22:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 yexa9YMKxuGg; Mon, 21 Jul 2008 22:04:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 98BE83A6846; Mon, 21 Jul 2008 22:04:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL9y1-000C80-HY for namedroppers-data@psg.com; Tue, 22 Jul 2008 04:59:17 +0000 Received: from [204.14.89.6] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL9xx-000Bwr-RR for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 04:59:15 +0000 Received: (qmail 10048 invoked by uid 399); 22 Jul 2008 04:58:41 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 22 Jul 2008 04:58:41 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <488568FC.1030903@dougbarton.us> Date: Mon, 21 Jul 2008 21:58:36 -0700 From: Doug Barton User-Agent: Thunderbird 2.0.0.14 (X11/20080606) MIME-Version: 1.0 To: Roy Arends CC: namedroppers@ops.ietf.org, Alessandro.Linari@nominet.org.uk Subject: Re: increasing DNS message entropy, a solution for NATs References: In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Roy Arends wrote: > The proposed solution to solve the problem highlighted by Dan Kaminsky is > randomizing source ports. As some have mentioned, NAT/PAT scenarios do not > benefit from this solution. I'm not as up on firewall/NAT stuff as I used to be, but don't most of them nowadays try to assign the same port on the outside as the client starts with on the inside? I do know that most firewalls nowadays have knobs to enable "randomization" of the outgoing UDP ports, so while it may not have the same level of effectiveness as what BIND is doing directly, it is "better than nothing." > A while back, Alessandro Linari (Oxford Brookes, working in our advanced > projects team), mentioned this alternative solution: > > A simple, straightforward method to increase entropy in DNS message > transaction, is to query for the same name twice (or N times for even more > increased entropy) and require that the answers be the same. This does > require a change to the resolver, but not to the authoritative server. That actually depends on how the authoritative server is configured. For example, I've written in the past about a hack we added when I was DNS Admin at Yahoo! to limit the number of A records in a rotor to those that would fit into a 512 byte UDP packet. So, if this proposal was in effect at that time, you would be virtually certain to get a different response _every_ time you query, which would trigger the "we're being attacked" alarm. I don't want to go down the "but that's a protocol violation" road again on this topic, I know it is. My point in this context is that this is being done "out in the wild," and it's probably being done a lot more often than people realize. Plenty of other folks have chimed in on why this multiple query idea is probably not a good path to pursue, but I thought I'd throw one more log on the fire. hth, Doug -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 22:05:12 2008 Return-Path: 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 71B3D3A6846; Mon, 21 Jul 2008 22:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] 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 yCw4BrKUgxyi; Mon, 21 Jul 2008 22:05:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E82193A67FF; Mon, 21 Jul 2008 22:05:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KL9yk-000CKe-S7 for namedroppers-data@psg.com; Tue, 22 Jul 2008 05:00:02 +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 ) id 1KL9yg-000CJu-RA for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 05:00:00 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id DFAA1A1049 for ; Tue, 22 Jul 2008 04:59:48 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Mon, 21 Jul 2008 21:37:22 MST." References: <55957.1216574145@nsa.vix.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Tue, 22 Jul 2008 04:59:48 +0000 Message-ID: <59239.1216702788@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: DFAA1A1049.16B16 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: dns hop by hop transaction security for queries Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Oh. I get it. You're trying to make deploying DNSSEC look easy in > comparison. > > :-) :-). if there are no configuration knobs, no new error messages, no changes to DHCP or /etc/resolv.conf or rendezvous, and no dependencies on the U S Gov't to approve signing something before we can all start using the technology, then it will be extraordinarily easier to deploy than DNSSEC. it's just code and there are no forklifts. -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 23:41:15 2008 Return-Path: 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 D50C13A68FA; Mon, 21 Jul 2008 23:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 g2rJ-hpSnTrq; Mon, 21 Jul 2008 23:41:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4FBFC3A692F; Mon, 21 Jul 2008 23:41:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLBSp-0004fh-OQ for namedroppers-data@psg.com; Tue, 22 Jul 2008 06:35:11 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLBSk-0004XO-0J for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 06:35:09 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KLBSg-0004r6-7P; Tue, 22 Jul 2008 08:35:02 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 28FD04B4E2; Tue, 22 Jul 2008 08:35:14 +0200 (CEST) Date: Tue, 22 Jul 2008 08:35:14 +0200 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: there is a leak: message entropy increase urgent Message-ID: <20080722063514.GD19153@outpost.ds9a.nl> References: <52078.1216697706@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52078.1216697706@nsa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dan Kaminksy's issue accidentally leaked? http://blog.invisibledenizen.org/2008/07/kaminskys-dns-issue-accidentally-leaked.html Plus : On Tue, Jul 22, 2008 at 03:35:06AM +0000, Paul Vixie wrote: > > > The algorithm might in fact be quite simple: > > > 1) See if a remote nameserver talks extended query id. > > > 2) If it doesn't fall back to TCP and get the bits from there. > > > 3) If that doesn't work, wait for people to fix their firewalls. > > this is completely undeployable. tcp is blocked in way too many places, and > the large commercial stub vendors would never implement #3 above, which turns > this into the same basic downgrade vector all versions of XQID or cookies > have ever had. At least this shows us a path that gives immediate benefit to those who play, especially the "opportunistic keep-state EDNS PING" where resolvers cache who has done EDNS PING in te past, and know they should not be downgraded (for now). "[it] might be doable to slowly turn this on. First try the ping and use it if available, and keep state ("this IP address pings back to us, don't believe any answers where it doesn't"), but don't fall back to TCP. A year from now we turn on fall back to TCP if you don't EDNS-ping back. People who are afraid they will be overwhelmed by TCP queries make sure they have EDNS-pingback ability. " EDNS PING moved to EDNS option 5 today. I'll wrap up some informal specs and see who plays. There is an immediate benefit for everybody who joins. Especially since http://blog.invisibledenizen.org/2008/07/kaminskys-dns-issue-accidentally-leaked.html .. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 21 23:57:49 2008 Return-Path: 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 A30473A692F; Mon, 21 Jul 2008 23:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.461 X-Spam-Level: X-Spam-Status: No, score=-103.461 tagged_above=-999 required=5 tests=[AWL=3.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 UxzYzZ6nc1De; Mon, 21 Jul 2008 23:57:48 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id DF5AC3A6949; Mon, 21 Jul 2008 23:57:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLBjO-000841-1A for namedroppers-data@psg.com; Tue, 22 Jul 2008 06:52:18 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLBjK-00083f-6K for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 06:52:16 +0000 Received: from [192.168.100.27] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 3F2F1C2DA3; Tue, 22 Jul 2008 07:52:10 +0100 (BST) Date: Tue, 22 Jul 2008 07:53:49 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: dns hop by hop transaction security for queries Message-ID: <9A3DEBA3D8FF82A3FFFB3142@nimrod.local> In-Reply-To: <59239.1216702788@nsa.vix.com> References: <55957.1216574145@nsa.vix.com> <59239.1216702788@nsa.vix.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 22 July 2008 04:59:48 +0000 Paul Vixie wrote: > if there are no configuration knobs, no new error messages, no changes to > DHCP or /etc/resolv.conf or rendezvous, and no dependencies on the U S > Gov't to approve signing something before we can all start using the > technology, then it will be extraordinarily easier to deploy than DNSSEC. > it's just code and there are no forklifts. How much of the perceived problem is lack of signing by USG in your opinion? I think there are other options (along the lines of DLV) that would allow faster deployment if this was substantially the longest pole in the tent and would allow CNOBIN, ccTLDs etc. to sign their zones if they were so minded. Clearly this would leave individual users to sign their zones, but those being spoofed / phished would have every incentive to get on with it. Alex -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 00:10:23 2008 Return-Path: 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 CDC7D3A68AC; Tue, 22 Jul 2008 00:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599] 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 3bQSr1Z7mW+o; Tue, 22 Jul 2008 00:10:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B10403A68CD; Tue, 22 Jul 2008 00:10:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLBwH-000AoK-EI for namedroppers-data@psg.com; Tue, 22 Jul 2008 07:05:37 +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 ) id 1KLBw7-000AnK-0y for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 07:05:34 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 5378FA10FE; Tue, 22 Jul 2008 07:05:19 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Alex Bligh cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Tue, 22 Jul 2008 07:53:49 +0100." <9A3DEBA3D8FF82A3FFFB3142@nimrod.local> References: <55957.1216574145@nsa.vix.com> <59239.1216702788@nsa.vix.com> <9A3DEBA3D8FF82A3FFFB3142@nimrod.local> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Tue, 22 Jul 2008 07:05:19 +0000 Message-ID: <69600.1216710319@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 5378FA10FE.9C885 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: dns hop by hop transaction security for queries Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Alex Bligh > > --On 22 July 2008 04:59:48 +0000 Paul Vixie wrote: > > > if there are no configuration knobs, no new error messages, no changes > > to DHCP or /etc/resolv.conf or rendezvous, and no dependencies on the U > > S Gov't to approve signing something before we can all start using the > > technology, then it will be extraordinarily easier to deploy than > > DNSSEC. it's just code and there are no forklifts. > > How much of the perceived problem is lack of signing by USG in your opin? icann can't make a change of this kind to the root zone without permission from a lot of people, definitely including its board and USG, probably including IAB or IESG, and possibly including its SSAC and RSSAC and GAC and ALAC committees. i don't know that USG is the last remaining approval, and for that matter i don't know if USG has been asked to approve anything. > I think there are other options (along the lines of DLV) that would allow > faster deployment if this was substantially the longest pole in the tent > and would allow CNOBIN, ccTLDs etc. to sign their zones if they were so > minded. Clearly this would leave individual users to sign their zones, > but those being spoofed / phished would have every incentive to get on > with it. suck though it may, we have to deploy dnssec. if icann can't sign the root zone then the TLDs and/or everybody else will have to make other arrangements, in which roy arends' DLVPTR work could be very important, or in which DLV could play a transition role. had we been able to bite, chew, and swallow dnssec, we could just use SIG(0) for stubs, and UDPPORT / QID predictability would not matter. i apologize for not making this case clearly enough when we launched DLV. i think most folks were so concerned about DLV being a power/glory grab that the merits and justifications and goals just didn't seem to register at all. -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 00:20:44 2008 Return-Path: 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 468673A6913; Tue, 22 Jul 2008 00:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599] 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 PnhJjjgko7jl; Tue, 22 Jul 2008 00:20:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 364AF3A68AC; Tue, 22 Jul 2008 00:20:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLC6U-000Cz7-Il for namedroppers-data@psg.com; Tue, 22 Jul 2008 07:16:10 +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 ) id 1KLC6P-000Cxq-R6 for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 07:16:07 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 95604A10DA for ; Tue, 22 Jul 2008 07:16:01 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Tue, 22 Jul 2008 08:35:14 +0200." <20080722063514.GD19153@outpost.ds9a.nl> References: <52078.1216697706@nsa.vix.com> <20080722063514.GD19153@outpost.ds9a.nl> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Tue, 22 Jul 2008 07:16:01 +0000 Message-ID: <70844.1216710961@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 95604A10DA.57060 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: there is a leak: message entropy increase urgent Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Dan Kaminksy's issue accidentally leaked? i don't think it was an accident. > > ... completely undeployable. tcp is blocked in way too many places, > > and the large commercial stub vendors would never implement #3 above, > > which turns this into the same basic downgrade vector all versions of > > XQID or cookies have ever had. > > At least this shows us a path that gives immediate benefit to those who > play, especially the "opportunistic keep-state EDNS PING" where resolvers > cache who has done EDNS PING in te past, and know they should not be > downgraded (for now). what's your plan for times when the responder legitimately does downgrade, or when load balancing (in the local or wide or remote area) replaces the endpoint entity in an on-path (non-spoofed) way? > EDNS PING moved to EDNS option 5 today. I'll wrap up some informal specs > and see who plays. this being the internet, there's room for a zillion boutique solutions. > There is an immediate benefit for everybody who joins. that may be so, but also, immediate risks, which will prevent scale. note, i've met several large internet companies recently who refuse to deploy EDNS at all, one said their eyeball count dropped by 3% when they started honouring EDNS signalling in their DNS responses. -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 00:28:06 2008 Return-Path: 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 546C93A68CD; Tue, 22 Jul 2008 00:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 jrUWAeJ5gpTE; Tue, 22 Jul 2008 00:28:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 735403A68AC; Tue, 22 Jul 2008 00:28:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLCE8-000ElT-V0 for namedroppers-data@psg.com; Tue, 22 Jul 2008 07:24:04 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLCE4-000Ekr-IE for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 07:24:03 +0000 Received: from [192.168.100.27] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 313C0C2DA3; Tue, 22 Jul 2008 08:23:57 +0100 (BST) Date: Tue, 22 Jul 2008 08:25:37 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: dns hop by hop transaction security for queries Message-ID: <3F1B1F109355E3A7D20BCB70@nimrod.local> In-Reply-To: <69600.1216710319@nsa.vix.com> References: <55957.1216574145@nsa.vix.com> <59239.1216702788@nsa.vix.com> <9A3DEBA3D8FF82A3FFFB3142@nimrod.local> <69600.1216710319@nsa.vix.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul, >> How much of the perceived problem is lack of signing by USG in your opin? > > icann can't make a change of this kind to the root zone without permission > from a lot of people, definitely including its board and USG, probably > including IAB or IESG, and possibly including its SSAC and RSSAC and GAC > and ALAC committees. i don't know that USG is the last remaining > approval, and for that matter i don't know if USG has been asked to > approve anything. Sorry, question incorrectly posed. How much of a perceived problem is lack of signing of the root zone? IE if a magic wand was waved and the root zone suddenly signed, how much of the problem would that fix? As I think there may be other spells to cast which would give sufficient band-aid without the root being signed (not involving ICANN or anyone else signing the zone). > suck though it may, we have to deploy dnssec. if icann can't sign the > root zone then the TLDs and/or everybody else will have to make other > arrangements, in which roy arends' DLVPTR work could be very important, > or in which DLV could play a transition role. had we been able to bite, > chew, and swallow dnssec, we could just use SIG(0) for stubs, and UDPPORT > / QID predictability would not matter. I think my question is then "is making other arrangements actually that hard technically?..." > i apologize for not making this case clearly enough when we launched DLV. > i think most folks were so concerned about DLV being a power/glory grab > that the merits and justifications and goals just didn't seem to register > at all. "... or does it boil down to a similar but different set of political organisational problems to signing the root?" Alex -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 00:36:53 2008 Return-Path: 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 197D23A6972; Tue, 22 Jul 2008 00:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] 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 16VV-xph5Q9E; Tue, 22 Jul 2008 00:36:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E6DE3A6848; Tue, 22 Jul 2008 00:36:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLCLL-000Gc7-EA for namedroppers-data@psg.com; Tue, 22 Jul 2008 07:31:31 +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 ) id 1KLCLH-000Gbh-Df for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 07:31:29 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id C35A7A10FC for ; Tue, 22 Jul 2008 07:31:23 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Tue, 22 Jul 2008 08:25:37 +0100." <3F1B1F109355E3A7D20BCB70@nimrod.local> References: <55957.1216574145@nsa.vix.com> <59239.1216702788@nsa.vix.com> <9A3DEBA3D8FF82A3FFFB3142@nimrod.local> <69600.1216710319@nsa.vix.com> <3F1B1F109355E3A7D20BCB70@nimrod.local> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Tue, 22 Jul 2008 07:31:23 +0000 Message-ID: <72007.1216711883@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: C35A7A10FC.F1599 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: dns hop by hop transaction security for queries Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Alex Bligh > > Sorry, question incorrectly posed. How much of a perceived problem is > lack of signing of the root zone? IE if a magic wand was waved and the > root zone suddenly signed, how much of the problem would that fix? i predict that 50 or so CCTLDs would sign within six months, and that COM would be signed within two years. i suppose it's saying something about the real expectations that those are optimistic "magic wand" numbers. > I think my question is then "is making other arrangements actually that > hard technically?..." no. DLV works today. its problem, similar to the two-query approach's problem, is that it won't scale to the size of the internet and the lifetime of our grandchildren's grandchildren. for that, we need roy arends' DLVPTR. -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 00:45:53 2008 Return-Path: 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 999903A6994; Tue, 22 Jul 2008 00:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599] 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 ZbTHgT715vis; Tue, 22 Jul 2008 00:45:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 81ED33A6848; Tue, 22 Jul 2008 00:45:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLCVR-000Io3-AV for namedroppers-data@psg.com; Tue, 22 Jul 2008 07:41:57 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLCVJ-000Imz-44 for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 07:41:51 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m6M7feDo001635; Tue, 22 Jul 2008 17:41:40 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200807220741.m6M7feDo001635@drugs.dv.isc.org> To: Paul Vixie Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: there is a leak: message entropy increase urgent In-reply-to: Your message of "Tue, 22 Jul 2008 07:16:01 GMT." <70844.1216710961@nsa.vix.com> Date: Tue, 22 Jul 2008 17:41:40 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > note, i've met several large internet companies recently who refuse to > deploy EDNS at all, one said their eyeball count dropped by 3% when they > started honouring EDNS signalling in their DNS responses. Was this before or after referrals to the COM servers from the root started exceeding 512 octets? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 00:47:49 2008 Return-Path: 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 C885B3A69C7; Tue, 22 Jul 2008 00:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.429 X-Spam-Level: X-Spam-Status: No, score=-0.429 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 AFOeAH5eaQNd; Tue, 22 Jul 2008 00:47:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DD16C3A69C2; Tue, 22 Jul 2008 00:47:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLCXk-000JQd-2n for namedroppers-data@psg.com; Tue, 22 Jul 2008 07:44:20 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLCXe-000JPW-Tm for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 07:44:16 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KLCXc-0005Y8-2z; Tue, 22 Jul 2008 09:44:12 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 6A9AD4B44C; Tue, 22 Jul 2008 09:44:26 +0200 (CEST) Date: Tue, 22 Jul 2008 09:44:26 +0200 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: there is a leak: message entropy increase urgent Message-ID: <20080722074425.GA28595@outpost.ds9a.nl> References: <52078.1216697706@nsa.vix.com> <20080722063514.GD19153@outpost.ds9a.nl> <70844.1216710961@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <70844.1216710961@nsa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jul 22, 2008 at 07:16:01AM +0000, Paul Vixie wrote: > note, i've met several large internet companies recently who refuse to > deploy EDNS at all, one said their eyeball count dropped by 3% when they > started honouring EDNS signalling in their DNS responses. Wow - I never knew it was this bad. Amazing how moribund DNS has become. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 00:48:34 2008 Return-Path: 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 190773A69A6; Tue, 22 Jul 2008 00:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=-0.508, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 qDjKLrpJH6qC; Tue, 22 Jul 2008 00:48:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1F3623A69CD; Tue, 22 Jul 2008 00:48:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLCXX-000JOo-4L for namedroppers-data@psg.com; Tue, 22 Jul 2008 07:44:07 +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 ) id 1KLCXT-000JO1-Bf for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 07:44:05 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 4F6D4A1106 for ; Tue, 22 Jul 2008 07:43:56 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Tue, 22 Jul 2008 17:41:40 +1000." <200807220741.m6M7feDo001635@drugs.dv.isc.org> References: <200807220741.m6M7feDo001635@drugs.dv.isc.org> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Tue, 22 Jul 2008 07:43:56 +0000 Message-ID: <73285.1216712636@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 4F6D4A1106.55FAC X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: there is a leak: message entropy increase urgent Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > note, i've met several large internet companies recently who refuse to > > deploy EDNS at all, one said their eyeball count dropped by 3% when they > > started honouring EDNS signalling in their DNS responses. > > Was this before or after referrals to the COM servers from > the root started exceeding 512 octets? after. as you know, inability to fit all the glue into 512 bytes is not cause for concern (nor TCP retry.) -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 01:41:07 2008 Return-Path: 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 1819228C10D; Tue, 22 Jul 2008 01:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=-0.439, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_44=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 S+zgI7vjp3BK; Tue, 22 Jul 2008 01:41:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 26A2728C106; Tue, 22 Jul 2008 01:41:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLDKl-0003nz-IW for namedroppers-data@psg.com; Tue, 22 Jul 2008 08:34:59 +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 ) id 1KLDKb-0003l0-VT for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 08:34:52 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 53314A10FC for ; Tue, 22 Jul 2008 08:34:26 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: ignoring icmp to make dtls work for the stub/RDNS relationship X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Tue, 22 Jul 2008 08:33:42 +0000 Message-ID: <78908.1216715622@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 53314A10FC.8D836 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: i really like the simplicity of the "just use dtls" approach. it can be done without a X.509 certification hierarchy, just ephemeral self-signed certs. it can be done without secrecy-encryption, using the null cipher. there are libraries that implement it on several popular platforms. there is an internet draft. it avoids all questions involving DNS payload or format changes. it would be way easier to implement than TKEY+TSIG, not in processor cycles mind you, but in number of lines of code a DNS guy would have to write. the thing that bothers me about it is fallback, which i consider to be absolutely necessary for universal deployment. fallback has to be made unforceable by an off-path attacker. this means ignoring ICMP (which can be forged) and using long timeouts and/or multiple retries (to outlast congestion based attacks). if i could be sure that ignoring ICMP was possible on all common modern platforms, i'd be willing to suggest the following: ICMP errors must always be sent and must always be seen. that is, before any DNS/DTLS negotiation packet is sent, an ICMP error message must be crafted (in BSD we call this a "raw" socket and it's how the "ping" utility works) and transmitted. and no incoming DTLS negotiation packet would be processed unless it was preceded by an ICMP error. the specific ICMP type and subtype would be chosen pseudorandomly from among a defined set of those which can make recvfrom() return -1. in this way, anyone who isn't prepared to ignore ICMP, can't do DTLS DNS. as an optimization, once someone has proved that they can ignore ICMP by getting beyond the initial session negotiation, these messages can cease to be sent and no longer required. thus normal queries would not have them, nor would session maintainance packets (key rollovers, if any) after the initial setup is complete. what i need to know is, is there at least one common modern platform on which it is not possible to ignore ICMP messages? note, we may have to restrict the transmission of ICMP to just the responder, which is more likely to have the nec'y privileges than is the initiator; and in this case, we'd only require the reception of ICMP in the initiator. this could deserve further study if we get that far. -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 02:00:01 2008 Return-Path: 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 593493A68B2; Tue, 22 Jul 2008 02:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 t4tGAQFGj32d; Tue, 22 Jul 2008 01:59:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B7CD33A67F4; Tue, 22 Jul 2008 01:59:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLDed-0008bF-Ay for namedroppers-data@psg.com; Tue, 22 Jul 2008 08:55:31 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLDeW-0008aa-H1 for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 08:55:29 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=tK1gYDTRJxdd/kvVtehQ+d5hkl87mm8sO35h1y8cea86iP7H6iMhY42S TlO7EZVQE/TDt2Y5xbjtMs9XHclMVcbBBKRlROOludRKm9k6x0im5xAOU Qz/p4gapgZn3ANc; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1216716924; x=1248252924; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Roy=20Arends"=20|Subject: =20Re:=20ignoring=20icmp=20to=20make=20dtls=20work=20for =20the=20stub/RDNS=20relationship|Date:=20Tue,=2022=20Jul =202008=2010:55:21=20+0200|Message-ID:=20|To:=20Paul=20Vixie=20|Cc:=20namedroppers@ ops.ietf.org|MIME-Version:=201.0|In-Reply-To:=20<78908.12 16715622@nsa.vix.com>|References:=20<78908.1216715622@nsa .vix.com>; bh=TMec/7PnmZW4eY6wgNkxdLNyABo+WHdhv+tgtBrOnQA=; b=lv/WRSCz+ukcbgp92CtxAaDZdH7njEfVSoxU1u5q8saJ+DowM2KXzrOX 0IuBvrCllz7dBhYg5C4OBzq92/FJVAUhXGzoMkNnYlL5qr/0N4OHPr270 J72xT+FQ3LE2QFz; X-IronPort-AV: E=Sophos;i="4.31,230,1215385200"; d="scan'208";a="5329555" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 22 Jul 2008 09:55:22 +0100 In-Reply-To: <78908.1216715622@nsa.vix.com> References: <78908.1216715622@nsa.vix.com> To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: ignoring icmp to make dtls work for the stub/RDNS relationship MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: "Roy Arends" Date: Tue, 22 Jul 2008 10:55:21 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 22/07/2008 09:55:22 AM, Serialize complete at 22/07/2008 09:55:22 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote on 07/22/2008 10:33:42 AM: > ignoring icmp to make dtls work for the stub/RDNS relationship > > i really like the simplicity of the "just use dtls" approach. it can be > done without a X.509 certification hierarchy, just ephemeral self-signed > certs. it can be done without secrecy-encryption, using the null cipher. > there are libraries that implement it on several popular platforms. there > is an internet draft. it avoids all questions involving DNS payload or > format changes. it would be way easier to implement than TKEY+TSIG, not > in processor cycles mind you, but in number of lines of code a DNS guy > would have to write. I really like the simplicity of "just running your own validating caching dns resolver" approach, like DRC suggested very early in a previous thread. Roy -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 07:52:35 2008 Return-Path: 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 75B463A6A41; Tue, 22 Jul 2008 07:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.688 X-Spam-Level: X-Spam-Status: No, score=-3.688 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 SzSbap86OKYa; Tue, 22 Jul 2008 07:52:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 107E53A6987; Tue, 22 Jul 2008 07:52:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLJ6l-0004gr-31 for namedroppers-data@psg.com; Tue, 22 Jul 2008 14:44:55 +0000 Received: from [131.111.8.135] (helo=ppsw-5.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLJ65-0004cf-NL for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 14:44:16 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:47223) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:fanf2) id 1KLJ5t-00029k-HB (Exim 4.67) (return-path ); Tue, 22 Jul 2008 15:44:01 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1KLJ5t-0005Er-A8 (Exim 4.67) (return-path ); Tue, 22 Jul 2008 15:44:01 +0100 Date: Tue, 22 Jul 2008 15:44:01 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Doug Barton cc: Roy Arends , namedroppers@ops.ietf.org, Alessandro.Linari@nominet.org.uk Subject: Re: increasing DNS message entropy, a solution for NATs In-Reply-To: <488568FC.1030903@dougbarton.us> Message-ID: References: <488568FC.1030903@dougbarton.us> User-Agent: Alpine 1.10 (LSU 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, 21 Jul 2008, Doug Barton wrote: > > I've written in the past about a hack we added when I was DNS Admin at > Yahoo! to limit the number of A records in a rotor to those that would > fit into a 512 byte UDP packet. So, if this proposal was in effect at > that time, you would be virtually certain to get a different response > _every_ time you query, which would trigger the "we're being attacked" > alarm. > > I don't want to go down the "but that's a protocol violation" road again > on this topic, I know it is. My point in this context is that this is > being done "out in the wild," and it's probably being done a lot more > often than people realize. Yes. DJB's tinydns uses this hack for A RR sets with more than 8 items. http://cr.yp.to/djbdns/balance.html Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT: NORTHWESTERLY 4 OR 5, BECOMING VARIABLE 3 LATER. MODERATE. FAIR. MODERATE OR GOOD. -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 12:07:15 2008 Return-Path: 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 66B453A6A5E; Tue, 22 Jul 2008 12:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] 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 jQvmyGyYgUOS; Tue, 22 Jul 2008 12:07:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 453453A6982; Tue, 22 Jul 2008 12:07:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLN5s-0005TQ-Gv for namedroppers-data@psg.com; Tue, 22 Jul 2008 19:00:16 +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 ) id 1KLN5o-0005T1-Nh for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 19:00:14 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 9D146A1022 for ; Tue, 22 Jul 2008 19:00:00 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Tue, 22 Jul 2008 19:00:00 +0000 Message-ID: <48935.1216753200@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 9D146A1022.F0177 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 as a working group document. note that this technique was told to me by david dagon fully three days before dan kaminsky told me about "the vulnerability" and as such, there is no causal relationship between this document and those events. also note that i have been running this in production without any errors or code changes for about the last four months. finally, note that Unbound also implements this feature, but hasn't enabled it by default (yet?) -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 12:35:14 2008 Return-Path: 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 C02AE3A677D; Tue, 22 Jul 2008 12:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 vaKNUBpI1Q+J; Tue, 22 Jul 2008 12:35:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E07F33A67D4; Tue, 22 Jul 2008 12:35:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLNXN-000BDd-Ea for namedroppers-data@psg.com; Tue, 22 Jul 2008 19:28:41 +0000 Received: from [69.46.124.26] (helo=outbound.afilias.info) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLNXJ-000B7m-FT for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 19:28:39 +0000 Received: from bmp-336-ms505.wa.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1KLNXD-0005Ek-6I; Tue, 22 Jul 2008 19:28:32 +0000 Message-ID: <488634DD.9040100@ca.afilias.info> Date: Tue, 22 Jul 2008 15:28:29 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 References: <48935.1216753200@nsa.vix.com> In-Reply-To: <48935.1216753200@nsa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: True Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: > please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 as a > working group document. note that this technique was told to me by david > dagon fully three days before dan kaminsky told me about "the vulnerability" > and as such, there is no causal relationship between this document and those > events. also note that i have been running this in production without any > errors or code changes for about the last four months. finally, note that > Unbound also implements this feature, but hasn't enabled it by default (yet?) > > I have read the document and fully support its adoption as a WG item. I encourage four others to do the same as fast as possible. ;-) Brian Dickson -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 12:42:52 2008 Return-Path: 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 570A53A68CB; Tue, 22 Jul 2008 12:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.444 X-Spam-Level: X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 gmqJ7VFZZ1AB; Tue, 22 Jul 2008 12:42:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7086F3A6827; Tue, 22 Jul 2008 12:42:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLNgE-000Cvn-T3 for namedroppers-data@psg.com; Tue, 22 Jul 2008 19:37:50 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLNg9-000Cv4-PN for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 19:37:48 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KLNg5-0006nK-BT; Tue, 22 Jul 2008 21:37:41 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 1DB213F68; Tue, 22 Jul 2008 21:37:56 +0200 (CEST) Date: Tue, 22 Jul 2008 21:37:55 +0200 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 Message-ID: <20080722193755.GA14820@outpost.ds9a.nl> References: <48935.1216753200@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48935.1216753200@nsa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jul 22, 2008 at 07:00:00PM +0000, Paul Vixie wrote: > please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 as a > working group document. note that this technique was told to me by david I've been a bit quiet on this front - despite implementing dns0x20 myself. dns0x20 does not add any entropy to queries involving domains with no alphabetical characters in them. Like . And it is exactly this . that is the grand prize. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 15:12:41 2008 Return-Path: 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 218793A68CB; Tue, 22 Jul 2008 15:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] 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 sdiUkSDL1CNL; Tue, 22 Jul 2008 15:12:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 975373A6840; Tue, 22 Jul 2008 15:12:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLQ1E-000Faz-5Z for namedroppers-data@psg.com; Tue, 22 Jul 2008 22:07:40 +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 ) id 1KLQ1A-000Faa-5C for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 22:07:38 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 66EC0A1049; Tue, 22 Jul 2008 22:07:32 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: bert hubert cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Tue, 22 Jul 2008 21:37:55 +0200." <20080722193755.GA14820@outpost.ds9a.nl> References: <48935.1216753200@nsa.vix.com> <20080722193755.GA14820@outpost.ds9a.nl> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Tue, 22 Jul 2008 22:07:32 +0000 Message-ID: <69526.1216764452@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 66EC0A1049.99B08 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > I've been a bit quiet on this front - despite implementing dns0x20 myself. > > dns0x20 does not add any entropy to queries involving domains with no > alphabetical characters in them. > Like . > And it is exactly this > . that is the grand prize. but not the only prize, and in most cases, too grand a prize. but is this a statement against adopting the document? that is, do the merits of the idea have to be uncontroversial at this stage? -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 15:18:59 2008 Return-Path: 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 C64883A68CB; Tue, 22 Jul 2008 15:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 thpSOi0GbNyQ; Tue, 22 Jul 2008 15:18:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E40E53A676A; Tue, 22 Jul 2008 15:18:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLQ8p-000HRO-6V for namedroppers-data@psg.com; Tue, 22 Jul 2008 22:15:31 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLQ8l-000HMc-85 for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 22:15:29 +0000 Received: from commandprompt.com (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m6MKOfto013588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Jul 2008 13:24:44 -0700 Date: Tue, 22 Jul 2008 16:22:14 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 Message-ID: <20080722202214.GM58564@commandprompt.com> References: <48935.1216753200@nsa.vix.com> <20080722193755.GA14820@outpost.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080722193755.GA14820@outpost.ds9a.nl> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Tue, 22 Jul 2008 13:24:44 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jul 22, 2008 at 09:37:55PM +0200, bert hubert wrote: > dns0x20 does not add any entropy to queries involving domains with no alphabetical characters in them. Is this an argument against adopting the draft as a WG item? Note that deciding the draft is a WG item does not entail that it will eventually be sent on for publication -- the WG could decide that the draft can't be made to work, or has fatal flaws, or something. A -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- 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: From dnsmaster@aeat.com Tue Jul 22 15:30:28 2008 Return-Path: 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 0EEDE3A676A for ; Tue, 22 Jul 2008 15:30:28 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -3.087 X-Spam-Level: X-Spam-Status: No, score=-3.087 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, GB_PHARMACY=1, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_FONT_FACE_BAD=0.884, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, MONEY_BACK=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 FgwdsZm1Hosg for ; Tue, 22 Jul 2008 15:30:27 -0700 (PDT) Received: from pool-96-241-155-44.washdc.fios.verizon.net (pool-96-241-155-44.washdc.fios.verizon.net [96.241.155.44]) by core3.amsl.com (Postfix) with SMTP id 0875C3A68B5 for ; Tue, 22 Jul 2008 15:30:26 -0700 (PDT) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Received: (qmail 14431 by uid 168); Tue, 22 Jul 2008 06:31:06 -0500 Message-Id: <20080722013106.14433.qmail@pool-96-241-155-44.washdc.fios.verizon.net> To: Subject: Three Days Only! Extra 25% Off. Details Inside. From: VIAGRA ® Official Site MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Tue, 22 Jul 2008 15:30:26 -0700 (PDT) Victoria's Secret
Must-Have Looks For Summer. If you are unable to see the images in this email, please click here.
Catalogue Quick Order Forward to a Friend



SPECIAL OFFER DETAILS:
*Easy Monthly Payments *No Risk 30-Day Money Back Guarantee

This special offer is available for only 3 days. Discounts are included in final prices.


You are receiving this email because you have subscribed to the Pharmacy® newsletter with the following address: dnsext-archive@ietf.org.

Unsubscribe | Privacy policy | Contact us

© 2008 Pharmacy All rights reserved.
From owner-namedroppers@ops.ietf.org Tue Jul 22 15:35:24 2008 Return-Path: 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 C5D483A6A58; Tue, 22 Jul 2008 15:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 l7++d8kCj5RD; Tue, 22 Jul 2008 15:35:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 46E223A6A59; Tue, 22 Jul 2008 15:35:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLQO1-000Kc3-Q5 for namedroppers-data@psg.com; Tue, 22 Jul 2008 22:31:13 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLQNy-000Kbj-1v for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 22:31:12 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=U5f0NKmJ5WvSPX398huFa4g/k68/Uvh9YRpvFhBTDyMtSAVbouSsvfcZ OImTHbFsdo77WQfv9EUxe1pq2FvE2NWX/01rkU1gbUMtxoUw/73+byscS sKuF/euVUdHVRyP; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1216765870; x=1248301870; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Roy=20Arends"=20|Subject: =20Re:=20please=20adopt=20http://tools.ietf.org/html/draf t-vixie-dnsext-dns0x20|Date:=20Wed,=2023=20Jul=202008=200 0:31:04=20+0200|Message-ID:=20|To:=20Pau l=20Vixie=20|Cc:=20namedroppers@ops.ietf.or g|MIME-Version:=201.0|In-Reply-To:=20<48935.1216753200@ns a.vix.com>|References:=20<48935.1216753200@nsa.vix.com>; bh=LxgyyEUISCo6SklqCBu4TFFz3HZf5AJMp+QoSgTTObI=; b=sqOOckyUazF0Ewx8XBPtB7Uf0jvQBhkoPymNhjwyKFus72GvXMO67nIT oV9CxAAu7vLPjfuk7dsr3W6X/IHr3WuC7jSyKXXWyE004aer71/XfNtl6 w1dWwZohF4Q82+o; X-IronPort-AV: E=Sophos;i="4.31,233,1215385200"; d="scan'208";a="4295725" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 22 Jul 2008 23:31:08 +0100 In-Reply-To: <48935.1216753200@nsa.vix.com> References: <48935.1216753200@nsa.vix.com> To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: "Roy Arends" Date: Wed, 23 Jul 2008 00:31:04 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 22/07/2008 11:31:08 PM, Serialize complete at 22/07/2008 11:31:08 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 I support this proposal. Roy Arends Nominet -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 16:06:11 2008 Return-Path: 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 EBA963A682A; Tue, 22 Jul 2008 16:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 w66E-G1obXn1; Tue, 22 Jul 2008 16:06:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D2B2A3A680C; Tue, 22 Jul 2008 16:06:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLQs2-0000eH-06 for namedroppers-data@psg.com; Tue, 22 Jul 2008 23:02:14 +0000 Received: from [193.1.169.37] (helo=cali.ucd.ie) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLQry-0000dy-FG for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 23:02:12 +0000 Received: from conversion-daemon.cali.ucd.ie by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0K4F00L01JVN6F00@cali.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 00:01:44 +0100 (IST) Received: from itservic-965dfc.no8.be ([83.141.81.52]) by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTPSA id <0K4F00LMYJYV5ZE0@cali.ucd.ie>; Wed, 23 Jul 2008 00:01:44 +0100 (IST) Date: Wed, 23 Jul 2008 00:03:26 +0100 From: Niall O'Reilly Subject: Re: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 In-reply-to: <48935.1216753200@nsa.vix.com> To: Paul Vixie , namedroppers@ops.ietf.org Cc: Niall.oReilly@ucd.ie Message-id: Organization: University College Dublin MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-15; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <48935.1216753200@nsa.vix.com> User-Agent: Opera Mail/9.51 (Win32) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, 22 Jul 2008 20:00:00 +0100, Paul Vixie wrote: > please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 as a > working group document. I have read the document and support the proposal to adopt it as a working group document. Niall O'Reilly -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 16:17:50 2008 Return-Path: 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 8E2A93A676A; Tue, 22 Jul 2008 16:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.767 X-Spam-Level: X-Spam-Status: No, score=-0.767 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 3GnU9KfMhA1q; Tue, 22 Jul 2008 16:17:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AAB113A68AD; Tue, 22 Jul 2008 16:17:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLR1h-0002VN-OJ for namedroppers-data@psg.com; Tue, 22 Jul 2008 23:12:13 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLR1a-0002Qy-QJ for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 23:12:11 +0000 Received: from [192.168.100.27] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 87992C2DAB; Wed, 23 Jul 2008 00:12:02 +0100 (BST) Date: Wed, 23 Jul 2008 00:13:49 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 Message-ID: <39CAAD7D92D60F78E7B00652@nimrod.local> In-Reply-To: <48935.1216753200@nsa.vix.com> References: <48935.1216753200@nsa.vix.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 22 July 2008 19:00:00 +0000 Paul Vixie wrote: > please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 as a > working group document. I have read and support this. Re the root zone stuff, I think the fact it doesn't protect against one attack (albeit an important one) does not mean that its potential in protecting against others should be ignored. And at adoption for a w/g doc stage, we are only looking for potential. Alex -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 16:58:19 2008 Return-Path: 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 5B9373A68B5; Tue, 22 Jul 2008 16:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 q7cnSFg96Nx4; Tue, 22 Jul 2008 16:58:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 77CA03A680C; Tue, 22 Jul 2008 16:58:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLRfR-000Asp-F0 for namedroppers-data@psg.com; Tue, 22 Jul 2008 23:53:17 +0000 Received: from [64.18.2.218] (helo=exprod7og116.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLRfN-000AsT-Lv for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 23:53:15 +0000 Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP; Tue, 22 Jul 2008 16:51:39 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id DE51A1A8203 for ; Tue, 22 Jul 2008 16:31:16 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.0.252] (66.93.162.128) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.278.0; Tue, 22 Jul 2008 16:31:16 -0700 Message-ID: <4DC83394-6F2C-4CB2-8373-05DCAABBEF7B@nominum.com> From: Ted Lemon To: In-Reply-To: <48935.1216753200@nsa.vix.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v928.1) Subject: Re: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 Date: Tue, 22 Jul 2008 16:31:14 -0700 References: <48935.1216753200@nsa.vix.com> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 22, 2008, at 12:00 PM, Paul Vixie wrote: > please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 > as a > working group document. I've read the draft and support its adoption as a working group document. -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 19:35:58 2008 Return-Path: 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 18E4C3A6850; Tue, 22 Jul 2008 19:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.553 X-Spam-Level: X-Spam-Status: No, score=-1.553 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 AEWnLNs3UBmc; Tue, 22 Jul 2008 19:35:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 34CE63A6802; Tue, 22 Jul 2008 19:35:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLU6p-000GS2-GB for namedroppers-data@psg.com; Wed, 23 Jul 2008 02:29:43 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLU6g-000GKF-ME for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 02:29:41 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=ca.afilias.info; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=FqojK/bKDqzCX2lp6MU5t7aDZYWCe3L0dYZu/EVbYhy6iKGjPa+bH1sWjGJaWnAASt6a6KEJXUxFZ2ATme0c/ByS+UJCTeDjwSD3Pxv8jSsXqxhK4oC3GvBAcryAYQBU; Received: from [199.212.90.13] (helo=calamari.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLU5N-000N1g-Ml; Wed, 23 Jul 2008 02:28:17 +0000 Cc: namedroppers@ops.ietf.org Message-Id: From: Joe Abley To: Paul Vixie In-Reply-To: <48935.1216753200@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 Date: Tue, 22 Jul 2008 22:28:12 -0400 References: <48935.1216753200@nsa.vix.com> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 22 Jul 2008, at 15:00, Paul Vixie wrote: > please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 > as a > working group document. I have read draft-vixie-dnsext-dns0x20 and support its adoption as a wg document. I would also volunteer to review future iterations of the document, if that seemed useful. Joe -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 23:21:02 2008 Return-Path: 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 790533A6A24; Tue, 22 Jul 2008 23:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.454 X-Spam-Level: X-Spam-Status: No, score=-0.454 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 5o-aP188XHI8; Tue, 22 Jul 2008 23:21:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3B2013A6A2A; Tue, 22 Jul 2008 23:21:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLXcW-0009m4-Hr for namedroppers-data@psg.com; Wed, 23 Jul 2008 06:14:40 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLXcR-0009lP-N7 for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 06:14:38 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KLXcJ-0003cs-AU; Wed, 23 Jul 2008 08:14:27 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 27B674B452; Wed, 23 Jul 2008 08:14:41 +0200 (CEST) Date: Wed, 23 Jul 2008 08:14:41 +0200 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 Message-ID: <20080723061441.GC14820@outpost.ds9a.nl> References: <48935.1216753200@nsa.vix.com> <20080722193755.GA14820@outpost.ds9a.nl> <69526.1216764452@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69526.1216764452@nsa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jul 22, 2008 at 10:07:32PM +0000, Paul Vixie wrote: > > dns0x20 does not add any entropy to queries involving domains with no > > alphabetical characters in them. > Like . > And it is exactly this > > . that is the grand prize. > > but not the only prize, and in most cases, too grand a prize. but is this > a statement against adopting the document? that is, do the merits of the > idea have to be uncontroversial at this stage? Please standardise away - it is a nice hack. I assume you'll be changing your domain to 'paulvixieonline.com' though! internetsoftwarecorporation.org also has a nice ring to it. I also note that 'com', which is just one lesser prize, has only 3 bits of 0x20 going for it. My favorite domain has just 2. The merits appear to be surely not enough to warrant any 'MUST randomise bit-0x20 in any query' language, though. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 23:25:17 2008 Return-Path: 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 4B9B93A6ABE; Tue, 22 Jul 2008 23:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599] 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 W0MWntsRIkLv; Tue, 22 Jul 2008 23:25:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4C4F33A6A2A; Tue, 22 Jul 2008 23:25:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLXj3-000BSy-8I for namedroppers-data@psg.com; Wed, 23 Jul 2008 06:21:25 +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 ) id 1KLXiz-000BSR-HN for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 06:21:23 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id CE67EA2534 for ; Wed, 23 Jul 2008 06:21:07 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Wed, 23 Jul 2008 08:14:41 +0200." <20080723061441.GC14820@outpost.ds9a.nl> References: <48935.1216753200@nsa.vix.com> <20080722193755.GA14820@outpost.ds9a.nl> <69526.1216764452@nsa.vix.com> <20080723061441.GC14820@outpost.ds9a.nl> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Wed, 23 Jul 2008 06:21:07 +0000 Message-ID: <13124.1216794067@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: CE67EA2534.4129D X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > The merits appear to be surely not enough to warrant any 'MUST randomise > bit-0x20 in any query' language, though. i agree, but then i felt that udp port randomization should have remained a BCP. i'll be comfortable with whatever the WG decides wrt the standards status (recommended vs. required) on dns-0x20. -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 22 23:29:15 2008 Return-Path: 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 9180B3A6A24; Tue, 22 Jul 2008 23:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.461 X-Spam-Level: X-Spam-Status: No, score=-0.461 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 34pEFWFbijau; Tue, 22 Jul 2008 23:29:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AB0BC3A6937; Tue, 22 Jul 2008 23:29:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLXmw-000COJ-1v for namedroppers-data@psg.com; Wed, 23 Jul 2008 06:25:26 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLXmp-000CNW-NF for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 06:25:23 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KLXmn-0003ku-Bp for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 08:25:17 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 6D1724B4D2; Wed, 23 Jul 2008 08:25:31 +0200 (CEST) Date: Wed, 23 Jul 2008 08:25:30 +0200 From: bert hubert To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: Re: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 Message-ID: <20080723062530.GE14820@outpost.ds9a.nl> References: <48935.1216753200@nsa.vix.com> <20080722193755.GA14820@outpost.ds9a.nl> <20080722202214.GM58564@commandprompt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080722202214.GM58564@commandprompt.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jul 22, 2008 at 04:22:14PM -0400, Andrew Sullivan wrote: > On Tue, Jul 22, 2008 at 09:37:55PM +0200, bert hubert wrote: > > dns0x20 does not add any entropy to queries involving domains with no alphabetical characters in them. > > Is this an argument against adopting the draft as a WG item? Note I don't mean it that way - it just does not strike me as something that will get us very far. But do adopt - lots of people want to. It was only years ago that 16 bits of additional random was claimed not to matter in the least, whereas we are now discussing a proposal that adds 0 bits of random to very important queries. Once you've "Kaminsky'd" the root, who cares about longer domains. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 23 05:50:45 2008 Return-Path: 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 904CF3A698B; Wed, 23 Jul 2008 05:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.925 X-Spam-Level: X-Spam-Status: No, score=-102.925 tagged_above=-999 required=5 tests=[AWL=3.675, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 DEXp3+fk9lWf; Wed, 23 Jul 2008 05:50:44 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 33ADB3A680C; Wed, 23 Jul 2008 05:50:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLdWH-0003cg-Pd for namedroppers-data@psg.com; Wed, 23 Jul 2008 12:32:37 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLdVq-0003b2-EM for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 12:32:27 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KLdKq-0006OC-DR; Wed, 23 Jul 2008 14:20:48 +0200 Received: from fweimer by bfk.de with local id 1KLdKv-0003t8-Hg; Wed, 23 Jul 2008 14:20:53 +0200 To: Yue Luo Cc: bert hubert , "namedroppers@ops.ietf.org" Subject: Re: diff between -02 and -03 of forgery-resilience References: <20080324131740.GB14818@outpost.ds9a.nl> <7F2791CD3A148642AF9069A0336EDE853792625419@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com> From: Florian Weimer Date: Wed, 23 Jul 2008 14:20:52 +0200 In-Reply-To: <7F2791CD3A148642AF9069A0336EDE853792625419@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com> (Yue Luo's message of "Mon, 24 Mar 2008 10:36:33 -0700") Message-ID: <82wsjc6bbv.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Yue Luo: > The draft discusses about the effect of TTL on the vulnerability. > This assumes that a record in the cache is not overwritten before > its expiration. This assumption needs more discussion. An attacker > can design ways to "piggy back" records in spoofed responses order > to overwrite important cache entries. For example, to attack > c.isi.edu, the attacker can use packet similar to that in section > 6.2.7 of RFC 1034. This has now been disclosed for real by Dan Kaminsky in his Wired interview. What about not processing further records which are present in a CNAME answer in the answer section as some sort of mitigation strategy? The downside is that it may cause additional cache misses, which has got a performance penalty--and traditionally, sending more requests meant that you increase your spoofing risk. Another option would be not to overwrite cached data with the piggy-backed record, but this requires that we put the data at a very low trust level (below everything listed in RFC 2181, I guess). It's also more difficult to implement correctly. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 23 09:32:08 2008 Return-Path: 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 6469A3A6A22; Wed, 23 Jul 2008 09:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.155 X-Spam-Level: X-Spam-Status: No, score=-104.155 tagged_above=-999 required=5 tests=[AWL=2.444, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 xcySo4-6KZSe; Wed, 23 Jul 2008 09:32:07 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 83C303A6407; Wed, 23 Jul 2008 09:32:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLh78-0006LM-Ao for namedroppers-data@psg.com; Wed, 23 Jul 2008 16:22:54 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLh6x-0006KR-Lj for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 16:22:51 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 696E733C1A for ; Wed, 23 Jul 2008 17:15:50 +0100 (BST) Message-ID: <48875934.8080101@links.org> Date: Wed, 23 Jul 2008 17:15:48 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: DNSEXT WG Subject: How do we get the whole world to upgrade to DNSSEC capable resolvers? X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Oh, I think we just did that. Next step? -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 23 09:58:31 2008 Return-Path: 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 4CCFF3A6AF3; Wed, 23 Jul 2008 09:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.792 X-Spam-Level: X-Spam-Status: No, score=-103.792 tagged_above=-999 required=5 tests=[AWL=2.807, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 n7yXa6o4GtgQ; Wed, 23 Jul 2008 09:58:30 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 802EA3A6AF1; Wed, 23 Jul 2008 09:58:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLhZm-000DZF-Uo for namedroppers-data@psg.com; Wed, 23 Jul 2008 16:52:30 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLhZc-000DYJ-Em for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 16:52:28 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id CF9B3C2DA3; Wed, 23 Jul 2008 17:52:17 +0100 (BST) Date: Wed, 23 Jul 2008 17:52:15 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Ben Laurie , DNSEXT WG cc: Alex Bligh Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Message-ID: <0D165394461618BA3B17B54B@Ximines.local> In-Reply-To: <48875934.8080101@links.org> References: <48875934.8080101@links.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 23 July 2008 17:15:48 +0100 Ben Laurie wrote: > Oh, I think we just did that. Doh, we forgot to make the world upgrade to serve DNSSEC data. > Next step? See above. Alex -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 23 10:36:25 2008 Return-Path: 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 72D6F3A6AF0; Wed, 23 Jul 2008 10:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.518 X-Spam-Level: X-Spam-Status: No, score=-105.518 tagged_above=-999 required=5 tests=[AWL=1.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 7PbJiAXVLsMl; Wed, 23 Jul 2008 10:36:24 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id B6BEF3A6ADE; Wed, 23 Jul 2008 10:36:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLi5h-000LQx-P2 for namedroppers-data@psg.com; Wed, 23 Jul 2008 17:25:29 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLi5d-000LQZ-UZ for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 17:25:27 +0000 Received: from [10.0.1.199] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id D014729B734; Wed, 23 Jul 2008 10:25:23 -0700 (PDT) Cc: DNSEXT WG Message-Id: From: David Conrad To: Ben Laurie In-Reply-To: <48875934.8080101@links.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Wed, 23 Jul 2008 10:25:23 -0700 References: <48875934.8080101@links.org> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 23, 2008, at 9:15 AM, Ben Laurie wrote: > Oh, I think we just did that. Actually, I suspect not, since I would guess this event has increased the number of dnscache sites out there. And PowerDNS (also unaffected by the vulnerability as I understand it) doesn't support DNSSEC either, right? Regards, -drc -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 23 11:47:27 2008 Return-Path: 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 975303A6876; Wed, 23 Jul 2008 11:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.514 X-Spam-Level: X-Spam-Status: No, score=-103.514 tagged_above=-999 required=5 tests=[AWL=3.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 3ZIryHMjSuQm; Wed, 23 Jul 2008 11:47:26 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 067F63A6AE2; Wed, 23 Jul 2008 11:47:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLjBe-000BUv-SM for namedroppers-data@psg.com; Wed, 23 Jul 2008 18:35:42 +0000 Received: from [82.93.240.211] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLjBM-000BUA-Pk for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 18:35:34 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KLj8G-0004yM-Ve for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 20:32:13 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 9209B4B44E; Wed, 23 Jul 2008 20:32:27 +0200 (CEST) Date: Wed, 23 Jul 2008 20:32:27 +0200 From: bert hubert To: David Conrad Cc: Ben Laurie , DNSEXT WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Message-ID: <20080723183227.GA11957@outpost.ds9a.nl> References: <48875934.8080101@links.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jul 23, 2008 at 10:25:23AM -0700, David Conrad wrote: > Actually, I suspect not, since I would guess this event has increased > the number of dnscache sites out there. And PowerDNS (also unaffected > by the vulnerability as I understand it) doesn't support DNSSEC > either, right? Correct - my reasoning can be found on http://ds9a.nl/dnssec/index.html#id2467146 Some older stuff: http://ds9a.nl/secure-dns.html DNS is part of the long chain from a named service to a physical server: 1) ARP to find the hardware serving the router/nameserver IP 2) DNS to find the server IP 3) BGP to find the link to the destination AS 4) (TCP/)IP to the actual server 5) Content Everybody who really cares about information security handles it in the application that deals with the content, and is close to the user. All the steps underneath have traditionally been plaintext, and have only been hardened enough to be secure enough that casual tampering is ruled out. Because we use real crypto for our important content anyhow, crypto that does authentication, this is not a problem. 1) ARPSEC has been proposed, but never went anywhere. Switches implement port security measures. 2) DNS has been hardened using random source ports 3) BGP has suffered the MD5 scare, and has now been hardened using TTL-checks to keep out strangers 4) TCP/IP has been hardened by making sure everybody uses unpredictable sequence numbers. You can see where this is going. DNSSEC would be the most complex protocol ever deployed on such a scale on the internet [1], with far reaching administrative and computational consequences for everybody, yet it would sit all the way down there in the stack. I wouldn't put any faith in secure DNS alone. So - DNS needs only to be strong enough to not be easily subverted in the process of transporting plaintext unauthenticated data. This puts an upper bound on the overhead (financial, technical and administrative) that we should commit to DNS security. And I firmly believe some simple measures will bring DNS to the required level of robustness against tampering, and that these simple measures will fit in the the 'overhead budget' mentioned above. [2] I also firmly believe DNSSEC will impose an order of magnitude more hassle than the world is willing to bear. Bert [1] The telephony world beats us hands down though. Think H.323 or SS7. [2] EDNS PING extra entropy, with gradual fallback to TCP to be introduced to give everybody the opportunity to deploy. Fallback to TCP in case of a single question-response {id,source-port} mismatch might even be enough! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 23 12:16:11 2008 Return-Path: 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 7F72E3A6A58; Wed, 23 Jul 2008 12:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.073 X-Spam-Level: X-Spam-Status: No, score=-106.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 rxMu9+9x7OyX; Wed, 23 Jul 2008 12:16:10 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id B294B3A68BC; Wed, 23 Jul 2008 12:16:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLjgJ-000JBX-8E for namedroppers-data@psg.com; Wed, 23 Jul 2008 19:07:23 +0000 Received: from [64.18.2.178] (helo=psmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLjgF-000JBD-7k for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 19:07:21 +0000 Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Wed, 23 Jul 2008 12:07:16 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id 2B4181A8206; Wed, 23 Jul 2008 12:07:16 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.0.252] (66.93.162.128) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 23 Jul 2008 12:07:15 -0700 CC: DNSEXT WG Message-ID: <2FFE6519-7E9C-4DE8-AF69-697A4D875011@nominum.com> From: Ted Lemon To: bert hubert In-Reply-To: <20080723183227.GA11957@outpost.ds9a.nl> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v928.1) Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Wed, 23 Jul 2008 12:07:13 -0700 References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 23, 2008, at 11:32 AM, bert hubert wrote: > So - DNS needs only to be strong enough to not be easily subverted > in the > process of transporting plaintext unauthenticated data. This puts an > upper > bound on the overhead (financial, technical and administrative) that > we > should commit to DNS security. So how to I avoid a situation where, when I type "http://www.bankofexample.com/ " in the URL bar of my browser, I get a web page from a phisher who provides me with a perfectly valid-looking but completely un-secured web site that will phish my password? Even if your bank ordinarily puts up a secure form, if a phisher can subvert your DNS, they can do this. Lest you claim "that's no problem, because people know not to submit private data to non-secure forms," answer me this: how often do you, a security-savvy person, actually look to see if you are submitting to a URL that uses SSL? Now, how often do you think your friend the perfectly intelligent non-computer-geek does it? How often does your elderly great aunt who had a stroke last year check? Maybe DNSSEC is the wrong answer to this question. But there needs to be an answer. And it can't be "that's the user's responsibility." Good security does not depend on user education. -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 23 12:36:00 2008 Return-Path: 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 D814A3A67D6; Wed, 23 Jul 2008 12:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.24 X-Spam-Level: X-Spam-Status: No, score=-105.24 tagged_above=-999 required=5 tests=[AWL=1.359, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 tWC4ga1k4Ef9; Wed, 23 Jul 2008 12:35:59 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 9B02C3A685E; Wed, 23 Jul 2008 12:35:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLk1W-000OXk-HX for namedroppers-data@psg.com; Wed, 23 Jul 2008 19:29:18 +0000 Received: from [131.111.8.130] (helo=ppsw-0.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLk10-000OQ7-2V for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 19:28:55 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:45638) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1KLjiJ-00034M-13 (Exim 4.67) (return-path ); Wed, 23 Jul 2008 20:09:27 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1KLjiJ-0003iv-9q (Exim 4.67) (return-path ); Wed, 23 Jul 2008 20:09:27 +0100 Date: Wed, 23 Jul 2008 20:09:27 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Florian Weimer cc: Yue Luo , bert hubert , "namedroppers@ops.ietf.org" Subject: Re: diff between -02 and -03 of forgery-resilience In-Reply-To: <82wsjc6bbv.fsf@mid.bfk.de> Message-ID: References: <20080324131740.GB14818@outpost.ds9a.nl> <7F2791CD3A148642AF9069A0336EDE853792625419@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com> <82wsjc6bbv.fsf@mid.bfk.de> User-Agent: Alpine 1.10 (LSU 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, 23 Jul 2008, Florian Weimer wrote: > > What about not processing further records which are present in a CNAME > answer in the answer section as some sort of mitigation strategy? The > downside is that it may cause additional cache misses, which has got a > performance penalty--and traditionally, sending more requests meant > that you increase your spoofing risk. > > Another option would be not to overwrite cached data with the > piggy-backed record, but this requires that we put the data at a very > low trust level (below everything listed in RFC 2181, I guess). It's > also more difficult to implement correctly. RFC 2181 says: "when the name sought is an alias only the record describing that alias is necessarily authoritative. Clients should assume that other records may have come from the server's cache." (Which I read as saying that the target data is second-to-least trustworthy.) Does this still apply if both names are in the same zone? If so, wouldn't that also defeat Kaminsky's attack? Not sure why it would be difficult to implement: it's very similar to the handling of additional data in MX replies, etc. Tony. -- f.anthony.n.finch http://dotat.at/ FAIR ISLE: SOUTH BACKING SOUTHEAST 4 OR 5, OCCASIONALLY 6 LATER. MODERATE, OCCASIONALLY ROUGH AT FIRST. OCCASIONAL DRIZZLE WITH FOG PATCHES. MODERATE OR GOOD, OCCASIONALLY VERY POOR. -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 23 13:19:47 2008 Return-Path: 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 871663A6A58; Wed, 23 Jul 2008 13:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.857 X-Spam-Level: X-Spam-Status: No, score=-103.857 tagged_above=-999 required=5 tests=[AWL=2.742, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 S4KX1H7GegCn; Wed, 23 Jul 2008 13:19:46 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 8C7453A68E7; Wed, 23 Jul 2008 13:19:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLkg4-0008OK-Rv for namedroppers-data@psg.com; Wed, 23 Jul 2008 20:11:12 +0000 Received: from [82.93.240.211] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLkfm-0008N9-RH for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 20:11:04 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KLjp0-0005TT-Fh for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 21:16:22 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 203C14B44E; Wed, 23 Jul 2008 21:16:37 +0200 (CEST) Date: Wed, 23 Jul 2008 21:16:36 +0200 From: bert hubert To: Ted Lemon Cc: DNSEXT WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Message-ID: <20080723191636.GB32507@outpost.ds9a.nl> References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> <2FFE6519-7E9C-4DE8-AF69-697A4D875011@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2FFE6519-7E9C-4DE8-AF69-697A4D875011@nominum.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jul 23, 2008 at 12:07:13PM -0700, Ted Lemon wrote: > So how to I avoid a situation where, when I type > "http://www.bankofexample.com/ " in the URL bar of my browser, I get a web > page from a phisher who provides me with a perfectly valid-looking but > completely un-secured web site that will phish my password? Even if your > bank ordinarily puts up a secure form, if a phisher can subvert your DNS, > they can do this. Ted - correct. So we must make sure it is very hard to subvert DNS, and in short order too! Like within a year. Port randomization buys us some time, but not a lot. DNS security is important, and it must be hard to mess with the DNS. How about: it takes people that can inspect packets and modify them in transit. Because these people can do almost everything already - we can focus on making sure DNS can't be hijacked by people unable to inspect and modify packets. I dare anybody to subvert the DNS+32 bits of additional entropy without being able to inspect and modify packets. To emulate this, run DNS over TCP today, and see if you can spoof it. > Maybe DNSSEC is the wrong answer to this question. But there needs > to be an answer. And it can't be "that's the user's > responsibility." Good security does not depend on user education. We are in full agreement here. DNS should at least not make this problem worse! Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 23 14:02:22 2008 Return-Path: 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 2721C3A68D8; Wed, 23 Jul 2008 14:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 1JympnFRZL38; Wed, 23 Jul 2008 14:02:21 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 642373A6832; Wed, 23 Jul 2008 14:02:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLlKd-000JM2-CE for namedroppers-data@psg.com; Wed, 23 Jul 2008 20:53:07 +0000 Received: from [69.17.117.8] (helo=mail6.sea5.speakeasy.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLlKQ-000JL7-CK for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 20:53:05 +0000 Received: (qmail 11951 invoked from network); 23 Jul 2008 20:46:13 -0000 Received: from unknown (HELO [164.99.130.27]) (federico@[130.57.22.201]) (envelope-sender ) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 23 Jul 2008 20:46:13 -0000 Message-ID: <48879999.8050903@ximian.com> Date: Wed, 23 Jul 2008 16:50:33 -0400 From: Federico Lucifredi User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 References: <48935.1216753200@nsa.vix.com> In-Reply-To: <48935.1216753200@nsa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: > please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 as a > working group document. note that this technique was told to me by david > dagon fully three days before dan kaminsky told me about "the vulnerability" > and as such, there is no causal relationship between this document and those > events. also note that i have been running this in production without any > errors or code changes for about the last four months. finally, note that > Unbound also implements this feature, but hasn't enabled it by default (yet?) > I have reviewed draft-vixie-dnsext-dns0x20 and support its adoption as a wg document. I will also gladly review future revisions. One comment on the current draft: 5.5 MAY want to reiterate explicitly that when not matching one of QUID, UDP Port number, question type or class, the responses is to be discarded but the server is not removed from SLIST. A bit pedantic maybe, but right now the draft explicitly covers only the all-match except-name-mismatch case. Best -F -- _________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish (Federico L. Lucifredi) - flucifredi@ximian.com -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 23 14:32:24 2008 Return-Path: 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 484163A6887; Wed, 23 Jul 2008 14:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.734 X-Spam-Level: X-Spam-Status: No, score=-105.734 tagged_above=-999 required=5 tests=[AWL=0.865, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 H9qBb8trAPrI; Wed, 23 Jul 2008 14:32:23 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 824B03A68DD; Wed, 23 Jul 2008 14:32:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLlpI-0001Um-4T for namedroppers-data@psg.com; Wed, 23 Jul 2008 21:24:48 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLlpA-0001U6-4q for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 21:24:42 +0000 Received: from [10.0.1.199] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id 3531529BBF9; Wed, 23 Jul 2008 14:14:16 -0700 (PDT) Cc: DNSEXT WG Message-Id: <8A91CF57-0CBD-4CF2-BF59-C7D59CB4B7B9@virtualized.org> From: David Conrad To: bert hubert In-Reply-To: <20080723191636.GB32507@outpost.ds9a.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Wed, 23 Jul 2008 14:14:10 -0700 References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> <2FFE6519-7E9C-4DE8-AF69-697A4D875011@nominum.com> <20080723191636.GB32507@outpost.ds9a.nl> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Bert, On Jul 23, 2008, at 12:16 PM, bert hubert wrote: > I dare anybody to subvert the DNS+32 bits of additional entropy > without > being able to inspect and modify packets. To emulate this, run DNS > over TCP > today, and see if you can spoof it. People have spoofed TCP streams remotely in the past, but that is somewhat irrelevant. You are constraining the problem so the solution you prefer fits. The reality is that the problem goes beyond your constraint, even today. For example, ISPs inspect and modify DNS packets in ways many end users find objectionable and there is no way for end users to programmatically detect this. XID (et al) are simply more hacks that attempt to treat symptoms, trying to protect the transport. The disease is lack of an ability to validate the data. DNSSEC (for all its many warts and wobbly bits) does actually treat the disease. Regards, -drc -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 23 15:50:36 2008 Return-Path: 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 B349228C1CC; Wed, 23 Jul 2008 15:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.627 X-Spam-Level: X-Spam-Status: No, score=-104.627 tagged_above=-999 required=5 tests=[AWL=1.972, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 rAuIxsuq1Y3A; Wed, 23 Jul 2008 15:50:23 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id EE2FE28C1DD; Wed, 23 Jul 2008 15:50:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLn29-000Lea-48 for namedroppers-data@psg.com; Wed, 23 Jul 2008 22:42:09 +0000 Received: from [204.152.184.167] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLn1q-000LTT-Jj for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 22:42:00 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id F27A1114083 for ; Wed, 23 Jul 2008 22:40:32 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id 672DDE6064 for ; Wed, 23 Jul 2008 22:40:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m6NMd2p9063651; Thu, 24 Jul 2008 08:39:02 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200807232239.m6NMd2p9063651@drugs.dv.isc.org> To: bert hubert Cc: David Conrad , Ben Laurie , DNSEXT WG From: Mark Andrews Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? In-reply-to: Your message of "Wed, 23 Jul 2008 20:32:27 +0200." <20080723183227.GA11957@outpost.ds9a.nl> Date: Thu, 24 Jul 2008 08:39:02 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > On Wed, Jul 23, 2008 at 10:25:23AM -0700, David Conrad wrote: > > Actually, I suspect not, since I would guess this event has increased > > the number of dnscache sites out there. And PowerDNS (also unaffected > > by the vulnerability as I understand it) doesn't support DNSSEC > > either, right? > > Correct - my reasoning can be found on > http://ds9a.nl/dnssec/index.html#id2467146 > > Some older stuff: http://ds9a.nl/secure-dns.html > > DNS is part of the long chain from a named service to a physical server: > > 1) ARP to find the hardware serving the router/nameserver IP > 2) DNS to find the server IP > 3) BGP to find the link to the destination AS > 4) (TCP/)IP to the actual server > 5) Content > > Everybody who really cares about information security handles it in the > application that deals with the content, and is close to the user. All the > steps underneath have traditionally been plaintext, and have only been > hardened enough to be secure enough that casual tampering is ruled out. > > Because we use real crypto for our important content anyhow, crypto that > does authentication, this is not a problem. > > 1) ARPSEC has been proposed, but never went anywhere. Switches implement > port security measures. > 2) DNS has been hardened using random source ports Which does not work well for large recursive servers due to port/descriptor exhaustion. Which also interacts badly with other ephemeral uses of UDP ports. Spaying all the ports with late DNS/udp responses is not a good idea. > 3) BGP has suffered the MD5 scare, and has now been hardened using TTL-checks > to keep out > strangers > 4) TCP/IP has been hardened by making sure everybody uses unpredictable seque > nce numbers. > > You can see where this is going. > > DNSSEC would be the most complex protocol ever deployed on such a scale on > the internet [1], with far reaching administrative and computational > consequences for everybody, yet it would sit all the way down there in the > stack. > > I wouldn't put any faith in secure DNS alone. > > So - DNS needs only to be strong enough to not be easily subverted in the > process of transporting plaintext unauthenticated data. This puts an upper > bound on the overhead (financial, technical and administrative) that we > should commit to DNS security. > > And I firmly believe some simple measures will bring DNS to the required > level of robustness against tampering, and that these simple measures will > fit in the the 'overhead budget' mentioned above. [2] > > I also firmly believe DNSSEC will impose an order of magnitude more hassle > than the world is willing to bear. > > Bert > > [1] The telephony world beats us hands down though. Think H.323 or SS7. > [2] EDNS PING extra entropy, with gradual fallback to TCP to be introduced > to give everybody the opportunity to deploy. Fallback to TCP in case of a > single question-response {id,source-port} mismatch might even be enough! > > -- > http://www.PowerDNS.com Open source, database driven DNS Software > http://netherlabs.nl Open and Closed source services > > -- > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 23 16:39:32 2008 Return-Path: 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 EB5F33A63C9; Wed, 23 Jul 2008 16:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.907 X-Spam-Level: X-Spam-Status: No, score=0.907 tagged_above=-999 required=5 tests=[AWL=-2.570, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, RDNS_NONE=0.1] 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 6XJ1GTXUtS5u; Wed, 23 Jul 2008 16:39:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D3C263A6857; Wed, 23 Jul 2008 16:39:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLnqm-0008DF-7l for namedroppers-data@psg.com; Wed, 23 Jul 2008 23:34:28 +0000 Received: from [82.93.240.211] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLnqi-0008C8-2i for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 23:34:26 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KLn8g-0007vC-NG for namedroppers@ops.ietf.org; Thu, 24 Jul 2008 00:48:54 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 9E8913F64; Thu, 24 Jul 2008 00:49:08 +0200 (CEST) Date: Thu, 24 Jul 2008 00:49:08 +0200 From: bert hubert To: Mark Andrews Cc: David Conrad , Ben Laurie , DNSEXT WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Message-ID: <20080723224908.GA1935@outpost.ds9a.nl> References: <20080723183227.GA11957@outpost.ds9a.nl> <200807232239.m6NMd2p9063651@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200807232239.m6NMd2p9063651@drugs.dv.isc.org> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jul 24, 2008 at 08:39:02AM +1000, Mark Andrews wrote: > > 2) DNS has been hardened using random source ports > Which does not work well for large recursive servers due > to port/descriptor exhaustion. Unsure what you refer to - this stuff has been in production for years now, at high query levels (20-30kqps per IP address), without problems. It takes some work, but high performance is never easy. It is a well solved problem however (by now). Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 23 17:00:14 2008 Return-Path: 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 C7D3A3A6A96; Wed, 23 Jul 2008 17:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 kkg6gK0dCTWy; Wed, 23 Jul 2008 17:00:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DEBCA3A6A95; Wed, 23 Jul 2008 17:00:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLoAD-000DRg-4d for namedroppers-data@psg.com; Wed, 23 Jul 2008 23:54:33 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLoA8-000DAq-ID for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 23:54:31 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m6NNpaup004404; Wed, 23 Jul 2008 23:51:36 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m6NNpajB004402; Wed, 23 Jul 2008 23:51:36 GMT Date: Wed, 23 Jul 2008 23:51:36 +0000 From: bmanning@karoshi.com To: bert hubert Cc: Mark Andrews , David Conrad , Ben Laurie , DNSEXT WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Message-ID: <20080723235136.GA4390@vacation.karoshi.com.> References: <20080723183227.GA11957@outpost.ds9a.nl> <200807232239.m6NMd2p9063651@drugs.dv.isc.org> <20080723224908.GA1935@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080723224908.GA1935@outpost.ds9a.nl> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jul 24, 2008 at 12:49:08AM +0200, bert hubert wrote: > On Thu, Jul 24, 2008 at 08:39:02AM +1000, Mark Andrews wrote: > > > 2) DNS has been hardened using random source ports > > Which does not work well for large recursive servers due > > to port/descriptor exhaustion. > > Unsure what you refer to - this stuff has been in production for years now, > at high query levels (20-30kqps per IP address), without problems. > > It takes some work, but high performance is never easy. It is a well solved > problem however (by now). > > Bert high is a relative term, as in high-performance 286 computers with 128M of memory. --bill -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 23 17:00:18 2008 Return-Path: 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 60CC03A6A96; Wed, 23 Jul 2008 17:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.081 X-Spam-Level: X-Spam-Status: No, score=-1.081 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 VqiCrWyH3937; Wed, 23 Jul 2008 17:00:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 55CCD3A6A95; Wed, 23 Jul 2008 17:00:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLoBn-000Dvy-Cq for namedroppers-data@psg.com; Wed, 23 Jul 2008 23:56:11 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLoBi-000Dqb-UO for namedroppers@ops.ietf.org; Wed, 23 Jul 2008 23:56:09 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 4192D5AC5C4 for ; Thu, 24 Jul 2008 09:31:25 +1000 (EST) Message-ID: <4887BF35.3030302@e164.org> Date: Thu, 24 Jul 2008 09:31:01 +1000 From: Duane User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: DNS exploit in the wild 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: http://www.caughq.org/exploits/CAU-EX-2008-0002.txt -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 23 19:11:59 2008 Return-Path: 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 842593A6A6B; Wed, 23 Jul 2008 19:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 morlSxYms38Y; Wed, 23 Jul 2008 19:11:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A0DC73A69C9; Wed, 23 Jul 2008 19:11:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLqDH-000Iti-Hq for namedroppers-data@psg.com; Thu, 24 Jul 2008 02:05:51 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLqDD-000Imj-7X for namedroppers@ops.ietf.org; Thu, 24 Jul 2008 02:05:49 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m6O25YhD080674; Thu, 24 Jul 2008 12:05:36 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200807240205.m6O25YhD080674@drugs.dv.isc.org> To: bert hubert Cc: David Conrad , Ben Laurie , DNSEXT WG From: Mark Andrews Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? In-reply-to: Your message of "Thu, 24 Jul 2008 00:49:08 +0200." <20080723224908.GA1935@outpost.ds9a.nl> Date: Thu, 24 Jul 2008 12:05:34 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > On Thu, Jul 24, 2008 at 08:39:02AM +1000, Mark Andrews wrote: > > > 2) DNS has been hardened using random source ports > > Which does not work well for large recursive servers due > > to port/descriptor exhaustion. > > Unsure what you refer to - this stuff has been in production for years now, > at high query levels (20-30kqps per IP address), without problems. > > It takes some work, but high performance is never easy. It is a well solved > problem however (by now). Over how many concurrent ports without introducing queuing delays? > Bert -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 23 23:22:03 2008 Return-Path: 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 032653A68D9; Wed, 23 Jul 2008 23:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.85 X-Spam-Level: X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 bwgnJZULL+Zo; Wed, 23 Jul 2008 23:22:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 184483A68B7; Wed, 23 Jul 2008 23:22:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLtzI-000Or3-Rc for namedroppers-data@psg.com; Thu, 24 Jul 2008 06:07:40 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLtzD-000OqW-IL for namedroppers@ops.ietf.org; Thu, 24 Jul 2008 06:07:38 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KLtz8-0001a0-7e for namedroppers@ops.ietf.org; Thu, 24 Jul 2008 08:07:30 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 8AF304B44E; Thu, 24 Jul 2008 08:07:44 +0200 (CEST) Date: Thu, 24 Jul 2008 08:07:44 +0200 From: bert hubert To: David Conrad Cc: DNSEXT WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Message-ID: <20080724060743.GA7420@outpost.ds9a.nl> References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> <2FFE6519-7E9C-4DE8-AF69-697A4D875011@nominum.com> <20080723191636.GB32507@outpost.ds9a.nl> <8A91CF57-0CBD-4CF2-BF59-C7D59CB4B7B9@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8A91CF57-0CBD-4CF2-BF59-C7D59CB4B7B9@virtualized.org> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jul 23, 2008 at 02:14:10PM -0700, David Conrad wrote: > You are constraining the problem so the solution you prefer fits. The No, it goes beyond that. I've constrained the problem to protecting DNS against people that do not have the ability to intercept and modify your packets. This is not an arbitrary restriction. People that CAN modify your packets in transit are a wholly different problem - they don't even need to bother with DNS to mess with your traffic. They can do so directly. Not even DNSSEC will stop them! And this defines the natural bounding box for how secure DNS MUST be, and with it a limit on the burden of securing it. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 23 23:53:17 2008 Return-Path: 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 8197F3A6972; Wed, 23 Jul 2008 23:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 M37KlAQK--lK; Wed, 23 Jul 2008 23:53:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E7253A68D0; Wed, 23 Jul 2008 23:53:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLucr-0008ZG-1L for namedroppers-data@psg.com; Thu, 24 Jul 2008 06:48:33 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KLucm-0008YQ-Qx for namedroppers@ops.ietf.org; Thu, 24 Jul 2008 06:48:31 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KLuck-0002GK-By for namedroppers@ops.ietf.org; Thu, 24 Jul 2008 08:48:26 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id E890D4B565; Thu, 24 Jul 2008 08:48:40 +0200 (CEST) Date: Thu, 24 Jul 2008 08:48:40 +0200 From: bert hubert To: Mark Andrews Cc: David Conrad , Ben Laurie , DNSEXT WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Message-ID: <20080724064839.GD7420@outpost.ds9a.nl> References: <20080723224908.GA1935@outpost.ds9a.nl> <200807240205.m6O25YhD080674@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200807240205.m6O25YhD080674@drugs.dv.isc.org> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jul 24, 2008 at 12:05:34PM +1000, Mark Andrews wrote: > > It takes some work, but high performance is never easy. It is a well solved > > problem however (by now). > > Over how many concurrent ports without introducing queuing > delays? This is rapidly moving outside of the scope of what most namedroppers readers will find interesting, but PowerDNS uses 1 fresh socket per outgoing query, by default up to 1024 simultaneous outstanding questions. My dnsreplay experiments at such high speeds do not show an appreciable queuing delay compared to lower query rates. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 24 06:45:30 2008 Return-Path: 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 D030A3A683C; Thu, 24 Jul 2008 06:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.904 X-Spam-Level: X-Spam-Status: No, score=-2.904 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 8gzEwdmekEOE; Thu, 24 Jul 2008 06:45:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A95013A6A00; Thu, 24 Jul 2008 06:45:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KM10K-000M4g-9z for namedroppers-data@psg.com; Thu, 24 Jul 2008 13:37:12 +0000 Received: from [69.46.124.26] (helo=outbound.afilias.info) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KM10E-000M1n-HO for namedroppers@ops.ietf.org; Thu, 24 Jul 2008 13:37:10 +0000 Received: from bmp-336-ms505.wa.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1KLzKF-0002Y7-4A; Thu, 24 Jul 2008 11:49:39 +0000 Message-ID: <48886C4D.4020500@ca.afilias.info> Date: Thu, 24 Jul 2008 07:49:33 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: bert hubert CC: David Conrad , DNSEXT WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> <2FFE6519-7E9C-4DE8-AF69-697A4D875011@nominum.com> <20080723191636.GB32507@outpost.ds9a.nl> <8A91CF57-0CBD-4CF2-BF59-C7D59CB4B7B9@virtualized.org> <20080724060743.GA7420@outpost.ds9a.nl> In-Reply-To: <20080724060743.GA7420@outpost.ds9a.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: True Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: bert hubert wrote: > On Wed, Jul 23, 2008 at 02:14:10PM -0700, David Conrad wrote: > >> You are constraining the problem so the solution you prefer fits. The >> > > No, it goes beyond that. I've constrained the problem to protecting DNS > against people that do not have the ability to intercept and modify your > packets. > > This is not an arbitrary restriction. People that CAN modify your > packets in transit are a wholly different problem - they don't even need to > bother with DNS to mess with your traffic. They can do so directly. Not even > DNSSEC will stop them! > > I beg to differ. The presumption you are making is, that (a) the people modifying the DNS are the same people hijacking your traffic, and (b) that no benefit can be brought by use of DNSSEC in this scenario. Allow me to provide a concrete example, typical of an IETF attendee who knows what they are doing. Joe is attending an IETF. He stays in a hotel. He uses his laptop to access the internet via the hotel's network. The hotel outsources their network stuff to a shady operator, who likes to hijack DNS packets so as to replace ads with other ads. All DNS traffic gets directed to a caching resolver that has been hacked for just such a purpose. That hacked resolver is vulnerable to the Kaminsky attack, and is poisoned. Joe has his own local recursive resolver running on his laptop, and wants to access his bank's web site. He types in http://mybank.tld which should redirect him to https://special-thing.mybank.tld. His resolver does its thing, but before it gets very far, the DNS queries it makes get intercepted, and bad answers from the hacked box get sent back, instead sending him to https://phishing-site.tld. DNSSEC makes this impossible. Note that the ability to access packets in flight is irrelevant, so long as the proper DNS answers are served, and redirects from non-https to https get done properly. Once the https is reached, TLS/SSL protects things, but the key is reaching the right sight to start with. Without the ability to handle non-https initiation URLs safely via DNS, it's all a house of cards. Saying that not using https for everything, is blaming the victim. So, in short, DNSSEC is the only answer that gets around this very real, very well known problem. The idea of using other methods of hardening DNS resolvers is flawed, when not everyone operating a resolver is necessarily strongly incented to harden their resolver (e.g. the hotel outsourcing folks). > And this defines the natural bounding box for how secure DNS MUST be, and > with it a limit on the burden of securing it. > I disagree that your choice is natural, and I disagree that it is sufficient. Brian -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 24 07:41:40 2008 Return-Path: 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 CE7993A683C; Thu, 24 Jul 2008 07:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Qwtm6o5vDSrI; Thu, 24 Jul 2008 07:41:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1B3383A6869; Thu, 24 Jul 2008 07:41:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KM1sP-0007jh-Oe for namedroppers-data@psg.com; Thu, 24 Jul 2008 14:33:05 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KM1sH-0007LR-7c for namedroppers@ops.ietf.org; Thu, 24 Jul 2008 14:32:59 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m6OEVAup008380; Thu, 24 Jul 2008 14:31:10 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m6OEV5G5008379; Thu, 24 Jul 2008 14:31:05 GMT Date: Thu, 24 Jul 2008 14:31:05 +0000 From: bmanning@karoshi.com To: Brian Dickson Cc: bert hubert , David Conrad , DNSEXT WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Message-ID: <20080724143105.GA8334@vacation.karoshi.com.> References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48886C4D.4020500@ca.afilias.info> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jul 24, 2008 at 07:49:33AM -0400, Brian Dickson wrote: > The hotel outsources their network stuff to a shady operator, who likes > to hijack DNS packets so as to replace > ads with other ads. > > All DNS traffic gets directed to a caching resolver that has been hacked > for just such a purpose. > That hacked resolver is vulnerable to the Kaminsky attack, and is poisoned. so, hacked -twice- (at least) > Joe has his own local recursive resolver running on his laptop, and > wants to access his bank's web site. > He types in http://mybank.tld which should redirect him to > https://special-thing.mybank.tld. > > His resolver does its thing, but before it gets very far, the DNS > queries it makes get intercepted, and bad > answers from the hacked box get sent back, instead sending him to > https://phishing-site.tld. > > DNSSEC makes this impossible. hogwash. he will get sent to https://phishing-site.tld. -IF- he validates and has the banks TA, then his browser -might- complain. DNSSEC only gives one the ability to discern when the authenticity and integrity of the data has been compromised. It provides zero means to correct the problem. > Note that the ability to access packets in flight is irrelevant, so long > as the proper DNS answers are served, > and redirects from non-https to https get done properly. Once the https > is reached, TLS/SSL protects things, > but the key is reaching the right sight to start with. er, right. unless of course an earlier haq (additional data stuffing) has placed the SSL cert into young Joes browser. > So, in short, DNSSEC is the only answer that gets around this very real, > very well known problem. does not get around it, DNSSEC shines a light on an otherwise ambigious transaction. > Brian that being said, i have been migrating all my DNS servers/services to be able to support DNSSEC. I feel port randomization is a diversion but that might be a minority opinion. (yeah, i took the time to randomize ports) --bill -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 24 07:57:24 2008 Return-Path: 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 A167A3A685A; Thu, 24 Jul 2008 07:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 qZORCTzB6G+T; Thu, 24 Jul 2008 07:57:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9CA833A6A38; Thu, 24 Jul 2008 07:57:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KM2BF-000Bcx-6M for namedroppers-data@psg.com; Thu, 24 Jul 2008 14:52:33 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KM2B6-000BcA-Rx for namedroppers@ops.ietf.org; Thu, 24 Jul 2008 14:52:27 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=ca.afilias.info; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=OxrD+F/M5B9DkBB5E7smGZz2XsEoEkH3t4GgoJsG4Rnyoqkfz5K9eC7xNkgKl9Fl0TNCb3Oaqsjj6d5M7clCgkxuizcikZCd6XYJErnPE0SAKqtV3H4ClL1a2lTVZTqh; Received: from [199.212.90.13] (helo=calamari.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KM29n-000ISF-M9; Thu, 24 Jul 2008 14:51:04 +0000 Cc: bert hubert , David Conrad , DNSEXT WG Message-Id: <63C0FFE7-17E6-4ECE-9A12-0537FE2E3F4B@ca.afilias.info> From: Joe Abley To: Brian Dickson In-Reply-To: <48886C4D.4020500@ca.afilias.info> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Thu, 24 Jul 2008 10:51:03 -0400 References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> <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> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 24 Jul 2008, at 07:49, Brian Dickson wrote: > His resolver does its thing, but before it gets very far, the DNS > queries it makes get intercepted, and bad > answers from the hacked box get sent back, instead sending him to https://phishing-site.tld > . > > DNSSEC makes this impossible. Surely, DNSSEC making that impossible relies on the validator on Joe's laptop insisting that the TLD and MYBANK.TLD zones are signed, and that a trust anchor exists to verify the signatures. If the validator on Joe's laptop has an empty cache, and no configuration which will make it insist particularly that those zones are signed, surely the middleware which is replying to queries could just return as if the root, TLD and MYBANK.TLD zones are unsigned. At that point there will be no signatures to verify, and it will be as if DNSSEC was never deployed. [If the validator has cached security information from the results of previous queries, then it might be able to know that a lack of signatures received whilst in the hotel is a problem. But things expire from caches, laptops run out of power and get restarted, operating system patches require reboots, etc, so it doesn't seem reasonable to assume this will always be the case. "impossible" above is fairly absolute.] I keep seeing people insist that query-intercepting middleware will be defeated with DNSSEC, but I can't see why. Perhaps I'm missing something. Joe -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 24 10:21:56 2008 Return-Path: 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 1F1A13A6A42; Thu, 24 Jul 2008 10:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.93 X-Spam-Level: X-Spam-Status: No, score=-0.93 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 jCzxxruUxXTx; Thu, 24 Jul 2008 10:21:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 09BDD3A6A0D; Thu, 24 Jul 2008 10:21:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KM4PQ-000FEa-6E for namedroppers-data@psg.com; Thu, 24 Jul 2008 17:15:20 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KM4PM-000FE4-JN for namedroppers@ops.ietf.org; Thu, 24 Jul 2008 17:15:18 +0000 Received: from commandprompt.com (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m6OFbXDw021271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Jul 2008 08:37:36 -0700 Date: Thu, 24 Jul 2008 11:35:04 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: New agenda posted Message-ID: <20080724153504.GF69431@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Thu, 24 Jul 2008 08:37:36 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, Owing to the recent events and the resulting increased importance of forgery resilence, we have altered somewhat the agenda for the WG meeting. I uploaded it just now. Please review it; comments are of course welcome. If you have a particular adjustment that is needed as a result, please let me know as soon as possible. I will try to be accommodating, because of the late notice. (Note that any problems with this can be laid exclusively at my feet: I sent this to Olafur, but he's on vacation and hasn't seen the revised agenda as far as I know. So you can save your rotten tomatoes for me.) We have reserved 30 minutes in the agenda for discussion of further work on forgery resilence. We do have some drafts to discuss in that time, but part of the time will certainly be for open discussion. This alteration of the schedule means that there is less time for discussion of some other things. If you have been preparing any presentation on the basis of the previous agenda, _please check the new one_. Let me know if I have cut you too far compared to what you had to say. (Also, think about whether you were saying more than needed because of the allocated slot.) If you are presenting, and have materials for upload, please send them to us as soon as possible. Thanks. Best regards, Andrew (for the Chairs) -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 24 15:22:29 2008 Return-Path: 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 3EE663A6A77; Thu, 24 Jul 2008 15:22:29 -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 7RfUdwHPZOXU; Thu, 24 Jul 2008 15:22:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4A63A3A6A7A; Thu, 24 Jul 2008 15:22:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KM959-00017s-55 for namedroppers-data@psg.com; Thu, 24 Jul 2008 22:14:43 +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 ) id 1KM955-00017T-1r for namedroppers@ops.ietf.org; Thu, 24 Jul 2008 22:14:41 +0000 Received: from jelte (vhe-520087.sshn.net [195.169.221.157]) by sol.nlnetlabs.nl (Postfix) with ESMTP id CDF2613002B for ; Fri, 25 Jul 2008 00:14:36 +0200 (CEST) Received: from [192.168.8.11] (dragon [192.168.8.11]) by jelte (Postfix) with ESMTP id 9D1E9CF9C2 for ; Fri, 25 Jul 2008 00:14:36 +0200 (CEST) Message-ID: <4888FED2.6060204@NLnetLabs.nl> Date: Fri, 25 Jul 2008 00:14:42 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: DNSEXT WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> <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> In-Reply-To: <63C0FFE7-17E6-4ECE-9A12-0537FE2E3F4B@ca.afilias.info> 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: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe Abley wrote: > >> DNSSEC makes this impossible. > > Surely, DNSSEC making that impossible relies on the validator on Joe's > laptop insisting that the TLD and MYBANK.TLD zones are signed, and that > a trust anchor exists to verify the signatures. > > If the validator on Joe's laptop has an empty cache, and no > configuration which will make it insist particularly that those zones > are signed, surely the middleware which is replying to queries could > just return as if the root, TLD and MYBANK.TLD zones are unsigned. At > that point there will be no signatures to verify, and it will be as if > DNSSEC was never deployed. > how would you verify anything without a trust anchor? I don't think anyone here implies that DNSSEC works when you do not actually turn it on on the resolver you are using. > > I keep seeing people insist that query-intercepting middleware will be > defeated with DNSSEC, but I can't see why. Perhaps I'm missing something. > It doesn't (in this scenario), but only because it actually does, and Joe cannot resolve anything. Then he will probably turn it off. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIiP7S4nZCKsdOncURArXIAKC5Q14tEiQkLIdvwKTbRseiIERrtgCgs6Pp qYsygSLxB8xXtG82dptkwLg= =zk6V -----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: From dnsiwahara@bz01.plala.or.jp Thu Jul 24 19:09:22 2008 Return-Path: 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 29CCB3A63D3 for ; Thu, 24 Jul 2008 19:09:22 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -16.913 X-Spam-Level: X-Spam-Status: No, score=-16.913 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DRUGS_ERECTILE=1, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_PHARMACY=1, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 LKteDo4Va5LH for ; Thu, 24 Jul 2008 19:09:15 -0700 (PDT) Received: from pc-230-90-214-201.cm.vtr.net (pc-230-90-214-201.cm.vtr.net [201.214.90.230]) by core3.amsl.com (Postfix) with SMTP id 12A623A68C1 for ; Thu, 24 Jul 2008 19:09:14 -0700 (PDT) Message-Id: <20080724030846.16293.qmail@pc-230-90-214-201.cm.vtr.net> To: Subject: Dear dnsext-archive@ietf.org Sweet summer 2008: Only for You dnsext-archive@ietf.org From: VIAGRA ® Official Site MIME-Version: 1.0 Content-Type: text/html Date: Thu, 24 Jul 2008 19:09:14 -0700 (PDT)
If you are having trouble viewing this email, please click here.

Privacy Policy Update Your Profile Unsubscribe

® 2008 Procter & Gamble
Viagra™ is a registered trademark of Pharmacy Company. Portions copyright Iconoculture, Inc.

P&G Privacy Team,

campaignid: trem5931


Message-Id: <20080722174644.5C00.342431-33118@web.vocalpoint.com>
From owner-namedroppers@ops.ietf.org Fri Jul 25 10:13:02 2008 Return-Path: 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 A8BCF3A699D; Fri, 25 Jul 2008 10:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 fNtKT8C-T2D9; Fri, 25 Jul 2008 10:13:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 828B43A6A65; Fri, 25 Jul 2008 10:13:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMQhG-000Gbc-Pw for namedroppers-data@psg.com; Fri, 25 Jul 2008 17:03:14 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMQhC-000Gaz-OB for namedroppers@ops.ietf.org; Fri, 25 Jul 2008 17:03:12 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=ca.afilias.info; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=Lc2vuZDmIEQKJct93mjOqC+7mPp+dVi3leFAfFLIk13c1UXK8gI7ry8nnIsCryfulPOYfBZYrVtxQ10i13OLPz5q2KeyxwnQkt4qc66I0IrbRqhQpZJur/KMyP4UIhP7; Received: from [199.212.90.13] (helo=calamari.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMQh8-0007em-7E; Fri, 25 Jul 2008 17:03:06 +0000 Cc: DNSEXT WG Message-Id: From: Joe Abley To: Jelte Jansen In-Reply-To: <4888FED2.6060204@NLnetLabs.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Fri, 25 Jul 2008 13:03:05 -0400 References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> <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> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 24 Jul 2008, at 18:14, Jelte Jansen wrote: > how would you verify anything without a trust anchor? Surely that's a mechanical detail. > I don't think anyone here implies that DNSSEC works when you do not > actually turn it on on the resolver you are using. The implication I was replying to seemed to state fairly clearly that DNSSEC would make it impossible for middleboxes to meddle with DNS queries and replies and provide answers that were not those that would be received from the authority-only servers concerned. I think that's wrong. I think that once someone is in the position of being able to meddle with the query/response stream, all bets are off and DNSSEC is no cure. What is required to circumvent such sabotage is not the ability to verify the integrity of the data in-band, but either the ability to signal that signatures should be present out-of-band, or a means of verifying transport integrity to a resolver which is trusted, or something. DNSSEC on its own isn't enough. Joe -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 25 11:08:50 2008 Return-Path: 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 9E6FE3A698F; Fri, 25 Jul 2008 11:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 K0crN5JN5sTL; Fri, 25 Jul 2008 11:08:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7D37E3A695F; Fri, 25 Jul 2008 11:08:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMRXV-000Mpv-SW for namedroppers-data@psg.com; Fri, 25 Jul 2008 17:57:13 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMRXO-000Mp6-O7 for namedroppers@ops.ietf.org; Fri, 25 Jul 2008 17:57:11 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=ca.afilias.info; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=CT5Oj+CcN78VZjJoVaeGJRx6PvFTIR2bp07rFo094lzkAKjhdMVuCw2lwFskppCZU833Rh4BAlGiIy44G1Ii2cctiC+I1fcrQbuopKpNYwr3iy1OqEXCNsSP13b7gNEU; Received: from [199.212.90.13] (helo=calamari.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMRXN-000895-9q; Fri, 25 Jul 2008 17:57:05 +0000 Cc: Jelte Jansen , DNSEXT WG Message-Id: <52A6E331-4970-4F59-BC82-FBFC1575E005@ca.afilias.info> From: Joe Abley To: Brian Dickson In-Reply-To: <488A0F4F.9050704@ca.afilias.info> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Fri, 25 Jul 2008 13:57:05 -0400 References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> <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> <488A0F4F.9050704@ca.afilias.info> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 25 Jul 2008, at 13:37, Brian Dickson wrote: > This would enable in-band resolvers to validate both the data, and > the presence or absence of zone signatures, on delegation chains, > and prevent downgrade attacks even by man-in-the-middle interference. If the transport can't be trusted then the presence or absence of such markers surely can't be trusted either. Hence "out-of-band" in my previous note. But I have not done very much thinking about this. I am mainly suggesting things as a way of learning. :-) Joe -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 25 11:44:47 2008 Return-Path: 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 91E0328C17B; Fri, 25 Jul 2008 11:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 rLPNgA5jTMo9; Fri, 25 Jul 2008 11:44:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A989528C172; Fri, 25 Jul 2008 11:44:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMSAk-000212-Gd for namedroppers-data@psg.com; Fri, 25 Jul 2008 18:37:46 +0000 Received: from [69.46.124.26] (helo=outbound.afilias.info) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMSAg-00020R-PS for namedroppers@ops.ietf.org; Fri, 25 Jul 2008 18:37:44 +0000 Received: from bmp-336-ms505.wa.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1KMREO-0008RW-4B; Fri, 25 Jul 2008 17:37:28 +0000 Message-ID: <488A0F4F.9050704@ca.afilias.info> Date: Fri, 25 Jul 2008 13:37:19 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Joe Abley CC: Jelte Jansen , DNSEXT WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> <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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: True Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Joe Abley wrote: > > On 24 Jul 2008, at 18:14, Jelte Jansen wrote: > >> how would you verify anything without a trust anchor? > > Surely that's a mechanical detail. > >> I don't think anyone here implies that DNSSEC works when you do not >> actually turn it on on the resolver you are using. > > The implication I was replying to seemed to state fairly clearly that > DNSSEC would make it impossible for middleboxes to meddle with DNS > queries and replies and provide answers that were not those that would > be received from the authority-only servers concerned. > > I think that's wrong. I think that once someone is in the position of > being able to meddle with the query/response stream, all bets are off > and DNSSEC is no cure. > > What is required to circumvent such sabotage is not the ability to > verify the integrity of the data in-band, but either the ability to > signal that signatures should be present out-of-band, or a means of > verifying transport integrity to a resolver which is trusted, or > something. DNSSEC on its own isn't enough. Would this be something analogous to the NSEC3 thing which gives the ability to "authenticate" NXDOMAIN responses by giving information about adjacent actual domains, modulo hashing to prevent zone enumeration? I.e. something which would return authoritative "no DS record present" in a similar sense, with extra information to allow the receiver to trust the response (about no DS being present, that is)? This would enable in-band resolvers to validate both the data, and the presence or absence of zone signatures, on delegation chains, and prevent downgrade attacks even by man-in-the-middle interference. Well, not so much prevent, as much as make it obvious that it is happening, and to allow the resolver to reject suspect data when the signature has been stripped... Brian -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 25 12:32:05 2008 Return-Path: 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 C31DE3A68AC; Fri, 25 Jul 2008 12:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 Do-ncPxGOFW7; Fri, 25 Jul 2008 12:32:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CEDB63A67AD; Fri, 25 Jul 2008 12:32:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMStl-0008eM-Lt for namedroppers-data@psg.com; Fri, 25 Jul 2008 19:24:17 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMSti-0008de-18 for namedroppers@ops.ietf.org; Fri, 25 Jul 2008 19:24:15 +0000 Received: from [10.0.1.199] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id AD10529FA3F; Fri, 25 Jul 2008 12:24:11 -0700 (PDT) Cc: DNSEXT WG Message-Id: <2B837EA4-9D88-4F65-A3D4-8B06B1391E41@virtualized.org> From: David Conrad To: Joe Abley In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Fri, 25 Jul 2008 12:24:09 -0700 References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> <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> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Joe, On Jul 25, 2008, at 10:03 AM, Joe Abley wrote: > I think that's wrong. I think that once someone is in the position > of being able to meddle with the query/response stream, all bets are > off and DNSSEC is no cure. The whole point of DNSSEC is to allow for the validation of responses by a validator to ensure they haven't been mucked with in transit. The most that an attacker, anywhere in a properly configured DNSSEC- protected query/response path, can do is denial of service. Once the response leaves the validator on its way to the application, either via the response to an unprotected stub resolver call over the network or via a intra-machine IPC, it can, of course be mucked with. This is why I believe that if people want to be safe, they need to run a validating caching server on their local machine (if the intra- machine IPC can be compromised, you've got bigger problems). But maybe I'm lacking context here... Regards, -drc -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 25 12:38:19 2008 Return-Path: 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 503B53A69A1; Fri, 25 Jul 2008 12:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 U1oV1mi7AV9C; Fri, 25 Jul 2008 12:38:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1C8EE3A68FE; Fri, 25 Jul 2008 12:38:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMT0A-0009hx-Qr for namedroppers-data@psg.com; Fri, 25 Jul 2008 19:30:54 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMT05-0009hB-U5 for namedroppers@ops.ietf.org; Fri, 25 Jul 2008 19:30:52 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KMT03-0007YT-BF for namedroppers@ops.ietf.org; Fri, 25 Jul 2008 21:30:47 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id CFCA44B44B; Fri, 25 Jul 2008 21:31:01 +0200 (CEST) Date: Fri, 25 Jul 2008 21:31:01 +0200 From: bert hubert To: Joe Abley Cc: Jelte Jansen , DNSEXT WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Message-ID: <20080725193101.GB8193@outpost.ds9a.nl> References: <20080723183227.GA11957@outpost.ds9a.nl> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jul 25, 2008 at 01:03:05PM -0400, Joe Abley wrote: > I think that's wrong. I think that once someone is in the position of > being able to meddle with the query/response stream, all bets are off > and DNSSEC is no cure. Wow - sure? I may be no friend of DNSSEC but I always assumed DNSSEC would be 'perfect' in this way. If this is true, it only strenghtens the case that the hassle of DNSSEC exceeds its merits by at least an order of magnitude. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 25 12:41:25 2008 Return-Path: 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 321033A685F; Fri, 25 Jul 2008 12:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.891 X-Spam-Level: X-Spam-Status: No, score=-0.891 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] 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 cLUVDo3Ym1Ic; Fri, 25 Jul 2008 12:41:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 16E423A67AD; Fri, 25 Jul 2008 12:41:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMT5Y-000AYc-Bt for namedroppers-data@psg.com; Fri, 25 Jul 2008 19:36:28 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMT5T-000AXe-37 for namedroppers@ops.ietf.org; Fri, 25 Jul 2008 19:36:26 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=ca.afilias.info; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=h9KZ/yaycOta8s/gB++QylnFr0Ha0hJEwmW13bxUnmt0r//Q4IN3EtgCD0NfNmvnsD1bq5KpW6/Bk0sO8b8NSzQZOBK7zhSrA2darvLF01KyTvcPPsz8PBlh3ljwVimD; Received: from [199.212.90.13] (helo=calamari.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMT5L-0009BF-Fv; Fri, 25 Jul 2008 19:36:19 +0000 Cc: Jelte Jansen , DNSEXT WG Message-Id: From: Joe Abley To: bert hubert In-Reply-To: <20080725193101.GB8193@outpost.ds9a.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Fri, 25 Jul 2008 15:36:15 -0400 References: <20080723183227.GA11957@outpost.ds9a.nl> <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> <20080725193101.GB8193@outpost.ds9a.nl> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 25 Jul 2008, at 15:31, bert hubert wrote: > On Fri, Jul 25, 2008 at 01:03:05PM -0400, Joe Abley wrote: >> I think that's wrong. I think that once someone is in the position of >> being able to meddle with the query/response stream, all bets are off >> and DNSSEC is no cure. > > Wow - sure? I may be no friend of DNSSEC but I always assumed DNSSEC > would > be 'perfect' in this way. > > If this is true, it only strenghtens the case that the hassle of > DNSSEC > exceeds its merits by at least an order of magnitude. I am feeling very ignorant right now, so let nobody take what follows as the voice of authority. Imagine a world in the future in which the root zone is signed, and some TLD zones are signed, and some other zones are signed. 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. If such a validator asks a question of a root server, or a TLD server, or some other server, and gets back an insecure referral, it seems to me the validator has no real way of knowing whether the insecure answers are from middleboxes, or direct from real infrastructure that happens not to have deployed DNSSEC. Hand-configuring your validator to tell it "ORG is signed, root is signed, don't believe anybody who tells you otherwise" would presumably fix that. But replicating such dynamic information by way of static configuration in millions of independently-managed resolvers doesn't seem very scaleable. Perhaps it's sufficient just to tell your validator "the root is signed, don't believe answers which suggest otherwise". But that requires a signed root, and in the mean time DNSSEC isn't providing any protection from middleboxes. Joe -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 25 15:22:46 2008 Return-Path: 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 4C9F23A6862; Fri, 25 Jul 2008 15:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 8EBEKU6+tOxY; Fri, 25 Jul 2008 15:22:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3CBA43A67E1; Fri, 25 Jul 2008 15:22:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMVZP-00082d-SY for namedroppers-data@psg.com; Fri, 25 Jul 2008 22:15:27 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMVZI-00081h-BM for namedroppers@ops.ietf.org; Fri, 25 Jul 2008 22:15:26 +0000 Received: from commandprompt.com (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m6PMCW5h030393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 25 Jul 2008 15:12:39 -0700 Date: Fri, 25 Jul 2008 18:10:02 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Message-ID: <20080725221002.GK29775@commandprompt.com> 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> <20080725193101.GB8193@outpost.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Fri, 25 Jul 2008 15:12:39 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [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?) A -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 25 16:14:35 2008 Return-Path: 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 ) 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 ) 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 User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Andrew Sullivan 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> <20080725193101.GB8193@outpost.ds9a.nl> <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: -----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: From owner-namedroppers@ops.ietf.org Fri Jul 25 16:18:43 2008 Return-Path: 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 E1A4A3A694F; Fri, 25 Jul 2008 16:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 qM-sCaJWzVCi; Fri, 25 Jul 2008 16:18:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2EEA13A6949; Fri, 25 Jul 2008 16:18:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMWUQ-000FHY-Vu for namedroppers-data@psg.com; Fri, 25 Jul 2008 23:14:22 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMWUN-000FH3-4w for namedroppers@ops.ietf.org; Fri, 25 Jul 2008 23:14:21 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=lo+Ibx0HHfpW5ePqTgdm0XvVf0OITy/Lr5e/INLWAJS9IzhF4yq4XFbd LkndFh+v3ABRfUjOjeq011jLQXlvDoMEfv/pLalshpMngNSY4bmYIfAZr oLNcUiAAleEs5cf; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1217027659; x=1248563659; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Roy=20Arends"=20|Subject: =20Re:=20How=20do=20we=20get=20the=20whole=20world=20to =20upgrade=20to=20DNSSEC=20capable=09resolvers?|Date:=20S at,=2026=20Jul=202008=2001:14:08=20+0200|Message-ID:=20|To:=20namedroppers@ops.ietf.org |MIME-Version:=201.0|In-Reply-To:=20<20080725221002.GK297 75@commandprompt.com>|References:=20<2FFE6519-7E9C-4DE8-A F69-697A4D875011@nominum.com>=20<20080723191636.GB32507@o utpost.ds9a.nl>=20<8A91CF57-0CBD-4CF2-BF59-C7D59CB4B7B9@v irtualized.org>=20<20080724060743.GA7420@outpost.ds9a.nl> =20<48886C4D.4020500@ca.afilias.info>=20<63C0FFE7-17E6-4E CE-9A12-0537FE2E3F4B@ca.afilias.info>=20<4888FED2.6060204 @NLnetLabs.nl>=20=20<20080725193101.GB8193@outpost.ds9a.nl> =20 =20<20080725221002.GK29775@commandprompt.com>; bh=+ZyDZMJy/Mvill9ILwZxzgWTBBZN6zncYwFzufWAmNU=; b=3BsY3q2mYpnZFIwXJJCZyFBjRRzcpsSIV5RVb3SDbAuIG/KzipPY9EUz frQYrT2T03r5HDolTPHtpCGIAIc0SYwwb/PUPRyGUVrvJUCzYxOPOAq/p YablmYZrwWYrVPF; X-IronPort-AV: E=Sophos;i="4.31,254,1215385200"; d="scan'208";a="5437887" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 26 Jul 2008 00:14:10 +0100 In-Reply-To: <20080725221002.GK29775@commandprompt.com> 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> <20080725193101.GB8193@outpost.ds9a.nl> <20080725221002.GK29775@commandprompt.com> To: namedroppers@ops.ietf.org Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: "Roy Arends" Date: Sat, 26 Jul 2008 01:14:08 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 26/07/2008 12:14:10 AM, Serialize complete at 26/07/2008 12:14:10 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: When a validator has a trust anchor configured for root, it _expects_ signatures for root. No signatures -> no validation -> data marked bogus -> client/stub gets servfail (*). When a validator has a trust anchor configured for root, it expects signatures for root and _everything_ below until it hits a proof of absence of DS. This proof is given by NSEC/NSEC3 records and its signatures. If something mucks in the middle, is either removing a sig or does fondles the data even one single teeny bit, -> failed validation -> data marked bogus -> client/stub gets a servfail (*). DNSSEC is perfect that way, in Berts terms. Roy Arends Nominet UK (*) The client/stub has the option to query the validating resolver with the CD bit set, in which case the resolver may return bad/bogus data. -- 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: From owner-namedroppers@ops.ietf.org Fri Jul 25 16:56:59 2008 Return-Path: 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 2DA723A68D6; Fri, 25 Jul 2008 16:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 hAxX8t4q6J8y; Fri, 25 Jul 2008 16:56:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3DD483A67D4; Fri, 25 Jul 2008 16:56:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMX26-000JQv-Es for namedroppers-data@psg.com; Fri, 25 Jul 2008 23:49:10 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMX22-000JQP-5C for namedroppers@ops.ietf.org; Fri, 25 Jul 2008 23:49:08 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=ca.afilias.info; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=f+M0AL4k6+jHcnZQ+2uTnhHEFu7bi4LB5I+JucX8J8csRs2Es5KAprNemXRZp42txIzGJ7K6UFsVUihsE1nJC9WzTnPC+F2OBGR8FNYuHpHqE/CpeFwrdtTgaF+AYvhT; Received: from [209.226.201.250] (helo=[10.205.40.104]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMX0Y-000BP4-Fp; Fri, 25 Jul 2008 23:47:34 +0000 Cc: Andrew Sullivan , namedroppers@ops.ietf.org Message-Id: <872FAAA4-94ED-4CE8-BA8D-7792BEE2D867@ca.afilias.info> From: Joe Abley To: Jelte Jansen In-Reply-To: <488A5CC8.7010009@NLnetLabs.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Fri, 25 Jul 2008 19:47:39 -0400 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> <20080725193101.GB8193@outpost.ds9a.nl> <20080725221002.GK29775@commandprompt.com> <488A5CC8.7010009@NLnetLabs.nl> X-Mailer: Apple Mail (2.926) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 25 Jul 2008, at 19:07, Jelte Jansen wrote: > 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. Got it. Joe -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 26 04:32:28 2008 Return-Path: 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 7A4AB28C102; Sat, 26 Jul 2008 04:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 BK5UKBvfsZtV; Sat, 26 Jul 2008 04:32:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8B35528C0E7; Sat, 26 Jul 2008 04:32:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMhso-000409-QE for namedroppers-data@psg.com; Sat, 26 Jul 2008 11:24:18 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMhsj-0003ua-PK for namedroppers@ops.ietf.org; Sat, 26 Jul 2008 11:24:16 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m6QBMRup027033; Sat, 26 Jul 2008 11:22:27 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m6QBMQPt027032; Sat, 26 Jul 2008 11:22:26 GMT Date: Sat, 26 Jul 2008 11:22:26 +0000 From: bmanning@vacation.karoshi.com To: David Conrad Cc: Joe Abley , DNSEXT WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Message-ID: <20080726112226.GA26985@vacation.karoshi.com.> References: <20080723183227.GA11957@outpost.ds9a.nl> <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> <2B837EA4-9D88-4F65-A3D4-8B06B1391E41@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B837EA4-9D88-4F65-A3D4-8B06B1391E41@virtualized.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jul 25, 2008 at 12:24:09PM -0700, David Conrad wrote: > Joe, > > On Jul 25, 2008, at 10:03 AM, Joe Abley wrote: > >I think that's wrong. I think that once someone is in the position > >of being able to meddle with the query/response stream, all bets are > >off and DNSSEC is no cure. > > The whole point of DNSSEC is to allow for the validation of responses > by a validator to ensure they haven't been mucked with in transit. > The most that an attacker, anywhere in a properly configured DNSSEC- > protected query/response path, can do is denial of service. so, it does not matter where the data comes from, as long as the "wrapper" is intact. > Once the response leaves the validator on its way to the application, > either via the response to an unprotected stub resolver call over the > network or via a intra-machine IPC, it can, of course be mucked with. > This is why I believe that if people want to be safe, they need to run > a validating caching server on their local machine (if the intra- > machine IPC can be compromised, you've got bigger problems). you are not alone in this belief. > But maybe I'm lacking context here... this is no doubt true for many of us. > Regards, > -drc --bill -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 26 04:39:52 2008 Return-Path: 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 B2D0628C157; Sat, 26 Jul 2008 04:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.142 X-Spam-Level: X-Spam-Status: No, score=-102.142 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, SARE_MILLIONSOF=0.315, 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 DiXzP2CHINaS; Sat, 26 Jul 2008 04:39:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B765C28C142; Sat, 26 Jul 2008 04:39:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMi2k-0004yf-OC for namedroppers-data@psg.com; Sat, 26 Jul 2008 11:34:34 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMi2f-0004sp-Uq for namedroppers@ops.ietf.org; Sat, 26 Jul 2008 11:34:32 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m6QBTeup027076; Sat, 26 Jul 2008 11:29:40 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m6QBTUm0027075; Sat, 26 Jul 2008 11:29:30 GMT Date: Sat, 26 Jul 2008 11:29:30 +0000 From: bmanning@vacation.karoshi.com To: Joe Abley Cc: bert hubert , Jelte Jansen , DNSEXT WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Message-ID: <20080726112930.GB26985@vacation.karoshi.com.> 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> <20080725193101.GB8193@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > 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. such a construct -might- be built, but of little or no use. this is analogous to a "bare" resolver with no cache or special configuration ... knowing nothing about where to send queries. without "belt/suspenders", the resolver is kind of useless. > Hand-configuring your validator to tell it "ORG is signed, root is > signed, don't believe anybody who tells you otherwise" would > presumably fix that. But replicating such dynamic information by way > of static configuration in millions of independently-managed resolvers > doesn't seem very scaleable. > > Perhaps it's sufficient just to tell your validator "the root is > signed, don't believe answers which suggest otherwise". But that > requires a signed root, and in the mean time DNSSEC isn't providing > any protection from middleboxes. again, this is almost exactly the problem of maintaining the root.cache file. some folks maintain their copies by hand, some download from random sites (l.o.f). the trick here is key maintainance/distribution. its not a protocol issue. > > Joe --bill -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 26 07:57:41 2008 Return-Path: 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 7C9A63A69FE; Sat, 26 Jul 2008 07:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.286 X-Spam-Level: X-Spam-Status: No, score=-1.286 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 VqJt4I-tNenu; Sat, 26 Jul 2008 07:57:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B17E83A6969; Sat, 26 Jul 2008 07:57:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMl70-000OQd-Iq for namedroppers-data@psg.com; Sat, 26 Jul 2008 14:51:10 +0000 Received: from [217.70.190.232] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMl6v-000OPr-Nd for namedroppers@ops.ietf.org; Sat, 26 Jul 2008 14:51:07 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 12F5C948FC; Sat, 26 Jul 2008 16:44:02 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id 7CC13157ABC; Sat, 26 Jul 2008 16:41:11 +0200 (CEST) Date: Sat, 26 Jul 2008 15:41:11 +0100 From: Stephane Bortzmeyer To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Message-ID: <20080726144111.GA5204@laperouse.bortzmeyer.org> References: <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> <20080725193101.GB8193@outpost.ds9a.nl> <20080725221002.GK29775@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 8.04 (hardy) User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sat, Jul 26, 2008 at 01:14:08AM +0200, Roy Arends wrote a message of 28 lines which said: > When a validator has a trust anchor configured for root, it _expects_ > signatures for root. Which means there is no way back? If we sign ".fr", and people start to configure the trust anchor for ".fr" in their validating resolvers, we can no longer revert to the original, non-signed, system, should problems occur? Am I correct? AFAIK, DNSSEC has no way to express policies (in a RFC5016-like way) such as "should be signed". -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 26 09:44:32 2008 Return-Path: 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 4A2D43A69FE; Sat, 26 Jul 2008 09:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 2uFNCDNoOJ7z; Sat, 26 Jul 2008 09:44:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4793B28C0E2; Sat, 26 Jul 2008 09:44:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMmmA-000AS0-UA for namedroppers-data@psg.com; Sat, 26 Jul 2008 16:37:46 +0000 Received: from [69.46.124.26] (helo=outbound.afilias.info) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMmm6-000APz-OM for namedroppers@ops.ietf.org; Sat, 26 Jul 2008 16:37:44 +0000 Received: from bmp-336-ms505.wa.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1KMmWx-0000Ho-3d; Sat, 26 Jul 2008 16:22:03 +0000 Message-ID: <488B4F1B.2020104@ca.afilias.info> Date: Sat, 26 Jul 2008 12:21:47 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Stephane Bortzmeyer CC: Roy Arends , namedroppers@ops.ietf.org Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? References: <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> <20080725193101.GB8193@outpost.ds9a.nl> <20080725221002.GK29775@commandprompt.com> <20080726144111.GA5204@laperouse.bortzmeyer.org> In-Reply-To: <20080726144111.GA5204@laperouse.bortzmeyer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: True Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Stephane Bortzmeyer wrote: > On Sat, Jul 26, 2008 at 01:14:08AM +0200, > Roy Arends wrote > a message of 28 lines which said: > > >> When a validator has a trust anchor configured for root, it _expects_ >> signatures for root. >> > > Which means there is no way back? If we sign ".fr", and people start > to configure the trust anchor for ".fr" in their validating resolvers, > we can no longer revert to the original, non-signed, system, should > problems occur? > > Am I correct? AFAIK, DNSSEC has no way to express policies (in a > RFC5016-like way) such as "should be signed". > You are correct. However, if the root was signed, there would be no need for having separate trust anchors configured for a signed .fr. And, this would mean that turning on or off the status of "is .fr signed?" could be handed from the root zone, allowing *relative* ease in backing out the signing of any TLD. No configuration changes would be needed by the operators of validating resolvers. (IMHO, in addition to signing the root zone, there need to be changes to the speed with which changes of a technical nature can be made, once the technical administration of a TLD has been authoritatively and contractually delegated to an entity. Those include changes to A and AAAA glue records, and addition/removal of DNSSEC signatures (and thus the "signed"/"not-signed" status).) Brian -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 26 10:07:59 2008 Return-Path: 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 A26543A68CE; Sat, 26 Jul 2008 10:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.37 X-Spam-Level: X-Spam-Status: No, score=-102.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, 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 TYZfzzMYfS+M; Sat, 26 Jul 2008 10:07:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A3CDF3A67AB; Sat, 26 Jul 2008 10:07:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMn9d-000D81-B5 for namedroppers-data@psg.com; Sat, 26 Jul 2008 17:02:01 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMn9O-000Cvw-Tl for namedroppers@ops.ietf.org; Sat, 26 Jul 2008 17:01:49 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m6QGxfup029204; Sat, 26 Jul 2008 16:59:41 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m6QGxdsW029201; Sat, 26 Jul 2008 16:59:39 GMT Date: Sat, 26 Jul 2008 16:59:34 +0000 From: bmanning@vacation.karoshi.com To: Brian Dickson Cc: Stephane Bortzmeyer , Roy Arends , namedroppers@ops.ietf.org Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Message-ID: <20080726165934.GA29158@vacation.karoshi.com.> References: <48886C4D.4020500@ca.afilias.info> <63C0FFE7-17E6-4ECE-9A12-0537FE2E3F4B@ca.afilias.info> <4888FED2.6060204@NLnetLabs.nl> <20080725193101.GB8193@outpost.ds9a.nl> <20080725221002.GK29775@commandprompt.com> <20080726144111.GA5204@laperouse.bortzmeyer.org> <488B4F1B.2020104@ca.afilias.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <488B4F1B.2020104@ca.afilias.info> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sat, Jul 26, 2008 at 12:21:47PM -0400, Brian Dickson wrote: > Stephane Bortzmeyer wrote: > >On Sat, Jul 26, 2008 at 01:14:08AM +0200, > > Roy Arends wrote > > a message of 28 lines which said: > > > > > >>When a validator has a trust anchor configured for root, it _expects_ > >>signatures for root. > >> > > > >Which means there is no way back? If we sign ".fr", and people start > >to configure the trust anchor for ".fr" in their validating resolvers, > >we can no longer revert to the original, non-signed, system, should > >problems occur? > > > >Am I correct? AFAIK, DNSSEC has no way to express policies (in a > >RFC5016-like way) such as "should be signed". > > > > You are correct. > > However, if the root was signed, there would be no need for having > separate trust anchors configured > for a signed .fr. presuming facts not in evidence. how are you to -know- that the root has the "right" DS for .FR? most operational keystores will have at least four keys and likely operational practice will be, roughly 3 per relevant org; the current, the immediate past, and the next future key. as a grad student, I will likely have keys from (at least) these places: my school, the parent org (.EDU), the root, the LIR, the RIR. that looks like 15 keys... :) > And, this would mean that turning on or off the status of "is .fr > signed?" could be handed from the root > zone, allowing *relative* ease in backing out the signing of any TLD. No > configuration changes would > be needed by the operators of validating resolvers. > > (IMHO, in addition to signing the root zone, there need to be changes to > the speed with which changes > of a technical nature can be made, once the technical administration of > a TLD has been authoritatively > and contractually delegated to an entity. Those include changes to A and > AAAA glue records, and > addition/removal of DNSSEC signatures (and thus the > "signed"/"not-signed" status).) > > Brian > > -- > 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: -- 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: From owner-namedroppers@ops.ietf.org Sat Jul 26 14:31:45 2008 Return-Path: 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 979CD3A69A2; Sat, 26 Jul 2008 14:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 f0mJpd5VgjiR; Sat, 26 Jul 2008 14:31:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 75FED3A68A1; Sat, 26 Jul 2008 14:31:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMrEG-000H1d-29 for namedroppers-data@psg.com; Sat, 26 Jul 2008 21:23:04 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KMrEC-000H0x-1j for namedroppers@ops.ietf.org; Sat, 26 Jul 2008 21:23:02 +0000 Received: from [172.16.10.232] (guestroom-nat.meeting.ietf.org [130.129.64.64]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m6QLMs9u086933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Jul 2008 23:22:55 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <488B95AC.8030509@nlnetlabs.nl> Date: Sat, 26 Jul 2008 23:22:52 +0200 From: Matthijs Mekking User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: Stephane Bortzmeyer CC: namedroppers@ops.ietf.org Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? References: <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> <20080725193101.GB8193@outpost.ds9a.nl> <20080725221002.GK29775@commandprompt.com> <20080726144111.GA5204@laperouse.bortzmeyer.org> In-Reply-To: <20080726144111.GA5204@laperouse.bortzmeyer.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [213.154.224.1]); Sat, 26 Jul 2008 23:22:55 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephane Bortzmeyer wrote: > On Sat, Jul 26, 2008 at 01:14:08AM +0200, > Roy Arends wrote > a message of 28 lines which said: > >> When a validator has a trust anchor configured for root, it _expects_ >> signatures for root. > > Which means there is no way back? If we sign ".fr", and people start > to configure the trust anchor for ".fr" in their validating resolvers, > we can no longer revert to the original, non-signed, system, should > problems occur? If you use a mechanism like described in rfc5011, there is a way back. Section 5 says: "A trust point that has all of its trust anchors revoked is considered deleted and is treated as if the trust point was never configured." So you have to revoke your KSKs and give resolvers some time to update their trust anchors. - - Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIi5WsIXqNzxRs6egRAmidAJ42jQ5mnJIqztMYAsAE3hZcyiRYagCfR4W9 nK7o/eebFI1iySR+iNqAlUY= =mjym -----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: From owner-namedroppers@ops.ietf.org Sun Jul 27 17:08:35 2008 Return-Path: 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 74FC23A69C8; Sun, 27 Jul 2008 17:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.75 X-Spam-Level: X-Spam-Status: No, score=-4.75 tagged_above=-999 required=5 tests=[AWL=-1.499, 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] 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 wAvZIniAJAeW; Sun, 27 Jul 2008 17:08:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8BE193A685A; Sun, 27 Jul 2008 17:08:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNG9V-000L3c-Oa for namedroppers-data@psg.com; Sun, 27 Jul 2008 23:59:49 +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 ) id 1KNG9P-000L2q-Ci for namedroppers@ops.ietf.org; Sun, 27 Jul 2008 23:59:48 +0000 Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1KNFjm-0003rd-U6; Mon, 28 Jul 2008 01:33:14 +0200 Received: from localhost by x27.adm.denic.de with local id 1KNFib-0007OG-BU; Mon, 28 Jul 2008 01:32:01 +0200 Date: Mon, 28 Jul 2008 01:32:01 +0200 From: Peter Koch To: IETF DNSEXT WG Subject: Re: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 Message-ID: <20080727233201.GA28260@x27.adm.denic.de> References: <48935.1216753200@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48935.1216753200@nsa.vix.com> User-Agent: Mutt/1.4.2.3i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jul 22, 2008 at 07:00:00PM +0000, Paul Vixie wrote: > please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 as a > working group document. note that this technique was told to me by david I have read draft-vixie-dnsext-dns0x20-00.txt. I like the idea as a clever engineering exercise (or "hack"), but I do not support this going on standards track or BCP, because I fear the operational side effects. Also, I think the WG should not rush through proposals in the light of the so-called "Kaminsky attack", but should instead - after disclosure allows - inspect and analyse the attack vectors to address the vulnerabilities in particular. However, the proposal appears to fit into the charter and dnsext is the right venue to discuss it. Therefore I "support" the adoption. I'd also be willing to review future revisions of the draft. -Peter -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 27 18:59:05 2008 Return-Path: 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 2864B3A692E; Sun, 27 Jul 2008 18:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 ujMdk-0tFQ5a; Sun, 27 Jul 2008 18:59:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3F0613A685A; Sun, 27 Jul 2008 18:59:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNHv5-00063f-TQ for namedroppers-data@psg.com; Mon, 28 Jul 2008 01:53:03 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNHv2-000638-II for namedroppers@ops.ietf.org; Mon, 28 Jul 2008 01:53:01 +0000 Received: from [10.0.1.2] (guestroom-nat.meeting.ietf.org [130.129.64.64]) by virtualized.org (Postfix) with ESMTP id 224C42A3B26; Sun, 27 Jul 2008 18:52:58 -0700 (PDT) Cc: DNSEXT WG Message-Id: From: David Conrad To: bmanning@vacation.karoshi.com In-Reply-To: <20080726165934.GA29158@vacation.karoshi.com.> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Mon, 28 Jul 2008 02:52:53 +0100 References: <48886C4D.4020500@ca.afilias.info> <63C0FFE7-17E6-4ECE-9A12-0537FE2E3F4B@ca.afilias.info> <4888FED2.6060204@NLnetLabs.nl> <20080725193101.GB8193@outpost.ds9a.nl> <20080725221002.GK29775@commandprompt.com> <20080726144111.GA5204@laperouse.bortzmeyer.org> <488B4F1B.2020104@ca.afilias.info> <20080726165934.GA29158@vacation.karoshi.com.> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 26, 2008, at 5:59 PM, bmanning@vacation.karoshi.com wrote: > how are you to -know- that the root has the "right" DS for .FR? Because if the root didn't, then it would imply the NSes or glue could also be wrong. Same process will be used to vet requests to alter all of these. Regards, -drc -- 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: From owner-namedroppers@ops.ietf.org Sun Jul 27 20:39:22 2008 Return-Path: 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 12D853A6813; Sun, 27 Jul 2008 20:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, 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 t6T1D6z3qrtA; Sun, 27 Jul 2008 20:39:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 34D153A67AF; Sun, 27 Jul 2008 20:39:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNJTO-000Egx-ML for namedroppers-data@psg.com; Mon, 28 Jul 2008 03:32:34 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNJTK-000Ea1-BC for namedroppers@ops.ietf.org; Mon, 28 Jul 2008 03:32:33 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m6S3V7up016551; Mon, 28 Jul 2008 03:31:07 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m6S3V7RH016550; Mon, 28 Jul 2008 03:31:07 GMT Date: Mon, 28 Jul 2008 03:31:07 +0000 From: bmanning@vacation.karoshi.com To: David Conrad Cc: bmanning@vacation.karoshi.com, DNSEXT WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Message-ID: <20080728033107.GA16527@vacation.karoshi.com.> References: <4888FED2.6060204@NLnetLabs.nl> <20080725193101.GB8193@outpost.ds9a.nl> <20080725221002.GK29775@commandprompt.com> <20080726144111.GA5204@laperouse.bortzmeyer.org> <488B4F1B.2020104@ca.afilias.info> <20080726165934.GA29158@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jul 28, 2008 at 02:52:53AM +0100, David Conrad wrote: > On Jul 26, 2008, at 5:59 PM, bmanning@vacation.karoshi.com wrote: > > how are you to -know- that the root has the "right" DS for .FR? > > Because if the root didn't, then it would imply the NSes or glue could > also be wrong. Same process will be used to vet requests to alter all > of these. > > Regards, > -drc sure. the point that i tried to make was/is, that DS verification is critical ... regardless of where in the heirarchy one finds oneself. end of the day, it depends on the validators configured TAs. --bill -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 28 09:03:15 2008 Return-Path: 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 E185928C1E5; Mon, 28 Jul 2008 09:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[AWL=-1.202, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] 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 Afqnnxn1TSm0; Mon, 28 Jul 2008 09:03:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E5E2B28C1F4; Mon, 28 Jul 2008 09:03:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNV3z-000MJI-8P for namedroppers-data@psg.com; Mon, 28 Jul 2008 15:55:07 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNV3v-000MIB-86 for namedroppers@ops.ietf.org; Mon, 28 Jul 2008 15:55:05 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6SFsxAO021711 for ; Mon, 28 Jul 2008 11:55:00 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200807281555.m6SFsxAO021711@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Jul 2008 11:53:32 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: Forgery Resistance phase #2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This message is sent in my role as chair with consent of my co-chair but without his editing help, thus any mistakes in this message are mine and only mine. The large volume of message over the last 2 weeks related to how to make DNS safer made me think about "what are all the different possible approaches?" Below is a list of ideas I have heard mentioned or thought off. The list is supposed to be as complete as possible, if there is anything missing feel free to bring it up. Some of the ideas are stupid or do not make sense but are documented here for sake of completeness. Deployment of some of these ideas can be done real soon, others require extensive software upgrades. The final solution selection may include more than one ideas below as there is frequently not just one solution. The goal of this email is that the WG is in a position to know that it is selecting from a "complete set" of solutions When/IF the WG (or DNSOP WG) decides that it should attempt to document/recommend more approaches than what was covered in the FR-draft. Covered in FR draft: Query ID Source Port Source Address Randomness possibilities that originators have: Destination Address [1] Case games (like x20) Multiple identical questions [5] Repeat question [6] Spread question to number of nameservers. [7] Delay question [8] Time spaced repeated questions [9] "random" TCP query [11] What Destinations can do to increase protection: More addresses: [10] DNSSEC Protections that require both parties collaboration: TSIG DNS cookies TKEY + TSIG/SIG(0) SIG(0) Destination Protocol/port [2] Query name hacks (pre and post fixes) [3] EDNS ECHO [4] QCount > 1 [14] QClass top bit 8 redefinition [13] IPsec tunnels [12] IPv6 preference [15] Steps that resolvers can take to protect them self: Forgery Detection and react to forgery attempts. Steps that Operators of Authorative servers/zone owners can take: Deploy only current software Deploy DNSSEC Update ACL rules to reflect current recommended DNS port usage. Comments: [1] Destination Address: Many implementations go to first name server in an NS set all the time, some go to the one they know is closest or go to the one that they know has answered a query in the past, one they have an A record for, etc. From security point of view always selecting a random server is the best one. From an operating point of view this may/will cause more delays/errors. For high availability zones with short names having large NS sets is an possible source of randomness for example "." has 13 A address this adds 3.5 bits of randomness for resolvers that use random selection. By expanding this to randomly select IPv4 and IPv6 as transport for query another bit can be added. [2] Destination Port: Another potential source for randomness is to reserve 4 - 16 ports that DNS servers MUST listen on. 16 ports add 4 bits of randomness. [3] This relates to adding .QNAME in query section or QNAME. or even if QNAME is a.b.c to do a..b.c or a.b..c is in this case has a known prefix in the first label that is registered with IANA so people can avoid it, if is multiple labels the first label should encode how many bytes or labels to strip. [4] EDNS Echo: A simple option to EDNS that instructs a server to copy back this option in the answer or the answer is not to be trusted. The contents of the option is random data unique to the query. [5] In this case a resolver fires a number of identical questions off and expects to get the same number of identical answers. [6] In this case the resolver repeats the question after getting an answer, it expects an identical answer. [7] Spread question to a number of nameservers/recursive resolvers, expects to get back identical answers from all. [8] Here the resolver waits for a short random time before sending the question but it is listening for answers from the time it forms the question. This is to detect forgery attack before sending the question. [9] In this case the resolver sends queries that are spaced in time and it expects the answers to come back in the same order as sent the time between second and subsequent answers should approximate the transmission time. [10] More designation addresses, larger NS sets potentially offer more protection as the client has more addresses to choose from. [11] TCP queries are controversial as they require more state and overhead. Over the last few years we have seen TCP stacks optimized for handling large number of TCP connections thus the assumptions for not using TCP for DNS should be reexamined and requiring TCP port to be available on authorative servers will allow clients to fall back on TCP in specified situations. [12] IPSEC: this is an option when there is strong relationship between two DNS entities, it is not clear how applicable this it is in the random resolver talking to random server. [13] Right now about 4 classes are defined in the IANA registry. Use and deployment of new classes is difficult to say the least. For this reason it is tempting to steal some of these unusable bits into help protect the protocol. The proposal is to redefine the top 8 bits into a QID and servers would ignore these bits when checking class answer but echo them back in the answer's QCLASS. [14] QCOUNT > 1 is currently not allowed but could be used to add randomness to the query if the second query is ignored in the answer processing but is copied into the answer. There are number of different possibilities in how the randomness is expressed in the: label, QCLASS, QTYPE or all. [15] IPv6 preference for queries, A resolver can cycle through many privacy address to increase source address randomization. Sorry for the lack of attributions in this posting, if/when this becomes an an ID that will be fixed. Olafur -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 28 10:05:54 2008 Return-Path: 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 A214528C10C; Mon, 28 Jul 2008 10:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] 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 PdZUa+5-Ova7; Mon, 28 Jul 2008 10:05:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A18393A6A91; Mon, 28 Jul 2008 10:05:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNW4Q-0003yr-JS for namedroppers-data@psg.com; Mon, 28 Jul 2008 16:59:38 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNW4L-0003yJ-RI for namedroppers@ops.ietf.org; Mon, 28 Jul 2008 16:59:36 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 865ABC2DB2; Mon, 28 Jul 2008 17:59:30 +0100 (BST) Date: Mon, 28 Jul 2008 17:59:27 +0100 From: Alex Bligh Reply-To: Alex Bligh To: =?UTF-8?Q?=C3=93lafur_Gu=C3=B0mundsson_=2FDNSEXT_chair?= , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: Forgery Resistance phase #2 Message-ID: In-Reply-To: <200807281555.m6SFsxAO021711@stora.ogud.com> References: <200807281555.m6SFsxAO021711@stora.ogud.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 28 July 2008 11:53:32 -0400 "=C3=93lafur Gu=C3=B0mundsson /DNSEXT = chair"=20 wrote: > The list is supposed to be as complete as possible, if there is anything > missing feel free to bring it up. I contribute these for completeness without expressing an opinion as to their validity or otherwise: 1. There seems a body of opinion on namedroppers that replacing stub resolvers by full recursive caching resolvers improves forgery resistance. 2. Under "Deploy DNSSEC" some commentators have said a long pole in the tent of deployability is signing the root, hence DLV and DLVPTR are relevant to the topic in that they could speed deployment of DNSSEC. I think it's a useful list BTW. Another useful list would be to define the problem space(s) being addressed as there was some debate about that too. Alex -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 28 11:13:02 2008 Return-Path: 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 D2FFC3A6ABE; Mon, 28 Jul 2008 11:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 o1oSHHB4fPJQ; Mon, 28 Jul 2008 11:13:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 569CE3A6AE2; Mon, 28 Jul 2008 11:13:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNX8I-000Dk4-VO for namedroppers-data@psg.com; Mon, 28 Jul 2008 18:07:42 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNX8F-000Dj1-Dw for namedroppers@ops.ietf.org; Mon, 28 Jul 2008 18:07:40 +0000 X-IronPort-AV: E=Sophos;i="4.31,266,1215388800"; d="scan'208";a="90552676" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 28 Jul 2008 18:07:39 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6SI7csn022017 for ; Mon, 28 Jul 2008 11:07:38 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6SI7Zcx026036 for ; Mon, 28 Jul 2008 18:07:38 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 11:07:37 -0700 Received: from stealth-10-32-254-179.cisco.com ([10.32.254.179]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 11:07:36 -0700 Message-Id: <0460ACD4-46DC-4440-8DFD-97AD997AFD88@cisco.com> From: Richard Johnson To: namedroppers@ops.ietf.org In-Reply-To: <48935.1216753200@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 Date: Mon, 28 Jul 2008 11:07:36 -0700 References: <48935.1216753200@nsa.vix.com> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 28 Jul 2008 18:07:37.0019 (UTC) FILETIME=[D10360B0:01C8F0DC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=194; t=1217268459; x=1218132459; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=raj@cisco.com; z=From:=20Richard=20Johnson=20 |Subject:=20Re=3A=20please=20adopt=20http=3A//tools.ietf.or g/html/draft-vixie-dnsext-dns0x20 |Sender:=20; bh=XnD7ndNihsA0BLs2NT9D+XBm57W9ynQvzCuPoq7y5J8=; b=lu1ATrxYDdW4PxUPMUtCXONeSbY62lGDibiwS5e5XDvNhtPCXxQthA7vp4 23aBF+A5OQ5lON05mWjEqghZGyUIbLESF8nsZYV05bpdjou10t8T/JMXJZq1 VDUazb1+hf16w5OkitrDf3hY/LNxPfhYbGmdai1djYV1ixDppmHxQ=; Authentication-Results: sj-dkim-1; header.From=raj@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Yet another supporter... /raj On Jul 22, 2008, at 12:00 PM, Paul Vixie wrote: > please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 > as a > working group document. -- 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: From owner-namedroppers@ops.ietf.org Mon Jul 28 11:25:02 2008 Return-Path: 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 278E43A6A9F; Mon, 28 Jul 2008 11:25:02 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char D3 hex): To: \323lafur Gu\251\243munds[...] X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] 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 ztrmb0KJE3zK; Mon, 28 Jul 2008 11:25:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 57BD73A6861; Mon, 28 Jul 2008 11:25:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNXKC-000G5I-LI for namedroppers-data@psg.com; Mon, 28 Jul 2008 18:20:00 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNXK7-000G2x-96 for namedroppers@ops.ietf.org; Mon, 28 Jul 2008 18:19:58 +0000 Received: from [130.129.22.27] ([130.129.22.27]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m6SII8ZL085668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 11:18:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200807281555.m6SFsxAO021711@stora.ogud.com> References: <200807281555.m6SFsxAO021711@stora.ogud.com> Date: Mon, 28 Jul 2008 19:18:07 +0100 To: Ólafur Gu©£mundsson /DNSEXT chair , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: Forgery Resistance phase #2 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 11:53 AM -0400 7/28/08, Ólafur Gu©£mundsson /DNSEXT chair wrote: >Steps that resolvers can take to protect them self: > Forgery Detection > and react to forgery attempts. There is a glaring lack of footnote on that second one. I have heard multiple suggestions in the hallways this week. A bit more detail here would be appreciated. --Paul Hoffman, Director --VPN Consortium -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 29 00:18:34 2008 Return-Path: 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 293343A69EF; Tue, 29 Jul 2008 00:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.247 X-Spam-Level: X-Spam-Status: No, score=-5.247 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 fNXl2GgSDs4E; Tue, 29 Jul 2008 00:18:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E3CD43A67D2; Tue, 29 Jul 2008 00:18:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNjHH-000Epi-9W for namedroppers-data@psg.com; Tue, 29 Jul 2008 07:05:47 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNjHC-000Ep4-L1 for namedroppers@ops.ietf.org; Tue, 29 Jul 2008 07:05:45 +0000 X-IronPort-AV: E=Sophos;i="4.31,270,1215388800"; d="scan'208";a="15652906" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 29 Jul 2008 07:05:34 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6T75XFb030617 for ; Tue, 29 Jul 2008 09:05:33 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6T75Xh3010056 for ; Tue, 29 Jul 2008 07:05:33 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 09:05:33 +0200 Received: from [130.129.23.78] ([10.61.80.248]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 09:05:33 +0200 Message-Id: From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: IETF DNSEXT WG In-Reply-To: <0460ACD4-46DC-4440-8DFD-97AD997AFD88@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 Date: Tue, 29 Jul 2008 08:05:25 +0100 References: <48935.1216753200@nsa.vix.com> <0460ACD4-46DC-4440-8DFD-97AD997AFD88@cisco.com> X-Mailer: Apple Mail (2.928.1) X-OriginalArrivalTime: 29 Jul 2008 07:05:33.0459 (UTC) FILETIME=[7E56E630:01C8F149] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=191; t=1217315133; x=1218179133; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20

|Subject:=20Re=3A=20please=20adopt=20http=3A//tools.ietf.or g/html/draft-vixie-dnsext-dns0x20 |Sender:=20; bh=shpiWPEBUFJP18dAKVVo4/o38fQ0RrEAIhBmJHeEeHA=; b=NSCgQVgRbTuw9g7CSAnpYmC1sxB6LQWEtduqrfMWm6N3sbNTD366aqitO5 aAJMr1zPQ3eIR6ZwUOTk2l5LGtZ3xfrtIj2nmC8nF4rbK67xPl2NINb4Jk/a 0YQQIPJOfN; Authentication-Results: ams-dkim-2; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jul 22, 2008, at 12:00 PM, Paul Vixie wrote: > please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 > as a > working group document. Yup, please do! Patrik -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 29 01:00:47 2008 Return-Path: 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 6434D28C0ED; Tue, 29 Jul 2008 01:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, UNPARSEABLE_RELAY=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 0PL5PukvR2UP; Tue, 29 Jul 2008 01:00:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 271B73A67AA; Tue, 29 Jul 2008 01:00:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNjyF-000JSz-8U for namedroppers-data@psg.com; Tue, 29 Jul 2008 07:50:11 +0000 Received: from [64.136.55.15] (helo=outbound-mail.vgs.untd.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNjy9-000JS6-SK for namedroppers@ops.ietf.org; Tue, 29 Jul 2008 07:50:09 +0000 Received: from outbound-bu1.vgs.untd.com (webmail02.vgs.untd.com [10.181.12.142]) by smtpout03.vgs.untd.com with SMTP id AABEJ7U67AFD5FJA for (sender ); Tue, 29 Jul 2008 00:49:49 -0700 (PDT) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPY4JTTQHXKwT21Lw3Uy9BYPbuWP6mfiNUg== Received: (from fergdawg@netzero.net) by webmail02.vgs.untd.com (jqueuemail) id NQ9KQQWZ; Tue, 29 Jul 2008 00:49:04 PDT Received: from [76.103.61.74] by webmail02.vgs.untd.com with HTTP: Tue, 29 Jul 2008 07:48:41 GMT X-Originating-IP: [76.103.61.74] Mime-Version: 1.0 From: "Paul Ferguson" Date: Tue, 29 Jul 2008 07:48:41 GMT To: paf@cisco.com Cc: namedroppers@ops.ietf.org Subject: Re: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 X-Mailer: Webmail Version 4.0 Message-Id: <20080729.004841.17756.3@webmail02.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 9:4:991683156 X-MAIL-INFO:4295ed50647dcdb96504b9c410b92119056481652905053085596551e920712969e00154291561c0810d79d92d8124a9a4509599a56da544f4d1346d4434446484b1f5f579b4edf5f989648d091d3ddd5050d151b599a5 X-UNTD-Peer-Info: 10.181.12.142|webmail02.vgs.untd.com|outbound-bu1.vgs.untd.com|fergdawg@netzero.net Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Patrik F=E4ltstr=F6m wrote: >On Jul 22, 2008, at 12:00 PM, Paul Vixie wrote: > >> please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 = >> as a >> working group document. > >Yup, please do! > > Patrik > Can I add my voice of support, too? ;-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIjstVq1pz9mNUZTMRAp4HAJ9qeNYoKzoGj8g4ag+pTFq9Se85twCgr5vP 1u5rrqD8kIFOLcyL3jY8P0w=3D =3DUY/g -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 29 03:38:36 2008 Return-Path: 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 00F023A69F3; Tue, 29 Jul 2008 03:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.946 X-Spam-Level: X-Spam-Status: No, score=-0.946 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 b1mkD7XckXIo; Tue, 29 Jul 2008 03:38:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 278113A68F3; Tue, 29 Jul 2008 03:38:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNmVD-0008zZ-Mj for namedroppers-data@psg.com; Tue, 29 Jul 2008 10:32:23 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNmV6-0008ya-5L for namedroppers@ops.ietf.org; Tue, 29 Jul 2008 10:32:21 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6TAVpsg032327; Tue, 29 Jul 2008 06:31:52 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200807291031.m6TAVpsg032327@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 29 Jul 2008 06:06:10 -0400 To: Paul Hoffman , namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Re: Forgery Resistance phase #2 In-Reply-To: References: <200807281555.m6SFsxAO021711@stora.ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 14:18 28/07/2008, Paul Hoffman wrote: >At 11:53 AM -0400 7/28/08, =D3lafur Gu=A9=A3mundsson /DNSEXT > chair wrote: >>Steps that resolvers can take to protect them self: >> Forgery Detection >> and react to forgery attempts. > >There is a glaring lack of footnote on that=20 >second one. I have heard multiple suggestions in=20 >the hallways this week. A bit more detail here would be appreciated. yes it does, but this is a new area for DNS, suggestions are welcome. The danger here is a that some possible fall backs might be worse than doing nothing. Olafur Olafur -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 29 03:49:53 2008 Return-Path: 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 1F7343A68B2; Tue, 29 Jul 2008 03:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.312 X-Spam-Level: X-Spam-Status: No, score=-102.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 h0PQ+zyJ4HTB; Tue, 29 Jul 2008 03:49:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 315AA3A68CB; Tue, 29 Jul 2008 03:49:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNmhk-000AFE-3z for namedroppers-data@psg.com; Tue, 29 Jul 2008 10:45:20 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNmhf-000AEg-J0 for namedroppers@ops.ietf.org; Tue, 29 Jul 2008 10:45:17 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 18E4E3A6A71; Tue, 29 Jul 2008 03:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D Action:draft-ietf-dnsext-dnssec-rsasha256-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080729104502.18E4E3A6A71@core3.amsl.com> Date: Tue, 29 Jul 2008 03:45:01 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC Author(s) : J. Jansen Filename : draft-ietf-dnsext-dnssec-rsasha256-05.txt Pages : 9 Date : 2008-07-29 This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-rsasha256-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-29033516.I-D@ietf.org> --NextPart-- -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 29 04:02:58 2008 Return-Path: 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 540873A6AB1; Tue, 29 Jul 2008 04:02:58 -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 6pABOyqVG+oD; Tue, 29 Jul 2008 04:02:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6D0573A6A39; Tue, 29 Jul 2008 04:02:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNmuG-000BYm-1s for namedroppers-data@psg.com; Tue, 29 Jul 2008 10:58:16 +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 ) id 1KNmu9-000BXW-TP for namedroppers@ops.ietf.org; Tue, 29 Jul 2008 10:58:12 +0000 Received: from jelte (vhe-520087.sshn.net [195.169.221.157]) by sol.nlnetlabs.nl (Postfix) with ESMTP id 599DE13002C for ; Tue, 29 Jul 2008 12:58:08 +0200 (CEST) Received: from [192.168.8.11] (dragon [192.168.8.11]) by jelte (Postfix) with ESMTP id 24757CF982 for ; Tue, 29 Jul 2008 12:58:08 +0200 (CEST) Message-ID: <488EF7BF.8050709@NLnetLabs.nl> Date: Tue, 29 Jul 2008 12:58:07 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: I-D Action:draft-ietf-dnsext-dnssec-rsasha256-05.txt References: <20080729104502.18E4E3A6A71@core3.amsl.com> In-Reply-To: <20080729104502.18E4E3A6A71@core3.amsl.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: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the DNS Extensions Working Group of the IETF. > > > Title : Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC > Author(s) : J. Jansen > Filename : draft-ietf-dnsext-dnssec-rsasha256-05.txt > Pages : 9 > Date : 2008-07-29 > > This document describes how to produce RSA/SHA-256 and RSA/SHA-512 > DNSKEY and RRSIG resource records for use in the Domain Name System > Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-05.txt > As discussed here on namedroppers, I removed the section about how SHA1 signatures should be ignored, and only refer to RFC4035 section 2.2 as protection against downgrade attacks, which should be enough. I also removed the informational reference to NIST SP 800-57 part 3, which unfortunately has not been released in time. Instead I just made that reference to SP 800-57 in general. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIjve/4nZCKsdOncURAtpRAJ9iZXS3CPzlwRs9XVWJPqN0faKuXQCghBrU P+fl+MyP0ls++8/fqVO1gLk= =2Agf -----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: From dns@eye-con.com Tue Jul 29 04:59:42 2008 Return-Path: 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 ED0D03A6850 for ; Tue, 29 Jul 2008 04:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.933 X-Spam-Level: X-Spam-Status: No, score=-91.933 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_LETTER=-2, HTML_EXTRA_CLOSE=2.809, HTML_FONT_SIZE_HUGE=0.057, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_XBL=3.033, RELAY_IS_220=2.118, SARE_UNI=0.591, 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 48psPj8JxCrd for ; Tue, 29 Jul 2008 04:59:42 -0700 (PDT) Received: from n220246065234.netvigator.com (n220246065234.netvigator.com [220.246.65.234]) by core3.amsl.com (Postfix) with SMTP id 594D23A6A73 for ; Tue, 29 Jul 2008 04:59:41 -0700 (PDT) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Message-Id: <20080729155857.5060.qmail@n220246065234.netvigator.com> To: Subject: Anjelina Jolie XXX Video Free. From: MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit Date: Tue, 29 Jul 2008 04:59:41 -0700 (PDT)
Free Video Nude Anjelina Jolie

About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From owner-namedroppers@ops.ietf.org Tue Jul 29 06:00:48 2008 Return-Path: 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 226DB28C2A8; Tue, 29 Jul 2008 06:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 XHiMwiAGZiM5; Tue, 29 Jul 2008 06:00:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A7E3E28C2A7; Tue, 29 Jul 2008 06:00:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNoco-000MfJ-9X for namedroppers-data@psg.com; Tue, 29 Jul 2008 12:48:22 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNobd-000MYV-OY for namedroppers@ops.ietf.org; Tue, 29 Jul 2008 12:47:41 +0000 Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m6TBw7A1031764 for ; Tue, 29 Jul 2008 07:58:07 -0400 Received: from 619893L ([129.6.220.160]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id m6TBvqna021590 for ; Tue, 29 Jul 2008 07:57:56 -0400 From: "Scott Rose" To: Subject: RE: I-D Action:draft-ietf-dnsext-dnssec-rsasha256-05.txt Date: Tue, 29 Jul 2008 07:57:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <488EF7BF.8050709@NLnetLabs.nl> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: For those that care about references - NIST Special Pub 800-57 Part 3 only has more specific recommendations about key management but refers to Part 1 for all general pointers like key lengths, hash algorithms to use for specific security strengths, etc. So 800-57 Part 1 has all the necessary information, just in a non-DNSSEC specific format. Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Jelte Jansen > Sent: Tuesday, July 29, 2008 6:58 AM > To: namedroppers@ops.ietf.org > Subject: Re: I-D Action:draft-ietf-dnsext-dnssec-rsasha256-05.txt > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > This draft is a work item of the DNS Extensions Working Group > of the IETF. > > > > > > Title : Use of SHA-2 algorithms with RSA in > DNSKEY and RRSIG Resource Records for DNSSEC > > Author(s) : J. Jansen > > Filename : draft-ietf-dnsext-dnssec-rsasha256-05.txt > > Pages : 9 > > Date : 2008-07-29 > > > > This document describes how to produce RSA/SHA-256 and RSA/SHA-512 > > DNSKEY and RRSIG resource records for use in the Domain Name System > > Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-rsash a256-05.txt > As discussed here on namedroppers, I removed the section about how SHA1 signatures should be ignored, and only refer to RFC4035 section 2.2 as protection against downgrade attacks, which should be enough. I also removed the informational reference to NIST SP 800-57 part 3, which unfortunately has not been released in time. Instead I just made that reference to SP 800-57 in general. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIjve/4nZCKsdOncURAtpRAJ9iZXS3CPzlwRs9XVWJPqN0faKuXQCghBrU P+fl+MyP0ls++8/fqVO1gLk= =2Agf -----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: -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 29 06:34:04 2008 Return-Path: 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 3193928C2CE; Tue, 29 Jul 2008 06:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] 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 VWbaYtCf64QZ; Tue, 29 Jul 2008 06:34:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B50728C2E1; Tue, 29 Jul 2008 06:34:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNpGT-00010z-2I for namedroppers-data@psg.com; Tue, 29 Jul 2008 13:29:21 +0000 Received: from [204.9.75.100] (helo=kansas.jhsoft.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNpGO-00010U-4H for namedroppers@ops.ietf.org; Tue, 29 Jul 2008 13:29:18 +0000 Received: from hemsen by kansas.jhsoft.com (MDaemon PRO v9.6.2) with ESMTP id md50000105072.msg for ; Tue, 29 Jul 2008 13:29:15 +0000 From: =?iso-8859-1?Q?Jesper_G._H=F8y?= To: =?iso-8859-1?Q?'=D3lafur_Gu=F0mundsson_/DNSEXT__chair'?= , References: <200807281555.m6SFsxAO021711@stora.ogud.com> In-Reply-To: <200807281555.m6SFsxAO021711@stora.ogud.com> Subject: RE: Forgery Resistance phase #2 Date: Tue, 29 Jul 2008 15:28:21 +0200 Message-ID: <027b01c8f17e$f99b0a80$ecd11f80$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjwztzlQtIeU0NpQEa+RPu1D7Oa5gAr0JIA Content-Language: en-us X-Authenticated-Sender: jesper@jhsoft.com X-MDRemoteIP: 87.56.149.202 X-Return-Path: jesper@jhsoft.com X-Envelope-From: jesper@jhsoft.com X-MDaemon-Deliver-To: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I think my XQID suggestion (http://www.jhsoft.com/dns-xqid.htm), which = by the way seems like a even better idea in light of the Kaminsky bug, is somewhere in your list already. But I would be very interested to learn more about the other items. Could you possibly expand the list with some links to more details on = the other ideas? Thanks, Jesper =20 > -----Original Message----- > From: owner-namedroppers@ops.ietf.org [mailto:owner- > namedroppers@ops.ietf.org] On Behalf Of =D3lafur Gu=F0mundsson /DNSEXT > chair > Sent: Monday, July 28, 2008 5:54 PM > To: namedroppers@ops.ietf.org > Subject: Forgery Resistance phase #2 >=20 >=20 > This message is sent in my role as chair with consent of my co-chair > but without > his editing help, thus any mistakes in this message are mine and only > mine. >=20 > The large volume of message over the last 2 weeks related to how to > make DNS > safer made me think about "what are all the different possible > approaches?" > Below is a list of ideas I have heard mentioned or thought off. >=20 > The list is supposed to be as complete as possible, if there is > anything > missing feel free to bring it up. > Some of the ideas are stupid or do not make sense but are documented > here > for sake of completeness. > Deployment of some of these ideas can be done real soon, others = require > extensive software upgrades. The final solution selection may include > more than > one ideas below as there is frequently not just one solution. >=20 > The goal of this email is that the WG is in a position to know that it > is > selecting from a "complete set" of solutions When/IF the WG (or DNSOP > WG) > decides that it should attempt to document/recommend more approaches > than > what was covered in the FR-draft. >=20 > Covered in FR draft: > Query ID > Source Port > Source Address >=20 > Randomness possibilities that originators have: > Destination Address [1] > Case games (like x20) > Multiple identical questions [5] > Repeat question [6] > Spread question to number of nameservers. [7] > Delay question [8] > Time spaced repeated questions [9] > "random" TCP query [11] >=20 >=20 > What Destinations can do to increase protection: > More addresses: [10] > DNSSEC >=20 > Protections that require both parties collaboration: > TSIG > DNS cookies > TKEY + TSIG/SIG(0) > SIG(0) Destination Protocol/port [2] > Query name hacks (pre and post fixes) [3] > EDNS ECHO [4] > QCount > 1 [14] > QClass top bit 8 redefinition [13] > IPsec tunnels [12] > IPv6 preference [15] >=20 > Steps that resolvers can take to protect them self: > Forgery Detection > and react to forgery attempts. >=20 > Steps that Operators of Authorative servers/zone owners can take: > Deploy only current software > Deploy DNSSEC > Update ACL rules to reflect current recommended DNS port usage. >=20 > Comments: > [1] Destination Address: Many implementations go to first name server > in an > NS set all the time, some go to the one they know is closest or > go > to the one that they know has answered a query in the past, one > they > have an A record for, etc. > From security point of view always selecting a random server is > the > best one. From an operating point of view this may/will cause > more > delays/errors. For high availability zones with short names > having > large NS sets is an possible source of randomness for example "." > has > 13 A address this adds 3.5 bits of randomness for resolvers that > use > random selection. By expanding this to randomly select IPv4 and > IPv6 > as transport for query another bit can be added. >=20 > [2] Destination Port: Another potential source for randomness is to > reserve > 4 - 16 ports that DNS servers MUST listen on. 16 ports add 4 bits > of > randomness. >=20 > [3] This relates to adding .QNAME in query section or > QNAME. or even if QNAME is a.b.c to do > a..b.c or a.b..c > is in this case has a known prefix in the first label > that is registered with IANA so people can avoid it, > if is multiple labels the first label should encode > how many bytes or labels to strip. >=20 > [4] EDNS Echo: A simple option to EDNS that instructs a server to copy > back > this option in the answer or the answer is not to be trusted. > The contents of the option is random data unique to the query. >=20 > [5] In this case a resolver fires a number of identical questions off > and > expects to get the same number of identical answers. >=20 > [6] In this case the resolver repeats the question after getting an > answer, > it expects an identical answer. >=20 > [7] Spread question to a number of nameservers/recursive resolvers, > expects to get back identical answers from all. >=20 > [8] Here the resolver waits for a short random time before sending the > question but it is listening for answers from the time it forms > the question. > This is to detect forgery attack before sending the question. >=20 > [9] In this case the resolver sends queries that are spaced in time > and it expects the answers to come back in the same order as sent > the > time between second and subsequent answers should approximate > the transmission time. >=20 > [10] More designation addresses, larger NS sets potentially offer more > protection as the client has more addresses to choose from. >=20 > [11] TCP queries are controversial as they require more state and > overhead. > Over the last few years we have seen TCP stacks optimized for > handling > large number of TCP connections thus the assumptions for not > using TCP > for DNS should be reexamined and requiring TCP port to be > available on > authorative servers will allow clients to fall back on TCP in > specified situations. >=20 > [12] IPSEC: this is an option when there is strong relationship = between > two > DNS entities, it is not clear how applicable this it is in the > random > resolver talking to random server. >=20 > [13] Right now about 4 classes are defined in the IANA registry. Use > and deployment > of new classes is difficult to say the least. For this reason it > is tempting > to steal some of these unusable bits into help protect the > protocol. > The proposal is to redefine the top 8 bits into a QID and servers > would > ignore these bits when checking class answer but echo them back > in the > answer's QCLASS. >=20 > [14] QCOUNT > 1 is currently not allowed but could be used to add > randomness to > the query if the second query is ignored in the answer processing > but is copied into the answer. There are number of different > possibilities > in how the randomness is expressed in the: label, QCLASS, QTYPE > or all. >=20 > [15] IPv6 preference for queries, A resolver can cycle through many > privacy address to increase source address randomization. >=20 >=20 > Sorry for the lack of attributions in this posting, if/when this > becomes an > an ID that will be fixed. >=20 > Olafur >=20 >=20 > -- > 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: -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 29 07:30:03 2008 Return-Path: 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 2158E28C231; Tue, 29 Jul 2008 07:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] 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 n77PebL6oXei; Tue, 29 Jul 2008 07:30:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC96B28C1E5; Tue, 29 Jul 2008 07:30:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNq74-0006Gn-34 for namedroppers-data@psg.com; Tue, 29 Jul 2008 14:23:42 +0000 Received: from [204.9.75.100] (helo=kansas.jhsoft.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNq6l-0006Ed-UE for namedroppers@ops.ietf.org; Tue, 29 Jul 2008 14:23:28 +0000 Received: from hemsen by kansas.jhsoft.com (MDaemon PRO v9.6.2) with ESMTP id md50000105092.msg for ; Tue, 29 Jul 2008 14:19:05 +0000 From: =?iso-8859-1?Q?Jesper_G._H=F8y?= To: References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> In-Reply-To: <20080723183227.GA11957@outpost.ds9a.nl> Subject: RE: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Tue, 29 Jul 2008 16:18:09 +0200 Message-ID: <028601c8f185$eeb51b90$cc1f52b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acjs+O4OhwtbP2SqRkC+eycJYRWY3gEh9FJg Content-Language: en-us X-Authenticated-Sender: jesper@jhsoft.com X-MDRemoteIP: 87.56.149.202 X-Return-Path: jesper@jhsoft.com X-Envelope-From: jesper@jhsoft.com X-MDaemon-Deliver-To: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I second Bert's view on DNSSEC, and it is for much the same reasons that we do not have DNSSEC in Simple DNS Plus either. There may be other good reasons to push DNSSEC, but it really is overkill for the Kaminsky bug IMHO. The core problem with the Kaminsky bug, and other cache poisoning scenarios, is the short 16 bit transaction ID. So why not simply expand this ID to a secure length? And not just ~16 bits (random ports) or 2+ bits (x020) - but really secure length like 128 bits. This seems a lot easier than getting DNSSEC in place, signing the root, getting EVERYBODY to sign their zones, repeat for rollover, etc., etc. Some will probably argue that this doesn't help against on-the-wire-attacks. But if the bad buy is one-the-wire, then he can replace any data at will anyway. DNSSEC is no help here. Of course we already have SSL to solve that problem. So why not keep DNS simple? Am I oversimplifying matters? Sincerely, Jesper > -----Original Message----- > From: owner-namedroppers@ops.ietf.org [mailto:owner- > namedroppers@ops.ietf.org] On Behalf Of bert hubert > Sent: Wednesday, July 23, 2008 8:32 PM > To: David Conrad > Cc: Ben Laurie; DNSEXT WG > Subject: Re: How do we get the whole world to upgrade to DNSSEC capable > resolvers? > > On Wed, Jul 23, 2008 at 10:25:23AM -0700, David Conrad wrote: > > Actually, I suspect not, since I would guess this event has increased > > the number of dnscache sites out there. And PowerDNS (also > unaffected > > by the vulnerability as I understand it) doesn't support DNSSEC > > either, right? > > Correct - my reasoning can be found on > http://ds9a.nl/dnssec/index.html#id2467146 > > Some older stuff: http://ds9a.nl/secure-dns.html > > DNS is part of the long chain from a named service to a physical > server: > > 1) ARP to find the hardware serving the router/nameserver IP > 2) DNS to find the server IP > 3) BGP to find the link to the destination AS > 4) (TCP/)IP to the actual server > 5) Content > > Everybody who really cares about information security handles it in the > application that deals with the content, and is close to the user. All > the > steps underneath have traditionally been plaintext, and have only been > hardened enough to be secure enough that casual tampering is ruled out. > > Because we use real crypto for our important content anyhow, crypto > that > does authentication, this is not a problem. > > 1) ARPSEC has been proposed, but never went anywhere. Switches > implement > port security measures. > 2) DNS has been hardened using random source ports > 3) BGP has suffered the MD5 scare, and has now been hardened using TTL- > checks to keep out > strangers > 4) TCP/IP has been hardened by making sure everybody uses unpredictable > sequence numbers. > > You can see where this is going. > > DNSSEC would be the most complex protocol ever deployed on such a scale > on > the internet [1], with far reaching administrative and computational > consequences for everybody, yet it would sit all the way down there in > the > stack. > > I wouldn't put any faith in secure DNS alone. > > So - DNS needs only to be strong enough to not be easily subverted in > the > process of transporting plaintext unauthenticated data. This puts an > upper > bound on the overhead (financial, technical and administrative) that we > should commit to DNS security. > > And I firmly believe some simple measures will bring DNS to the > required > level of robustness against tampering, and that these simple measures > will > fit in the the 'overhead budget' mentioned above. [2] > > I also firmly believe DNSSEC will impose an order of magnitude more > hassle > than the world is willing to bear. > > Bert > > [1] The telephony world beats us hands down though. Think H.323 or SS7. > [2] EDNS PING extra entropy, with gradual fallback to TCP to be > introduced > to give everybody the opportunity to deploy. Fallback to TCP in case of > a > single question-response {id,source-port} mismatch might even be > enough! > > -- > http://www.PowerDNS.com Open source, database driven DNS Software > http://netherlabs.nl Open and Closed source services > > -- > 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: -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 29 07:55:21 2008 Return-Path: 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 CBD793A6927; Tue, 29 Jul 2008 07:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] 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 qFQOfQI6rPqu; Tue, 29 Jul 2008 07:55:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CE6093A6B88; Tue, 29 Jul 2008 07:55:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNqWV-00097S-AP for namedroppers-data@psg.com; Tue, 29 Jul 2008 14:49:59 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNqWL-000963-GF for namedroppers@ops.ietf.org; Tue, 29 Jul 2008 14:49:51 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 7FB4CC2DA3; Tue, 29 Jul 2008 15:49:46 +0100 (BST) Date: Tue, 29 Jul 2008 15:49:43 +0100 From: Alex Bligh Reply-To: Alex Bligh To: =?UTF-8?Q?Jesper_G=2E_H=C3=B8y?= , namedroppers@ops.ietf.org cc: Alex Bligh Subject: RE: How do we get the whole world to upgrade to DNSSEC capable resolvers? Message-ID: In-Reply-To: <028601c8f185$eeb51b90$cc1f52b0$@com> References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> <028601c8f185$eeb51b90$cc1f52b0$@com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 29 July 2008 16:18:09 +0200 "Jesper G. H=C3=B8y" = wrote: > Some will probably argue that this doesn't help against > on-the-wire-attacks. But if the bad buy is one-the-wire, then he can > replace any data at will anyway. DNSSEC is no help here. DNSSEC does indeed guard against on-the-wire attacks. What sort of attack are you thinking of that it cannot guard against? Alex -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 29 08:12:37 2008 Return-Path: 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 6ABF928C21E; Tue, 29 Jul 2008 08:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] 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 cCFsR8IEpfry; Tue, 29 Jul 2008 08:12:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7EE1428C1C6; Tue, 29 Jul 2008 08:12:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNqmB-000Ajc-Lr for namedroppers-data@psg.com; Tue, 29 Jul 2008 15:06:11 +0000 Received: from [204.9.75.100] (helo=kansas.jhsoft.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNqm7-000Aiu-Fs for namedroppers@ops.ietf.org; Tue, 29 Jul 2008 15:06:09 +0000 Received: from hemsen by kansas.jhsoft.com (MDaemon PRO v9.6.2) with ESMTP id md50000105112.msg for ; Tue, 29 Jul 2008 15:06:06 +0000 From: =?UTF-8?Q?Jesper_G._H=C3=B8y?= To: "'Alex Bligh'" , References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> <028601c8f185$eeb51b90$cc1f52b0$@com> In-Reply-To: Subject: RE: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Tue, 29 Jul 2008 17:05:09 +0200 Message-ID: <028a01c8f18c$7f6bb620$7e432260$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acjxil21NNof69HRSBadsSG+C9i7LQAAZ27g Content-Language: en-us X-Authenticated-Sender: jesper@jhsoft.com X-MDRemoteIP: 87.56.149.202 X-Return-Path: jesper@jhsoft.com X-Envelope-From: jesper@jhsoft.com X-MDaemon-Deliver-To: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: If DNSSEC tell you (signed and secure) that my website is at 1.2.3.4 - = the bad guy on the wire can still intercept and replace all the traffic = from your browser to 1.2.3.4 and feed his own stuff back to your browser = appearing to come from 1.2.3.4. Having the correct IP address of my web-server is no guarantee that you = are actually talking to the right server - when the bad guy is = on-the-wire that is. Jesper > -----Original Message----- > From: Alex Bligh [mailto:alex@alex.org.uk] > Sent: Tuesday, July 29, 2008 4:50 PM > To: Jesper G. H=C3=B8y; namedroppers@ops.ietf.org > Cc: Alex Bligh > Subject: RE: How do we get the whole world to upgrade to DNSSEC = capable > resolvers? >=20 >=20 >=20 > --On 29 July 2008 16:18:09 +0200 "Jesper G. H=C3=B8y" = > wrote: >=20 > > Some will probably argue that this doesn't help against > > on-the-wire-attacks. But if the bad buy is one-the-wire, then he can > > replace any data at will anyway. DNSSEC is no help here. >=20 > DNSSEC does indeed guard against on-the-wire attacks. What sort of > attack > are you thinking of that it cannot guard against? >=20 > Alex -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 29 08:27:39 2008 Return-Path: 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 A79F528C17C; Tue, 29 Jul 2008 08:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] 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 2-6gesfFkATz; Tue, 29 Jul 2008 08:27:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C4DE73A67B7; Tue, 29 Jul 2008 08:27:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNr2M-000Cnw-MJ for namedroppers-data@psg.com; Tue, 29 Jul 2008 15:22:54 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNr2C-000Cm6-34 for namedroppers@ops.ietf.org; Tue, 29 Jul 2008 15:22:46 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 5E118C2DA3; Tue, 29 Jul 2008 16:22:41 +0100 (BST) Date: Tue, 29 Jul 2008 16:22:38 +0100 From: Alex Bligh Reply-To: Alex Bligh To: =?UTF-8?Q?Jesper_G=2E_H=C3=B8y?= , namedroppers@ops.ietf.org cc: Alex Bligh Subject: RE: How do we get the whole world to upgrade to DNSSEC capable resolvers? Message-ID: <572015C3F44995F54736D38B@Ximines.local> In-Reply-To: <028a01c8f18c$7f6bb620$7e432260$@com> References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> <028601c8f185$eeb51b90$cc1f52b0$@com> <028a01c8f18c$7f6bb620$7e432260$@com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 29 July 2008 17:05:09 +0200 "Jesper G. H=C3=B8y" = wrote: > If DNSSEC tell you (signed and secure) that my website is at 1.2.3.4 - > the bad guy on the wire can still intercept and replace all the traffic > from your browser to 1.2.3.4 and feed his own stuff back to your browser > appearing to come from 1.2.3.4. > > Having the correct IP address of my web-server is no guarantee that you > are actually talking to the right server - when the bad guy is > on-the-wire that is. Sure, but then that's true of any use of trusted information in an insecure manner. DNS doesn't just carry IP addresses, and there's nothing to prevent one from putting other information (e.g. public keys) in the DNS. You mentioned "that's what SSL is for"; it would be equally possible to secure http (or smtp or whatever) using public keys retrieved over DNSSEC to avoid the attack you mention over. Without DNSSEC you need some other mechanism of ensuring the public key is correct; whilst SSL certificates have got good traction for HTTP, they haven't for (e.g.) SMTP. This is a useful discussion if only because it shows there are two meanings of "on the wire attacks" (i.e. attacks to DNS, and attacks based on an intercept of the results of the lookups). Alex -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 29 09:26:30 2008 Return-Path: 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 445733A67A3; Tue, 29 Jul 2008 09:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] 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 xtEMNyzXa+Z6; Tue, 29 Jul 2008 09:26:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 45A683A67B6; Tue, 29 Jul 2008 09:26:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNrvK-000Jj9-Kx for namedroppers-data@psg.com; Tue, 29 Jul 2008 16:19:42 +0000 Received: from [204.9.75.100] (helo=kansas.jhsoft.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNrvG-000JiM-9t for namedroppers@ops.ietf.org; Tue, 29 Jul 2008 16:19:40 +0000 Received: from hemsen by kansas.jhsoft.com (MDaemon PRO v9.6.2) with ESMTP id md50000105133.msg for ; Tue, 29 Jul 2008 16:19:36 +0000 From: =?UTF-8?Q?Jesper_G._H=C3=B8y?= To: "'Alex Bligh'" , References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> <028601c8f185$eeb51b90$cc1f52b0$@com> <028a01c8f18c$7f6bb620$7e432260$@com> <572015C3F44995F54736D38B@Ximines.local> In-Reply-To: <572015C3F44995F54736D38B@Ximines.local> Subject: RE: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Tue, 29 Jul 2008 18:18:41 +0200 Message-ID: <029401c8f196$c5822bd0$50868370$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjxjvPr7hFGfeP7R4u16W54oZM7PwAA/88w Content-Language: en-us X-Authenticated-Sender: jesper@jhsoft.com X-MDRemoteIP: 87.56.149.202 X-Return-Path: jesper@jhsoft.com X-Envelope-From: jesper@jhsoft.com X-MDaemon-Deliver-To: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I agree - and I am not arguing against DNSSEC as a whole. As I started out saying - "There may be other good reasons to push = DNSSEC" - distributing public keys certainly may be one of those. However, this was in regards to the Kaminsky bug, which is all about = carrying IP addresses (A/AAAA RRSets in response Additional section). So to clarify: DNSSEC doesn't make much difference when the bad guy is = on-the-wire - for IP address records. Without having thought this through, I think resolvers could probably = ignore anything else (non A/AAAA RRSets) in the response Additional = section - limiting the Kaminsky bug to such records. But that's a = different thread... Carrying IP addresses is still by far the biggest use of DNS. And I am just not convinced that it is a good idea to apply DNSSEC's = complexity to this most fundamental part of our Internet. I believe a simpler solution stands a much better chance of actually = being implemented and used, and therefore is more secure overall. Especially if such a solution does not require any end-user action other = than patching. Sincerely, Jesper > -----Original Message----- > From: Alex Bligh [mailto:alex@alex.org.uk] > Sent: Tuesday, July 29, 2008 5:23 PM > To: Jesper G. H=C3=B8y; namedroppers@ops.ietf.org > Cc: Alex Bligh > Subject: RE: How do we get the whole world to upgrade to DNSSEC = capable > resolvers? >=20 >=20 >=20 > --On 29 July 2008 17:05:09 +0200 "Jesper G. H=C3=B8y" = > wrote: >=20 > > If DNSSEC tell you (signed and secure) that my website is at 1.2.3.4 > - > > the bad guy on the wire can still intercept and replace all the > traffic > > from your browser to 1.2.3.4 and feed his own stuff back to your > browser > > appearing to come from 1.2.3.4. > > > > Having the correct IP address of my web-server is no guarantee that > you > > are actually talking to the right server - when the bad guy is > > on-the-wire that is. >=20 > Sure, but then that's true of any use of trusted information in an > insecure manner. DNS doesn't just carry IP addresses, and there's > nothing > to prevent one from putting other information (e.g. public keys) in = the > DNS. You mentioned "that's what SSL is for"; it would be equally > possible > to secure http (or smtp or whatever) using public keys retrieved over > DNSSEC to avoid the attack you mention over. Without DNSSEC you need > some other mechanism of ensuring the public key is correct; whilst > SSL certificates have got good traction for HTTP, they haven't for > (e.g.) SMTP. >=20 > This is a useful discussion if only because it shows there are two > meanings > of "on the wire attacks" (i.e. attacks to DNS, and attacks based on an > intercept of the results of the lookups). >=20 > Alex -- 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: From owner-namedroppers@ops.ietf.org Tue Jul 29 09:48:53 2008 Return-Path: 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 5BD853A67EF; Tue, 29 Jul 2008 09:48:52 -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 ze5C1qh1AqcT; Tue, 29 Jul 2008 09:48:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8678F3A6910; Tue, 29 Jul 2008 09:48:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNsJQ-000MdC-KJ for namedroppers-data@psg.com; Tue, 29 Jul 2008 16:44:36 +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 ) id 1KNsJM-000McU-61 for namedroppers@ops.ietf.org; Tue, 29 Jul 2008 16:44:34 +0000 Received: from jelte (vhe-520087.sshn.net [195.169.221.157]) by sol.nlnetlabs.nl (Postfix) with ESMTP id E384613002C for ; Tue, 29 Jul 2008 18:44:30 +0200 (CEST) Received: from [192.168.8.11] (dragon [192.168.8.11]) by jelte (Postfix) with ESMTP id AEC54CF982 for ; Tue, 29 Jul 2008 18:44:30 +0200 (CEST) Message-ID: <488F48EE.6020807@NLnetLabs.nl> Date: Tue, 29 Jul 2008 18:44:30 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> <028601c8f185$eeb51b90$cc1f52b0$@com> <028a01c8f18c$7f6bb620$7e432260$@com> <572015C3F44995F54736D38B@Ximines.local> <029401c8f196$c5822bd0$50868370$@com> In-Reply-To: <029401c8f196$c5822bd0$50868370$@com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesper G. Høy wrote: > I agree - and I am not arguing against DNSSEC as a whole. > As I started out saying - "There may be other good reasons to push DNSSEC" - distributing public keys certainly may be one of those. > > However, this was in regards to the Kaminsky bug, which is all about carrying IP addresses (A/AAAA RRSets in response Additional section). > So to clarify: DNSSEC doesn't make much difference when the bad guy is on-the-wire - for IP address records. > Any protocol that uses A/AAAA addresses could be in danger if it doesn't have its own protection (and indeed still would be with DNSSEC, if an attacker has full wire access). But, this includes DNS itself. Someone nasty could, for instance, not change a www or smtp A record, but an actual NS A record, thereby becoming authoritative for an entire zone, and all its data. > Without having thought this through, I think resolvers could probably ignore anything else (non A/AAAA RRSets) in the response Additional section - limiting the Kaminsky bug to such records. But that's a different thread... > They should already :) (as well as ignore out-of-bailiwick etc) Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIj0ju4nZCKsdOncURAk+UAJ9qNcxfhrAEDrZHM/OYf0Vs454sZwCgjrAd 3V0cDX5Re3zD+JS5gjBd/IA= =t2RX -----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: From owner-namedroppers@ops.ietf.org Wed Jul 30 02:22:24 2008 Return-Path: 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 CE8B63A6BC7; Wed, 30 Jul 2008 02:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 GetLeJvLXNyP; Wed, 30 Jul 2008 02:22:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F5E83A6B9A; Wed, 30 Jul 2008 02:22:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KO7og-000FY3-CQ for namedroppers-data@psg.com; Wed, 30 Jul 2008 09:17:54 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KO7oc-000FXa-Sa for namedroppers@ops.ietf.org; Wed, 30 Jul 2008 09:17:52 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id A2BF2C2DAB; Wed, 30 Jul 2008 10:17:48 +0100 (BST) Date: Wed, 30 Jul 2008 10:17:43 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Alex Bligh , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: Forgery resilience: straw man proposal Message-ID: <8979D3CEC4ABCD6DE0C47320@Ximines.local> In-Reply-To: <429776829478B32E1ED8DF85@Ximines.local> References: <429776829478B32E1ED8DF85@Ximines.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 30 July 2008 10:14:17 +0100 Alex Bligh wrote: > 1. Use IPsec AH in transport mode between the stub resolver and the > recursive nameserver. This provides authentication of the recursive > nameserver to the stub resolver (see below), integrity protection, > replay protection and (as an unneeded bonus I think) non-repudiation. I should have added that it does not suffer the computational overhead of requiring encryption/decryption at each end. Alex -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 30 02:22:34 2008 Return-Path: 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 992513A6B9A; Wed, 30 Jul 2008 02:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.383 X-Spam-Level: X-Spam-Status: No, score=-0.383 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 fMRPVR+q3hK3; Wed, 30 Jul 2008 02:22:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9FE6E3A6BC7; Wed, 30 Jul 2008 02:22:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KO7lP-000F8N-QD for namedroppers-data@psg.com; Wed, 30 Jul 2008 09:14:31 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KO7lL-000F7f-FO for namedroppers@ops.ietf.org; Wed, 30 Jul 2008 09:14:29 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 93F45C2DA7; Wed, 30 Jul 2008 10:14:20 +0100 (BST) Date: Wed, 30 Jul 2008 10:14:17 +0100 From: Alex Bligh Reply-To: Alex Bligh To: namedroppers@ops.ietf.org cc: Alex Bligh Subject: Forgery resilience: straw man proposal Message-ID: <429776829478B32E1ED8DF85@Ximines.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Here's a straw man proposal for forgery resilience between stub resolvers and recursive nameservers with minimal invention of new protocols: 1. Use IPsec AH in transport mode between the stub resolver and the recursive nameserver. This provides authentication of the recursive nameserver to the stub resolver (see below), integrity protection, replay protection and (as an unneeded bonus I think) non-repudiation. 2. Determine availability of, and the public key for the recursive nameserver the same way as its IP is obtained, IE through a BOOTP/DHCP/ IPCP option in most cases. If it's not there, use normal IP. If it is there, do not fall back. Whilst DHCP options etc. can be spoofed, they'd have to be spoofed early, and in any case if Malory can spoof these options he can simply insert his own nameserver IP addresses anyway. The really paranoid can protect BOOTP/DHCP/IPCP in other ways. 3. IPsec AH in transport mode is not compatible with NAT. This is partly a blessing in disguise. This means that a typical middlebox in the form of an end user NAT box needs to act as an ALG, i.e. either a caching resolver or what in old DNS terminology would have been called a "forwarder". This has two advantages. Firstly, in this scenario it's the NAT box which is the recipient of the DHCP/BOOTP/IPCP option, so is best placed to make the IPsec queries and need not then distribute this information (and indeed should not if it's NATing). Secondly, as the NAT box originates the IPsec queries, it can then be optional for devices on the end-user side of the NAT to speak IPsec at all, as their query will simply be sent to the NAT box, which would forward a query for the same records on but wrapped up in IPsec. Of course as a forwarder the NAT box could advertise its own IPsec key to prevent forgery between the NAT box and the end user for IPsec AH aware end users. Note that NAT (or more accurately NAPT) seems to break other forgery resilience schemes (e.g. entropy increasing ones) so some degree of rewrite is necessary here, and this has the advantage of a rewrite only on middleboxen than need not extend to end user boxes (as well as at the caching resolver / ISP side). 4. As it is unnecessary for the query originator to be authenticated to the resolver (as opposed to vice versa), all query originators could use the same null key. Please make allowance for lack of caffeine so far today. I don't claim this is the best solution, merely that it should be considered amongst others. Alex -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 30 08:01:38 2008 Return-Path: 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 779AB3A6C12; Wed, 30 Jul 2008 08:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] 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 OQ+-8a4Sc58j; Wed, 30 Jul 2008 08:01:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 723423A6C0E; Wed, 30 Jul 2008 08:01:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOD2s-00028N-Ge for namedroppers-data@psg.com; Wed, 30 Jul 2008 14:52:54 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOD2n-00027h-IG for namedroppers@ops.ietf.org; Wed, 30 Jul 2008 14:52:52 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KOD2Z-00076a-EO; Wed, 30 Jul 2008 16:52:35 +0200 Received: from fweimer by bfk.de with local id 1KOD2g-0007Pj-4y; Wed, 30 Jul 2008 16:52:42 +0200 To: Scott Rose Cc: IETF DNSEXT WG Subject: Re: New version of draft-ietf-dnsext-rfc2672bis-dname available References: <487E08CD.60508@nist.gov> From: Florian Weimer Date: Wed, 30 Jul 2008 16:52:42 +0200 Message-ID: <82r69b8lvp.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Scott Rose: > I know we missed the deadline (my fault). But the -14 version of the > DNAMEbis draft is available here: > > http://www.dnsops.gov/draft-ietf-dnsext-rfc2672bis-dname-14.html > http://www.dnsops.gov/draft-ietf-dnsext-rfc2672bis-dname-14.txt I would like to see section 3.4 updated with language like this: If a recursive caching name server encounters a DNAME RR which contradicts information already in the cache (excluding CNAME records), it SHOULD NOT cache the DNAME RR, but it MAY cache the CNAME record received along with it or synthesized from the DNAME record, subject the rules for CNAME caching. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 30 10:45:48 2008 Return-Path: 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 7CCE928C39E; Wed, 30 Jul 2008 10:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.797 X-Spam-Level: X-Spam-Status: No, score=0.797 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MISSING_HEADERS=1.292, RDNS_NONE=0.1] 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 On-AVcfbWQLK; Wed, 30 Jul 2008 10:45:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 624303A6876; Wed, 30 Jul 2008 10:45:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOFaP-000MmU-Jy for namedroppers-data@psg.com; Wed, 30 Jul 2008 17:35:41 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOFaK-000Mle-Mw for namedroppers@ops.ietf.org; Wed, 30 Jul 2008 17:35:39 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m6UHZYxw046366 for ; Wed, 30 Jul 2008 13:35:34 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m6UHZYer046365 for namedroppers@ops.ietf.org; Wed, 30 Jul 2008 13:35:34 -0400 (EDT) (envelope-from namedroppers) 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 ) id 1KNt3b-0001kE-4p for namedroppers@ops.ietf.org; Tue, 29 Jul 2008 17:32:21 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 61694A9D21; Tue, 29 Jul 2008 17:32:11 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie cc: "=?iso-8859-1?Q?'=D3lafur_Gu=F0mundsson_/DNSEXT__chair'?=" , namedroppers@ops.ietf.org Subject: XQID (Re: Forgery Resistance phase #2 ) In-Reply-To: Your message of "Tue, 29 Jul 2008 15:28:21 +0200." <027b01c8f17e$f99b0a80$ecd11f80$@com> References: <200807281555.m6SFsxAO021711@stora.ogud.com> <027b01c8f17e$f99b0a80$ecd11f80$@com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Tue, 29 Jul 2008 17:32:11 +0000 Message-ID: <1135.1217352731@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 61694A9D21.01A81 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] > I think my XQID suggestion (http://www.jhsoft.com/dns-xqid.htm), which by > the way seems like a even better idea in light of the Kaminsky bug, is > somewhere in your list already. if we can amend the edns spec to require that for the XQID option, a reply without XQID will cause the transaction to be repeated several times across all of the zone's nameservers, with a different random UDP port and 16-bit QID each time, then i will support the XQID proposal. (this logic for repeat-on-suspicion is more or less what we're recommending in 0x20, and it's possible that if there are enough 0x20 bits available, then an XQID could be made optional for that transaction.) -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 30 11:14:15 2008 Return-Path: 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 C25AA3A6C2F; Wed, 30 Jul 2008 11:14:15 -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 Ev9oVjqezRPL; Wed, 30 Jul 2008 11:14:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D3E543A6972; Wed, 30 Jul 2008 11:14:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOG6x-0001AC-AY for namedroppers-data@psg.com; Wed, 30 Jul 2008 18:09:19 +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 ) id 1KOG6t-00019f-1J for namedroppers@ops.ietf.org; Wed, 30 Jul 2008 18:09:17 +0000 Received: from jelte (vhe-520087.sshn.net [195.169.221.157]) by sol.nlnetlabs.nl (Postfix) with ESMTP id C56E013002C; Wed, 30 Jul 2008 20:09:13 +0200 (CEST) Received: from [192.168.8.11] (dragon [192.168.8.11]) by jelte (Postfix) with ESMTP id 51015CF982; Wed, 30 Jul 2008 20:09:13 +0200 (CEST) Message-ID: <4890AE49.7040006@NLnetLabs.nl> Date: Wed, 30 Jul 2008 20:09:13 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: XQID (Re: Forgery Resistance phase #2 ) References: <200807281555.m6SFsxAO021711@stora.ogud.com> <027b01c8f17e$f99b0a80$ecd11f80$@com> <1135.1217352731@nsa.vix.com> In-Reply-To: <1135.1217352731@nsa.vix.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: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Vixie wrote: >> I think my XQID suggestion (http://www.jhsoft.com/dns-xqid.htm), which by >> the way seems like a even better idea in light of the Kaminsky bug, is >> somewhere in your list already. > > if we can amend the edns spec to require that for the XQID option, a reply > without XQID will cause the transaction to be repeated several times across > all of the zone's nameservers, with a different random UDP port and 16-bit > QID each time, then i will support the XQID proposal. (this logic for > repeat-on-suspicion is more or less what we're recommending in 0x20, and > it's possible that if there are enough 0x20 bits available, then an XQID > could be made optional for that transaction.) > correct me if i'm wrong, but i think you might be confusing two proposals here. XQID and the EDNS PING proposal. XQID appends entropy to the actual query name, and shouldn't be downgradeable by leaving out something (because then the answer wouldn't be the same as the query). Using EDNS PING is 'cleaner' (it doesn't muck with the query), but would need something like you ask for here. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIkK5J4nZCKsdOncURAvtOAJ427eN0V+fScDIKXbb59rKhyk9JDACglknN QlLw6qkqdjuqKkcIrGLyktw= =tRLv -----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: From owner-namedroppers@ops.ietf.org Wed Jul 30 11:19:42 2008 Return-Path: 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 E280F3A68AF; Wed, 30 Jul 2008 11:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 LfonXtq5gj02; Wed, 30 Jul 2008 11:19:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BBF5C3A659B; Wed, 30 Jul 2008 11:19:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOGD8-00022s-1e for namedroppers-data@psg.com; Wed, 30 Jul 2008 18:15:42 +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 ) id 1KOGCx-00021Y-2N for namedroppers@ops.ietf.org; Wed, 30 Jul 2008 18:15:40 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id F0C30A9D1D; Wed, 30 Jul 2008 18:15:22 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Florian Weimer cc: Scott Rose , IETF DNSEXT WG In-Reply-To: Your message of "Wed, 30 Jul 2008 16:52:42 +0200." <82r69b8lvp.fsf@mid.bfk.de> References: <487E08CD.60508@nist.gov> <82r69b8lvp.fsf@mid.bfk.de> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Wed, 30 Jul 2008 18:15:22 +0000 Message-ID: <65672.1217441722@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: F0C30A9D1D.0F9C2 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: New version of draft-ietf-dnsext-rfc2672bis-dname available Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > I know we missed the deadline (my fault). But the -14 version of the > > DNAMEbis draft is available here: > > > > http://www.dnsops.gov/draft-ietf-dnsext-rfc2672bis-dname-14.html > > http://www.dnsops.gov/draft-ietf-dnsext-rfc2672bis-dname-14.txt > > I would like to see section 3.4 updated with language like this: > > If a recursive caching name server encounters a DNAME RR which > contradicts information already in the cache (excluding CNAME > records), it SHOULD NOT cache the DNAME RR, but it MAY cache the > CNAME record received along with it or synthesized from the DNAME > record, subject the rules for CNAME caching. seconded. -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 30 12:05:11 2008 Return-Path: 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 972BC3A681F; Wed, 30 Jul 2008 12:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 juGnMDUUBgDa; Wed, 30 Jul 2008 12:05:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E12D928C3C9; Wed, 30 Jul 2008 12:04:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOGqk-0007sL-1n for namedroppers-data@psg.com; Wed, 30 Jul 2008 18:56:38 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOGqT-0007qK-Pe for namedroppers@ops.ietf.org; Wed, 30 Jul 2008 18:56:30 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KOGqO-0007op-4m; Wed, 30 Jul 2008 20:56:16 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id BCFF14B47A; Wed, 30 Jul 2008 20:56:30 +0200 (CEST) Date: Wed, 30 Jul 2008 20:56:30 +0200 From: bert hubert To: Peter Koch Cc: IETF DNSEXT WG Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers" Message-ID: <20080730185630.GC31705@outpost.ds9a.nl> References: <200806262033.m5QKXJxA036876@ogud.com> <20080712111535.GA22518@x27.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080712111535.GA22518@x27.adm.denic.de> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sat, Jul 12, 2008 at 01:15:35PM +0200, Peter Koch wrote: > Introduction: > 1st paragraph, self-reference: s/this RFC/this document/ done > last paragraph > I support changing "For protocol extensions under development" to leave > out "under development". :-) If you really want. I'd hope they would still see development though. > NITs: > s/RRSET/RRSet/g > s/IPSEC/IPsec/g Done. > Section 4.1: > Forcing a _query_, some other occurences where "question" should be replaced > with "query", same in 4.5 In some places this weirds the language - we ask questions, not queries. I've changed over the other places. > Section 5: > An attacker can benefit from this exact phenomenon if it can force > the target resolver to have multiple equivalent outstanding queries > at any one time to the same authoritative server. > > ... where "equivalent" means that QNAME/QTYPE/QCLASS are identical. Added. > > 6. Accepting only in-zone records > > That should be "in-domain", because the resolver can't tell the zone > boundaries. > > If accepted uncritically, the resolver stands the chance of accepting > data from an untrusted source. Care must be taken to only accept > data if it is known that the originator is authoritative for that > data. > > ... authoritative for the QNAME or a parent of the QNAME. > > Same reason: zone cuts are invisible. Done. > IMHO the document could benefit from an example here (see my earlier > posting for a suggestion). I'll dig it up. > For a domain with a TTL of 60 seconds, the 10% level is hit after 24 > minutes, 50% after less than 3 hours, 90% after around 9 hours. > > Domains don't have TTLs, so s/domain/RRSet/ (in both paragraphs). Done. > Section 9: > > address MUST match the query's source IP address. A mismatch should > be considered a format error, and the response invalid. > > How should the resolver treat an "invalid" response? I'd guess silently > dropping it and waiting for the next would be preferrable over sending > FORMERR to the querying client? Perhaps - the language now says the response is invalid, and leaves it up to the resolver. > o Use an unpredictable source port for outgoing queries from the > range (53, or > 1024) of available ports that is as large as > possible and practicable; > > typo: >= 1024 Addressed in another way in an earlier revision, but the result is the same. > > In case these abilities are enabled, the implementation MUST strive > to have its choices of source port and query ID remain unpredictable, > > That's the normative language I think could be improved - independent of > BCP vs. standards track: "MUST strive" implies "nice try". > "MUST minimize the predictablity ... " or similar would get rid of these > connotations. This paragraph has been dropped and replaced by new language. > > 10. Security Considerations > > The mutual effect of source port randomization on forewalls and NATs > has been mentioned before. If nothing more, the security considerations > must mention that ... > > "The effects of source port randomization may be dramatically reduced > by NAT devices which either serialize or limit in volume the UDP source > ports used by the querying resolver." Fine words, thanks. Please find your updates in http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset/33 Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 30 12:05:44 2008 Return-Path: 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 8C51228C3CB; Wed, 30 Jul 2008 12:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 sqibdk0FWR2C; Wed, 30 Jul 2008 12:05:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8080D28C3B6; Wed, 30 Jul 2008 12:05:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOGuN-0008P8-2Z for namedroppers-data@psg.com; Wed, 30 Jul 2008 19:00:23 +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 ) id 1KOGuJ-0008OR-7c for namedroppers@ops.ietf.org; Wed, 30 Jul 2008 19:00:21 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 84708A9D1B; Wed, 30 Jul 2008 19:00:06 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Jelte Jansen cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Wed, 30 Jul 2008 20:09:13 +0200." <4890AE49.7040006@NLnetLabs.nl> References: <200807281555.m6SFsxAO021711@stora.ogud.com> <027b01c8f17e$f99b0a80$ecd11f80$@com> <1135.1217352731@nsa.vix.com> <4890AE49.7040006@NLnetLabs.nl> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Wed, 30 Jul 2008 19:00:06 +0000 Message-ID: <71458.1217444406@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 84708A9D1B.326D6 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: XQID (Re: Forgery Resistance phase #2 ) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > correct me if i'm wrong, but i think you might be confusing two > proposals here. XQID and the EDNS PING proposal. XQID appends entropy to > the actual query name, and shouldn't be downgradeable by leaving out > something (because then the answer wouldn't be the same as the query). > > Using EDNS PING is 'cleaner' (it doesn't muck with the query), but would > need something like you ask for here. yes, and i apologize for my confusion, i'm jittery from too much coffee and too little sleep in the last few weeks. PING with that modification to EDNS's fallback would work, though i'm beginning to realize that the requirement should be phrased as "each query transaction must be protected by XYZ bits of high quality random entropy, which can be reached using any combination of udp port number, query ID, DNS 0x20 bits, PING, or repeated queries". XYZ is probably about 50 if we want to rule out guessing attacks. -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 30 12:34:17 2008 Return-Path: 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 6D6DA3A6953; Wed, 30 Jul 2008 12:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 boHGeo8UwHnC; Wed, 30 Jul 2008 12:34:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 545F53A68DF; Wed, 30 Jul 2008 12:34:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOHM3-000CFV-S3 for namedroppers-data@psg.com; Wed, 30 Jul 2008 19:28:59 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOHLz-000CE8-H0 for namedroppers@ops.ietf.org; Wed, 30 Jul 2008 19:28:57 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KOHLx-0008Fq-DC for namedroppers@ops.ietf.org; Wed, 30 Jul 2008 21:28:53 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 0B4B64B452; Wed, 30 Jul 2008 21:29:07 +0200 (CEST) Date: Wed, 30 Jul 2008 21:29:07 +0200 From: bert hubert To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: Re: WGLC summary for draft-ietf-dnsext-forgery-resilience Message-ID: <20080730192907.GA4703@outpost.ds9a.nl> References: <20080718200235.GG73459@commandprompt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080718200235.GG73459@commandprompt.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Hello working group, To my great sadness I won't be able to join you in Dublin, but rest assured I'll spend quality time with my ten-week old son instead. -06 has been posted: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-06.txt I've updated chapter 9 as outlined in the posting by Andrew, plus addressed all nits Peter Koch had open. Some more below: On Fri, Jul 18, 2008 at 04:02:35PM -0400, Andrew Sullivan wrote: > Minor changes: > Apply nits that number of people have brought up including > Jelte Jansen, Paul Hoffman, Paul Vixie, Peter Koch, Alex Brown, > Andreas Gustafsson, Jimmei Tatuya. I could not find open nits by Jelte, Paul, Paul, Alex Bligh, Andreas or Jinmei. Additionally, Peter Koch told me he sent me an example which would fit well in the draft, but I can't find it, but I did promise I'd include it. If any of you feels I've ignored any of your nits, please please let me know. Finally, I've been doing the math for Kaminksy-style spoofing, it is interesting. I hope to share it with you later tonight. A naive calculation shows we should not be overly worried, delving into it deeper makes me worry again. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 30 12:34:59 2008 Return-Path: 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 4A41B3A68ED; Wed, 30 Jul 2008 12:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.334 X-Spam-Level: X-Spam-Status: No, score=-102.334 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 rYL47ITndbSm; Wed, 30 Jul 2008 12:34:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4A4CC3A68DF; Wed, 30 Jul 2008 12:34:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOHNR-000CTG-9A for namedroppers-data@psg.com; Wed, 30 Jul 2008 19:30:25 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOHNN-000CSD-Bv for namedroppers@ops.ietf.org; Wed, 30 Jul 2008 19:30:23 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id CEC943A6884; Wed, 30 Jul 2008 12:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D Action:draft-ietf-dnsext-forgery-resilience-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080730193001.CEC943A6884@core3.amsl.com> Date: Wed, 30 Jul 2008 12:30:01 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Measures for making DNS more resilient against forged answers Author(s) : B. Hubert, R. Mook Filename : draft-ietf-dnsext-forgery-resilience-06.txt Pages : 25 Date : 2008-07-30 The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder. Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation. By describing certain behaviour that has previously not been standardised, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 1034. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-forgery-resilience-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-30122140.I-D@ietf.org> --NextPart-- -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 30 12:36:30 2008 Return-Path: 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 735033A68D8; Wed, 30 Jul 2008 12:36:30 -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 CwJrrlyzmtbz; Wed, 30 Jul 2008 12:36:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 54CA93A68B0; Wed, 30 Jul 2008 12:36:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOHLk-000CC9-Lx for namedroppers-data@psg.com; Wed, 30 Jul 2008 19:28:40 +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 ) id 1KOHLf-000CBD-G0 for namedroppers@ops.ietf.org; Wed, 30 Jul 2008 19:28:38 +0000 Received: from jelte (vhe-520087.sshn.net [195.169.221.157]) by sol.nlnetlabs.nl (Postfix) with ESMTP id B4BF213002B; Wed, 30 Jul 2008 21:28:34 +0200 (CEST) Received: from [192.168.8.11] (dragon [192.168.8.11]) by jelte (Postfix) with ESMTP id 8E8C1CF982; Wed, 30 Jul 2008 21:28:34 +0200 (CEST) Message-ID: <4890C0E3.406@NLnetLabs.nl> Date: Wed, 30 Jul 2008 21:28:35 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: XQID (Re: Forgery Resistance phase #2 ) References: <200807281555.m6SFsxAO021711@stora.ogud.com> <027b01c8f17e$f99b0a80$ecd11f80$@com> <1135.1217352731@nsa.vix.com> <4890AE49.7040006@NLnetLabs.nl> <71458.1217444406@nsa.vix.com> In-Reply-To: <71458.1217444406@nsa.vix.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: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Vixie wrote: > > though i'm beginning to realize that the > requirement should be phrased as "each query transaction must be protected > by XYZ bits of high quality random entropy, which can be reached using any > combination of udp port number, query ID, DNS 0x20 bits, PING, or repeated > queries". XYZ is probably about 50 if we want to rule out guessing > attacks. > I'm actually not too sure of whether a 'mix and match to your hearts content' approach is what we should be trying to achieve here. Although that might make debugging problems so insanely difficult that switching to DNSSEC will be a relief :) I do have two questions, that probably go for all the add-entropy proposals; 1. Do all recursive servers even have access to enough entropy? This might not be a problem at all, or extra entropy could be arranged for busy ones, but it might be worth thinking about in advance. For that matter, what about dos attacks where the entropy pool itself is attacked, is that possible? What would happen then? 2. Is it feasible to require (as a deployment consideration or otherwise) that in setups where there might be multiple implementations pretending to be one server, all implementations should have the exact same feature set? Would we even want that? Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIkMDi4nZCKsdOncURAlTdAKDU19655aBuQq/NGIL9D/3PqIinUgCeKT34 I6CflhDt2VWTFZnUslBhYOs= =QGMD -----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: From owner-namedroppers@ops.ietf.org Wed Jul 30 12:41:35 2008 Return-Path: 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 31B3E3A68AB; Wed, 30 Jul 2008 12:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=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 FhTHNcr0+PQL; Wed, 30 Jul 2008 12:41:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D7EA13A683A; Wed, 30 Jul 2008 12:41:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOHTs-000DLr-Qq for namedroppers-data@psg.com; Wed, 30 Jul 2008 19:37:04 +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 ) id 1KOHTo-000DJz-4V for namedroppers@ops.ietf.org; Wed, 30 Jul 2008 19:37:01 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 88B18A9D13; Wed, 30 Jul 2008 19:36:55 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Jelte Jansen cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Wed, 30 Jul 2008 21:28:35 +0200." <4890C0E3.406@NLnetLabs.nl> References: <200807281555.m6SFsxAO021711@stora.ogud.com> <027b01c8f17e$f99b0a80$ecd11f80$@com> <1135.1217352731@nsa.vix.com> <4890AE49.7040006@NLnetLabs.nl> <71458.1217444406@nsa.vix.com> <4890C0E3.406@NLnetLabs.nl> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Wed, 30 Jul 2008 19:36:55 +0000 Message-ID: <76119.1217446615@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 88B18A9D13.E1469 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: XQID (Re: Forgery Resistance phase #2 ) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > I'm actually not too sure of whether a 'mix and match to your hearts > content' approach is what we should be trying to achieve here. Although > that might make debugging problems so insanely difficult that switching > to DNSSEC will be a relief :) tkey+tsig, or dnssec+sig(0), or vpn, should be considered equivilent. that has been my basic gripe with bert's draft on forgery resilience -- it mandates a specific method rather than offering a specific method and then mandating that some method equivilent or superior to that method in strength be used. > I do have two questions, that probably go for all the add-entropy proposals; > > 1. Do all recursive servers even have access to enough entropy? This > might not be a problem at all, or extra entropy could be arranged for > busy ones, but it might be worth thinking about in advance. For that > matter, what about dos attacks where the entropy pool itself is attacked, > is that possible? What would happen then? in my statement i called for "high quality randomness". if you don't have enough randomness, or if its quality is too low, then you can't speak dns. (and, i expect that banks will test your RDNS strength before letting you log in, assuming that this approach isn't already patented up the wazoo.) > 2. Is it feasible to require (as a deployment consideration or > otherwise) that in setups where there might be multiple implementations > pretending to be one server, all implementations should have the exact > same feature set? Would we even want that? i think we can strongly recommend, but not mandate, that all members of a local or distributed dns cluster (whether authority or recursive or stub) implement the same protections and options, but that in practice, stuff will be wrong, there will be churn, there will be partial rollouts for testing and QA, and thus it will always be nec'y for initiators to cope with inconsistent responders. -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 30 13:21:13 2008 Return-Path: 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 575B13A68ED; Wed, 30 Jul 2008 13:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 CBoGM378cf93; Wed, 30 Jul 2008 13:21:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6686E3A685C; Wed, 30 Jul 2008 13:21:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOI31-000HLn-5D for namedroppers-data@psg.com; Wed, 30 Jul 2008 20:13:23 +0000 Received: from [2001:888:10:36::23] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOI2v-000HJ9-Vj for namedroppers@ops.ietf.org; Wed, 30 Jul 2008 20:13:21 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KOI2X-0000qP-Iu for namedroppers@ops.ietf.org; Wed, 30 Jul 2008 22:12:53 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id E7DD84B452; Wed, 30 Jul 2008 22:13:06 +0200 (CEST) Date: Wed, 30 Jul 2008 22:13:06 +0200 From: bert hubert To: Jelte Jansen Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: XQID (Re: Forgery Resistance phase #2 ) Message-ID: <20080730201306.GA5206@outpost.ds9a.nl> References: <200807281555.m6SFsxAO021711@stora.ogud.com> <027b01c8f17e$f99b0a80$ecd11f80$@com> <1135.1217352731@nsa.vix.com> <4890AE49.7040006@NLnetLabs.nl> <71458.1217444406@nsa.vix.com> <4890C0E3.406@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4890C0E3.406@NLnetLabs.nl> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jul 30, 2008 at 09:28:35PM +0200, Jelte Jansen wrote: > 1. Do all recursive servers even have access to enough entropy? This > might not be a problem at all, or extra entropy could be arranged for > busy ones, but it might be worth thinking about in advance. For that I discussed this with Amit Klein, who I think can rightfully claim to be an expert on DNS randomness, and he doesn't think it is a problem. He suggests using block or streamcipher based pseudo-random generator, seeded using 'real random'. Even if all excreted pseudo-random is observed from that point onward, reverse engineering the state of the pseudo-random generator is equivalent to breaking the cipher it uses, based on an unknown plaintext (the truly random seed that is being encrypted over and over). Amit does suggest rekeying every once in a while since AES performed by software on known hardware leaks a tiny bit of information in the time it takes to encrypt a block. This last technique was discovered by Dan J. Bernstein btw. Odd that :-) Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 30 13:48:46 2008 Return-Path: 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 512BF3A69CF; Wed, 30 Jul 2008 13:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 ss8nJ9OeY9G4; Wed, 30 Jul 2008 13:48:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 02AF53A69DB; Wed, 30 Jul 2008 13:48:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOIVc-000Kvf-Rv for namedroppers-data@psg.com; Wed, 30 Jul 2008 20:42:56 +0000 Received: from [65.201.175.9] (helo=cliffie.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOIVY-000Kv6-SZ for namedroppers@ops.ietf.org; Wed, 30 Jul 2008 20:42:55 +0000 Received: from [10.0.1.2] (unknown [130.129.65.164]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cliffie.verisignlabs.com (Postfix) with ESMTP id ADFA813675F for ; Wed, 30 Jul 2008 16:42:51 -0400 (EDT) Message-Id: From: "Blacka, David" To: IETF DNSEXT WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Proposed addition to dnssec-bis-updated: CD bit Date: Wed, 30 Jul 2008 21:42:50 +0100 X-Mailer: Apple Mail (2.926) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Folks, Here is another bit for the dnssec-bis-updates draft that appears to have fallen through the cracks. It is unclear, however, that this addition has any sort of consensus, so a positive acknowledgement that this text is OK would be nice. Here is the proposed addition: 3.7. Setting the CD bit on Requests When processing a request with the CD bit set, the resolver MUST set the CD bit on its upstream queries. Any comments? -- David Blacka Sr. Engineer Platform Product Development -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 30 13:50:00 2008 Return-Path: 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 46AEC3A69CF; Wed, 30 Jul 2008 13:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 fItNn5kUAmQP; Wed, 30 Jul 2008 13:49:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 846CA3A686C; Wed, 30 Jul 2008 13:49:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOISn-000KWi-QN for namedroppers-data@psg.com; Wed, 30 Jul 2008 20:40:01 +0000 Received: from [65.201.175.9] (helo=cliffie.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOISe-000KVi-Ca for namedroppers@ops.ietf.org; Wed, 30 Jul 2008 20:39:57 +0000 Received: from [10.0.1.2] (unknown [130.129.65.164]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cliffie.verisignlabs.com (Postfix) with ESMTP id B31C413675F for ; Wed, 30 Jul 2008 16:39:50 -0400 (EDT) Message-Id: From: "Blacka, David" To: IETF DNSEXT WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Proposed addition for dnssec-bis-updates: AD bit Date: Wed, 30 Jul 2008 21:39:49 +0100 X-Mailer: Apple Mail (2.926) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Folks, Looking at the dnssec-bis-updates presentation from the DNSEXT meeting in Philadelphia, it was apparent that a few bits had fallen through the cracks between then and now. This is one of them. Anyway, here is the proposed additional text: 3.6. Setting the AD bit on Replies Section 3.2.3 of [RFC4035] describes under which conditions a validating resolver should set or clear the AD bit in a response. In order to protect legacy stub resolvers and middleboxes, validating resolvers SHOULD only set the AD bit when a response both meets the conditions listed in RFC 4035, section 3.2.3, and the request contained either a set DO bit or a set AD bit. Note that the use of the AD bit in the query was previously undefined. This document defines it as a signal indicating that the requester understands and is interested in the value of the AD bit in the response. This allows a requestor to indicate that it understands the AD bit without also requesting DNSSEC data via the DO bit. Any comments? -- David Blacka Sr. Engineer Platform Product Development -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 30 21:07:48 2008 Return-Path: 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 9CA7A3A69BA; Wed, 30 Jul 2008 21:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 asUADLKi4f8s; Wed, 30 Jul 2008 21:07:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6C8963A68CF; Wed, 30 Jul 2008 21:07:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOPIB-000BEC-GQ for namedroppers-data@psg.com; Thu, 31 Jul 2008 03:57:31 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOPHy-000BCb-86 for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 03:57:25 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 70AD533C1E; Thu, 31 Jul 2008 04:57:15 +0100 (BST) Message-ID: <4891381B.1070400@links.org> Date: Thu, 31 Jul 2008 04:57:15 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Masataka Ohta CC: Roy Arends , namedroppers@ops.ietf.org, Alessandro.Linari@nominet.org.uk Subject: Re: increasing DNS message entropy, a solution for NATs References: <488517CE.6060404@necom830.hpcl.titech.ac.jp> In-Reply-To: <488517CE.6060404@necom830.hpcl.titech.ac.jp> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Masataka Ohta wrote: > What? Resolvers behind NAT/PAT are directly talking to authoritative > servers? Why not? And on the question of NAT randomness: http://www.links.org/?p=352. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 30 21:12:00 2008 Return-Path: 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 416DA3A6A4E; Wed, 30 Jul 2008 21:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 al7ExWplUIUo; Wed, 30 Jul 2008 21:11:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 73E323A6889; Wed, 30 Jul 2008 21:11:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOPPl-000Bso-E2 for namedroppers-data@psg.com; Thu, 31 Jul 2008 04:05:21 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOPPF-000BoM-Qb for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 04:04:51 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 4C59433C1C; Thu, 31 Jul 2008 05:04:48 +0100 (BST) Message-ID: <489139E0.8010305@links.org> Date: Thu, 31 Jul 2008 05:04:48 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: bert hubert CC: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 References: <48935.1216753200@nsa.vix.com> <20080722193755.GA14820@outpost.ds9a.nl> In-Reply-To: <20080722193755.GA14820@outpost.ds9a.nl> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: bert hubert wrote: > On Tue, Jul 22, 2008 at 07:00:00PM +0000, Paul Vixie wrote: >> please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 as a >> working group document. note that this technique was told to me by david > > I've been a bit quiet on this front - despite implementing dns0x20 myself. > > dns0x20 does not add any entropy to queries involving domains with no alphabetical characters in them. > > Like . > > And it is exactly this . that is the grand prize. I've got this great idea ... why not sign . ? -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Wed Jul 30 21:35:09 2008 Return-Path: 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 96E9B3A6C1D; Wed, 30 Jul 2008 21:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] 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 DOCIbLmAsRzb; Wed, 30 Jul 2008 21:35:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 124DA3A67AF; Wed, 30 Jul 2008 21:35:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOPns-000EEV-Kf for namedroppers-data@psg.com; Thu, 31 Jul 2008 04:30:16 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOPnn-000EDt-RO for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 04:30:14 +0000 Received: (qmail 22611 invoked from network); 31 Jul 2008 05:16:28 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 31 Jul 2008 05:16:28 -0000 Message-ID: <48913FA1.5010501@necom830.hpcl.titech.ac.jp> Date: Thu, 31 Jul 2008 13:29:21 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Ben Laurie CC: Roy Arends , namedroppers@ops.ietf.org, Alessandro.Linari@nominet.org.uk Subject: Re: increasing DNS message entropy, a solution for NATs References: <488517CE.6060404@necom830.hpcl.titech.ac.jp> <4891381B.1070400@links.org> In-Reply-To: <4891381B.1070400@links.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ben Laurie wrote: >> What? Resolvers behind NAT/PAT are directly talking to authoritative >> servers? > Why not? Because various NAT/PAT gateways put all the possible and impossible modificaitons on certain, including DNS, packets that there is virtually no directness expected. > And on the question of NAT randomness: http://www.links.org/?p=352. That is one, among so many, example of indirectness of NAT. Masataka Ohta -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 00:25:21 2008 Return-Path: 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 DA7FB28C0E6; Thu, 31 Jul 2008 00:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 Pl090EcjhEPR; Thu, 31 Jul 2008 00:25:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 080E43A6C21; Thu, 31 Jul 2008 00:25:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOSQk-000428-OH for namedroppers-data@psg.com; Thu, 31 Jul 2008 07:18:34 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOSQh-00041O-7V for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 07:18:33 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id AF947C2DA3; Thu, 31 Jul 2008 08:18:25 +0100 (BST) Date: Thu, 31 Jul 2008 08:18:23 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Masataka Ohta , Ben Laurie cc: Roy Arends , namedroppers@ops.ietf.org, Alessandro.Linari@nominet.org.uk, Alex Bligh Subject: Re: increasing DNS message entropy, a solution for NATs Message-ID: In-Reply-To: <48913FA1.5010501@necom830.hpcl.titech.ac.jp> References: <488517CE.6060404@necom830.hpcl.titech.ac.jp> <4891381B.1070400@links.org> <48913FA1.5010501@necom830.hpcl.titech.ac.jp> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 31 July 2008 13:29:21 +0900 Masataka Ohta wrote: > Because various NAT/PAT gateways put all the possible and impossible > modificaitons on certain, including DNS, packets that there is virtually > no directness expected. I am guessing this is a very common SoHo configuration though. Alex -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 01:00:46 2008 Return-Path: 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 483EF28C22D; Thu, 31 Jul 2008 01:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 ZpR9p0sbwyve; Thu, 31 Jul 2008 01:00:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6492B28C1F4; Thu, 31 Jul 2008 01:00:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOT0L-0008lQ-Iy for namedroppers-data@psg.com; Thu, 31 Jul 2008 07:55:21 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOT0H-0008kO-TA for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 07:55:19 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id BEAACFF26C for ; Thu, 31 Jul 2008 17:55:20 +1000 (EST) Message-ID: <48916FCA.3040402@e164.org> Date: Thu, 31 Jul 2008 17:54:50 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs References: <488517CE.6060404@necom830.hpcl.titech.ac.jp> <4891381B.1070400@links.org> <48913FA1.5010501@necom830.hpcl.titech.ac.jp> In-Reply-To: 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: Alex Bligh wrote: >> Because various NAT/PAT gateways put all the possible and impossible >> modificaitons on certain, including DNS, packets that there is virtually >> no directness expected. > > I am guessing this is a very common SoHo configuration though. Has anyone stopped to ask how much effort/emphasis should really be spent trying to protect end users? People perpetrating attacks on the internet still pay attention to the principals of economics, that is getting the most benefit from the least amount of work. For what it's worth, I think the real focus here should be ISP resolvers, not home users. Not to mention this should be a simpler problem to solve for a number of reasons. It seems to me that there is an excessive amount of attention being paid to protect what is potentially 1 machine in most cases. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 01:23:16 2008 Return-Path: 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 4A58B3A6B64; Thu, 31 Jul 2008 01:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 fDtKaj+-Ekh5; Thu, 31 Jul 2008 01:23:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 65B3B3A6A89; Thu, 31 Jul 2008 01:23:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTM0-000Bb8-1G for namedroppers-data@psg.com; Thu, 31 Jul 2008 08:17:44 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTLw-000BaL-4R for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 08:17:42 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id C4F0433C26; Thu, 31 Jul 2008 09:17:37 +0100 (BST) Message-ID: <48917522.4040200@links.org> Date: Thu, 31 Jul 2008 09:17:38 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Alex Bligh CC: Masataka Ohta , Roy Arends , namedroppers@ops.ietf.org, Alessandro.Linari@nominet.org.uk Subject: Re: increasing DNS message entropy, a solution for NATs References: <488517CE.6060404@necom830.hpcl.titech.ac.jp> <4891381B.1070400@links.org> <48913FA1.5010501@necom830.hpcl.titech.ac.jp> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Alex Bligh wrote: > > > --On 31 July 2008 13:29:21 +0900 Masataka Ohta > wrote: > >> Because various NAT/PAT gateways put all the possible and impossible >> modificaitons on certain, including DNS, packets that there is virtually >> no directness expected. > > I am guessing this is a very common SoHo configuration though. Given the difficulty of getting IPv4 address space these days, it's pretty common full stop. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 01:23:56 2008 Return-Path: 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 716ED3A6B0D; Thu, 31 Jul 2008 01:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 Z6QrbxgrEXZo; Thu, 31 Jul 2008 01:23:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 94BC73A6B55; Thu, 31 Jul 2008 01:23:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTNW-000BpV-R2 for namedroppers-data@psg.com; Thu, 31 Jul 2008 08:19:18 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTNB-000BlS-W3 for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 08:19:00 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 8BD9E33C1E; Thu, 31 Jul 2008 09:18:56 +0100 (BST) Message-ID: <48917571.3030402@links.org> Date: Thu, 31 Jul 2008 09:18:57 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Masataka Ohta CC: Roy Arends , namedroppers@ops.ietf.org, Alessandro.Linari@nominet.org.uk Subject: Re: increasing DNS message entropy, a solution for NATs References: <488517CE.6060404@necom830.hpcl.titech.ac.jp> <4891381B.1070400@links.org> <48913FA1.5010501@necom830.hpcl.titech.ac.jp> In-Reply-To: <48913FA1.5010501@necom830.hpcl.titech.ac.jp> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Masataka Ohta wrote: > Ben Laurie wrote: > >>> What? Resolvers behind NAT/PAT are directly talking to authoritative >>> servers? > >> Why not? > > Because various NAT/PAT gateways put all the possible and impossible > modificaitons on certain, including DNS, packets that there is virtually > no directness expected. I can't really parse this. What do you mean by "directness"? And what possible/impossible modifications to NAT/PAT gateways make to packets? >> And on the question of NAT randomness: http://www.links.org/?p=352. > > That is one, among so many, example of indirectness of NAT. Source port modification, you mean? -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 01:24:22 2008 Return-Path: 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 76E783A6B0D; Thu, 31 Jul 2008 01:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 dbhZqa3vN1+1; Thu, 31 Jul 2008 01:24:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2BA703A6A82; Thu, 31 Jul 2008 01:24:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTOA-000BvE-K3 for namedroppers-data@psg.com; Thu, 31 Jul 2008 08:19:58 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTO7-000BuM-0i for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 08:19:56 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 931F133C46; Thu, 31 Jul 2008 09:19:53 +0100 (BST) Message-ID: <489175AA.2050403@links.org> Date: Thu, 31 Jul 2008 09:19:54 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Duane CC: namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs References: <488517CE.6060404@necom830.hpcl.titech.ac.jp> <4891381B.1070400@links.org> <48913FA1.5010501@necom830.hpcl.titech.ac.jp> <48916FCA.3040402@e164.org> In-Reply-To: <48916FCA.3040402@e164.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Duane wrote: > Alex Bligh wrote: > >>> Because various NAT/PAT gateways put all the possible and impossible >>> modificaitons on certain, including DNS, packets that there is virtually >>> no directness expected. >> I am guessing this is a very common SoHo configuration though. > > Has anyone stopped to ask how much effort/emphasis should really be > spent trying to protect end users? > > People perpetrating attacks on the internet still pay attention to the > principals of economics, that is getting the most benefit from the least > amount of work. > > For what it's worth, I think the real focus here should be ISP > resolvers, not home users. Not to mention this should be a simpler > problem to solve for a number of reasons. > > It seems to me that there is an excessive amount of attention being paid > to protect what is potentially 1 machine in most cases. This problem does not only affect home users. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 01:31:21 2008 Return-Path: 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 7C11B3A67EC; Thu, 31 Jul 2008 01:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.124 X-Spam-Level: X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[AWL=-0.629, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 2NTniXvLuvFE; Thu, 31 Jul 2008 01:31:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9F18A3A6780; Thu, 31 Jul 2008 01:31:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTUk-000CtQ-0v for namedroppers-data@psg.com; Thu, 31 Jul 2008 08:26:46 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTUf-000Cmj-Ev for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 08:26:44 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id A3516FF26C; Thu, 31 Jul 2008 18:25:58 +1000 (EST) Message-ID: <489176FA.90406@e164.org> Date: Thu, 31 Jul 2008 18:25:30 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Ben Laurie CC: namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs References: <488517CE.6060404@necom830.hpcl.titech.ac.jp> <4891381B.1070400@links.org> <48913FA1.5010501@necom830.hpcl.titech.ac.jp> <48916FCA.3040402@e164.org> <489175AA.2050403@links.org> In-Reply-To: <489175AA.2050403@links.org> 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: Ben Laurie wrote: > This problem does not only affect home users. Lets face it, most people that would/will be effected won't upgrade their routers, so that's already a lost cause, anyone that does upgrade their NAT solution should do a better job of it and it's not really a DNS issue. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 01:43:32 2008 Return-Path: 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 CA84B3A69D8; Thu, 31 Jul 2008 01:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.061 X-Spam-Level: X-Spam-Status: No, score=-1.061 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 UqNNiOGrMapv; Thu, 31 Jul 2008 01:43:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EBF333A69CA; Thu, 31 Jul 2008 01:43:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTg5-000EWJ-Gc for namedroppers-data@psg.com; Thu, 31 Jul 2008 08:38:29 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTg2-000EVa-5c for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 08:38:27 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id E261BFF26C; Thu, 31 Jul 2008 18:38:28 +1000 (EST) Message-ID: <489179E8.3070106@e164.org> Date: Thu, 31 Jul 2008 18:38:00 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Ben Laurie CC: namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs References: <488517CE.6060404@necom830.hpcl.titech.ac.jp> <4891381B.1070400@links.org> <48913FA1.5010501@necom830.hpcl.titech.ac.jp> <48916FCA.3040402@e164.org> <489175AA.2050403@links.org> <489176FA.90406@e164.org> <489178A3.404@links.org> In-Reply-To: <489178A3.404@links.org> 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: Ben Laurie wrote: > Duane wrote: >> Ben Laurie wrote: >> >>> This problem does not only affect home users. >> >> Lets face it, most people that would/will be effected won't upgrade >> their routers, so that's already a lost cause, anyone that does upgrade >> their NAT solution should do a better job of it and it's not really a >> DNS issue. > > Then why are we discussing it? Beats me, everyone seems rather concerned over an issue that no one could fix if they wanted to in any case. That isn't to say that someone shouldn't be doing in terms of getting NAT better for in future, but existing deployments by and large are never going to be upgraded until new hardware is purchased. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 01:45:09 2008 Return-Path: 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 7C6333A6807; Thu, 31 Jul 2008 01:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 cGeX1lrn4pCw; Thu, 31 Jul 2008 01:45:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2FFAC3A698B; Thu, 31 Jul 2008 01:45:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTbI-000Dp2-Q9 for namedroppers-data@psg.com; Thu, 31 Jul 2008 08:33:32 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTb9-000Dhm-Np for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 08:33:30 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 4394733C1C; Thu, 31 Jul 2008 09:32:34 +0100 (BST) Message-ID: <489178A3.404@links.org> Date: Thu, 31 Jul 2008 09:32:35 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Duane CC: namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs References: <488517CE.6060404@necom830.hpcl.titech.ac.jp> <4891381B.1070400@links.org> <48913FA1.5010501@necom830.hpcl.titech.ac.jp> <48916FCA.3040402@e164.org> <489175AA.2050403@links.org> <489176FA.90406@e164.org> In-Reply-To: <489176FA.90406@e164.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Duane wrote: > Ben Laurie wrote: > >> This problem does not only affect home users. > > Lets face it, most people that would/will be effected won't upgrade > their routers, so that's already a lost cause, anyone that does upgrade > their NAT solution should do a better job of it and it's not really a > DNS issue. Then why are we discussing it? -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 01:51:00 2008 Return-Path: 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 C781E3A6780; Thu, 31 Jul 2008 01:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.01 X-Spam-Level: X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 6VDs+OHgVzNn; Thu, 31 Jul 2008 01:50:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 038913A67EC; Thu, 31 Jul 2008 01:50:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTm3-000FG6-My for namedroppers-data@psg.com; Thu, 31 Jul 2008 08:44:39 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTm0-000FFQ-8F for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 08:44:37 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 0D644FF26C; Thu, 31 Jul 2008 18:44:38 +1000 (EST) Message-ID: <48917B59.6090209@e164.org> Date: Thu, 31 Jul 2008 18:44:09 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Ben Laurie CC: namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs References: <488517CE.6060404@necom830.hpcl.titech.ac.jp> <4891381B.1070400@links.org> <48913FA1.5010501@necom830.hpcl.titech.ac.jp> <48916FCA.3040402@e164.org> <489175AA.2050403@links.org> <489176FA.90406@e164.org> <489178A3.404@links.org> <489179E8.3070106@e164.org> <48917AD3.5080200@links.org> In-Reply-To: <48917AD3.5080200@links.org> 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: Ben Laurie wrote: >> Beats me, everyone seems rather concerned over an issue that no one >> could fix if they wanted to in any case. That isn't to say that someone >> shouldn't be doing in terms of getting NAT better for in future, but >> existing deployments by and large are never going to be upgraded until >> new hardware is purchased. > > Whether that's true or not, isn't it a good idea that the new hardware > actually does the right thing? I already suggested that, but apparently NAT needs to be fixed as much as DNS in new hardware. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 01:52:31 2008 Return-Path: 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 0CEE73A6A82; Thu, 31 Jul 2008 01:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 zQxUs6GpvyUW; Thu, 31 Jul 2008 01:52:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 77E253A67EC; Thu, 31 Jul 2008 01:52:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTjT-000Eyl-FS for namedroppers-data@psg.com; Thu, 31 Jul 2008 08:41:59 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTjP-000Ey3-Py for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 08:41:57 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 4330F33C1E; Thu, 31 Jul 2008 09:41:54 +0100 (BST) Message-ID: <48917AD3.5080200@links.org> Date: Thu, 31 Jul 2008 09:41:55 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Duane CC: namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs References: <488517CE.6060404@necom830.hpcl.titech.ac.jp> <4891381B.1070400@links.org> <48913FA1.5010501@necom830.hpcl.titech.ac.jp> <48916FCA.3040402@e164.org> <489175AA.2050403@links.org> <489176FA.90406@e164.org> <489178A3.404@links.org> <489179E8.3070106@e164.org> In-Reply-To: <489179E8.3070106@e164.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Duane wrote: > Ben Laurie wrote: >> Duane wrote: >>> Ben Laurie wrote: >>> >>>> This problem does not only affect home users. >>> Lets face it, most people that would/will be effected won't upgrade >>> their routers, so that's already a lost cause, anyone that does upgrade >>> their NAT solution should do a better job of it and it's not really a >>> DNS issue. >> Then why are we discussing it? > > Beats me, everyone seems rather concerned over an issue that no one > could fix if they wanted to in any case. That isn't to say that someone > shouldn't be doing in terms of getting NAT better for in future, but > existing deployments by and large are never going to be upgraded until > new hardware is purchased. Whether that's true or not, isn't it a good idea that the new hardware actually does the right thing? -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 01:56:45 2008 Return-Path: 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 067E03A6855; Thu, 31 Jul 2008 01:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 fjJG80uSIzFv; Thu, 31 Jul 2008 01:56:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BD7F33A6804; Thu, 31 Jul 2008 01:56:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTsT-000GAR-AO for namedroppers-data@psg.com; Thu, 31 Jul 2008 08:51:17 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTsP-000G9L-Cp for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 08:51:15 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 9C63A33C1E; Thu, 31 Jul 2008 09:51:09 +0100 (BST) Message-ID: <48917CFE.1030206@links.org> Date: Thu, 31 Jul 2008 09:51:10 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Duane CC: namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs References: <488517CE.6060404@necom830.hpcl.titech.ac.jp> <4891381B.1070400@links.org> <48913FA1.5010501@necom830.hpcl.titech.ac.jp> <48916FCA.3040402@e164.org> <489175AA.2050403@links.org> <489176FA.90406@e164.org> <489178A3.404@links.org> <489179E8.3070106@e164.org> <48917AD3.5080200@links.org> <48917B59.6090209@e164.org> In-Reply-To: <48917B59.6090209@e164.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Duane wrote: > Ben Laurie wrote: > >>> Beats me, everyone seems rather concerned over an issue that no one >>> could fix if they wanted to in any case. That isn't to say that someone >>> shouldn't be doing in terms of getting NAT better for in future, but >>> existing deployments by and large are never going to be upgraded until >>> new hardware is purchased. >> Whether that's true or not, isn't it a good idea that the new hardware >> actually does the right thing? > > I already suggested that, but apparently NAT needs to be fixed as much > as DNS in new hardware. Exactly. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 02:01:44 2008 Return-Path: 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 7F8883A6A24; Thu, 31 Jul 2008 02:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.42 X-Spam-Level: X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 vAV+5sC5+5nz; Thu, 31 Jul 2008 02:01:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A89AC3A6804; Thu, 31 Jul 2008 02:01:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTvh-000GcA-O5 for namedroppers-data@psg.com; Thu, 31 Jul 2008 08:54:37 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTve-000GbW-A0 for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 08:54:35 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 038DDC2DA3; Thu, 31 Jul 2008 09:54:29 +0100 (BST) Date: Thu, 31 Jul 2008 09:54:27 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Duane , Ben Laurie cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: increasing DNS message entropy, a solution for NATs Message-ID: <9166990207B2C79815D1392E@Ximines.local> In-Reply-To: <489176FA.90406@e164.org> References: <488517CE.6060404@necom830.hpcl.titech.ac.jp> <4891381B.1070400@links.org> <48913FA1.5010501@necom830.hpcl.titech.ac.jp> <48916FCA.3040402@e164.org> <489175AA.2050403@links.org> <489176FA.90406@e164.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 31 July 2008 18:25:30 +1000 Duane wrote: > Lets face it, most people that would/will be effected won't upgrade > their routers, so that's already a lost cause, anyone that does upgrade > their NAT solution should do a better job of it and it's not really a > DNS issue. I am guessing the half-life of ADSL equipment is less than 3 years. Alex -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 02:02:21 2008 Return-Path: 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 4746B3A6885; Thu, 31 Jul 2008 02:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.967 X-Spam-Level: X-Spam-Status: No, score=-0.967 tagged_above=-999 required=5 tests=[AWL=-0.472, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 sPsNt18pmZvU; Thu, 31 Jul 2008 02:02:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5EEF33A6A13; Thu, 31 Jul 2008 02:02:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTwD-000Gip-AS for namedroppers-data@psg.com; Thu, 31 Jul 2008 08:55:09 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOTw9-000GgW-6y for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 08:55:06 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id D5130FF26C; Thu, 31 Jul 2008 18:55:03 +1000 (EST) Message-ID: <48917DC8.7070004@e164.org> Date: Thu, 31 Jul 2008 18:54:32 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Ben Laurie CC: namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs References: <488517CE.6060404@necom830.hpcl.titech.ac.jp> <4891381B.1070400@links.org> <48913FA1.5010501@necom830.hpcl.titech.ac.jp> <48916FCA.3040402@e164.org> <489175AA.2050403@links.org> <489176FA.90406@e164.org> <489178A3.404@links.org> <489179E8.3070106@e164.org> <48917AD3.5080200@links.org> <48917B59.6090209@e164.org> <48917CFE.1030206@links.org> In-Reply-To: <48917CFE.1030206@links.org> 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: Ben Laurie wrote: > Duane wrote: >> Ben Laurie wrote: >> >>>> Beats me, everyone seems rather concerned over an issue that no one >>>> could fix if they wanted to in any case. That isn't to say that someone >>>> shouldn't be doing in terms of getting NAT better for in future, but >>>> existing deployments by and large are never going to be upgraded until >>>> new hardware is purchased. >>> Whether that's true or not, isn't it a good idea that the new hardware >>> actually does the right thing? >> >> I already suggested that, but apparently NAT needs to be fixed as much >> as DNS in new hardware. > > Exactly. Ok, so problem solved as far as I can see, someone just needs to tell hardware companies to fix NAT + DNS and that's that. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 02:16:48 2008 Return-Path: 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 93E553A6A1C; Thu, 31 Jul 2008 02:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 CrLkORegEqm5; Thu, 31 Jul 2008 02:16:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 81A103A6855; Thu, 31 Jul 2008 02:16:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOUCI-000Iy7-HY for namedroppers-data@psg.com; Thu, 31 Jul 2008 09:11:46 +0000 Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOUCC-000IxC-4I for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 09:11:42 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KOUC8-0008Je-Gy for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 11:11:36 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id C31864B47D; Thu, 31 Jul 2008 11:11:50 +0200 (CEST) Date: Thu, 31 Jul 2008 11:11:50 +0200 From: bert hubert To: Alex Bligh Cc: Duane , Ben Laurie , namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs Message-ID: <20080731091150.GA19184@outpost.ds9a.nl> References: <488517CE.6060404@necom830.hpcl.titech.ac.jp> <4891381B.1070400@links.org> <48913FA1.5010501@necom830.hpcl.titech.ac.jp> <48916FCA.3040402@e164.org> <489175AA.2050403@links.org> <489176FA.90406@e164.org> <9166990207B2C79815D1392E@Ximines.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9166990207B2C79815D1392E@Ximines.local> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jul 31, 2008 at 09:54:27AM +0100, Alex Bligh wrote: > >Lets face it, most people that would/will be effected won't upgrade > >their routers, so that's already a lost cause, anyone that does upgrade > >their NAT solution should do a better job of it and it's not really a > >DNS issue. > > I am guessing the half-life of ADSL equipment is less than 3 years. While that may be true, the level of fail is showing no similar signs however.. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 02:16:51 2008 Return-Path: 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 49DF43A6A1C; Thu, 31 Jul 2008 02:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=-1.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 CH5OXq+3pqpT; Thu, 31 Jul 2008 02:16:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 157E43A6855; Thu, 31 Jul 2008 02:16:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOUDW-000J8g-Qe for namedroppers-data@psg.com; Thu, 31 Jul 2008 09:13:02 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOUDR-000J7n-Qg for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 09:12:59 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:To:Cc:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=UOYb1A1mLgTV7GZCW+JSq+Sx2DaJzttbmVbZR5bdEVR6nvotSkyWzd4B d3ORhl/8Z+2mXUxEAQwM7Lfbe4TvXB9ZxuF/t2dcp7mtoyPot0uALqfRe v8g/seTh7B0dCJh; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1217495577; x=1249031577; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20incre asing=20DNS=20message=20entropy,=20a=20solution=20for=20N ATs|Date:=20Thu,=2031=20Jul=202008=2010:12:56=20+0100 |Message-ID:=20|To:=20Alex=20Bligh=20|Cc:=20namedroppers@ops.ietf.org |MIME-Version:=201.0|In-Reply-To:=20<9166990207B2C79815D1 392E@Ximines.local>; bh=KbsF9P14YCyNkwczsZyFn4L4wfL9maZEltSDjorTie4=; b=TC7kS0f+Ym6RLHrFKKUpEVxJBldFQ61t0wN8srrFlAHrMbUCQRKmjo1l K5Uthd+hjJ3fgFL8JiQgoh/eG47WoZJATZVVAXdLHWtaPTXcaf6kf9ejM AmB6zo9NFokzIIp; X-IronPort-AV: E=Sophos;i="4.31,285,1215385200"; d="scan'208";a="5610239" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 31 Jul 2008 10:12:56 +0100 In-Reply-To: <9166990207B2C79815D1392E@Ximines.local> To: Alex Bligh Cc: namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 31 Jul 2008 10:12:56 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 31/07/2008 10:12:56 AM, Serialize complete at 31/07/2008 10:12:56 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > I am guessing the half-life of ADSL equipment is less than 3 years. Unfortunately for many manufacturers the half-life of firmware updates is the same :( Ray -- Ray Bellis, MA(Oxon) Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 02:27:40 2008 Return-Path: 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 D73E83A6A7B; Thu, 31 Jul 2008 02:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.223 X-Spam-Level: X-Spam-Status: No, score=0.223 tagged_above=-999 required=5 tests=[AWL=-0.727, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, RDNS_NONE=0.1] 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 Mk5Qy4BI0mlr; Thu, 31 Jul 2008 02:27:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E30F63A6989; Thu, 31 Jul 2008 02:27:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOUMa-000KNq-Nu for namedroppers-data@psg.com; Thu, 31 Jul 2008 09:22:24 +0000 Received: from [193.176.144.134] (helo=gw.sidn.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOUMW-000KN6-F8 for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 09:22:22 +0000 Received: by localhost.sidn.nl (TUNIX/Firewall Mail Server) with ESMTP id CD4CE3AEE6 for ; Thu, 31 Jul 2008 11:22:18 +0200 (CEST) Received: by gw.sidn.nl (TUNIX/Firewall Mail Server) with ESMTP for ; Thu, 31 Jul 2008 11:22:18 +0200 (CEST) Received: from [192.168.11.151] ([192.168.11.151]) by sidn.nl with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jul 2008 11:22:18 +0200 Date: Thu, 31 Jul 2008 11:22:03 +0200 (CEST) From: Antoin Verschuren X-X-Sender: sidn@walhalla.antoin.nl To: Alex Bligh cc: namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs In-Reply-To: <9166990207B2C79815D1392E@Ximines.local> Message-ID: References: <488517CE.6060404@necom830.hpcl.titech.ac.jp> <4891381B.1070400@links.org> <48913FA1.5010501@necom830.hpcl.titech.ac.jp> <48916FCA.3040402@e164.org> <489175AA.2050403@links.org> <489176FA.90406@e164.org> <9166990207B2C79815D1392E@Ximines.local> User-Agent: Alpine 1.00 (DEB 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-OriginalArrivalTime: 31 Jul 2008 09:22:18.0368 (UTC) FILETIME=[EDAC2800:01C8F2EE] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, 31 Jul 2008, Alex Bligh wrote: >> Lets face it, most people that would/will be effected won't upgrade >> their routers, so that's already a lost cause, anyone that does upgrade >> their NAT solution should do a better job of it and it's not really a >> DNS issue. > > I am guessing the half-life of ADSL equipment is less than 3 years. But it can't hurt to educate the vendors so they do it right. I'f you're behind a NAT, like I am, and run a DNS server, like I do, and if you care enough to get it right, like I do, then you replace your cheap hardware with a proper one anyway. Let's get lists out of vendors that do it proper/inproper so the problem will go away. And must give you this thought: Being behind a NAT that passes through port randomness unaffected when there is no other traffic, other activity behind the NAT can even increase the randomness of the ports as nobody can "guess" the activity I'm going to do on my internal network. Antoin. -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 02:31:23 2008 Return-Path: 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 A985D3A6885; Thu, 31 Jul 2008 02:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.124 X-Spam-Level: X-Spam-Status: No, score=-4.124 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 ZDuthoXIxuqt; Thu, 31 Jul 2008 02:31:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B29EF3A67EC; Thu, 31 Jul 2008 02:31:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOUM8-000KIX-Sw for namedroppers-data@psg.com; Thu, 31 Jul 2008 09:21:56 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOUM4-000KHj-PM for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 09:21:54 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:To:Cc:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=L6AcIlfZL+uDTb3afQU9sB8zGMgLY7nWigw6LZJraJAOrYHjOILtQ5Np 5J+ryfaKCWPEFad+5n4XsWFtRiZ7wiaTXvL2Zw87wSrmacwZCepEM81Vp wnSHxNinbCudp3z; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1217496112; x=1249032112; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20incre asing=20DNS=20message=20entropy,=20a=20solution=20for=20N ATs|Date:=20Thu,=2031=20Jul=202008=2010:21:50=20+0100 |Message-ID:=20|To:=20Duane=20|Cc:=20namedroppers@ops.ietf.org|MIME-Version:=201. 0|In-Reply-To:=20<48917DC8.7070004@e164.org>; bh=93WyTZCsEY7EKF8RHmvk2N3XdmpPogSPw/EPjMN+XKI=; b=Uocvyz3yzKsUciCQOhV/kcfk62giGqkwDeULqD5DRv/K07h8ssr0bt+N j9fOAIAaOneTHRlQV0H8ETJ5u1/B3u3OoYdlFvSRr4B0Ex3cvC5ODVQdT ZSMjCES28LEwwI/; X-IronPort-AV: E=Sophos;i="4.31,285,1215385200"; d="scan'208";a="5610410" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 31 Jul 2008 10:21:51 +0100 In-Reply-To: <48917DC8.7070004@e164.org> To: Duane Cc: namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 31 Jul 2008 10:21:50 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 31/07/2008 10:21:50 AM, Serialize complete at 31/07/2008 10:21:50 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Ok, so problem solved as far as I can see, someone just needs to tell > hardware companies to fix NAT + DNS and that's that. Actually there's stacks of other stuff that the router manufacturers need to fix relating to DNS, particularly w.r.t the DNS proxies contained in most CPE: - tcp/53 support - currently almost non-existent - DNSSEC support - some mfrs block DNSSEC queries - EDNS0 - many DNS proxies can't do UDP fragment reassembly - open udp/53 ports on the WAN interface - probable "poor" PRNGs for port and QID selection (c.f. Ben's blog article) There's going to be a report published fairly soon containing the results of a joint study between myself and a US-based researcher detailing which routers have various deficiencies. Ray -- Ray Bellis, MA(Oxon) Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 02:55:40 2008 Return-Path: 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 66D303A69C6; Thu, 31 Jul 2008 02:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.931 X-Spam-Level: X-Spam-Status: No, score=-0.931 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 8AYhlAgCBsyk; Thu, 31 Jul 2008 02:55:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 84BF63A6807; Thu, 31 Jul 2008 02:55:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOUoW-000OLO-5x for namedroppers-data@psg.com; Thu, 31 Jul 2008 09:51:16 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOUoS-000OKh-MA for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 09:51:14 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 7639CFF26C; Thu, 31 Jul 2008 19:51:10 +1000 (EST) Message-ID: <48918AF4.9030309@e164.org> Date: Thu, 31 Jul 2008 19:50:44 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs References: <48917DC8.7070004@e164.org> <20080731094709.GA23362@vacation.karoshi.com.> In-Reply-To: <20080731094709.GA23362@vacation.karoshi.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: bmanning@vacation.karoshi.com wrote: > as long as your going to point fingers, jumbograms in general > get the short shrift. 4k UDP... 9k large frame... don't fit > nicely in a SoHo device. > > Make sure you use/refer to David Piscatellos excellent study of > firewalls. I'm surprised no one mentioned IPv6 since we're on this soap box. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 02:58:16 2008 Return-Path: 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 9771B3A6B11; Thu, 31 Jul 2008 02:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, 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 uf3udkhZHMJ9; Thu, 31 Jul 2008 02:58:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 882833A6885; Thu, 31 Jul 2008 02:58:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOUm2-000O0Z-5L for namedroppers-data@psg.com; Thu, 31 Jul 2008 09:48:42 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOUlx-000Nmf-LA for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 09:48:40 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m6V9l9up023378; Thu, 31 Jul 2008 09:47:10 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m6V9l9Yw023377; Thu, 31 Jul 2008 09:47:09 GMT Date: Thu, 31 Jul 2008 09:47:09 +0000 From: bmanning@vacation.karoshi.com To: Ray.Bellis@nominet.org.uk Cc: Duane , namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs Message-ID: <20080731094709.GA23362@vacation.karoshi.com.> References: <48917DC8.7070004@e164.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jul 31, 2008 at 10:21:50AM +0100, Ray.Bellis@nominet.org.uk wrote: > > Ok, so problem solved as far as I can see, someone just needs to tell > > hardware companies to fix NAT + DNS and that's that. > > Actually there's stacks of other stuff that the router manufacturers need > to fix relating to DNS, particularly w.r.t the DNS proxies contained in > most CPE: > > - tcp/53 support - currently almost non-existent > - DNSSEC support - some mfrs block DNSSEC queries > - EDNS0 - many DNS proxies can't do UDP fragment reassembly > - open udp/53 ports on the WAN interface > - probable "poor" PRNGs for port and QID selection (c.f. Ben's blog > article) > > There's going to be a report published fairly soon containing the results > of a joint study between myself and a US-based researcher detailing which > routers have various deficiencies. > > Ray > as long as your going to point fingers, jumbograms in general get the short shrift. 4k UDP... 9k large frame... don't fit nicely in a SoHo device. Make sure you use/refer to David Piscatellos excellent study of firewalls. --bill -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 03:11:51 2008 Return-Path: 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 6003B3A6B11; Thu, 31 Jul 2008 03:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 iNU6-qXaUy0Z; Thu, 31 Jul 2008 03:11:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7225C3A6AFF; Thu, 31 Jul 2008 03:11:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOV31-00009g-8W for namedroppers-data@psg.com; Thu, 31 Jul 2008 10:06:15 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOV2x-000094-4v for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 10:06:13 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=BjAfHRTkyq2qITTgXroxbcOCrA29TxsTq3PDBW5vLvQBaaDJ26RXnAVC JGqcXIfEu1lJMyqD2tLfx8RvhrVPlywL5pXJO55bdPMP29pq5YKO36FXw z67/dcbMBkUCEJk; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1217498771; x=1249034771; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20incre asing=20DNS=20message=20entropy,=20a=20solution=20for=20N ATs|Date:=20Thu,=2031=20Jul=202008=2011:06:08=20+0100 |Message-ID:=20|To:=20namedroppers@ops.i etf.org|MIME-Version:=201.0|In-Reply-To:=20<48918AF4.9030 309@e164.org>; bh=hwj2nJuEZR9vP1jtffWVQQTyZsnyW9bR8duLWVIuaY8=; b=zTHYYV1YQt+bLgxKkfCDPk6bCvRAdz6bMKWnOYqoQd8yNEkMfqCTBlV4 FqLyocHPEsggVFeUomCtBxAqQDGJsPi+CTUeuCXOFwYZYadZ7x0kW3ANf ilVUObgfsVS51wB; X-IronPort-AV: E=Sophos;i="4.31,285,1215385200"; d="scan'208";a="4498172" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 31 Jul 2008 11:06:09 +0100 In-Reply-To: <48918AF4.9030309@e164.org> To: namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 31 Jul 2008 11:06:08 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 31/07/2008 11:06:08 AM, Serialize complete at 31/07/2008 11:06:08 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > I'm surprised no one mentioned IPv6 since we're on this soap box. That would be nice, but AFAIK my own test environment (which uses rp-pppoe and pppd as a DSL BRAS) isn't capable of doing IPv6. Ray -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 03:33:45 2008 Return-Path: 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 3B42B3A6A38; Thu, 31 Jul 2008 03:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, 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 4td7lOitZXRQ; Thu, 31 Jul 2008 03:33:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 30A543A6AEB; Thu, 31 Jul 2008 03:33:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOVOA-00030n-7e for namedroppers-data@psg.com; Thu, 31 Jul 2008 10:28:06 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOVO4-0002ro-A5 for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 10:28:04 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m6VAQWup023652; Thu, 31 Jul 2008 10:26:32 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m6VAQWbx023651; Thu, 31 Jul 2008 10:26:32 GMT Date: Thu, 31 Jul 2008 10:26:32 +0000 From: bmanning@vacation.karoshi.com To: Duane Cc: bmanning@vacation.karoshi.com, Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs Message-ID: <20080731102632.GB23446@vacation.karoshi.com.> References: <48917DC8.7070004@e164.org> <20080731094709.GA23362@vacation.karoshi.com.> <48918AF4.9030309@e164.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48918AF4.9030309@e164.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jul 31, 2008 at 07:50:44PM +1000, Duane wrote: > bmanning@vacation.karoshi.com wrote: > > > as long as your going to point fingers, jumbograms in general > > get the short shrift. 4k UDP... 9k large frame... don't fit > > nicely in a SoHo device. > > > > Make sure you use/refer to David Piscatellos excellent study of > > firewalls. > > I'm surprised no one mentioned IPv6 since we're on this soap box. sorry about the indirect reference http://www.icann.org/committees/security/sac016.htm > Duane --bill -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 03:39:56 2008 Return-Path: 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 324BC3A6C37; Thu, 31 Jul 2008 03:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.223 X-Spam-Level: X-Spam-Status: No, score=-102.223 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 B1YZC2i3HjEc; Thu, 31 Jul 2008 03:39:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 80EA33A6809; Thu, 31 Jul 2008 03:39:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOVUq-0003z1-9i for namedroppers-data@psg.com; Thu, 31 Jul 2008 10:35:00 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOVUh-0003nh-TU for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 10:34:56 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m6VAXMup023710; Thu, 31 Jul 2008 10:33:22 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m6VAXMbi023709; Thu, 31 Jul 2008 10:33:22 GMT Date: Thu, 31 Jul 2008 10:33:22 +0000 From: bmanning@vacation.karoshi.com To: Ray.Bellis@nominet.org.uk Cc: namedroppers@ops.ietf.org Subject: Re: increasing DNS message entropy, a solution for NATs Message-ID: <20080731103322.GC23446@vacation.karoshi.com.> References: <48918AF4.9030309@e164.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jul 31, 2008 at 11:06:08AM +0100, Ray.Bellis@nominet.org.uk wrote: > > I'm surprised no one mentioned IPv6 since we're on this soap box. > > That would be nice, but AFAIK my own test environment (which uses rp-pppoe > and pppd as a DSL BRAS) isn't capable of doing IPv6. some folks have a hard time seeing boxen of that ilk as being routers. stripped down NAT, sure. > Ray so as long as you and your US researcher are clear that you are looking at "settop boxes" ... then I have no problems. but if you start building a punchlist of desired characteristics that are missing, then you'll be getting any number of feature requests. if one is after EDNS0 support, then dealing w/ UDP fragmentation will be an issue -unless- the device in question can handle 4k UDP frames. "rewriting" DNS queries will muck w/ DNSSEC signed data. etc.etc. good luck. --bill -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 04:53:46 2008 Return-Path: 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 46DFC3A6A79; Thu, 31 Jul 2008 04:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.431 X-Spam-Level: X-Spam-Status: No, score=-0.431 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 P0XGxxtmpt6m; Thu, 31 Jul 2008 04:53:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C59013A6BF2; Thu, 31 Jul 2008 04:53:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOWcp-000Cp9-4d for namedroppers-data@psg.com; Thu, 31 Jul 2008 11:47:19 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOWcd-000Cnt-Mx for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 11:47:09 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id D6AC9C2DAB; Thu, 31 Jul 2008 12:47:03 +0100 (BST) Date: Thu, 31 Jul 2008 12:47:00 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Antoin Verschuren cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: increasing DNS message entropy, a solution for NATs Message-ID: <4DF9D395F8348880AD9A6DEB@Ximines.local> In-Reply-To: References: <488517CE.6060404@necom830.hpcl.titech.ac.jp> <4891381B.1070400@links.org> <48913FA1.5010501@necom830.hpcl.titech.ac.jp> <48916FCA.3040402@e164.org> <489175AA.2050403@links.org> <489176FA.90406@e164.org> <9166990207B2C79815D1392E@Ximines.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 31 July 2008 11:22:03 +0200 Antoin Verschuren wrote: >> I am guessing the half-life of ADSL equipment is less than 3 years. > > But it can't hurt to educate the vendors so they do it right. Indeed that was my point. I am assuming end users never (or hardly ever) upgrade their firmware. Thus realistically speaking the only way to get non-broken NAT (or other DNS related features) into the ecosystem is to educate vendors and wait for the existing hardware base to churn. Alex -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 07:35:35 2008 Return-Path: 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 9F25E3A6923; Thu, 31 Jul 2008 07:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] 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 7Q3UhQKFxIRd; Thu, 31 Jul 2008 07:35:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AD3B83A67BD; Thu, 31 Jul 2008 07:35:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOZ8N-0007lh-AP for namedroppers-data@psg.com; Thu, 31 Jul 2008 14:28:03 +0000 Received: from [203.15.51.2] (helo=zinarktei.zerlargal.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOZ8J-0007kh-AY for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 14:28:01 +0000 Received: from zinarktei.client.uq.net.au ([203.15.51.2] helo=zinarktei.zerlargal.org) by zinarktei.zerlargal.org with esmtp (Exim 4.44) id 1KOZ8B-0005Wh-GE; Fri, 01 Aug 2008 00:27:52 +1000 Date: Fri, 1 Aug 2008 00:27:50 +1000 (EST) From: Bruce Campbell To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 In-Reply-To: <48935.1216753200@nsa.vix.com> Message-ID: References: <48935.1216753200@nsa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, 22 Jul 2008, Paul Vixie wrote: > please adopt http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20 as a > working group document. Yes, but with at least one change; section 5.4 implies that its a good idea to preserve the case of the original query in the reply from the resolver to the requesting application. This needs to be a 'MUST' to avoid any issues with existing application libraries which already have expectations of case preservation, ie: 5.4. Requestors MUST restore the case of the original question name after the successful verification of the 0x20 bits in the reply, before further decompression of the reply or forwarding onto a previous requestor in the chain. This is to ensure that verification of 0x20 bits by earlier requestors works as expected, and that any sections that use compression pointers which point into the question section are not contaminated by otherwise unexpected changes to 0x20 bits. During the dnsext discussion, there was the comment from marcos in the jabber room to the effect that the 0x20 draft does not mention any interactions with DNSSEC. This probably needs to be addressed in a 5.6. to the effect of 'A DNSSEC response shall be preferred over mismatches in the question section'. --==-- Bruce. -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 10:40:49 2008 Return-Path: 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 1C0223A68E0; Thu, 31 Jul 2008 10:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.115 X-Spam-Level: X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 HPdC3QrUhZvP; Thu, 31 Jul 2008 10:40:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 373C83A6892; Thu, 31 Jul 2008 10:40:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOc1E-00078w-5Z for namedroppers-data@psg.com; Thu, 31 Jul 2008 17:32:52 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOc19-00078T-Gk for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 17:32:50 +0000 Received: from commandprompt.com ([130.129.21.23]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m6VHZJ4j018897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 Jul 2008 10:35:22 -0700 Date: Thu, 31 Jul 2008 18:32:42 +0100 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Working Group Last Call for draft-ietf-dnsext-rfc2672bis-dname-14 Message-ID: <20080731173241.GB93159@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Thu, 31 Jul 2008 10:35:23 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, This message starts a four week working group last call for "Update to DNAME Redirection in the DNS". The latest draft, and the history of the document, can be found at . If approved, the document will obsolete RFC 2672. If approved, the document will update RFC 3363 and RFC 4294. Please read the document carefully. Please send any remarks you have about the draft to the working group mailing list. The document process rules for this working group require that five working group members state that they have read the document, and that there be consensus that the document be published as a standards track document with a target status of Proposed Standard. The last call ends at 2008-08-28 17:00 EDT. Best regards, Andrew (for the chairs) -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 11:55:18 2008 Return-Path: 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 D0C693A6A9C; Thu, 31 Jul 2008 11:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 qJrhT4WseqCy; Thu, 31 Jul 2008 11:55:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 05B9F28C1A5; Thu, 31 Jul 2008 11:55:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOdBQ-000GKR-HL for namedroppers-data@psg.com; Thu, 31 Jul 2008 18:47:28 +0000 Received: from [217.75.101.38] (helo=vic20.blipp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOdBM-000GJy-E3 for namedroppers@ops.ietf.org; Thu, 31 Jul 2008 18:47:26 +0000 Received: from [130.129.23.156] (randombot.meeting.ietf.org [130.129.23.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by vic20.blipp.com (Postfix) with ESMTPSA id 8C92EEF273 for ; Thu, 31 Jul 2008 20:47:22 +0200 (CEST) Message-Id: <2B760B19-5C02-456A-B4BF-C52A67C34432@blipp.com> From: Patrik Wallstrom To: namedroppers@ops.ietf.org Content-Type: multipart/signed; boundary=Apple-Mail-27-852147327; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v926) Subject: DNS-spoofing Date: Thu, 31 Jul 2008 20:47:12 +0200 X-Mailer: Apple Mail (2.926) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-27-852147327 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit John Dickinson demonstrated on the dnsext wg meeting today that you can spoof a local DNS reslover in 95ms. The resolver had a fixed source port. -- patrik_wallstrom->foodfight->pawal@blipp.com->+46-733173956 --Apple-Mail-27-852147327 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFMDCCBSww ggMUoAMCAQICAwQM8TANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNzA5MTcxODQyMThaFw0w OTA5MTYxODQyMThaMDoxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEeMBwGCSqGSIb3DQEJARYP cGF3YWxAYmxpcHAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoL+/YI9Nr8hW 9dOv+NNH3/Di3fJbVGIXnuLqgvobACCnXQefhbI8eqA+M5iHNBZGgT3bXcIjvLtmWQRBMeAQL8gQ 4PpKjxFuB5381IUEFmicfql/RmJlO/MOn3qqrAPgKJEOr0hKeNiygfotBaAJa9xtOdyaxihK8ymA lSBcdf0r47NcV9V1m1wrCbIvk3hHn7BcejWn+Hnvrb6CMjSyYapUVrjyq0bX+ZL7UVbs9rWE+GBy ow4Fuu57rv8E0Foqji7B3YsT4ygVyG7y7af2v7se1wxFi3LOooSl18S1lFcFtlse75l+28fkXrj8 oNnQ4f5xCLECHP6PHcbIMHmhqQIDAQABo4H7MIH4MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgEN BEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0 cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGC NwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYW aHR0cDovL29jc3AuY2FjZXJ0Lm9yZzAaBgNVHREEEzARgQ9wYXdhbEBibGlwcC5jb20wDQYJKoZI hvcNAQEFBQADggIBADRBbcU1cASsaHWOMzUFeU82tnDD1ti3TYpsbdBn4fm4Y0fal9mNld7byFv+ mRi1vGJnWuIUmCwDPF50ckpGsekOpaTt7oVV2BVYNdRUVeZcUMrvP+PiWsggjrQahUSVnpRrXsGp /L7NjEkhoR40AKB396WtVJYI4YJRqTgwQAqjuhNyaxiKe+5pYQ8obvAIY76fLsu4/LgLg5UZkM1y +Vh2+MyvFR9STe1aMv2fKwG0P/DFITgYAX5nN7rV4PUxSCsObzO2JSO+iYUaobdahtOylBjUFCxN aHpQkEnwGhaM+t55erdqERDdfTgKyCJr8v/MGgPM8H4mt+UWBZUUAS5Z1BsIlRR0HCdxsP0Ij56h Q21ErkcRm3TZKbO8KWLG7SIPbgYeSE3FnHQShbkZ1g+1++8Q1CYErOkSmFSHVcYxAtqqDNL2+wh3 19qnbC7H71GGs5lFYyJZuTAKKiHMbMOB3jqQcfxWUmhGeaHoMw+s1nqeOhdOm9MLqI4OGMARWeHy 19QFhxtRSREeJtLRgx2luQwOIUZEJF5mjOc8oJjZ3/nUMIPyKI04Do49z1Oi3WFjRZD/AZfLSnyH F7sEVVTNofu7px5yuOrBDvBDwLJKo68Lvf8TJR7iUc/ObmgxTJG+6c382PMd53CXHXuRe+W5H6OZ CJSbHkmn+ii0mIqZMYIDMzCCAy8CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMV aHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5 MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwQM8TAJBgUrDgMCGgUAoIIBhzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA3MzExODQ3MTJaMCMG CSqGSIb3DQEJBDEWBBTJD83/CNvpZyqneCjxerzkhiGYdjCBkQYJKwYBBAGCNxAEMYGDMIGAMHkx EDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UE AxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMEDPEwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMEDPEwDQYJKoZIhvcN AQEBBQAEggEAcy1FJMtJV223MyisTID3TcmTZZKLvb8uJFTctG0YDQpis9criH6OLsXxgki54N8C YxnTn57Muq0XmYi2fsxXf/5B2MjYqnqJ4yJlOjnpetTdkohQoE2+nVIKWXjYX4GRyRmM4bwwbeMK wQjvm/yNrIsVS9RBbeknOd2/YV/sYPCLA1TxWBMH90Hs1Ywx49WxRQoYObYE+lxRLy/nmtSmTXi/ Yx3q/G/bC7amB5oUBhS/qIQ2DrIyk3X2IoLQy+qvX92283XNS0Il678xY0Mf1gS63pP4jJzR2r7a tZS+HgL1ajQi/V8RKFbfE4i7a6URUOyWhy33X18JSn+O3hP1UAAAAAAAAA== --Apple-Mail-27-852147327-- -- 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: From owner-namedroppers@ops.ietf.org Thu Jul 31 18:02:11 2008 Return-Path: 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 AA99A28C399; Thu, 31 Jul 2008 18:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 W+BGjCknagtU; Thu, 31 Jul 2008 18:02:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7DAFB28C398; Thu, 31 Jul 2008 18:02:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOiug-0006DQ-UX for namedroppers-data@psg.com; Fri, 01 Aug 2008 00:54:34 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOiud-0006Cu-6u for namedroppers@ops.ietf.org; Fri, 01 Aug 2008 00:54:33 +0000 Received: from commandprompt.com ([130.129.21.23]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m710v2cu017318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 Jul 2008 17:57:06 -0700 Date: Fri, 1 Aug 2008 01:54:24 +0100 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: DNS-spoofing Message-ID: <20080801005409.GA94387@commandprompt.com> References: <2B760B19-5C02-456A-B4BF-C52A67C34432@blipp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B760B19-5C02-456A-B4BF-C52A67C34432@blipp.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Thu, 31 Jul 2008 17:57:07 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [no hat] On Thu, Jul 31, 2008 at 08:47:12PM +0200, Patrik Wallstrom wrote: > John Dickinson demonstrated on the dnsext wg meeting today that you can > spoof a local DNS reslover in 95ms. The resolver had a fixed source port. I understood from his remarks, also, that John hadn't seen anything except what had leaked. Best, A -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- 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: