From owner-namedroppers@ops.ietf.org Wed Oct 1 04:00: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 B508F3A6A61; Wed, 1 Oct 2008 04:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.242 X-Spam-Level: X-Spam-Status: No, score=-5.242 tagged_above=-999 required=5 tests=[AWL=-0.194, 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 NCEgSq1GG5bI; Wed, 1 Oct 2008 03:59:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A81A73A6C33; Wed, 1 Oct 2008 03:59:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kkz8I-000Kmn-L5 for namedroppers-data@psg.com; Wed, 01 Oct 2008 10:40:38 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kkz8E-000KmE-DM for namedroppers@ops.ietf.org; Wed, 01 Oct 2008 10:40:36 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m91Ae01q003310; Wed, 1 Oct 2008 03:40:10 -0700 (PDT) Cc: Nicholas Weaver , Andrew Sullivan , namedroppers@ops.ietf.org Message-Id: <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> From: Nicholas Weaver To: mayer@gis.net In-Reply-To: <48E2FAC3.7070509@gis.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [dnsext] Re: Protecting caches? Date: Wed, 1 Oct 2008 03:40:00 -0700 References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sep 30, 2008, at 9:21 PM, Danny Mayer wrote: > > I don't altogether agree with this. DNSSEC will only protect up to the > resolver. What people keep forgetting about in this discussion is that > what you are really trying to protect is the application, most > likely a > browser, from receiving bad answers, and therefore preventing the DNS > resolver from returning bad answers is not enough. The application is > one or two hops away from the resolving DNS. Some systems like Windows > uses a DNS cache to cache answers on top of everything else. As long > as > getaddrinfo() and friends cannot request and receive a DNSSEC > "certified" response you are dropped right back to the original > problems. Worse than that, if you manage to poison the answers in the > resolver, you also poison the on-system cache AND the application. How > many applications request new answers once they have one? > getaddrinfo() > and friends don't even tell you what the TTL on the answers you do get > so you have no way of deciding when to re-request an answer in the > first > place even if the address was originally valid. The getaddrinfo() relies on the host's stub resolver. If the host stub resolver respects DNSSEC, you do get protection up to getaddrinfo(), because I think most implementations will silently fail when DNSSEC fails. This is generally regarded as a primary feature, the implementation "fails safe" but with no way to override unless a getaddrinfo_no_DNSSEC() function is added in the API. This is also considered a primary bug when you talk to Eric Rescorla, as SSL/TLS had this behavior initially and it proved problematic: most "failures" were benign. The fundamental problem with DNSSEC is how the application USES getaddrinfo(): it either trusts the name or it doesn't. If its an end-to-end secure application, it never actually trusted the name, because the application doesn't trust the network, so DNSSEC bought nothing. Zippo. Zilch. Nada. If its not end-to-end secure, it trusts the name as well as the network. This is a BIG problem if the resolver is poisoned by an out- of-path adversary (eg, blind cache poisoning, a corrupted recursive resolver, etc). But it is not a big problem if the attacker is a man-in-the-middle: Yes, the attacker can MitM the DNS, but can also MitM the application in almost all cases, as the naming path and the data path are convergent in practice in almost all cases. Thus from a cryptographic security viewpoint, DNSSEC is exactly backwards: the PRIMARY threat model addressed, a man-in-the-middle, is not addressable at the naming operation, but must be addressed at the application or application transport layer. Period. The secondary problem is one of deployment: Both the stub resolvers (Microsoft, Apple) need to be updated to check DNSSEC, the recursive resolvers must pass the information unchanged or check DNSSEC, and the authoritative servers must provide DNSSEC, the latter being a big pain, in many ways due to trust anchor issues. eg, see Clayton's rant on trying to set up a DNSSEC-supporting domain: http://www.lightbluetouchpaper.org/2008/09/29/root-of-trust/ This is why I believe that the problem with out-of-path adversaries (blind cache poisoning) needs to be addressed in the resolvers, without changing the protocol and without changing the authorities. And I believe there is a lot more than just "more entropy" which can be done. -- to unsubscribe send a message to namedroppers-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 Oct 1 11:13: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 E0C173A6856; Wed, 1 Oct 2008 11:13:40 -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 mljFyESbi8F3; Wed, 1 Oct 2008 11:13:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CD4BB3A67E9; Wed, 1 Oct 2008 11:13:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kl622-000DlZ-Qp for namedroppers-data@psg.com; Wed, 01 Oct 2008 18:02:38 +0000 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 1Kl61v-000Dki-KW for namedroppers@ops.ietf.org; Wed, 01 Oct 2008 18:02:36 +0000 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 2BAE050846; Wed, 1 Oct 2008 11:15:58 -0700 (PDT) Date: Wed, 01 Oct 2008 11:15:57 -0700 From: Eric Rescorla To: Nicholas Weaver Cc: mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? In-Reply-To: <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> 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: <20081001181558.2BAE050846@romeo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Wed, 1 Oct 2008 03:40:00 -0700, Nicholas Weaver wrote: > The getaddrinfo() relies on the host's stub resolver. If the host > stub resolver respects DNSSEC, you do get protection up to > getaddrinfo(), because I think most implementations will silently fail > when DNSSEC fails. > > This is generally regarded as a primary feature, the implementation > "fails safe" but with no way to override unless a And my Kiboizer alerts... > getaddrinfo_no_DNSSEC() function is added in the API. This is also > considered a primary bug when you talk to Eric Rescorla, as SSL/TLS > had this behavior initially and it proved problematic: most "failures" > were benign. To expand on this point a little bit wrt TLS: The original assumption when SSL/TLS was designed was that validation failures (name mismatches, expired certs, unknown CAs, etc.) should be treated as hard failures. For instance, IE behaved this way. However, it quickly became apparent that a lot of such failures weren't attacks, but rather self-signed certs, configuration errors, etc., and the vendors were forced to put in the ability to override the checks. It's not clear how this experience transfers to DNSSEC, of course, since SSL/TLS provides benefits (confidentiality) against passive attacks even if the server uses a self-signed cert, whereas DNSSEC does not, so there's less incentive to deploy in a weak way. However, that still leaves open a variety of misconfigurations: all of these cryptographic techniques invert Postel's dictum about being liberal in what you accept. so if there is any reasonable base rate of misconfigurations, e.g., signatures outside their validity windows, then there's going to be a real issue in determining how to handle verification failures, especially with the limited channel available between the resolver and the user. -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 Wed Oct 1 16:17: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 7D9963A6B21; Wed, 1 Oct 2008 16:17:48 -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 YWBPLxU9XGf4; Wed, 1 Oct 2008 16:17:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 647073A6AB8; Wed, 1 Oct 2008 16:17:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlApy-000IWY-Kd for namedroppers-data@psg.com; Wed, 01 Oct 2008 23:10:30 +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 1KlApp-000IPB-0x for namedroppers@ops.ietf.org; Wed, 01 Oct 2008 23:10:25 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m91N8O7E006987; Wed, 1 Oct 2008 23:08:24 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m91N8MVZ006986; Wed, 1 Oct 2008 23:08:22 GMT Date: Wed, 1 Oct 2008 23:08:22 +0000 From: bmanning@vacation.karoshi.com To: Eric Rescorla Cc: Nicholas Weaver , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? Message-ID: <20081001230822.GA6966@vacation.karoshi.com.> References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081001181558.2BAE050846@romeo.rtfm.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > This is generally regarded as a primary feature, the implementation > > "fails safe" but with no way to override unless a > > And my Kiboizer alerts... > > > getaddrinfo_no_DNSSEC() function is added in the API. This is also > > considered a primary bug when you talk to Eric Rescorla, as SSL/TLS > > had this behavior initially and it proved problematic: most "failures" > > were benign. > > It's not clear how this experience transfers to DNSSEC, of course, > since SSL/TLS provides benefits (confidentiality) against passive > attacks even if the server uses a self-signed cert, whereas DNSSEC > does not, so there's less incentive to deploy in a weak way. However, > that still leaves open a variety of misconfigurations: all of these > cryptographic techniques invert Postel's dictum about being liberal in > what you accept. so if there is any reasonable base rate of > misconfigurations, e.g., signatures outside their validity windows, > then there's going to be a real issue in determining how to handle > verification failures, especially with the limited channel available > between the resolver and the user. > > -Ekr the other option is to "fail open" ... eg. things are just like they are now. --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 Oct 1 18:34: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 EEA813A6AEC; Wed, 1 Oct 2008 18:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[AWL=-0.301, 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 6ddj8coGyCPP; Wed, 1 Oct 2008 18:34:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 12D603A6958; Wed, 1 Oct 2008 18:34:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlCyC-0003hK-Bi for namedroppers-data@psg.com; Thu, 02 Oct 2008 01:27:08 +0000 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 1KlCy8-0003gd-Q0 for namedroppers@ops.ietf.org; Thu, 02 Oct 2008 01:27:06 +0000 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id C266C50846; Wed, 1 Oct 2008 18:40:30 -0700 (PDT) Date: Wed, 01 Oct 2008 18:40:30 -0700 From: Eric Rescorla To: bmanning@vacation.karoshi.com Cc: Eric Rescorla , Nicholas Weaver , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? In-Reply-To: <20081001230822.GA6966@vacation.karoshi.com.> References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.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: <20081002014030.C266C50846@romeo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Wed, 1 Oct 2008 23:08:22 +0000, bmanning@vacation.karoshi.com wrote: > > > > This is generally regarded as a primary feature, the implementation > > > "fails safe" but with no way to override unless a > > > > And my Kiboizer alerts... > > > > > getaddrinfo_no_DNSSEC() function is added in the API. This is also > > > considered a primary bug when you talk to Eric Rescorla, as SSL/TLS > > > had this behavior initially and it proved problematic: most "failures" > > > were benign. > > > > It's not clear how this experience transfers to DNSSEC, of course, > > since SSL/TLS provides benefits (confidentiality) against passive > > attacks even if the server uses a self-signed cert, whereas DNSSEC > > does not, so there's less incentive to deploy in a weak way. However, > > that still leaves open a variety of misconfigurations: all of these > > cryptographic techniques invert Postel's dictum about being liberal in > > what you accept. so if there is any reasonable base rate of > > misconfigurations, e.g., signatures outside their validity windows, > > then there's going to be a real issue in determining how to handle > > verification failures, especially with the limited channel available > > between the resolver and the user. > > > > -Ekr > > the other option is to "fail open" ... eg. things are > just like they are now. This seems plausible in some cases but not others. I.e., if the signature is expired, that's probably fine. However, if the signature is totally broken, doesn't accepting it kind of obviate the point of DNSSEC? -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 Wed Oct 1 18:44: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 8FBB43A67FA; Wed, 1 Oct 2008 18:44:33 -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 Th3c-8Ad0csq; Wed, 1 Oct 2008 18:44:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 87D293A6B21; Wed, 1 Oct 2008 18:44:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlDC4-0005ja-Cd for namedroppers-data@psg.com; Thu, 02 Oct 2008 01:41:28 +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 1KlDBy-0005Xx-QZ for namedroppers@ops.ietf.org; Thu, 02 Oct 2008 01:41:25 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m921dt7E008784; Thu, 2 Oct 2008 01:39:55 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m921dtsl008783; Thu, 2 Oct 2008 01:39:55 GMT Date: Thu, 2 Oct 2008 01:39:55 +0000 From: bmanning@vacation.karoshi.com To: Eric Rescorla Cc: bmanning@vacation.karoshi.com, Nicholas Weaver , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? Message-ID: <20081002013955.GA8748@vacation.karoshi.com.> References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081002014030.C266C50846@romeo.rtfm.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Oct 01, 2008 at 06:40:30PM -0700, Eric Rescorla wrote: > At Wed, 1 Oct 2008 23:08:22 +0000, > bmanning@vacation.karoshi.com wrote: > > > > > > This is generally regarded as a primary feature, the implementation > > > > "fails safe" but with no way to override unless a > > > > > > And my Kiboizer alerts... > > > > > > > getaddrinfo_no_DNSSEC() function is added in the API. This is also > > > > considered a primary bug when you talk to Eric Rescorla, as SSL/TLS > > > > had this behavior initially and it proved problematic: most "failures" > > > > were benign. > > > > > > It's not clear how this experience transfers to DNSSEC, of course, > > > since SSL/TLS provides benefits (confidentiality) against passive > > > attacks even if the server uses a self-signed cert, whereas DNSSEC > > > does not, so there's less incentive to deploy in a weak way. However, > > > that still leaves open a variety of misconfigurations: all of these > > > cryptographic techniques invert Postel's dictum about being liberal in > > > what you accept. so if there is any reasonable base rate of > > > misconfigurations, e.g., signatures outside their validity windows, > > > then there's going to be a real issue in determining how to handle > > > verification failures, especially with the limited channel available > > > between the resolver and the user. > > > > > > -Ekr > > > > the other option is to "fail open" ... eg. things are > > just like they are now. > > This seems plausible in some cases but not others. I.e., if the > signature is expired, that's probably fine. However, if the > signature is totally broken, doesn't accepting it kind of obviate > the point of DNSSEC? > > -Ekr well, i'd not accept it - I'd flag it as "not validatable" and proceed w/ resolution. sure - but then we have dns working at the same level as today. I'd rather have the DNS continue to work, for some level of work, than for it to fail and be dependent on someone else to correct the errors. Granted, this might be a tuneable knob that some operational enclaves will want to set to fail closed, but a "least surprise" default seems to be to fail open. a default of servfail on validation failure seems like a nearly insurmountable hurdle for adoption. --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 Oct 2 01:45: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 65CBB3A691D; Thu, 2 Oct 2008 01:45:45 -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 VTNl74FkNNeq; Thu, 2 Oct 2008 01:45:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 60BAE3A6848; Thu, 2 Oct 2008 01:45:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlJhz-000DDl-JG for namedroppers-data@psg.com; Thu, 02 Oct 2008 08:38: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 1KlJht-000DCb-L9 for namedroppers@ops.ietf.org; Thu, 02 Oct 2008 08:38:49 +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 1KlJha-0000Lf-DY; Thu, 02 Oct 2008 10:38:26 +0200 Received: from fweimer by bfk.de with local id 1KlJhf-0005dg-T4; Thu, 02 Oct 2008 10:38:35 +0200 To: Mark Andrews Cc: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Reminder: two WGLC closing in one week References: <200809262103.m8QL3USA067104@drugs.dv.isc.org> From: Florian Weimer Date: Thu, 02 Oct 2008 10:38:29 +0200 In-Reply-To: <200809262103.m8QL3USA067104@drugs.dv.isc.org> (Mark Andrews's message of "Sat, 27 Sep 2008 07:03:30 +1000") Message-ID: <8263ob2xyy.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: * Mark Andrews: >> DO necessarily implies UD because the synthesized CNAME is not signed >> and thus not visible to a DNSSEC client (section 3.1). > > DO indicates that you want the DNSSEC records. DO was originally conceived as "intent to validate". It's not used this way, though. > UD indicates that you don't want the synthesised CNAME. > > There are cases where you don't want DO to imply UD. > Think humans reading the output. If UD is debugging-only, I don't think it's worth the effort. --=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 Oct 2 05:45: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 887863A6CCC; Thu, 2 Oct 2008 05:45:31 -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 ISuZTwYgeJQl; Thu, 2 Oct 2008 05:45:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B41393A68B9; Thu, 2 Oct 2008 05:45:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlNSp-0005l6-F4 for namedroppers-data@psg.com; Thu, 02 Oct 2008 12:39:27 +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 1KlNSi-0005c9-DH for namedroppers@ops.ietf.org; Thu, 02 Oct 2008 12:39:24 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m92CbZ7E013479; Thu, 2 Oct 2008 12:37:35 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m92CbXgU013478; Thu, 2 Oct 2008 12:37:33 GMT Date: Thu, 2 Oct 2008 12:37:33 +0000 From: bmanning@vacation.karoshi.com To: Nicholas Weaver Cc: mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? Message-ID: <20081002123733.GA13334@vacation.karoshi.com.> References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Oct 01, 2008 at 03:40:00AM -0700, Nicholas Weaver wrote: > > The getaddrinfo() relies on the host's stub resolver. If the host > stub resolver respects DNSSEC, you do get protection up to > getaddrinfo(), because I think most implementations will silently fail > when DNSSEC fails. if this is the case, then DNSSEC is a non-starter. actually, i've yet to see a validator be stateless enough to be able to be wrapped into a system call. remember, resolution and validation are different things. getaddrinfo() is a resolution tool, an ephemeral system call that maintains no state. validation depends on resolution working - so as to be able to get the data needed to perform the function. and validation requires state and (to be effective) a cache. > This is generally regarded as a primary feature, the implementation > "fails safe" but with no way to override unless a > getaddrinfo_no_DNSSEC() function is added in the API. This is also > considered a primary bug when you talk to Eric Rescorla, as SSL/TLS > had this behavior initially and it proved problematic: most "failures" > were benign. regarded as a feature by whom? > The fundamental problem with DNSSEC is how the application USES > getaddrinfo(): it either trusts the name or it doesn't. again, you are conflating resoultion w/ validation. getaddrinfo() returns data ... w/o any warrantees on accuracy or integrity. if you want that, then you have to involke a validator. the "trust" does not lie w/ the systemcall. > If its an end-to-end secure application, it never actually trusted the > name, because the application doesn't trust the network, so DNSSEC > bought nothing. Zippo. Zilch. Nada. unless the application under discussion is DNS. and even then, DNSSEC doesn't care abt trusting the network or the intermediate nodes that might hold the data. > Thus from a cryptographic security viewpoint, DNSSEC is exactly > backwards: the PRIMARY threat model addressed, a man-in-the-middle, is > not addressable at the naming operation, but must be addressed at the > application or application transport layer. Period. i think i misunderstand your terms here: naming operation application DNSSEC protects the applicaiton DNS. Trust is not transitive and can not be presumed to map to other applications. The best DNSSEC can do is assure the data received was received intact from a known source. what SSH or SMTP or NTP does with the data returned from a resolution request is up to that application, not the DNS. > The secondary problem is one of deployment: Both the stub resolvers > (Microsoft, Apple) need to be updated to check DNSSEC, the recursive > resolvers must pass the information unchanged or check DNSSEC, and the > authoritative servers must provide DNSSEC, the latter being a big > pain, in many ways due to trust anchor issues. eg, see Clayton's rant > on trying to set up a DNSSEC-supporting domain: > http://www.lightbluetouchpaper.org/2008/09/29/root-of-trust/ its not that hard - many folks are signing their data. i remain unconvinced that stub resolvers need to be updated. I belive validation can and should be done asyncronously from resolution. And it is true that a validator API is sadly lacking - although there have been several efforts over the years to bring something forward. > This is why I believe that the problem with out-of-path adversaries > (blind cache poisoning) needs to be addressed in the resolvers, > without changing the protocol and without changing the authorities. > And I believe there is a lot more than just "more entropy" which can > be done. > > > -- > to 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 Thu Oct 2 06:58: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 98EB13A6CC2; Thu, 2 Oct 2008 06:58:36 -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 goaYEMy27USo; Thu, 2 Oct 2008 06:58:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ACF7A3A677D; Thu, 2 Oct 2008 06:58:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlOX3-000BVL-5c for namedroppers-data@psg.com; Thu, 02 Oct 2008 13:47:53 +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 1KlOWo-000BTv-N2 for namedroppers@ops.ietf.org; Thu, 02 Oct 2008 13:47:43 +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 1KlOWj-0001KO-69; Thu, 02 Oct 2008 13:47:33 +0000 Subject: Re: [dnsext] Re: Protecting caches? From: Shane Kerr To: bmanning@vacation.karoshi.com Cc: namedroppers@ops.ietf.org In-Reply-To: <20081002123733.GA13334@vacation.karoshi.com.> References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081002123733.GA13334@vacation.karoshi.com.> Content-Type: text/plain Date: Thu, 02 Oct 2008 15:47:35 +0200 Message-Id: <1222955255.19380.305.camel@shane-macbook-pro> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-Authenticated: True Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Bill, On Thu, 2008-10-02 at 12:37 +0000, bmanning@vacation.karoshi.com wrote: > its not that hard - many folks are signing their data. > i remain unconvinced that stub resolvers need to be updated. > I belive validation can and should be done asyncronously from > resolution. And it is true that a validator API is sadly > lacking - although there have been several efforts over the > years to bring something forward. Can you point us to some of these? Too bad the IETF does not "do APIs". (Except when it does, of course.) -- Shane -- to unsubscribe send a message to namedroppers-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 Oct 2 08:07: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 6A9583A67E4; Thu, 2 Oct 2008 08:07: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 QgiHfl41yJFk; Thu, 2 Oct 2008 08:07:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8B3E53A69CD; Thu, 2 Oct 2008 08:07:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlPgM-000I4t-Pk for namedroppers-data@psg.com; Thu, 02 Oct 2008 15:01:34 +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 1KlPgE-000I3h-GS for namedroppers@ops.ietf.org; Thu, 02 Oct 2008 15:01:32 +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 m92F1JLB072566; Thu, 2 Oct 2008 11:01:20 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200810021501.m92F1JLB072566@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Oct 2008 11:01:12 -0400 To: Florian Weimer From: Olafur Gudmundsson Subject: Re: [dnsext] Reminder: two WGLC closing in one week Cc: namedroppers@ops.ietf.org In-Reply-To: <8263ob2xyy.fsf@mid.bfk.de> References: <200809262103.m8QL3USA067104@drugs.dv.isc.org> <8263ob2xyy.fsf@mid.bfk.de> 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: At 04:38 02/10/2008, Florian Weimer wrote: >* Mark Andrews: > > >> DO necessarily implies UD because the synthesized CNAME is not signed > >> and thus not visible to a DNSSEC client (section 3.1). > > > > DO indicates that you want the DNSSEC records. > >DO was originally conceived as "intent to validate". It's not used >this way, though. DO was designed to address two issues: - Protect DNSSEC-ignorant resolvers that failed when they saw "unknown" RR types. - Keep answers smaller for DNSSEC ignorant queriers. When DO was proposed, someone observed "DNSSEC is only for consenting adults" > > UD indicates that you don't want the synthesised CNAME. > > > > There are cases where you don't want DO to imply UD. > > Think humans reading the output. > >If UD is debugging-only, I don't think it's worth the effort. UD is an exit plan from "synthesize CNAME forever" as the old exit plan "new version of EDNS" is not on the horizon. There are actively maintained non-DNSSEC DNAME-aware resolvers out there and these resolvers can send queries with DO=0 and UD=1. One of the objections from for placing DNAME records in the root zone was the "CNAME synthesis overhead". 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 Oct 2 08:18: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 2673A3A6AA8; Thu, 2 Oct 2008 08:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=-0.155, 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 sGRzeFxkGe95; Thu, 2 Oct 2008 08:18:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9AB9D3A6881; Thu, 2 Oct 2008 08:18:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlPpJ-000J2b-TY for namedroppers-data@psg.com; Thu, 02 Oct 2008 15:10:49 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlPp6-000J1O-Nv for namedroppers@ops.ietf.org; Thu, 02 Oct 2008 15:10:42 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m92FA3UQ020439; Thu, 2 Oct 2008 08:10:27 -0700 (PDT) Cc: Nicholas Weaver , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: bmanning@vacation.karoshi.com In-Reply-To: <20081002123733.GA13334@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 v929.2) Subject: Re: [dnsext] Re: Protecting caches? Date: Thu, 2 Oct 2008 08:10:02 -0700 References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081002123733.GA13334@vacation.karoshi.com.> X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Oct 2, 2008, at 5:37 AM, bmanning@vacation.karoshi.com wrote: >> This is generally regarded as a primary feature, the implementation >> "fails safe" but with no way to override unless a >> getaddrinfo_no_DNSSEC() function is added in the API. This is also >> considered a primary bug when you talk to Eric Rescorla, as SSL/TLS >> had this behavior initially and it proved problematic: most >> "failures" >> were benign. > > regarded as a feature by whom? Discussions in this mailing list, I can't remember where. >> The fundamental problem with DNSSEC is how the application USES >> getaddrinfo(): it either trusts the name or it doesn't. > > again, you are conflating resoultion w/ validation. > getaddrinfo() returns data ... w/o any warrantees on > accuracy or integrity. if you want that, then you have > to involke a validator. the "trust" does not lie w/ the systemcall. I don't get the distinction. Pardon my ignorance, but the resolution process in DNSSEC should include validation. Unless the recursive resolver is told otherwise, it validates DNSSEC signatures before returning a value. Unless the stub resolver is misconfigured, it validates DNSSEC signatures before returning the value. getaddrinfo() is a wrapper around a call to the local stub resolver. Thus if the stub resolver validates as part of the lookup process, getaddrinfo() validates as part of the lookup process. ANd if you trust the operating system, you can trust the operating system's stub resolver to do this properly. >> If its an end-to-end secure application, it never actually trusted >> the >> name, because the application doesn't trust the network, so DNSSEC >> bought nothing. Zippo. Zilch. Nada. > > unless the application under discussion is DNS. > and even then, DNSSEC doesn't care abt trusting the > network or the intermediate nodes that might hold the > data. How many end-host lookups are "DNS is the application"? Almost none. DNS is a tool used by the end application to map a (usually human readable) name into a set of addresses, for communication with those addresses. DNSSEC is a way for the end application to have assurance that the name to address mapping is legitimate. >> Thus from a cryptographic security viewpoint, DNSSEC is exactly >> backwards: the PRIMARY threat model addressed, a man-in-the-middle, >> is >> not addressable at the naming operation, but must be addressed at the >> application or application transport layer. Period. > > i think i misunderstand your terms here: > > naming operation > application > > DNSSEC protects the applicaiton DNS. Trust is not transitive > and can not be presumed to map to other applications. The best > DNSSEC can do is assure the data received was received intact > from a known source. what SSH or SMTP or NTP does with the > data returned from a resolution request is up to that application, > not the DNS. Actually, trust is transitive all the time. Your application trusts the underlying operating system, for example. The problem is that in 99.9999% of the cases, if the application transitively trusts the DNS name it gets from the host operating system, it also transitively trusts the network itself. And if the application did not trust the DNS name, it does NOT trust the network. >> The secondary problem is one of deployment: Both the stub resolvers >> (Microsoft, Apple) need to be updated to check DNSSEC, the recursive >> resolvers must pass the information unchanged or check DNSSEC, and >> the >> authoritative servers must provide DNSSEC, the latter being a big >> pain, in many ways due to trust anchor issues. eg, see Clayton's >> rant >> on trying to set up a DNSSEC-supporting domain: >> http://www.lightbluetouchpaper.org/2008/09/29/root-of-trust/ > > its not that hard - many folks are signing their data. > i remain unconvinced that stub resolvers need to be updated. > I belive validation can and should be done asyncronously from > resolution. And it is true that a validator API is sadly > lacking - although there have been several efforts over the > years to bring something forward. Why should validation be done independently? Why should separate validation be done at all? In fact, I will argue that independent validation is EXACTLY the wrong answer for almost all applications: If the application needs to independently validate the name, its not going to bother, and SHOULD NOT be changed to bother: its going to do a cryptographic validation directly to the address on the other side: TLS, IPSec, ssh, whatever, because such validation not only ensures that the name is correct, but that the transport is correct and has integrity. For such an application, separate name validation is useless, and will not be done. And if an application doesn't bother independently validating the name, its not going to bother doing end-to-end cryptography either, so it gets completely decimated by a MitM, and a Man-in-the-middle on the naming traffic is almost always on the same path as a man-in-the- middle on the data traffic. In fact, the big use for DNSSEC, I believe, is NOT for securing DNS names against a man-in-the-middle (a useless endeavor), but as a "item respository with cryptographic integrity", where NON-naming information is stored. Not because its a particularly good one (the size limits make it a particularly BAD one in fact), but because there is no other off the shelf existing secure distributed database code that is readily avaliable, unlike transport . And for this, the API could just be a piece of resolver code as a library in the application or a standalone application, like TLS and ssh are today for anyone who uses it. And would want to be this way, because the desired policies on failures etc should not be relying on the end host's stub resolver code anyway. -- to unsubscribe send a message to namedroppers-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 Oct 2 08:52: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 7C1263A693F; Thu, 2 Oct 2008 08:52:33 -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 V3KJMiqQ1bYU; Thu, 2 Oct 2008 08:52:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 442303A67A8; Thu, 2 Oct 2008 08:52:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlQOR-000NGG-Mk for namedroppers-data@psg.com; Thu, 02 Oct 2008 15:47: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 1KlQOG-000NEV-1m for namedroppers@ops.ietf.org; Thu, 02 Oct 2008 15:46:57 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m92FkrV1073034 for ; Thu, 2 Oct 2008 11:46:53 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m92FkrE2073033 for namedroppers@ops.ietf.org; Thu, 2 Oct 2008 11:46:53 -0400 (EDT) (envelope-from namedroppers) Received: from [2001:4f8:3:bb:2e0:81ff:fe52:9971] (helo=mail2.ntp.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KktDT-000GgS-8M for namedroppers@ops.ietf.org; Wed, 01 Oct 2008 04:21:37 +0000 Received: from mail.antoniuk.md (mail.antoniuk.md [65.86.158.146]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.ntp.org (Postfix) with ESMTP id 58359398CD; Wed, 1 Oct 2008 04:21:30 +0000 (UTC) (envelope-from mayer@ntp.isc.org) Received: from cust-63-209-233-224.bos-dynamic.gis.net ([63.209.233.224] helo=[10.10.10.100]) by mail.antoniuk.md with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KktCn-00054n-6G; Wed, 01 Oct 2008 00:20:53 -0400 Message-ID: <48E2FAA0.7090001@ntp.isc.org> Date: Wed, 01 Oct 2008 00:20:48 -0400 From: Danny Mayer Reply-To: mayer@ntp.isc.org User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: [dnsext] Re: Protecting caches? References: <20080827170822.GH18946@commandprompt.com> In-Reply-To: <20080827170822.GH18946@commandprompt.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-kostecke.net-MailScanner: Found to be clean X-kostecke.net-MailScanner-From: mayer@ntp.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. ] Andrew Sullivan wrote: > No hat. > > Dear colleagues, > > In the discussion around forgery resilience so far, I've seen some > discussion on how to detect cache poisoning attempts, and some > discussion on how to foil the attack itself by reducing the ability of > the attacker to send bad data to a resolver. (I've also seen the > observation, several times, that DNSSEC will solve these problems > anyway, so we should concentrate on deploying that; that's an > operational problem now, and not on-topic for this list.) I don't altogether agree with this. DNSSEC will only protect up to the resolver. What people keep forgetting about in this discussion is that what you are really trying to protect is the application, most likely a browser, from receiving bad answers, and therefore preventing the DNS resolver from returning bad answers is not enough. The application is one or two hops away from the resolving DNS. Some systems like Windows uses a DNS cache to cache answers on top of everything else. As long as getaddrinfo() and friends cannot request and receive a DNSSEC "certified" response you are dropped right back to the original problems. Worse than that, if you manage to poison the answers in the resolver, you also poison the on-system cache AND the application. How many applications request new answers once they have one? getaddrinfo() and friends don't even tell you what the TTL on the answers you do get so you have no way of deciding when to re-request an answer in the first place even if the address was originally valid. Danny -- to unsubscribe send a message to namedroppers-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 Oct 2 12:21: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 B2B0F3A69CD; Thu, 2 Oct 2008 12:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.014 X-Spam-Level: X-Spam-Status: No, score=-0.014 tagged_above=-999 required=5 tests=[AWL=0.481, 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 mCQnhF31Xmzt; Thu, 2 Oct 2008 12:21:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D3C783A6879; Thu, 2 Oct 2008 12:21:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlTd1-000KYN-8U for namedroppers-data@psg.com; Thu, 02 Oct 2008 19:14: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 1KlTcx-000KXp-0t for namedroppers@ops.ietf.org; Thu, 02 Oct 2008 19:14:21 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m92JEGDG096656 for ; Thu, 2 Oct 2008 15:14:16 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m92JEGRm096655 for namedroppers@ops.ietf.org; Thu, 2 Oct 2008 15:14:16 -0400 (EDT) (envelope-from namedroppers) Received: from [208.17.35.58] (helo=paoakoavas09.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlSOs-000BKa-9K for namedroppers@ops.ietf.org; Thu, 02 Oct 2008 17:55:44 +0000 Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.61032989; Thu, 02 Oct 2008 13:55:19 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Oct 2008 13:55:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [dnsext] (Off-Topic) DNSSEC Technical Testing Date: Thu, 2 Oct 2008 13:54:58 -0400 Message-ID: <45AEC6EF95942140888406588E1A660205B9E31F@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (Off-Topic) DNSSEC Technical Testing Thread-Index: Ackkt/vrXZ9GtSzhRd2qtxpvnx+UEA== From: "Livingood, Jason" To: , X-OriginalArrivalTime: 02 Oct 2008 17:55:20.0094 (UTC) FILETIME=[09090BE0:01C924B8] 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. ] Yesterday, we attended a DNSSEC policy meeting in Washington, where we announced that we've started a DNSSEC technical trial at Comcast. We tend to be rather hands-on learners, so we implemented a DNSSEC-capable resolver in our production network. Anyone on the public Internet is welcome to point to our server and test against it. Please contact us if you'd like error logs (should you have problems), would like keys added, or have other questions. =20 The IP is 68.87.64.154, and trial info is available at info at http://www.dnssec.comcast.net. We plan to test Unbound, BIND, and Nominum resolvers, and will share test results (before & after activation/use of DNSSEC). We also plan to document what we experience and issues we face, for the benefit of others in the community. =20 =20 Regards, Jason =20 Jason Livingood National Engineering & Technical Operations Comcast Cable Communications -- to unsubscribe send a message to namedroppers-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 Oct 2 12: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 90EBE3A69CD; Thu, 2 Oct 2008 12:21:13 -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 qVK3ENh0UVTm; Thu, 2 Oct 2008 12:21:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7FB4B3A6879; Thu, 2 Oct 2008 12:21:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlTdP-000Kae-4o for namedroppers-data@psg.com; Thu, 02 Oct 2008 19:14: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 1KlTdK-000KZz-IY for namedroppers@ops.ietf.org; Thu, 02 Oct 2008 19:14:44 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m92JEfNk096673 for ; Thu, 2 Oct 2008 15:14:41 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m92JEfk1096672 for namedroppers@ops.ietf.org; Thu, 2 Oct 2008 15:14:41 -0400 (EDT) (envelope-from namedroppers) Received: from [193.110.157.143] (helo=newtla.xelerance.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlTIa-000I8H-S7 for namedroppers@ops.ietf.org; Thu, 02 Oct 2008 18:53:18 +0000 Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id 2B18ABEA3; Thu, 2 Oct 2008 14:44:51 -0400 (EDT) Date: Thu, 2 Oct 2008 14:44:51 -0400 (EDT) From: Paul Wouters To: "Livingood, Jason" cc: dnsop@ietf.org, namedroppers@ops.ietf.org Subject: [dnsext] Re: [DNSOP] (Off-Topic) DNSSEC Technical Testing In-Reply-To: <45AEC6EF95942140888406588E1A660205B9E31F@PACDCEXCMB04.cable.comcast.com> Message-ID: References: <45AEC6EF95942140888406588E1A660205B9E31F@PACDCEXCMB04.cable.comcast.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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. ] On Thu, 2 Oct 2008, Livingood, Jason wrote: > The IP is 68.87.64.154, and trial info is available at info at > http://www.dnssec.comcast.net. We plan to test Unbound, BIND, and > Nominum resolvers, and will share test results (before & after > activation/use of DNSSEC). We also plan to document what we experience > and issues we face, for the benefit of others in the community. Thanks! I added you to the map on http://www.xelerance.com/dnssec/ Paul (info will appear soon as non-google map there as well) -- to unsubscribe send a message to namedroppers-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 Oct 2 15:22: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 D3F933A6913; Thu, 2 Oct 2008 15:22:09 -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 uUf6LV40Ebrx; Thu, 2 Oct 2008 15:22:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F28213A68E3; Thu, 2 Oct 2008 15:22:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlWT1-000A9l-F0 for namedroppers-data@psg.com; Thu, 02 Oct 2008 22:16:15 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlWSu-000A9G-E8 for namedroppers@ops.ietf.org; Thu, 02 Oct 2008 22:16:13 +0000 Received: by core3.amsl.com (Postfix, from userid 30) id DDFBB3A690B; Thu, 2 Oct 2008 15:15:39 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Subject: [dnsext] Last Call: draft-ietf-dnsext-forgery-resilience (Measures for making DNS more resilient against forged answers) to Proposed Standard Reply-to: ietf@ietf.org CC: Message-Id: <20081002221539.DDFBB3A690B@core3.amsl.com> Date: Thu, 2 Oct 2008 15:15:39 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Measures for making DNS more resilient against forged answers ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-10-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15593&rfc_flag=0 -- to unsubscribe send a message to namedroppers-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 Oct 2 16:23: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 7AC0F3A6A57; Thu, 2 Oct 2008 16:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.27 X-Spam-Level: X-Spam-Status: No, score=-5.27 tagged_above=-999 required=5 tests=[AWL=-0.222, 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 KulHMyDELk08; Thu, 2 Oct 2008 16:23:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7FCF03A69E8; Thu, 2 Oct 2008 16:23:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlXRK-000EB4-Ue for namedroppers-data@psg.com; Thu, 02 Oct 2008 23:18:34 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlXRH-000EAl-2a for namedroppers@ops.ietf.org; Thu, 02 Oct 2008 23:18:33 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m92NHeUe013082; Thu, 2 Oct 2008 16:17:40 -0700 (PDT) Cc: Nicholas Weaver , IETF-Announce , Message-Id: <9D4D9C40-3503-4C85-9236-BE75F4139019@icsi.berkeley.edu> From: Nicholas Weaver To: ietf@ietf.org In-Reply-To: <20081002221539.DDFBB3A690B@core3.amsl.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [dnsext] Last Call: draft-ietf-dnsext-forgery-resilience (Measures for making DNS more resilient against forged answers) to Proposed Standard Date: Thu, 2 Oct 2008 16:17:40 -0700 References: <20081002221539.DDFBB3A690B@core3.amsl.com> X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I believe this draft is insufficient: 4.1: Frankly speaking, with all the mechanisms out there, you must assume that an attacker can force queries of the attacker's choosing at times of the attacker's choosing, within a fraction of a second in almost all cases. This is not by directly generating a request to the server, but by performing some application operation (eg, mail request where the SMTP resolver checks it, a Javascript loaded in a victim's browser, etc. Preventing external recursive queries is about as an effective defense as a chalk line on the ground saying "do not cross". More importantly, Time to Live ONLY applies if the cache policy is such that there are no Race until win attacks. In order to eliminate race-until-win cases on a particular name, different cache behavior is necessary over how currently it is specified in RFC2181. See http://www.ietf.org/internet-drafts/draft-weaver-dnsext-comprehensive-resolver-00.txt section 10 for details on one such cache policy which can prevent all race-until-win attacks. See http://tools.ietf.org/id/draft-wijngaards-dnsext-resolver-side-mitigation-00.txt section 3.3/3.4 for an approximation of such a policy. Section 4 also excludes two significant additional entropy sources which can't always be used but can often be used: 0x20 matching and duplication, since ~32b entropy is only marginally sufficient, but 40b + (achievable through 0x20 and/or duplication) is for protecting the cache. Likewise, section 7-8 explicitly ignore the effects of "race until win". As long as a resolver will accept any additional data from a result into the cache, even when in scope (section 6's recommendations enable race-until-win attacks), TTL becomes 0 regardless of the actual TTL of the record. This is the real power of the Kaminski attack: it is not a reduction in packet-work for the attacker, but a reduction in time. Thus, the paragraph in section 10 is also incorrect: Long TTLs from the authority provide no protection unless the recursive resolver implements the conservative acceptance policy. Long TTLs should not be encouraged as a security measure, because unless resolver cache acceptance is changed, they are not a security measure, but could instead cause more failures/difficulties. And without changing cache acceptance, you must assume that TTL = W in sections 7-8. On Oct 2, 2008, at 3:15 PM, The IESG wrote: > The IESG has received a request from the DNS Extensions WG (dnsext) to > consider the following document: > > - 'Measures for making DNS more resilient against forged answers ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the > ietf@ietf.org mailing lists by 2008-10-16. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-07.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15593&rfc_flag=0 > > > -- > to 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 Fri Oct 3 08:27: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 E2D8728C295; Fri, 3 Oct 2008 08:27:20 -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 TywgF-EAbIZz; Fri, 3 Oct 2008 08:27:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E2C7028C249; Fri, 3 Oct 2008 08:27:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlmR1-000EPI-FS for namedroppers-data@psg.com; Fri, 03 Oct 2008 15:19:15 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KlmQt-000EOS-D0 for namedroppers@ops.ietf.org; Fri, 03 Oct 2008 15:19:10 +0000 Received: by core3.amsl.com (Postfix, from userid 30) id 34EF228C256; Fri, 3 Oct 2008 08:18:36 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , dnsext mailing list , dnsext chair Subject: [dnsext] Protocol Action: 'Domain Name System (DNS) IANA Considerations' to BCP Message-Id: <20081003151837.34EF228C256@core3.amsl.com> Date: Fri, 3 Oct 2008 08:18:37 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: The IESG has approved the following document: - 'Domain Name System (DNS) IANA Considerations ' as a BCP This document is the product of the DNS Extensions Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-07.txt - Technical Summary The document updates rules for how certain DNS parameter values are allocated. In most cases this is a relaxation of the existing rules. The document is giving guidance to IANA on policies for allocation. The DNS community wants to simplify the rules for allocation of new RR types, and this document combined with the rules in RFC3597 makes this possible. For RR types that fit within the rules a simple template and review by WG and a designated expert is the new process. Most other changes from RFC2929 are insignificant. - Working Group Summary There is a broad consensus that this document is an improvement over its predecessor. - Protocol Quality This is document about IETF/IANA process so there are no implementations. The working group and sponsoring AD are running an experiment of the new RR type process concurrently with the publication request. see: http://psg.com/lists/namedroppers/namedroppers.2006/msg01601.html http://psg.com/lists/namedroppers/namedroppers.2006/msg01603.html http://psg.com/lists/namedroppers/namedroppers.2007/msg00068.html http://psg.com/lists/namedroppers/namedroppers.2007/msg00070.html -- to unsubscribe send a message to namedroppers-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 Oct 6 03:56: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 DEDA23A6AAD; Mon, 6 Oct 2008 03:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=-3.208, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_52=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_91=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 kcWLSWtgMGdh; Mon, 6 Oct 2008 03:56:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D07A028C1A1; Mon, 6 Oct 2008 03:56:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmnaR-000Bvj-VA for namedroppers-data@psg.com; Mon, 06 Oct 2008 10:45:11 +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 1KmnaL-000BuZ-Ok for namedroppers@ops.ietf.org; Mon, 06 Oct 2008 10:45:09 +0000 Received: from denic.de ([10.122.65.106]) by office.denic.de with esmtp id 1KmnaI-0002mf-Ph; Mon, 06 Oct 2008 12:45:02 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id BA7B882BF90; Mon, 6 Oct 2008 12:45:02 +0200 (CEST) Date: Mon, 6 Oct 2008 12:45:02 +0200 From: Peter Koch To: IETF DNSEXT WG Subject: [dnsext] Re: REMINDER: rfc2672bis WGLC expiring! Message-ID: <20081006104502.GC45536@unknown.office.denic.de> References: <20080828161708.GR23588@commandprompt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080828161708.GR23588@commandprompt.com> User-Agent: Mutt/1.4.2.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Hello, On Thu, Aug 28, 2008 at 12:17:08PM -0400, Andrew Sullivan wrote: > We posted the WGLC for draft-ietf-dnsext-rfc2672bis-dname-14 on > 2008-07-31. here is my review of that draft with apologies for the late response. I have deliberately not read other people's review for "implementation independence", so far. The draft is in a really good shape for the most part, so generally I support it going forward on standards track, but there are some nits and a few requests for clarification that I think could improve the clarity and quality of the document, if addressed. I do explicitly not support section 4, for reasons given down in the text. The intended goal could be achieved better and cleaner (process wise) with a different approach, IMHO. Best regards, Peter > Update to DNAME Redirection in the DNS > draft-ietf-dnsext-rfc2672bis-dname-14 > 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]. NIT: This is easily lost between the abstract and the toc and could better go into the introduction, maybe as a subsection > 1. Introduction > This document is a revision of the original specification of DNAME in > RFC 2672 [RFC2672]. DNAME was conceived to help with the problem of > maintaining address-to-name mappings in a context of network > renumbering. With a careful set-up, a renumbering event in the > network causes no change to the authoritative server that has the > address-to-name mappings. Examples in practice are classless reverse > address space delegations. CLARIFY: I don't understand the server's (sic!) role here. Do you mean that with the scheme suggested in section 5.3 of RFC 2672 there is no change needed to the reverse mapping _data_ in the respective zone? > 2. The DNAME Resource Record > > 2.1. Format > > The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is > not class-sensitive. [...] NIT: Later in the document it is mentioned that DNAME is a singleton type, but for completeness I'd suggest to state this here, too. > 2.2. The DNAME Substitution > A DNAME substitution is performed by replacing the suffix labels of > the name being sought matching the owner name of the DNAME resource > record with the string of labels in the RDATA field. The matching CLARIFY: Maybe _because_ I know how it works, I was confused by this description. Maybe it's the ordering: A DNAME substitution is performed by replacing those suffix labels of the QNAME that match the DNAME RR's owner name with the domain name in the DNAME RR's RDATA. TERMINOLOGY: On several occurences the draft talks about "a DNAME" when it actually refers to a DNAME RR. DNAME can be confused with "domain name" and sometimes -- as with the term "CNAME" -- it isn't too obvious whether the owner, the target/RDATA or the whole RR is meant. Suggested solution: consequently use "DNAME RR" where appropriate. > QNAME owner DNAME target result > ---------------- -------------- -------------- ----------------- > com. example.com. example.net. > example.com. example.com. example.net. > a.example.com. example.com. example.net. a.example.net. > a.b.example.com. example.com. example.net. a.b.example.net. > ab.example.com. b.example.com. example.net. > foo.example.com. example.com. example.net. foo.example.net. CLARIFY: the latest example line is not different from the third, is it? Suggest to remove the "foo" example. > a.x.example.com. x.example.com. example.net. a.example.net. > a.example.com. example.com. y.example.net. a.y.example.net. > cyc.example.com. example.com. example.com. cyc.example.com. > cyc.example.com. example.com. c.example.com. cyc.c.example.com. > shortloop.x.x. x. . shortloop.x. > shortloop.x. x. . shortloop. We should "eat our own dogfood" here and stick with RFC 2606 TLDs, even if that causes a line break, IMHO. > corner case DNAME can form a loop. Resolvers and servers should be > cautious in devoting resources to a query, but be aware that fairly > long chains of DNAMEs may be valid. Zone content administrators > should take care to insure that there are no loops that could occur > when using DNAME or DNAME/CNAME redirection. The fuzziness is likely deliberate, but "fairly long" isn't enough guidance IMHO. Also, the text seems to demand loop detection instead of setting a lower bound (of, say, 8 or 16) for the combined DNAME/CNAME chain length. > 2.3. DNAME Apex not Redirected itself > Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its > owner name; the owner name of a DNAME is not redirected itself. The > domain name that owns a DNAME record is allowed to have other > resource record types at that domain name, except DNAMEs or CNAMEs. > This means that DNAME RRs are not allowed at the parent side of a > delegation point but are allowed at a zone apex. The precondition doesn't seem to support the conclusion. The reason that DNAME RRs can't appear in parallel to the dlegating NS RRSet is that the protocol just doesn't allow anything else but the NS RRSet, glue address records and DNSSEC RRs at the delegation point in the parent. This is no special property of the DNMAE RR type. > 2.4. Names Next to and Below a DNAME Record > > Resource records MUST NOT exist at any domain name subordinate to the > owner of a DNAME RR. To get the contents for names subordinate to > that owner, the DNAME redirection must be invoked and the resulting In the spirit of RFC 4592, I think the question of existence of names should be addressed at least in addition to the existence of RRSets. Do names below a DNAME RR's owner exist? Does that depend on the resolution of the target? How does this interact with CNAME synthesis? NIT: suggest to replace "content" for names with ``RRSets associated with'' > target queried. A server MAY refuse to load a zone that has data at > a domain name subordinate to a domain name owning a DNAME RR. If the This supports unpredictable behaviour, so I'd suggest to allow the strict variant only for master servers, not slaves. People running "multi master" setups need to know what they are doing, but no harm is done when a slave loads a zone with occluded data as long as it coirrectly treats the DNAME RR. > occluded, RFC 2136 [RFC2136], section 7.18. Also a server SHOULD > refuse to load a zone subordinate to the owner of a DNAME record in > the ancestor zone. See Section 5.2 for further discussion related to Same here. Imagine migration from a child zone to a DNAME'd tree. Outright refusal doesn't appear helpful to me from an operational perspective. > DNAME is a singleton type, meaning only one DNAME is allowed per > name. The owner name of a DNAME can only have one DNAME RR, and no > CNAME RRs can exist at that name. These rules make sure that for a > single domain name only one redirection exists, and thus no confusion > which one to follow. A server SHOULD refuse to load a zone that > violates these rules. People have been arguing that names below a CNAME RR's owner do exist and can have/own non-CNAME RRSets. Therefore, I don't understand why a DNAME and a CNAME RR could not co-exist. There's no immediate confusion since for the owner name the CNAME RR is to be consulted, whereas everything below the owner would be covered by the DNAME RR. Both _could_ have different targets, but that possibility (or opportunity, if you wish) should not prohibit the RR types' co-existence. > 2.5. Compression of the DNAME record. > Although the previous DNAME specification [RFC2672] (that is > obsoleted by this specification) talked about signaling to allow > compression of the target name, such signaling has never been > specified and this document also does not specify this signaling > behavior. Wouldn't the "UD" bit provide this signalling? Not that I'd expect much gain from compression in DNAME RRs, though ... > 3. Processing > > The DNAME RR causes type NS additional section processing. That would mean the NS RRSet for the DNAME RR's target would be queried for by the responding authoritative server? I'd rather not see explicit QTYPE=NS queries being introduced en passant without a more detailed specification. Also, im sceptical of the gain to be achieved here, since most paranoid^Wmodern resolvers would likely ignore random NS RRSets anyway. > 3.1. CNAME synthesis and UD bit > section for old resolvers. The owner name of the CNAME is the QNAME > of the query. DNSSEC [RFC4033], [RFC4034], [RFC4035] says that the > synthesized CNAME does not have to be signed. The DNAME has an RRSIG NIT: RFC 4035 actually says it SHOULD NOT be signed. > and a validating resolver can check the CNAME against the DNAME > record and validate the DNAME record. > > Resolvers MUST be able to handle a synthesized CNAME TTL of zero or > equal to the TTL of the corresponding DNAME record. A TTL of zero > means that the CNAME can be discarded immediately after processing > the answer. DNAME aware resolvers can set the Understand-DNAME (UD > bit) to receive a response with only the DNAME RR and no synthesized > CNAMEs. NIT: Is this descriptive only or meant to be normative? Then I'd suggest to s/can/SHOULD/; > resolver processing of unsigned synthesized CNAMEs. Resolvers can > set this in a query to request omission of the synthesized CNAMEs. NIT: "can" or "MAY"? > Servers copy the UD bit to the response, and can omit synthesized NIT: Servers "MUST" copy? Or should they only copy the UD bit, if a DNAME RR was actually involved in finding the answer? > CNAMEs from the answer. Older resolvers do not set the UD bit, and > older servers do not copy the UD bit to the answer, and will not omit > synthesized CNAMEs. NIT: To avoid ambiguity and since older servers' behaviour cannot be retroactively changes, I'd change "do not copy" and "will not" to "are not expected to" ... CLARIFY: What are the expectations for unsolicited UD bits in responses? > Servers MUST be able to answer a query for a synthesized CNAME. Like > other query types this invokes the DNAME, and synthesizes the CNAME > into the answer. CLARIFY: What type of servers is meant here? Authoritative servers MUST synthesize a CNAME RR for an RD=0, QTYPE=CNAME query and set the AA bit? Recursive "servers" are a bit different, since they might not want to respond to RD=0 and with RD=1, they'd be obliged to follow the CNAME/DNAME to resolve the CNAME at the target, wouldn't they? > 3.2. Server algorithm [admittedly skipped] > 3.3. Wildcards > > The use of DNAME in conjunction with wildcards is discouraged > [RFC4592]. Thus records of the form "*.example.com DNAME > example.net" SHOULD NOT be used. NIT: Use normative language in the normative part of the text rather than the example: The use of DNAME RRs at the wildcard owner is NOT RECOMMENDED. Thus records ... ought not to be used {credits to Ed ;-} > A server MAY give a warning that the behavior is unspecified if such NIT: s/A server/An authoritative server/; > a wildcarded DNAME is loaded. The server MAY refuse it, refuse to > load or refuse dynamic update. CLARIFY: What does "MAY refuse it" mean? Should it ignore just this DNAME RR? CLARIFY: Which error code to use for a dynamic update refusal? > 3.4. Acceptance and Intermediate Storage > > Recursive caching name servers can encounter data at names below the > owner name of a DNAME RR, due to a change at the authoritative server NIT/TERMINOLOGY: change in the zone (not at the server) > where data from before and after the change resides in the cache. > This conflict situation is a transitional phase, that ends when the > old data times out. The caching name server can opt to store both > old and new data and treat each as if the other did not exist, or > drop the old data, or drop the longer domain name. In any approach, NIT: s/drop the longer domain name/drop the DNAME RR with the longer owner name/ > Recursive caching name servers MUST perform CNAME synthesis on behalf > of DNAME-ignorant clients. A recursive caching name server that > understands DNAMEs can send out queries on behalf of clients with the > UD bit set (See Section 3.1). After receiving the answers the > recursive caching name server sends replies to DNAME ignorant clients > that include DNAMEs and synthesized CNAMEs. CLARIFY/NIT: rearrange sentences to disambiguate: A recursive caching name server that understands DNAME RRs MUST(?) send a query with the UD bit sets on behalf of its client. After receiving the response, the recursive caching name server sends a reply that contains the DNAME RR and a synthesized CNAME RR to a client that did not set the UD bit in the original query. > 4. DNAME Discussions in Other Documents > The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME. > The opening premise of this section is demonstrably wrong, and so the > conclusion based on that premise is wrong. In particular, [RFC3363] > deprecates the use of DNAME in the IPv6 reverse tree, which is then > carried forward as a recommendation in [RFC4294]. Based on the > experience gained in the meantime, [RFC3363] should be revised, > dropping all constraints on having DNAME RRs in these zones. This > would greatly improve the manageability of the IPv6 reverse tree. > These changes are made explicit below. > > In [RFC3363], the paragraph > > "The issues for DNAME in the reverse mapping tree appears to be > closely tied to the need to use fragmented A6 in the main tree: if > one is necessary, so is the other, and if one isn't necessary, the > other isn't either. Therefore, in moving RFC 2874 to experimental, > the intent of this document is that use of DNAME RRs in the reverse > tree be deprecated." > > is to be replaced with the word "DELETED". This is a purely operational issue for the maintenance of the IPv6 reverse tree and thus has little place in this clarification of the DNAME document, IMHO. Also, the proposed change - apart from trying to "edit" a foreign document, which doesn't sound right to me in the first place - provides little guideline, even though the introductory text claims, it "would greatly improve the manageability of the IPv6 reverse tree". I'd rather drop this and address the issue of v6 reverse mapping in a separate document that actually says _how_ this great improvement can be achieved. > In [RFC4294], the reference to DNAME was left in as an editorial > oversight. The paragraph > > "Those nodes are NOT RECOMMENDED to support the experimental A6 and > DNAME Resource Records [RFC3363]." > > is to be replaced by > > "Those nodes are NOT RECOMMENDED to support the experimental > A6 Resource Record [RFC3363]." If that was truly an oversight, then this change should either be posted as an erratum with appropriate review and AD approval or RFC 4294 should be updated. Of course, there's little point in explicitly "NOT RECOMMENDING" DNAME implementations for v6 nodes -- as opposed to "not recommending" (the former discourages, the latter just doesn't encourage). Therefore, I really would like to see this section be dropped completely. > 5.1. Canonical hostnames cannot be below DNAME owners > > The names listed as target names of MX, NS, PTR and SRV [RFC2782] > records must be canonical hostnames. This means no CNAME or DNAME > redirection may be present during DNS lookup of the address records > for the host. This is discussed in RFC 2181 [RFC2181], section 10.3, > and RFC 1912 [RFC1912], section 2.4. For SRV see RFC 2782 [RFC2782] > page 4. NIT: s/page 4/description of "Target"/ > The upshot of this is that although the lookup of a PTR record can > involve DNAMEs, the name listed in the PTR record can not fall under > a DNAME. The same holds for NS, SRV and MX records. For example, > when punycode alternates for a zone use DNAME then the NS, MX, SRV NIT: "punycode" is probably old terminology these days, so why not explicitly mention IDNs here, but ... This seems to be a leftover from the early DNAME clarification that was inspired by the IDN TLD discussion. The explicit reference to IDN/punycode seems odd to me, since even when the document says "for example", it looks like a special IDN problem, which it isn't. IMHO the previous text in this section is good enough to serve as a reference for technical input into the IDN debate. > 7. Security Considerations > > DNAME redirects queries elsewhere, which may impact security based on > policy and the security status of the zone with the DNAME and the > redirection zone's security status. NIT: s/redirection zone's/redirection target zone's/ -- to unsubscribe send a message to namedroppers-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 Oct 6 08:12: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 4BAE13A6A1D; Mon, 6 Oct 2008 08:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.641 X-Spam-Level: X-Spam-Status: No, score=-0.641 tagged_above=-999 required=5 tests=[AWL=-0.146, 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 ma5N58zjhcvS; Mon, 6 Oct 2008 08:12:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5C9163A688C; Mon, 6 Oct 2008 08:12:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmrW3-000Es3-4r for namedroppers-data@psg.com; Mon, 06 Oct 2008 14:56:55 +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 1KmrVm-000Epp-AE for namedroppers@ops.ietf.org; Mon, 06 Oct 2008 14:56:45 +0000 Received: from [192.168.1.101] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m96EuSmR053845; Mon, 6 Oct 2008 10:56:28 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> Date: Mon, 6 Oct 2008 10:55:02 -0400 To: Michael StJohns From: Edward Lewis Subject: Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: Edward Lewis , namedroppers@ops.ietf.org 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: At 18:04 -0400 9/24/08, Michael StJohns wrote: >If "intermediate validation to protect legacy stub resolvers" were deprecated, >I'd agree with you. (can we please huh huh can we deprecate it????) If we deprecate that, what's the point of DNSSEC? DNSSEC is designed to stem cache poisoning, so that caches don't give out answers they can't verify to their clients. The client to cache is protected by TSIG, TKEY, IPSEC, or maybe just crossing one's fingers and hoping for the link to be secure. (Legacy has to count on the latter - assuming legacy is pre-TSIG et.al.) >Since we're still touting the utility of having an intermediate make a >decision about what it wants to send to a stub based on the intermediate's >understanding of security, we need to pick a consistent understanding of >that security. (In other words, the application we're concerned with here >is the stub side server of the validating resolver). Or we make use of the CD bit. In early workshops (about 10 years ago I mean) we ran into the problem that not all computers agreed on the current time. (NTP wasn't as widespread as it is now.) The way around that at the time was to use the CD bit and get the answer as it passed through from the source. >ps - anyone want to take a whack at documenting how various applications >should handle various DNSSEC outcomes? The ones I can think of off the top >of my head that should be done are: SMTP (both submitter to MTA and MTA >to MTA), HTTP (what the browser does *before* the user gets involved - >pretty sure just exposing the DNSSEC resolution state isn't the best >answer), SSH, peer-to-peer. DNSSEC was built ("repeat chorus") to stem cache poisoning, i.e., protect the admission of DNS data to the cache. It wasn't meant to protect the applications making use of the data. If an application wants to act like a cache with a verifier, fine. Then it asks for everything with CD, gets as much raw data, and does it's own check. If it can't reach the source (because of firewalls, forwarders, etc.,), well it's up a creek anyway. To an application - either their is an answer in DNS or not. The grey area is too hard to make use of, a general solution isn't useful. It's like with lame delegation testing in the reverse map. There are a lot of screw ups there, a lot follow certain pathologies that, even common, make up a small percentage of the total problems. It isn't worth trying to diagnose for the few predictable misconfigurations. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 6 08:21: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 6145228C0FF; Mon, 6 Oct 2008 08:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.627 X-Spam-Level: *** X-Spam-Status: No, score=3.627 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, 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 ADvoWg3Z8Oqw; Mon, 6 Oct 2008 08:21:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 321783A6A3F; Mon, 6 Oct 2008 08:21:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kmrns-000Gvs-So for namedroppers-data@psg.com; Mon, 06 Oct 2008 15:15:20 +0000 Received: from [66.249.92.169] (helo=ug-out-1314.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kmrng-000Gtw-KZ for namedroppers@ops.ietf.org; Mon, 06 Oct 2008 15:15:18 +0000 Received: by ug-out-1314.google.com with SMTP id q7so1897223uge.2 for ; Mon, 06 Oct 2008 08:15:06 -0700 (PDT) Received: by 10.210.126.18 with SMTP id y18mr4895876ebc.77.1223306106403; Mon, 06 Oct 2008 08:15:06 -0700 (PDT) Received: by 10.210.121.1 with HTTP; Mon, 6 Oct 2008 08:15:06 -0700 (PDT) Message-ID: Date: Mon, 6 Oct 2008 17:15:06 +0200 From: "=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=" To: namedroppers@ops.ietf.org Subject: [dnsext] Re: REMINDER: rfc2672bis WGLC expiring! In-Reply-To: <20080828161708.GR23588@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20080828161708.GR23588@commandprompt.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: SGVsbG8sCgpJIGhhdmUgcmVhZCB0aGUgZG9jdW1lbnQgKGhhdmluZyBubyBwcmlvciBkZWVwIGtu b3dsZWRnZSBvZiBETkFNRSkKYW5kIGhhdmUgZmV3IGNvbW1lbnRzOgoKPiA1LjMuMS4gIEROQU1F IGJpdCBpbiBOU0VDIHR5cGUgbWFwCj4KPiAgICBXaGVuIGEgdmFsaWRhdG9yIGNoZWNrcyB0aGUg TlNFQyBSUnMgcmV0dXJuZWQgb24gYSBuYW1lIGVycm9yCj4gICAgcmVzcG9uc2UsIGl0IFNIT1VM RCBjaGVjayB0aGF0IHRoZSBETkFNRSBiaXQgaXMgbm90IHNldC4gIElmIHRoZQo+ICAgIEROQU1F IGJpdCBpcyBzZXQgdGhlbiB0aGUgRE5BTUUgc3Vic3RpdHV0aW9uIHNob3VsZCBoYXZlIGJlZW4g ZG9uZSwKPiAgICBidXQgaGFzIG5vdC4KCklmIHlvdSBza2lwIHJlYWRpbmcgcGFyYWdyYXBoIHRp dGxlLCB5b3UgY2FuIGJlIGVhc2lseSBjb25mdXNlZCwKd2hhdCB0aGlzIGRvZXMgbWVhbnMuICBJ IHRoaW5rIHRoYXQgbWVudGlvbmluZyBpdCBpbiBwYXJhZ3JhcGggYXMKd2VsbCBtYWtlcyB0aGlu Z3MgbW9yZSBjbGVhcmVyOgoKICAgV2hlbiBhIHZhbGlkYXRvciBjaGVja3MgdGhlIE5TRUMgUlJz IHJldHVybmVkIG9uIGEgbmFtZSBlcnJvcgogICByZXNwb25zZSwgaXQgU0hPVUxEIGNoZWNrIHRo YXQgdGhlIEROQU1FIGJpdCAqaW4gTlNFQyB0eXBlIG1hcCoKICAgaXMgbm90IHNldC4gIElmIHRo ZSBETkFNRSBiaXQgaXMgc2V0IHRoZW4gdGhlIEROQU1FIHN1YnN0aXR1dGlvbgogICBzaG91bGQg aGF2ZSBiZWVuIGRvbmUsIGJ1dCBoYXMgbm90LgoKKioKClN0ZXAgNSBpbiBTZWN0aW9uIDMuMiBk b2Vzbid0ICJlbmQiLiAgSXQncyBub3QgY2xlYXIgd2hhdCB0byBkbyBuZXh0LgoKKioKCkl0J3Mg bm90IHZlcnkgY2xlYXIgd2hhdCBzZXJ2ZXIgdHlwZSAoYXV0aG9yaXRhdGl2ZSwgcmVjdXJzaXZl KSBkb2VzIHdoYXQuCkl0J3Mgc3RhcnRzIHRvIGJlIG1vcmUgY2xlYXIgaW4gU2VjdGlvbiAzLCBi dXQgSSBzdGlsbCB0aGluayB0aGF0IHRoaXMKbmVlZHMgdG8gYmUgc3RhdGVkIG1vcmUgZXhwbGlj aXRseS4KCkF0IHdoYXQgcG9pbnQgaXMgdGhlIENOQU1FIHN5bnRoZXNpcyBkb25lPwoKV2hhdCBp ZjoKCi0gZW5kLWNsaWVudCBzZW5kcyBxdWVyeSB3aXRob3V0IFVECi0gcmVjdXJzaXZlIHNlcnZl ciBzZW5kcyBxdWVyeSB3aXRoIFVECi0gYXV0aG9yaXRhdGl2ZSBzZXJ2ZXIgc2VuZCBhbnN3ZXIg d2l0aCBETkFNRSBhbmQgc3ludGhlc2lzZWQgQ05BTUUKICAoaXQgTUFZIGRyb3AgaXQpCi0gZG9l cyByZWN1cnNpdmUgc2VydmVyIHVzZSByZWNlaXZlZCBDTkFNRSB0byBhbnN3ZXIgdGhlIGVuZC1j bGllbnQKT1IKLSBkb2VzIHJlY3Vyc2l2ZSBzZXJ2ZXIgZG8gaXQncyBvd24gQ05BTUUgc3ludGhl c2lzCk9SCi0gaXQncyB1cCB0byBpbXBsZW1lbnRvcgo/CgpPbmRyZWoKLS0gCiBPbmTFmWVqIFN1 csO9CiB0ZWNobmlja8O9IMWZZWRpdGVsL0NoaWVmIFRlY2huaWNhbCBPZmZpY2VyCiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogQ1ouTklDLCB6LnMucC5vLiAgLS0g IC5jeiBkb21haW4gcmVnaXN0cnkKIEFtZXJpY2vDoSAyMywxMjAgMDAgUHJhaGEgMixDemVjaCBS ZXB1YmxpYwogbWFpbHRvOm9uZHJlai5zdXJ5QG5pYy5jeiAgaHR0cDovL25pYy5jei8KIHNpcDpv bmRyZWouc3VyeUBuaWMuY3ogdGVsOis0MjAuMjIyNzQ1MTEwCiBtb2I6KzQyMC43MzkwMTM2OTkg ICAgIGZheDorNDIwLjIyMjc0NTExMgogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0K -- to unsubscribe send a message to namedroppers-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 Oct 6 08:25: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 BE00F28C10F; Mon, 6 Oct 2008 08:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.62 X-Spam-Level: X-Spam-Status: No, score=-0.62 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 EvjwmSog-AJp; Mon, 6 Oct 2008 08:25:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E3BDF3A69BC; Mon, 6 Oct 2008 08:25:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmrrR-000HKd-IL for namedroppers-data@psg.com; Mon, 06 Oct 2008 15:19: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 1KmrrK-000HJd-9z for namedroppers@ops.ietf.org; Mon, 06 Oct 2008 15:18:59 +0000 Received: from [192.168.1.101] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m96FGTfT054009; Mon, 6 Oct 2008 11:16:29 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20081002014030.C266C50846@romeo.rtfm.com> References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> Date: Mon, 6 Oct 2008 11:08:02 -0400 To: Eric Rescorla From: Edward Lewis Subject: Re: [dnsext] Re: Protecting caches? Cc: bmanning@vacation.karoshi.com, Eric Rescorla , Nicholas Weaver , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org 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: At 18:40 -0700 10/1/08, Eric Rescorla wrote: >At Wed, 1 Oct 2008 23:08:22 +0000, >bmanning@vacation.karoshi.com wrote: >> the other option is to "fail open" ... eg. things are >> just like they are now. > >This seems plausible in some cases but not others. I.e., if the >signature is expired, that's probably fine. However, if the >signature is totally broken, doesn't accepting it kind of obviate >the point of DNSSEC? Smoothing over bumps in security is a fine way to let operational issues fester unnoticed. Absent proof of widespread, successful, attacks on DNS caches today (I am told there are many attacks that don't get air time), I bet that the majority of DNSSEC "positives" will be the result of misconfigurations. A common one will be maladjusted clocks on verifiers, especially if a user machine attempts to take validation into it's own hands. I base this on our experience in the early workshops before NTP was on all our machines (because we were so burned by time). (I once had a machine that had the right time of day and month/day, but the year was off by one. That took a lot of squinting at screens and paper before I noticed it.) There are five entities involved in an canonical verification - user, ISP, root, TLD, enterprise. While errors may be rare, I bet errors will still outpace attacks. Especially after DNSSEC has been running for some time. So failing open is probably a bad strategy, neglecting the security implications, for operational reasons much less obviating the point of DNSSEC. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 6 09:14: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 8D3B43A688C; Mon, 6 Oct 2008 09:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.242 X-Spam-Level: X-Spam-Status: No, score=-5.242 tagged_above=-999 required=5 tests=[AWL=-0.194, 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 JWcHKBHCz7I4; Mon, 6 Oct 2008 09:14:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5FB983A687C; Mon, 6 Oct 2008 09:14:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kmsem-000Ne9-IA for namedroppers-data@psg.com; Mon, 06 Oct 2008 16:10:00 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kmseb-000Ncl-Ng for namedroppers@ops.ietf.org; Mon, 06 Oct 2008 16:09:55 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m96G9mtE014852; Mon, 6 Oct 2008 09:09:48 -0700 (PDT) Message-Id: <80CAC5D9-7BDD-44E1-ACC0-90A6D585B5C6@icsi.berkeley.edu> From: Nicholas Weaver 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 v929.2) Subject: [dnsext] One other argument for local scope... Date: Mon, 6 Oct 2008 09:09:48 -0700 Cc: Nicholas Weaver X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I've made the argument that there should be a separate notion of local scope (data which is only valid for resolving an individual outstanding query) and global scope (the cache), because of the ability to prevent race-until-win attacks by limiting what gets included into the global scope. One other advantage, it makes the following case always resolve correctly: example.com NS ns.example2.org ns.example2.org A 12.34.56.78 example2.org NS ns.example.com ns.example.com A 90.12.34.56 This will resolve both correctly AND safely: A query to .com for www.example.com will get: example.com NS ns.example2.org ns.example2.org A 12.34.56.78 Since it is safe to use the value for ns.example2.org's A record within the local scope (after all, you trust that example.com's NS is ns.example2.org, so you can trust that A record solely for the purpose of this lookup), the recursive resolver will contact ns.example2.org and get the proper value. Yet because it is not within the global scope, the out-of-bailywick A record can't affect any other query, making it safe. Yet if you have only a global scope (only a cache), you can NEVER accept the A record for ns.example2.org if you want safety, instead you'd try to query .org for ns.example2.org, which points you to .com, which will fail (Open the box with the crowbar inside the box). Yet if you want resolution to work with only global scope, you are unsafe, as an attacker could use this to at least temporarily bind an arbitrary name to his value (old school cache poisoning). Thoughts? Comments? One other question: Is there any document explicitly forbidding or recommending against the case in question? -- to unsubscribe send a message to namedroppers-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 Oct 6 09:27: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 985F028C1F5; Mon, 6 Oct 2008 09:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 cwMupHd8wZFt; Mon, 6 Oct 2008 09:27:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9F77028C1F2; Mon, 6 Oct 2008 09:27:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kmsrm-000P4J-MK for namedroppers-data@psg.com; Mon, 06 Oct 2008 16:23:26 +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 1Kmsrj-000P2y-3w for namedroppers@ops.ietf.org; Mon, 06 Oct 2008 16:23:25 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 2D2BAAB5EA; Mon, 6 Oct 2008 16:22:20 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Nicholas Weaver cc: IETF DNSEXT WG In-Reply-To: Your message of "Mon, 06 Oct 2008 09:09:48 MST." <80CAC5D9-7BDD-44E1-ACC0-90A6D585B5C6@icsi.berkeley.edu> References: <80CAC5D9-7BDD-44E1-ACC0-90A6D585B5C6@icsi.berkeley.edu> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Mon, 06 Oct 2008 16:22:20 +0000 Message-ID: <41404.1223310140@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 2D2BAAB5EA.0B5B4 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: [dnsext] One other argument for local scope... Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Thoughts? Comments? i am becoming very comfortable with the idea of local scope. -- to unsubscribe send a message to namedroppers-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 Oct 6 09:30: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 AD35C3A6ACE; Mon, 6 Oct 2008 09:30:07 -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.110, 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 vxXYDhRj0eL7; Mon, 6 Oct 2008 09:30:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C918A3A67DD; Mon, 6 Oct 2008 09:30:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmsvI-000PU4-7x for namedroppers-data@psg.com; Mon, 06 Oct 2008 16:27:04 +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 1Kmsv5-000PS1-UE for namedroppers@ops.ietf.org; Mon, 06 Oct 2008 16:26:54 +0000 Received: from [192.168.1.101] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m96GQRms027200; Mon, 6 Oct 2008 12:26:28 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <8263ob2xyy.fsf@mid.bfk.de> References: <200809262103.m8QL3USA067104@drugs.dv.isc.org> <8263ob2xyy.fsf@mid.bfk.de> Date: Mon, 6 Oct 2008 12:25:06 -0400 To: Florian Weimer From: Edward Lewis Subject: the DO bit Re: [dnsext] Reminder: two WGLC closing in one week Cc: Mark Andrews , Andrew Sullivan , namedroppers@ops.ietf.org 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: At 10:38 +0200 10/2/08, Florian Weimer wrote: >* Mark Andrews: > >>> DO necessarily implies UD because the synthesized CNAME is not signed >>> and thus not visible to a DNSSEC client (section 3.1). >> >> DO indicates that you want the DNSSEC records. > >DO was originally conceived as "intent to validate". It's not used >this way, though. No, "DO indicates that you want the DNSSEC records" is accurate. We (= the group that cobbled DNSSEC into BIND 8) stood up a name server before the DO bit was invented. After not hearing from the government agency that was funding the work on DNSSEC for a few days we realized that something was amiss. It turned out that we were responding to A record requests with responses enlarged by the DNSSEC records and the funding agency's firewalls were rejecting all traffic to port 53 over a certain size. This "eating our own dogfood" experience led to the DO bit. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 6 09:50: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 0C4DB3A6AFE; Mon, 6 Oct 2008 09:50:30 -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=[AWL=0.000, 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 OGc1rToFw4Y1; Mon, 6 Oct 2008 09:50:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 19E673A68F8; Mon, 6 Oct 2008 09:50:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmtEJ-0001eu-2o for namedroppers-data@psg.com; Mon, 06 Oct 2008 16:46:43 +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 1KmtEA-0001Up-IR for namedroppers@ops.ietf.org; Mon, 06 Oct 2008 16:46:37 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m96GhH7E029278; Mon, 6 Oct 2008 16:43:18 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m96GhHGS029277; Mon, 6 Oct 2008 16:43:17 GMT Date: Mon, 6 Oct 2008 16:43:17 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Cc: Florian Weimer , Mark Andrews , Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: the DO bit Re: [dnsext] Reminder: two WGLC closing in one week Message-ID: <20081006164317.GA29255@vacation.karoshi.com.> References: <200809262103.m8QL3USA067104@drugs.dv.isc.org> <8263ob2xyy.fsf@mid.bfk.de> 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, Oct 06, 2008 at 12:25:06PM -0400, Edward Lewis wrote: > At 10:38 +0200 10/2/08, Florian Weimer wrote: > >* Mark Andrews: > > > >>> DO necessarily implies UD because the synthesized CNAME is not signed > >>> and thus not visible to a DNSSEC client (section 3.1). > >> > >> DO indicates that you want the DNSSEC records. > > > >DO was originally conceived as "intent to validate". It's not used > >this way, though. > > No, "DO indicates that you want the DNSSEC records" is accurate. > > We (= the group that cobbled DNSSEC into BIND 8) stood up a name > server before the DO bit was invented. After not hearing from the > government agency that was funding the work on DNSSEC for a few days > we realized that something was amiss. It turned out that we were > responding to A record requests with responses enlarged by the DNSSEC > records and the funding agency's firewalls were rejecting all traffic > to port 53 over a certain size. This "eating our own dogfood" > experience led to the DO bit. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar it was a fine way to reduce email traffic. :) and shows the wisdom of actually "eating our own dog food". --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 Oct 6 11:56: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 609043A6A48; Mon, 6 Oct 2008 11:56:23 -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 Is4LM7G9ad+G; Mon, 6 Oct 2008 11:56:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3E4533A6A28; Mon, 6 Oct 2008 11:56:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmvCS-000EA3-K1 for namedroppers-data@psg.com; Mon, 06 Oct 2008 18:52:56 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmvCL-000E97-AU for namedroppers@ops.ietf.org; Mon, 06 Oct 2008 18:52:53 +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 D3BBB34AA79; Mon, 6 Oct 2008 11:52:48 -0700 (PDT) Cc: Namedroppers WG Message-Id: <2E662103-4B2F-40BD-8AF7-BA16F2E5CB35@virtualized.org> From: David Conrad To: Edward Lewis 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 v929.2) Subject: Re: the DO bit Re: [dnsext] Reminder: two WGLC closing in one week Date: Mon, 6 Oct 2008 11:52:40 -0700 References: <200809262103.m8QL3USA067104@drugs.dv.isc.org> <8263ob2xyy.fsf@mid.bfk.de> X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Hi, On Oct 6, 2008, at 9:25 AM, Edward Lewis wrote: >>> DO indicates that you want the DNSSEC records. >> DO was originally conceived as "intent to validate". It's not used >> this way, though. > No, "DO indicates that you want the DNSSEC records" is accurate. As someone with some minor involvement in the definition of DO, I can say that I actually _intended_ it to signal "intent to validate". It honestly never occurred to me that people would request DNSSEC-related RRs with no intent to validate them. The fact that BINDv9 hardcodes DO on, even if trust anchors aren't configured and regardless of the state of the multiple variables you have to set to turn on DNSSEC in BIND, came as something of a surprise. "Oops. My bad." > After not hearing from the government agency that was funding the > work on DNSSEC for a few days we realized that something was amiss. > It turned out that we were responding to A record requests with > responses enlarged by the DNSSEC records and the funding agency's > firewalls were rejecting all traffic to port 53 over a certain > size. This "eating our own dogfood" experience led to the DO bit. That was part of it. There were also resolvers out there at the time that did ... questionable things if you supplied them with RRs they didn't understand (some version of Windows NT DNS server, IIRC). And there was some concern that the root servers might be adversely impacted by having _all_ of their responses increase by 3 to 6 times. 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 Oct 6 11:58: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 17F563A6A48; Mon, 6 Oct 2008 11:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.592 X-Spam-Level: X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=0.903, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, 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 m0ACHHPJFIEs; Mon, 6 Oct 2008 11:58:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 060B53A686A; Mon, 6 Oct 2008 11:58:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kmv9T-000Ds6-1t for namedroppers-data@psg.com; Mon, 06 Oct 2008 18:49:51 +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 1Kmv9P-000DrD-41 for namedroppers@ops.ietf.org; Mon, 06 Oct 2008 18:49:49 +0000 Received: from [0.0.0.0] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m96Incrj028660; Mon, 6 Oct 2008 14:49:38 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <48CB0481.3090800@chrysler.com> References: <20080911152052.GH1008@commandprompt.com> <48CB0481.3090800@chrysler.com> Date: Mon, 6 Oct 2008 14:49:05 -0400 To: Kevin Darcy From: Edward Lewis Subject: Re: [dnsext] Request for new RRTYPE assignment: "ASSET" Cc: namedroppers@ops.ietf.org 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: At 20:08 -0400 9/12/08, Kevin Darcy wrote: >but as a matter of semantics, the word "asset" already has an >established meaning in the English language... "me too." >Would an alternative mnemonic be considered? > >ASLIST? > >ASGROUP? > >ASNUMS? ASR? (for AS Range, and to make it short - just 3 letters) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 6 21:02: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 A808E3A6828; Mon, 6 Oct 2008 21:02:51 -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.041, 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 5amoqNUUpi1W; Mon, 6 Oct 2008 21:02:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B5A033A684D; Mon, 6 Oct 2008 21:02:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kn3fu-000AIq-Td for namedroppers-data@psg.com; Tue, 07 Oct 2008 03:55:54 +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 1Kn3fr-000AIT-KG for namedroppers@ops.ietf.org; Tue, 07 Oct 2008 03:55:53 +0000 Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id C33BA6B5D8D; Mon, 6 Oct 2008 20:55:50 -0700 (PDT) Date: Mon, 06 Oct 2008 20:55:50 -0700 From: Eric Rescorla To: Edward Lewis Cc: Eric Rescorla , bmanning@vacation.karoshi.com, Nicholas Weaver , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? In-Reply-To: References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> 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: <20081007035550.C33BA6B5D8D@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Mon, 6 Oct 2008 11:08:02 -0400, Edward Lewis wrote: > > At 18:40 -0700 10/1/08, Eric Rescorla wrote: > >At Wed, 1 Oct 2008 23:08:22 +0000, > >bmanning@vacation.karoshi.com wrote: > > >> the other option is to "fail open" ... eg. things are > >> just like they are now. > > > >This seems plausible in some cases but not others. I.e., if the > >signature is expired, that's probably fine. However, if the > >signature is totally broken, doesn't accepting it kind of obviate > >the point of DNSSEC? > > Smoothing over bumps in security is a fine way to let operational > issues fester unnoticed. Absent proof of widespread, successful, > attacks on DNS caches today (I am told there are many attacks that > don't get air time), I bet that the majority of DNSSEC "positives" > will be the result of misconfigurations. I totally agree with this claim, but if your resolver accepts bogus signatures, then what's the point of having signatures at all? -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 Tue Oct 7 03:24: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 5523D28C168; Tue, 7 Oct 2008 03:24:39 -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 UlCZec4KHaSI; Tue, 7 Oct 2008 03:24:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C3D228C15E; Tue, 7 Oct 2008 03:24:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kn9Z0-000Id8-2F for namedroppers-data@psg.com; Tue, 07 Oct 2008 10:13:10 +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 1Kn9Ys-000IcO-PU for namedroppers@ops.ietf.org; Tue, 07 Oct 2008 10:13:04 +0000 Received: from bmp-336-ms506.wa.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1Kn9Ym-00015j-3R; Tue, 07 Oct 2008 10:12:56 +0000 Subject: Re: [dnsext] Err, CORRECT link for my comments... From: Shane Kerr To: Nicholas Weaver Cc: IETF DNSEXT WG In-Reply-To: <0BFEFBF0-E0EA-4A5F-9371-EA0FCE173C20@icsi.berkeley.edu> References: <0BFEFBF0-E0EA-4A5F-9371-EA0FCE173C20@icsi.berkeley.edu> Content-Type: text/plain Date: Tue, 07 Oct 2008 12:12:55 +0200 Message-Id: <1223374375.6688.259.camel@shane-macbook-pro> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-Authenticated: True Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Nicholas, On Tue, 2008-09-30 at 11:13 -0700, Nicholas Weaver wrote: > The proper name and link: > > http://www.ietf.org/internet-drafts/draft-weaver-dnsext-comprehensive-resolver-00.txt In general, very cool. As a specific comment, I think standardizing detection of entropy stripping might be worthwhile. Perhaps there is already technology that we can steal for this from various NAT working groups? Also, for the idea of optimizing by not fetching all the address records for an NS set, or fetching the NS set only after the second query, perhaps instead one could avoid every fetching the full set of A records, but rather fetch an additional record for each query? So for ns.example.com, ns2.example.com, ns3.example.com, the first query would look up ns.example.com, the second would look up ns2.example.com, and so on. You could even delay this sort of incremental lookups until the 2nd query. Actually, while your ideas of optimization seems to have come out of a desire to minimize the costs of forgery resistance, I think the idea of optimizing resolver performance is worthwhile outside of this context. Maybe this can be turned into a separate draft? :) -- Shane -- to unsubscribe send a message to namedroppers-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 Oct 7 05:14: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 8927E3A6B6C; Tue, 7 Oct 2008 05:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.683 X-Spam-Level: X-Spam-Status: No, score=-0.683 tagged_above=-999 required=5 tests=[AWL=-0.188, 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 uFTmfIIQJvId; Tue, 7 Oct 2008 05:14:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF3743A6B56; Tue, 7 Oct 2008 05:14:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnBNM-0008rF-FP for namedroppers-data@psg.com; Tue, 07 Oct 2008 12:09:16 +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 1KnBNC-0008pj-6u for namedroppers@ops.ietf.org; Tue, 07 Oct 2008 12:09:11 +0000 Received: from [192.168.1.101] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m97C8rs7036758; Tue, 7 Oct 2008 08:08:54 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20081007035550.C33BA6B5D8D@kilo.rtfm.com> References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> <20081007035550.C33BA6B5D8D@kilo.rtfm.com> Date: Tue, 7 Oct 2008 08:08:49 -0400 To: Eric Rescorla From: Edward Lewis Subject: Re: [dnsext] Re: Protecting caches? Cc: Edward Lewis , Eric Rescorla , bmanning@vacation.karoshi.com, Nicholas Weaver , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org 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: At 20:55 -0700 10/6/08, Eric Rescorla wrote: >I totally agree with this claim, but if your resolver >accepts bogus signatures, then what's the point of having >signatures at all? Depends on the exact meaning of "accepts." For normal use, a bogus signature should never be shrugged off or it is useless to invest the time in the entire franchise. The only time data with a bogus signature should be "accepted" is in a diagnostic mode, testing to determine if the bogosity is the result of an operational error or indeed a malicious attack. Accepted in the latter case means "is inspected." I think the result of DNSSEC is binary to an application - got a response[0] or didn't. [0] - includes NXDOMAIN and all other results. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 7 08:36: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 55C5D3A6B3A; Tue, 7 Oct 2008 08:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.387 X-Spam-Level: X-Spam-Status: No, score=-4.387 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_URI_EQUALS=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlw7x0-iv8cX; Tue, 7 Oct 2008 08:36:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF3AC3A699C; Tue, 7 Oct 2008 08:36:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnEVQ-000C24-59 for namedroppers-data@psg.com; Tue, 07 Oct 2008 15:29:48 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnEVG-000C0t-Ve for namedroppers@ops.ietf.org; Tue, 07 Oct 2008 15:29:46 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m97FT8Q3018413; Tue, 7 Oct 2008 08:29:32 -0700 (PDT) Cc: Nicholas Weaver , IETF DNSEXT WG Message-Id: <4E531501-8C44-4499-9718-5FB86DE804E8@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Shane Kerr In-Reply-To: <1223374375.6688.259.camel@shane-macbook-pro> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [dnsext] Err, CORRECT link for my comments... Date: Tue, 7 Oct 2008 08:29:08 -0700 References: <0BFEFBF0-E0EA-4A5F-9371-EA0FCE173C20@icsi.berkeley.edu> <1223374375.6688.259.camel@shane-macbook-pro> X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Oct 7, 2008, at 3:12 AM, Shane Kerr wrote: > Nicholas, > > On Tue, 2008-09-30 at 11:13 -0700, Nicholas Weaver wrote: >> The proper name and link: >> >> http://www.ietf.org/internet-drafts/draft-weaver-dnsext-comprehensive-resolver-00.txt > > In general, very cool. > > > As a specific comment, I think standardizing detection of entropy > stripping might be worthwhile. Perhaps there is already technology > that > we can steal for this from various NAT working groups? You need to do SOME probe to some remote server in order to detect a NAT or other weird device, and I think the best is a DNS authoritative server, simply because you also want to check for 0x20, renumbering of transaction IDs, and other behavior that some stupid stateful "firewall" may remove in the name of securing your network. The load on such an authority is rather low when targeting recursive resolvers: how often do those reboot or change IP? Such load would be nontrivial but not huge if you used this technique for stub resolvers: Say 100M systems, churn IP once a day: 100M queries/day x 200B/query = 20 GB/day. At $.20/GB, thats $4/day in bandwidth cost, not huge mind you but not something you are going to do for free without compensation. But this brings up a good point: for a stub resolver, what counts is the behavior between the stub and its recursive resolver, it only needs to query the behavior between the two, so a wildcarded name handled by the recursive resolver would probably be a good thing. Note also, by querying an authority (such as entropy.*.nettest.icir.org which is up at the moment, this is an experimental server so it is NOT stable however), since that gives the behavior of the recursive resolver, a stub resolver could use this to guage whether a recursive resolver is actually safe. If a recursive resolver is unsafe, it could switch to its own internal recursive resolver, or, better yet, switch to its own recursive resolver AND gripe to the user. To get a current example, this is how it returns: entropy.nettest.icIr.org. 1 IN CNAME status.pt=53495.ad=192.150.186.71.id=12321.0x20=T.nettest.icIr.org. status.pt=53495.ad=192.150.186.71.id=12321.0x20=T.nettest.icIr.org. 1 IN A 10.1.2.3 > Also, for the idea of optimizing by not fetching all the address > records > for an NS set, or fetching the NS set only after the second query, > perhaps instead one could avoid every fetching the full set of A > records, but rather fetch an additional record for each query? > > So for ns.example.com, ns2.example.com, ns3.example.com, the first > query > would look up ns.example.com, the second would look up > ns2.example.com, > and so on. > > You could even delay this sort of incremental lookups until the 2nd > query. Well, once you get one authoritative server, you don't need another unless there is a failure, if you are willing to tolerate slightly higher latency if you picked a "far" authoritative server. This is why Paul Vixie suggested "pick most-precise" if you are fetching one, because although thats might not be the closest, it is highly likely to be the same latency order as the eventual use of the remote system, so if you chose the higher latency choice it isn't likely to impact user experience too badly. > Actually, while your ideas of optimization seems to have come out of a > desire to minimize the costs of forgery resistance, I think the idea > of > optimizing resolver performance is worthwhile outside of this context. > Maybe this can be turned into a separate draft? :) Well, the problem is: its trying to get BACK to the performance of current bailywick checking. The rules for including into the global scope in conventional bailywick checking are more efficient in terms of reducing queries (those are the base-line case), but the conventional bailywick checking rules enable race until win (and also may introduce some strange sidecases that are probably safe but I still worry about). -- to unsubscribe send a message to namedroppers-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 Oct 7 08:57: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 B1F7F3A698E; Tue, 7 Oct 2008 08:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.287 X-Spam-Level: X-Spam-Status: No, score=-4.287 tagged_above=-999 required=5 tests=[AWL=-0.905, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_URI_EQUALS=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOkrPNFdwfcw; Tue, 7 Oct 2008 08:57:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 882453A6967; Tue, 7 Oct 2008 08:57:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnErI-000ECH-Sy for namedroppers-data@psg.com; Tue, 07 Oct 2008 15:52:24 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnEr5-000EAf-80 for namedroppers@ops.ietf.org; Tue, 07 Oct 2008 15:52:16 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m97Fq4Be021514; Tue, 7 Oct 2008 08:52:08 -0700 (PDT) Cc: Shane Kerr , IETF DNSEXT WG Message-Id: From: Nicholas Weaver To: Nicholas Weaver In-Reply-To: <4E531501-8C44-4499-9718-5FB86DE804E8@ICSI.Berkeley.EDU> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [dnsext] Err, CORRECT link for my comments... Date: Tue, 7 Oct 2008 08:52:03 -0700 References: <0BFEFBF0-E0EA-4A5F-9371-EA0FCE173C20@icsi.berkeley.edu> <1223374375.6688.259.camel@shane-macbook-pro> <4E531501-8C44-4499-9718-5FB86DE804E8@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Oct 7, 2008, at 8:29 AM, Nicholas Weaver wrote: > Note also, by querying an authority (such as > entropy.*.nettest.icir.org which is up at the moment, this is an > experimental server so it is NOT stable however), since that gives > the behavior of the recursive resolver, a stub resolver could use > this to guage whether a recursive resolver is actually safe. If a > recursive resolver is unsafe, it could switch to its own internal > recursive resolver, or, better yet, switch to its own recursive > resolver AND gripe to the user. > > > To get a current example, this is how it returns: > > entropy.nettest.icIr.org. 1 IN CNAME > status.pt=53495.ad=192.150.186.71.id=12321.0x20=T.nettest.icIr.org. > status.pt=53495.ad=192.150.186.71.id=12321.0x20=T.nettest.icIr.org. > 1 IN A 10.1.2.3 Oh, a couple comments as everyone seems to be testing the server: The 0x20 test is "Is it all lower or all upper or mixed case". Thus there is a 1 in ~2^20 chance that an 0x20 using resolver will falsely be reported as not using 0x20. The TTL is 1 second, but just in case the recursive resolver doesn't respect very short TTLs (I had it as 1 second because I don't necessarily trust 0 seconds to be abided by either), there is an arbitrary wildcarding in there for subdomains. Thus entropy.a.nettest.icir.org entropy.b.nettest.icir.org entropy.c.nettest.icir.org allows back to back tests regardless of how the resolver caches the result. -- to unsubscribe send a message to namedroppers-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 Oct 7 10:03: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 B6DA23A6B3A; Tue, 7 Oct 2008 10:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.666 X-Spam-Level: X-Spam-Status: No, score=-0.666 tagged_above=-999 required=5 tests=[AWL=-0.171, 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 n3u0xLRv5C4j; Tue, 7 Oct 2008 10:03:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 875A328C0F8; Tue, 7 Oct 2008 10:03:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnFsc-000M0E-Id for namedroppers-data@psg.com; Tue, 07 Oct 2008 16:57:50 +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 1KnFsU-000Lxz-Sy for namedroppers@ops.ietf.org; Tue, 07 Oct 2008 16:57:44 +0000 Received: from [10.31.201.38] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m97GuuaL039318; Tue, 7 Oct 2008 12:56:56 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20081007035550.C33BA6B5D8D@kilo.rtfm.com> References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> <20081007035550.C33BA6B5D8D@kilo.rtfm.com> Date: Tue, 7 Oct 2008 12:56:19 -0400 To: Eric Rescorla From: Edward Lewis Subject: Re: [dnsext] Re: Protecting caches? Cc: Edward Lewis , Eric Rescorla , bmanning@vacation.karoshi.com, Nicholas Weaver , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org 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: At 20:55 -0700 10/6/08, Eric Rescorla wrote: >I totally agree with this claim, but if your resolver >accepts bogus signatures, then what's the point of having >signatures at all? Perhaps my "is a fine way" and "fester unnoticed" weren't taken sarcastically enough. ;) If data accompanied by a signature that is proven to be invalid is accepted at all, then the effort is a waste. And what I meant was, in addition, if you do you are enabling poor operational practices and other poor habits. The only time a DNS verifier/iterator should pass on data that failed verification is within a debugging/reporting context. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 7 13:06: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 72A153A68A0; Tue, 7 Oct 2008 13:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.584 X-Spam-Level: X-Spam-Status: No, score=-0.584 tagged_above=-999 required=5 tests=[AWL=-0.089, 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 aJNusMEwAtNp; Tue, 7 Oct 2008 13:06:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 85B393A681A; Tue, 7 Oct 2008 13:06:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnIhS-000ISG-GC for namedroppers-data@psg.com; Tue, 07 Oct 2008 19:58:30 +0000 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 1KnIhO-000IQM-Ss for namedroppers@ops.ietf.org; Tue, 07 Oct 2008 19:58:28 +0000 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 137A850846; Tue, 7 Oct 2008 13:11:53 -0700 (PDT) Date: Tue, 07 Oct 2008 13:11:53 -0700 From: Eric Rescorla To: Edward Lewis Cc: Eric Rescorla , bmanning@vacation.karoshi.com, Nicholas Weaver , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? In-Reply-To: References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> <20081007035550.C33BA6B5D8D@kilo.rtfm.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: <20081007201153.137A850846@romeo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Tue, 7 Oct 2008 12:56:19 -0400, Edward Lewis wrote: > > At 20:55 -0700 10/6/08, Eric Rescorla wrote: > > >I totally agree with this claim, but if your resolver > >accepts bogus signatures, then what's the point of having > >signatures at all? > > Perhaps my "is a fine way" and "fester unnoticed" weren't taken > sarcastically enough. ;) Either that or my IQ is low today. I was totally baffled by it. > If data accompanied by a signature that is proven to be invalid is > accepted at all, then the effort is a waste. And what I meant was, > in addition, if you do you are enabling poor operational practices > and other poor habits. > > The only time a DNS verifier/iterator should pass on data that failed > verification is within a debugging/reporting context. I tend to agree with this, but isn't the consequence going to be a lot of hard failures due to otherwise innocuous misconfigurations? -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 Tue Oct 7 13:32: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 E24F228C0DE; Tue, 7 Oct 2008 13:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.651 X-Spam-Level: X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[AWL=-0.156, 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 h4LbNWqwnEMz; Tue, 7 Oct 2008 13:32:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1136E3A6B99; Tue, 7 Oct 2008 13:32:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnJ7t-000Lbe-Fl for namedroppers-data@psg.com; Tue, 07 Oct 2008 20:25:49 +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 1KnJ7p-000Lan-Hs for namedroppers@ops.ietf.org; Tue, 07 Oct 2008 20:25:47 +0000 Received: from [10.31.201.38] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m97KPPKh041329; Tue, 7 Oct 2008 16:25:25 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20081007201153.137A850846@romeo.rtfm.com> References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> <20081007035550.C33BA6B5D8D@kilo.rtfm.com> <20081007201153.137A850846@romeo.rtfm.com> Date: Tue, 7 Oct 2008 16:25:21 -0400 To: Eric Rescorla From: Edward Lewis Subject: Re: [dnsext] Re: Protecting caches? Cc: Edward Lewis , Eric Rescorla , bmanning@vacation.karoshi.com, Nicholas Weaver , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org 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: At 13:11 -0700 10/7/08, Eric Rescorla wrote: >I tend to agree with this, but isn't the consequence going to be a lot >of hard failures due to otherwise innocuous misconfigurations? Yeah. How do you decide between a bogus signature due to maliciousness and a bogus signature due to misconfiguration and a bogus signature due to a disagreement over policy, etc.? (Perhaps I should add, if there's just one signature to consider then it's cut and dry. If there are multiple signatures, if one works we are cool, if none work there's trouble. That is one way around disagreement over policy/some misconfigurations, etc.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 7 13:36: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 2683F3A6809; Tue, 7 Oct 2008 13:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.924 X-Spam-Level: X-Spam-Status: No, score=-0.924 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 NFzY3ob-CT4T; Tue, 7 Oct 2008 13:36:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 054E43A6A89; Tue, 7 Oct 2008 13:36:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnJDR-000MJL-72 for namedroppers-data@psg.com; Tue, 07 Oct 2008 20:31:33 +0000 Received: from [209.85.198.230] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnJDF-000MGr-4E for namedroppers@ops.ietf.org; Tue, 07 Oct 2008 20:31:23 +0000 Received: by rv-out-0506.google.com with SMTP id b25so3313900rvf.41 for ; Tue, 07 Oct 2008 13:31: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:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=F+OC/Qm27rJMwWmCsFjm5QxudFIkyhxZdECEun59qKU=; b=BCglfzO4895U3LFgwOb9sJN4gFxVfFtQHZUzAgHKyqLssfJ06ayABlJ6p1r/bQWva/ CjcBlS3wFWIUeWOOCnxUfKORRO1xv8BSL1y7euuHPzhq6VcfvqFgnPsc3DZETMs4ZlJ8 zChLEXXQoFAdVB58sF7i7kLAwlYECAyQc2jFA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=CZnICf+btf7fGnSM01e4Y4/9U5DFoyS4AcjhNJhLR8yyiQhV2DJHu7rqPoJjaJJi7d W5pnbVt2JWmUd3iDKG2WWgjYFK0FL9/ap/JPuvWO4YblqWvm4MV+uYv+NiJn6MJ/VRf2 pU7tDtCNK2VAX+YQ/g5g1kJaTp6tgasRscdxs= Received: by 10.141.76.21 with SMTP id d21mr4242913rvl.242.1223411479725; Tue, 07 Oct 2008 13:31:19 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Tue, 7 Oct 2008 13:31:19 -0700 (PDT) Message-ID: <396556a20810071331n42b933dfn6836e79a7c658e80@mail.gmail.com> Date: Tue, 7 Oct 2008 13:31:19 -0700 From: "Adam Langley" To: namedroppers@ops.ietf.org Subject: [dnsext] Rabin-Williams signatures for DNSSEC MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 64c2def11fa5842f Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I had the pleasure of chatting with Paul Vixie recently and he described some of the cryptographic issues with DNSSEC, specifically that smaller signatures would be very nice. So I wrote up [1] and [2]. [1] is in the form of an ID, although I've not actually submitted it as such yet. [2] contains the full (executable) specification of the signature scheme described in [1] Abstract: This document describes how to use Rabin-Williams public keys and signatures in DNSSEC. Rabin-Williams signatures provide for faster verification and smaller signatures than an equivalent RSA scheme, yet a hash-generic attack is provably equivalent to factoring. Introduction: DNSSEC seeks to secure the Domain Name System by using signatures that are precomputable to avoid requiring nameservers to perform a public key operation for each request. Thus, for DNSSEC, verification speed is vastly more important than signing speed. However, DNSSEC still uses UDP as the primary transport layer protocol and, despite increasing the maximum payload size, large signatures are problematic both because of bandwidth and because of the amplification possibilities in a denial of service attack. This would suggest that elliptic curve signature schemes should be attractive. By using a group of points of an elliptic curve rather than a multiplicative group, index calculus (and related) attacks are much less effective and a smaller group is still sufficiently secure. Using the ECDSA scheme on the NIST P192 curve results in 384-bit signatures. However, the verification operation is nearly 25x slower than 1024-bit RSA (2.33GHz Core2). A 1024-bit Rabin-Williams scheme (B=0, fixed, unprincipled, compressed) results in 512-bit signatures and the verification speed is about 4x faster than 1024-bit RSA. Due to Bernstein, we have a proof that a hash generic attack on such a scheme is equivalent to factoring. [1] http://www.imperialviolet.org/binary/draft-agl-dnsext-rwb0fuz.html [2] http://github.com/agl/rwb0fuz1024/tree/master%2Frwb0fuz1024.pdf?raw=true Cheers -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.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 Oct 7 13: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 AB42E3A67B3; Tue, 7 Oct 2008 13:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.705 X-Spam-Level: X-Spam-Status: No, score=-4.705 tagged_above=-999 required=5 tests=[AWL=-1.439, 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 wWgXD1kB9fYZ; Tue, 7 Oct 2008 13:57:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AEC083A6768; Tue, 7 Oct 2008 13:57:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnJXH-000Ot1-Fi for namedroppers-data@psg.com; Tue, 07 Oct 2008 20:52:03 +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 1KnJX6-000OrA-6O for namedroppers@ops.ietf.org; Tue, 07 Oct 2008 20:51:53 +0000 Received: from bmp-336-ms506.wa.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1KnJWt-0005uG-4W; Tue, 07 Oct 2008 20:51:39 +0000 Message-ID: <48EBCBDE.2040408@ca.afilias.info> Date: Tue, 07 Oct 2008 16:51:42 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Eric Rescorla CC: Edward Lewis , bmanning@vacation.karoshi.com, Nicholas Weaver , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> <20081007035550.C33BA6B5D8D@kilo.rtfm.com> <20081007201153.137A850846@romeo.rtfm.com> In-Reply-To: <20081007201153.137A850846@romeo.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated: True Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Eric Rescorla wrote: > At Tue, 7 Oct 2008 12:56:19 -0400, > Edward Lewis wrote: > >> If data accompanied by a signature that is proven to be invalid is >> accepted at all, then the effort is a waste. And what I meant was, >> in addition, if you do you are enabling poor operational practices >> and other poor habits. >> >> The only time a DNS verifier/iterator should pass on data that failed >> verification is within a debugging/reporting context. >> > > I tend to agree with this, but isn't the consequence going to be a lot > of hard failures due to otherwise innocuous misconfigurations? > Only if poor operational practices are observed by folks running authority servers and resolvers. E.g. the notion of "fire and forget" as an acceptable method of making changes to dnssec-critical systems. If someone runs any dnssec component, they would be well advised to stage changes with some kind of testing suite, to verify that the proposed change doesn't break the thing they operate. So, I would categorize, respectively, "a lot", "hard failures", and "otherwise innocuous" as "subjectively", "for the incautious sorts", and "you mean careless". :-) Seriously, though, the onus is on the operators of authority servers, and to a slightly lesser degree, validating resolver operators, to ensure that the bits they run, don't break when they start doing dnssec. And, the end-user really, really should never be able to disable the validation. Ever. For anyone. For any reason. 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 Tue Oct 7 14:21: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 7F6D33A6856; Tue, 7 Oct 2008 14:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[AWL=-0.144, 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 9HTlI+VXzK9M; Tue, 7 Oct 2008 14:21:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 923183A6768; Tue, 7 Oct 2008 14:21:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnJtS-00020t-DL for namedroppers-data@psg.com; Tue, 07 Oct 2008 21:14: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 1KnJtO-00020A-Lv for namedroppers@ops.ietf.org; Tue, 07 Oct 2008 21:14:56 +0000 Received: from [10.31.201.38] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m97LEEIf041761; Tue, 7 Oct 2008 17:14:15 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <48EBCBDE.2040408@ca.afilias.info> References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> <20081007035550.C33BA6B5D8D@kilo.rtfm.com> <20081007201153.137A850846@romeo.rtfm.com> <48EBCBDE.2040408@ca.afilias.info> Date: Tue, 7 Oct 2008 17:14:01 -0400 To: Brian Dickson From: Edward Lewis Subject: Re: [dnsext] Re: Protecting caches? Cc: Eric Rescorla , Edward Lewis , bmanning@vacation.karoshi.com, Nicholas Weaver , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org 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: At 16:51 -0400 10/7/08, Brian Dickson wrote: >Seriously, though, the onus is on the operators of authority servers, >and to a slightly lesser degree, validating resolver operators, >to ensure that the bits they run, don't break when they start doing dnssec. I believe the reverse will be true. When a web client user encounters an error due to a DNSSEC thumbs down, they call the ISP help desk (ie, "the Internet is down"). The ISP will "pay" when there are errors, therefore that's where the onus matters. The authority servers (root, tld, enterprise) all have responsibilities to make sure the DNSSEC is set up right, true. It is up to the ISP to make sure the validating cache server has the right keys and to have a help desk that can deal with the support calls. Worse for the ISP, there are multiple authority servers were mistakes can be made for just one validation chain, as well as user (ISP customer) mistakes. (One unwritten [until now] assumption is that the costs for help desk are considerable when the calls roll in.) The onus isn't only on the authority servers, but they do need to do things right. >And, the end-user really, really should never be able to disable the >validation. Ever. For anyone. For any reason. I don't know about that. If the problem is more likely to be due to an operational error then it is more likely not to be dangerous to turn off DNSSEC. 'Course, I am making a wild assumption that the incidence of "fat fingering" is greater than actual attacks. This assumption is not supported by any facts. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 7 14:25: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 604963A69E2; Tue, 7 Oct 2008 14:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.038 X-Spam-Level: X-Spam-Status: No, score=-5.038 tagged_above=-999 required=5 tests=[AWL=0.010, 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 NoIc17jqepS5; Tue, 7 Oct 2008 14:25:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 89F683A686C; Tue, 7 Oct 2008 14:25:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnK0H-0002qj-BQ for namedroppers-data@psg.com; Tue, 07 Oct 2008 21:22:01 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnK0D-0002q9-UK for namedroppers@ops.ietf.org; Tue, 07 Oct 2008 21:21:59 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m97LL4vc008070; Tue, 7 Oct 2008 14:21:28 -0700 (PDT) Cc: Nicholas Weaver , Brian Dickson , Eric Rescorla , bmanning@vacation.karoshi.com, mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Edward Lewis 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 v929.2) Subject: Re: [dnsext] Re: Protecting caches? Date: Tue, 7 Oct 2008 14:21:04 -0700 References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> <20081007035550.C33BA6B5D8D@kilo.rtfm.com> <20081007201153.137A850846@romeo.rtfm.com> <48EBCBDE.2040408@ca.afilias.info> X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Oct 7, 2008, at 2:14 PM, Edward Lewis wrote: > At 16:51 -0400 10/7/08, Brian Dickson wrote: > >> Seriously, though, the onus is on the operators of authority servers, >> and to a slightly lesser degree, validating resolver operators, >> to ensure that the bits they run, don't break when they start doing >> dnssec. > > I believe the reverse will be true. When a web client user > encounters an error due to a DNSSEC thumbs down, they call the ISP > help desk (ie, "the Internet is down"). The ISP will "pay" when > there are errors, therefore that's where the onus matters. > > The authority servers (root, tld, enterprise) all have > responsibilities to make sure the DNSSEC is set up right, true. It > is up to the ISP to make sure the validating cache server has the > right keys and to have a help desk that can deal with the support > calls. Worse for the ISP, there are multiple authority servers were > mistakes can be made for just one validation chain, as well as user > (ISP customer) mistakes. > > (One unwritten [until now] assumption is that the costs for help > desk are considerable when the calls roll in.) > > The onus isn't only on the authority servers, but they do need to do > things right. If this is a solution, NO ISP will install a validating DNSSEC resolver. Most of the key-management F@ups are the fault of the authorities, not of the resolvers. In fact, the whole idea of the root of trust is that beyond just making sure the CA-equivelent keys are OK, the resolver must be able to find everything out. That alone is a huge incentive to be "last mover": A good ISP can harden their resolver against out of path attacks to an effectively arbirtary level. And against in-path attackers, the customer's traffic is also screwed, not just the naming. So if DNSSEC results in more tech support calls because items don't resolve, through fault of the authorities and not the ISP's resolver, no ISP in its right mind would support it! Or if support is mandated, it will be set to "well, fail open anyway so it doesn't matter, but we can say we support DNSSEC" -- to unsubscribe send a message to namedroppers-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 Oct 7 15:39: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 86C2F28C18C; Tue, 7 Oct 2008 15:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.518 X-Spam-Level: X-Spam-Status: No, score=-5.518 tagged_above=-999 required=5 tests=[AWL=-1.081, 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 SP2R4CaT+Vwb; Tue, 7 Oct 2008 15:39:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BA5C228C184; Tue, 7 Oct 2008 15:39:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnL9G-000BXH-EI for namedroppers-data@psg.com; Tue, 07 Oct 2008 22:35:22 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnL9C-000BWf-PO for namedroppers@ops.ietf.org; Tue, 07 Oct 2008 22:35:20 +0000 Received: from [127.0.0.1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 71CB5A94451; Tue, 7 Oct 2008 22:35:18 +0000 (UTC) Cc: Paul Vixie , namedroppers@ops.ietf.org Message-Id: <4AFB1475-9829-4C4C-BC77-CF9F29C845B0@mail-abuse.org> From: Douglas Otis To: Francis Dupont In-Reply-To: <200808271704.m7RH4pYG083490@givry.fdupont.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: [dnsext] Re: SCTP (and DCCP) Date: Tue, 7 Oct 2008 15:35:18 -0700 References: <200808271704.m7RH4pYG083490@givry.fdupont.fr> X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 27, 2008, at 10:04 AM, Francis Dupont wrote: > In your previous mail you wrote: > >> DCCP is younger but its "market" is far larger. > > by "larger" do you mean "number of flows now using it" or > something else? > > => the potential market: SCTP was designed for SS7 and should > replace TCP extremely slowly, DCCP is for VoIP & co. Perhaps a bit faster now. Intel's SSE 4.2 instruction set in the now available Core i7 processors include a register accumulation of CRC32c against 8/16/32/64 bit registers or memory locations. -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 Tue Oct 7 15:40: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 09F4C28C165; Tue, 7 Oct 2008 15:40:35 -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 08LtkRqNtOAp; Tue, 7 Oct 2008 15:40:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2CB033A6768; Tue, 7 Oct 2008 15:40:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnL8H-000BQ1-9A for namedroppers-data@psg.com; Tue, 07 Oct 2008 22:34:21 +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 1KnL8C-000BFC-Dr for namedroppers@ops.ietf.org; Tue, 07 Oct 2008 22:34:19 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m97MWW7E011805; Tue, 7 Oct 2008 22:32:32 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m97MWV8b011804; Tue, 7 Oct 2008 22:32:31 GMT Date: Tue, 7 Oct 2008 22:32:31 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Cc: Brian Dickson , Eric Rescorla , bmanning@vacation.karoshi.com, Nicholas Weaver , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? Message-ID: <20081007223231.GA11773@vacation.karoshi.com.> References: <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> <20081007035550.C33BA6B5D8D@kilo.rtfm.com> <20081007201153.137A850846@romeo.rtfm.com> <48EBCBDE.2040408@ca.afilias.info> 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 Tue, Oct 07, 2008 at 05:14:01PM -0400, Edward Lewis wrote: > At 16:51 -0400 10/7/08, Brian Dickson wrote: > > >Seriously, though, the onus is on the operators of authority servers, > >and to a slightly lesser degree, validating resolver operators, > >to ensure that the bits they run, don't break when they start doing dnssec. > > I believe the reverse will be true. When a web client user > encounters an error due to a DNSSEC thumbs down, they call the ISP > help desk (ie, "the Internet is down"). The ISP will "pay" when > there are errors, therefore that's where the onus matters. and this will work when voice is VoIP/SIP/ENUM - dependent on DNS lookups working? can they still call anyone at that point? > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > --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 Tue Oct 7 18:03: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 60FC33A694C; Tue, 7 Oct 2008 18:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.254, 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 Orq9z9XyAFk4; Tue, 7 Oct 2008 18:03:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5A5463A6A9B; Tue, 7 Oct 2008 18:03:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnNCN-000OEc-7l for namedroppers-data@psg.com; Wed, 08 Oct 2008 00:46:43 +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 1KnNCJ-000OE2-8l for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 00:46:41 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id m980k9Nq081382; Wed, 8 Oct 2008 11:46:10 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200810080046.m980k9Nq081382@drugs.dv.isc.org> To: bmanning@vacation.karoshi.com Cc: Edward Lewis , Brian Dickson , Eric Rescorla , Nicholas Weaver , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Re: Protecting caches? In-reply-to: Your message of "Tue, 07 Oct 2008 22:32:31 -0000." <20081007223231.GA11773@vacation.karoshi.com.> Date: Wed, 08 Oct 2008 11:46:09 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <20081007223231.GA11773@vacation.karoshi.com.>, bmanning@vacation.ka roshi.com writes: > On Tue, Oct 07, 2008 at 05:14:01PM -0400, Edward Lewis wrote: > > At 16:51 -0400 10/7/08, Brian Dickson wrote: > > > > >Seriously, though, the onus is on the operators of authority servers, > > >and to a slightly lesser degree, validating resolver operators, > > >to ensure that the bits they run, don't break when they start doing dnssec > . > > > > I believe the reverse will be true. When a web client user > > encounters an error due to a DNSSEC thumbs down, they call the ISP > > help desk (ie, "the Internet is down"). The ISP will "pay" when > > there are errors, therefore that's where the onus matters. > > and this will work when voice is VoIP/SIP/ENUM - dependent on > DNS lookups working? can they still call anyone at that point? Use a land line, use mobile, use the neibours phone. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > Edward Lewis +1-571-434-5468 > > > > --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: -- 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 Oct 7 19: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 518C73A6897; Tue, 7 Oct 2008 19:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.038 X-Spam-Level: X-Spam-Status: No, score=-5.038 tagged_above=-999 required=5 tests=[AWL=0.010, 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 YlvTclMRtaMP; Tue, 7 Oct 2008 19:12:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 327A23A699E; Tue, 7 Oct 2008 19:12:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnOSb-0007aT-Pg for namedroppers-data@psg.com; Wed, 08 Oct 2008 02:07:33 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnOSU-0007Zo-Ka for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 02:07:31 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9826hjD010085; Tue, 7 Oct 2008 19:06:43 -0700 (PDT) Cc: Nicholas Weaver , bmanning@vacation.karoshi.com, Edward Lewis , Brian Dickson , Eric Rescorla , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Message-Id: <74487611-C7D5-4EAB-A5EF-B9AA82A93DF5@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Mark Andrews In-Reply-To: <200810080046.m980k9Nq081382@drugs.dv.isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [dnsext] Re: Protecting caches? Date: Tue, 7 Oct 2008 19:06:42 -0700 References: <200810080046.m980k9Nq081382@drugs.dv.isc.org> X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Oct 7, 2008, at 5:46 PM, Mark Andrews wrote: > > In message <20081007223231.GA11773@vacation.karoshi.com.>, bmanning@vacation.ka > roshi.com writes: >> On Tue, Oct 07, 2008 at 05:14:01PM -0400, Edward Lewis wrote: >>> At 16:51 -0400 10/7/08, Brian Dickson wrote: >>> >>>> Seriously, though, the onus is on the operators of authority >>>> servers, >>>> and to a slightly lesser degree, validating resolver operators, >>>> to ensure that the bits they run, don't break when they start >>>> doing dnssec >> . >>> >>> I believe the reverse will be true. When a web client user >>> encounters an error due to a DNSSEC thumbs down, they call the ISP >>> help desk (ie, "the Internet is down"). The ISP will "pay" when >>> there are errors, therefore that's where the onus matters. >> >> and this will work when voice is VoIP/SIP/ENUM - dependent on >> DNS lookups working? can they still call anyone at that point? > > Use a land line, use mobile, use the neibours phone. Or use an ISP that doesn't turn on that F@#)* break-the-Internet Security crap... This is a huge problem with DNSSEC: Because it is before-the-user, you can't do the "Nag the user" fallback positions you can with TLS or SSH. Thus you have either "accept" or "deny" on what are routine failures. And you can't rely on apps to "accept and then check" in the gray cases, because almost any app which would check would just do end-to- end crypto so DNSSEC is irrelevant for those. -- to unsubscribe send a message to namedroppers-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 Oct 7 19:57: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 E7EE13A6B3B; Tue, 7 Oct 2008 19:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.625 X-Spam-Level: X-Spam-Status: No, score=-4.625 tagged_above=-999 required=5 tests=[AWL=-1.359, 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 TgaUjLR5P6DH; Tue, 7 Oct 2008 19:57:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D062A3A6AED; Tue, 7 Oct 2008 19:57:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnP9f-000BJQ-1f for namedroppers-data@psg.com; Wed, 08 Oct 2008 02:52:03 +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 1KnP9M-000BHY-OV for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 02:51:55 +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 1KnP8w-00050G-4z; Wed, 08 Oct 2008 02:51:18 +0000 Message-ID: <48EC2029.2090404@ca.afilias.info> Date: Tue, 07 Oct 2008 22:51:21 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Nicholas Weaver CC: Mark Andrews , bmanning@vacation.karoshi.com, Edward Lewis , Eric Rescorla , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? References: <200810080046.m980k9Nq081382@drugs.dv.isc.org> <74487611-C7D5-4EAB-A5EF-B9AA82A93DF5@ICSI.Berkeley.EDU> In-Reply-To: <74487611-C7D5-4EAB-A5EF-B9AA82A93DF5@ICSI.Berkeley.EDU> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated: True Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Nicholas Weaver wrote: > > On Oct 7, 2008, at 5:46 PM, Mark Andrews wrote: > >> >> In message <20081007223231.GA11773@vacation.karoshi.com.>, >> bmanning@vacation.ka >> roshi.com writes: >>> and this will work when voice is VoIP/SIP/ENUM - dependent on >>> DNS lookups working? can they still call anyone at that point? >> >> Use a land line, use mobile, use the neibours phone. > > Or use an ISP that doesn't turn on that F@#)* break-the-Internet > Security crap... > If DNS lookups fail, it will be towards zones that have dnssec borkedness. Not to the whole f-ing world. If the ISPs own resolvers break (badly enough) so that nothing resolves, they should expect to lose customers. If the ISP turns off security, their customers can (and should) choose among: - switch ISP - run their own resolver - use third-party resolver service And, the DNS *of* vendors/providers of DNS software or services, should not be one of the sites that breaks. :-) (The proof is in the pudding, eating our own dog food, etc.) > This is a huge problem with DNSSEC: Because it is before-the-user, > you can't do the "Nag the user" fallback positions you can with TLS or > SSH. Thus you have either "accept" or "deny" on what are routine > failures. > > And you can't rely on apps to "accept and then check" in the gray > cases, because almost any app which would check would just do > end-to-end crypto so DNSSEC is irrelevant for those. Nothing prevents apps from embedding their own resolvers, with or without DNSSEC including gray/grey cases. Many, in fact, already do (have embedded (stub) resolvers). So, the whole thing is a bit of a straw man. 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 Tue Oct 7 19:59: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 044EE3A6AE6; Tue, 7 Oct 2008 19:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.273 X-Spam-Level: X-Spam-Status: No, score=0.273 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, 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 B7sbCA0RV94W; Tue, 7 Oct 2008 19:59:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 00FF33A684D; Tue, 7 Oct 2008 19:59:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnPDl-000Bhz-1r for namedroppers-data@psg.com; Wed, 08 Oct 2008 02:56:17 +0000 Received: from [208.17.35.58] (helo=paoakoavas09.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnPDh-000Bgj-A0 for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 02:56:15 +0000 Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.61236231; Tue, 07 Oct 2008 22:55:44 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 22:55:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dnsext] Re: Protecting caches? Date: Tue, 7 Oct 2008 22:55:38 -0400 Message-ID: In-Reply-To: <74487611-C7D5-4EAB-A5EF-B9AA82A93DF5@ICSI.Berkeley.EDU> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] Re: Protecting caches? Thread-Index: Acko7YnylwURR8RVSFKx+cYA9YEUYwAAQnwg References: <200810080046.m980k9Nq081382@drugs.dv.isc.org> <74487611-C7D5-4EAB-A5EF-B9AA82A93DF5@ICSI.Berkeley.EDU> From: "Griffiths, Chris" To: "Nicholas Weaver" , "Mark Andrews" Cc: , "Edward Lewis" , "Brian Dickson" , "Eric Rescorla" , , "Andrew Sullivan" , X-OriginalArrivalTime: 08 Oct 2008 02:55:44.0474 (UTC) FILETIME=[5B898BA0:01C928F1] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: >On Oct 7, 2008, at 5:46 PM, Mark Andrews wrote: > >> >> In message <20081007223231.GA11773@vacation.karoshi.com.>, >bmanning@vacation.ka >> roshi.com writes: >>> On Tue, Oct 07, 2008 at 05:14:01PM -0400, Edward Lewis wrote: >>>> At 16:51 -0400 10/7/08, Brian Dickson wrote: >>>> >>>>> Seriously, though, the onus is on the operators of authority >>>>> servers, >>>>> and to a slightly lesser degree, validating resolver operators, >>>>> to ensure that the bits they run, don't break when they start >>>>> doing dnssec >>> . >>>> >>>> I believe the reverse will be true. When a web client user >>>> encounters an error due to a DNSSEC thumbs down, they call the ISP >>>> help desk (ie, "the Internet is down"). The ISP will "pay" when >>>> there are errors, therefore that's where the onus matters. >>> >>> and this will work when voice is VoIP/SIP/ENUM - dependent on >>> DNS lookups working? can they still call anyone at that point? >> >> Use a land line, use mobile, use the neibours phone. > >Or use an ISP that doesn't turn on that F@#)* break-the-Internet >Security crap... > >This is a huge problem with DNSSEC: Because it is before-the-user, >you can't do the "Nag the user" fallback positions you can with TLS or >SSH. Thus you have either "accept" or "deny" on what are routine >failures. > >And you can't rely on apps to "accept and then check" in the gray >cases, because almost any app which would check would just do end-to- >end crypto so DNSSEC is irrelevant for those. This certainly concerns all ISP's and other users running resolvers in general. As I read up on DNSSEC (both RFC's and documentation that most of you wrote), the lack of a fallback as you mention becomes a serious concern. There is also the lack of a signed root and a severe anemia to folks pushing real world testing forward so we can make sure edge cases don't crop up. I am looking forward to having repositories for keys which has been brought up, but that is a stop gap. =20 We talk about VOIP/ENUM/SIP and frankly that scares me. What also scares me is broken keys for sites like Ebay, Facebook or Myspace if and when they exist. How are users going react when they can't get to these from their Phone or mobile device or even - gasp at their home just surfing the web. We need to assume that at some point applications will utilize DNSSEC responses either at an OS level or application level to confirm the authenticity of sites (Think DNS Prefetching). This will add even more complexity to troubleshooting issues. I am not convinced that this will stay out in front of the user. =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: From owner-namedroppers@ops.ietf.org Wed Oct 8 04:46: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 3B4333A682C; Wed, 8 Oct 2008 04:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.629 X-Spam-Level: X-Spam-Status: No, score=-0.629 tagged_above=-999 required=5 tests=[AWL=-0.134, 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 wbGS6O4Qkv64; Wed, 8 Oct 2008 04:46:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3A5023A677E; Wed, 8 Oct 2008 04:46:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnXMa-0006Vp-UA for namedroppers-data@psg.com; Wed, 08 Oct 2008 11:37:56 +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 1KnXMT-0006V0-DQ for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 11:37:51 +0000 Received: from [192.168.1.101] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m98Bb0R8048438; Wed, 8 Oct 2008 07:37:01 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> <20081007035550.C33BA6B5D8D@kilo.rtfm.com> <20081007201153.137A850846@romeo.rtfm.com> <48EBCBDE.2040408@ca.afilias.info> Date: Wed, 8 Oct 2008 07:36:41 -0400 To: Nicholas Weaver From: Edward Lewis Subject: Re: [dnsext] Re: Protecting caches? Cc: Edward Lewis , Nicholas Weaver , Brian Dickson , Eric Rescorla , bmanning@vacation.karoshi.com, mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org 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: At 14:21 -0700 10/7/08, Nicholas Weaver wrote: >So if DNSSEC results in more tech support calls because items don't resolve, >through fault of the authorities and not the ISP's resolver, no ISP in its >right mind would support it! Or if support is mandated, it will be set to >"well, fail open anyway so it doesn't matter, but we can say we >support DNSSEC" That's not a foregone conclusion though. As much work as it is for an ISP and as much of a chance that there may be hard work to avoid problems, ISPs do have the incentive to make sure that the DNS servers they operate give accurate answers to their customers. There are ISPs interested in DNSSEC. ISPs in Sweden are using it. Recently this too: http://www.dnssec.comcast.net/. And this relates a story about galve.se and an error. In this case DNSSEC was on-off-on. http://www.aptld.org/taipeifebruary2008/20-dnssec_2008_APTLD.pdf. Unfortunately the slides are not numbered, the three pertinent slides are towards the end. Just look for "galve.se". -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 8 07:27: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 BE29B3A6830; Wed, 8 Oct 2008 07:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.62 X-Spam-Level: X-Spam-Status: No, score=-0.62 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 KTzm0U+nlQ0g; Wed, 8 Oct 2008 07:27:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C75C53A6BCC; Wed, 8 Oct 2008 07:27:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnZvK-000Lko-NC for namedroppers-data@psg.com; Wed, 08 Oct 2008 14:21: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 1KnZv6-000Lik-FT for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 14:21:50 +0000 Received: from [10.31.201.38] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m98EKuMC049939; Wed, 8 Oct 2008 10:20:56 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200810080046.m980k9Nq081382@drugs.dv.isc.org> <74487611-C7D5-4EAB-A5EF-B9AA82A93DF5@ICSI.Berkeley.EDU> Date: Wed, 8 Oct 2008 10:17:39 -0400 To: "Griffiths, Chris" From: Edward Lewis Subject: RE: [dnsext] Re: Protecting caches? Cc: "Nicholas Weaver" , "Mark Andrews" , , "Edward Lewis" , "Brian Dickson" , "Eric Rescorla" , , "Andrew Sullivan" , 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: At 22:55 -0400 10/7/08, Griffiths, Chris wrote: >We talk about VOIP/ENUM/SIP and frankly that scares me. What also >scares me is broken keys for sites like Ebay, Facebook or Myspace if and >when they exist. How are users going react when they can't get to these >from their Phone or mobile device or even - gasp at their home just >surfing the web. I'm pretty confident that these dangers won't be realized. (Of course, DNSSEC even with the current momentum it has might never be realized.) Like everything else, before anything goes into mainstream production there will be a long trail of testing, documentation, process development, review (and all of that other boring stuff big companies do that open sourcers seem to hate) before it sees the light of day. Getting to production is going to take work. Getting DNSSEC to be relied upon is even more work. I gave a talk last week. I thought that the talk was fairly pessimistic about the future of DNSSEC because I presented a laundry list of the costs of deploying DNSSEC to just a ccTLD. I spent very little time on the revenue potentials. Afterwards someone commented that my talk was rather positive and encouraging. I asked "in what way?" They said that everything of value has a lot of costs in development, the cost element wasn't a scare to that level of management. As far as combining voice and data on one network, my boss in the early 90's already expressed that concern. Before any situation that requires putting eggs in baskets, you can bet there will be a lot of review. On the other hand, remember what it was like when there was no data network, no cellular, all we had then were land lines? It worked, via regulations and details. One of the lines from my presentation last week was "don't let engineers confuse cost with budget." What that meant was that often we have the tendency to look at a load of work and decide that it is too costly. We don't look at the benefit of the work though. DNSSEC might be another case. It's a lot of work to pull off, I mean all the elements working together. But the safety it offers, or the value of the safety, is currently high (the value fluctuates like any other market) and folks who hold the budget see a net positive in it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 8 07:55: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 EE41F3A6A9B; Wed, 8 Oct 2008 07:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[AWL=-0.117, 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 E4Ghg0fQO8f7; Wed, 8 Oct 2008 07:55:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DA0EB3A67F5; Wed, 8 Oct 2008 07:55:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnaMs-000Odu-Ly for namedroppers-data@psg.com; Wed, 08 Oct 2008 14:50:26 +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 1KnaMf-000OcV-Bh for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 14:50:20 +0000 Received: from [10.31.201.38] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m98EoAfv050295; Wed, 8 Oct 2008 10:50:11 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Wed, 8 Oct 2008 10:50:06 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: [dnsext] implementations of RFC 5155 (aka NSEC3) Cc: ed.lewis@neustar.biz 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: How many publicly released implementations of RFC 5155 (NSEC3) are available? (That is, not beta released, test drops, etc.) Any predictions on releases (of other implementations) in the future? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 8 08:56: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 631513A6BD0; Wed, 8 Oct 2008 08:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.039 X-Spam-Level: X-Spam-Status: No, score=-5.039 tagged_above=-999 required=5 tests=[AWL=0.009, 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 X-kf0m29M1Pv; Wed, 8 Oct 2008 08:56:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 25BA23A6B74; Wed, 8 Oct 2008 08:56:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnbG7-0004bz-A8 for namedroppers-data@psg.com; Wed, 08 Oct 2008 15:47:31 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnbG0-0004ai-Pd for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 15:47:27 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m98FklsC018024; Wed, 8 Oct 2008 08:47:13 -0700 (PDT) Cc: IETF DNSEXT WG Message-Id: From: Nicholas Weaver To: Edward Lewis 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 v929.2) Subject: Re: [dnsext] Re: Protecting caches? Date: Wed, 8 Oct 2008 08:46:47 -0700 References: <200810080046.m980k9Nq081382@drugs.dv.isc.org> <74487611-C7D5-4EAB-A5EF-B9AA82A93DF5@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Oct 8, 2008, at 7:17 AM, Edward Lewis wrote: > At 22:55 -0400 10/7/08, Griffiths, Chris wrote: > >> We talk about VOIP/ENUM/SIP and frankly that scares me. What also >> scares me is broken keys for sites like Ebay, Facebook or Myspace >> if and >> when they exist. How are users going react when they can't get to >> these >> from their Phone or mobile device or even - gasp at their home just >> surfing the web. > > I'm pretty confident that these dangers won't be realized. (Of > course, DNSSEC even with the current momentum it has might never be > realized.) Like everything else, before anything goes into > mainstream production there will be a long trail of testing, > documentation, process development, review (and all of that other > boring stuff big companies do that open sourcers seem to hate) > before it sees the light of day. Getting to production is going to > take work. Getting DNSSEC to be relied upon is even more work. > > I gave a talk last week. I thought that the talk was fairly > pessimistic about the future of DNSSEC because I presented a laundry > list of the costs of deploying DNSSEC to just a ccTLD. I spent very > little time on the revenue potentials. Afterwards someone commented > that my talk was rather positive and encouraging. I asked "in what > way?" They said that everything of value has a lot of costs in > development, the cost element wasn't a scare to that level of > management. Then again, a lot of things have cost without benefit. The problem is defining the BENEFIT for DNSSEC in terms of AGGREGATE system security. And the problem is, the benefit is very low: 1) It SHOULD NOT provide a net increase in security over well constructed resolvers against out-of-path adversaries. 2) It DOES provide a benefit in security if your ISP's resolver is corrupted. Yet some such corruption (eg, NX-domain wildcarding, MitMing Google) may be caused by the ISP or separate DNS provider for their own economic benefit. 3) It DOES NOT provide a net increase in security against an in-path (MitM) adversary under most conditions, because in such conditions, an in-path adversary can almost always also directly manipulate the data traffic. And if the application is resistant to in-path adversaries, it never really relied on the DNS name as anything more than a mnemonic because it needs to establish a direct cryptographic channel with the other side. Thus the only real BENEFIT is #4: 4) An external third party (eg the US Government) REQUIRES deployment of DNSSEC. or PERHAPS: 5) It is used by end-applications as an integrity-assured object store to allow an application to fetch the remote system's key fingerprint based on the DNSSEC CA infrastructure (and it IS a CA infrastructure, really) rather than using a separate CA infrastructure. But 5 won't occur until DNSSEC is widely used, because until it is widely used, the separate CA infrastructures are equally trustworthy and available today. But for this use, the problem is that DNSSEC values are too small. I'd want a nice, integrity assured, key->value database but I don't want values restricted to such small quantities of data. Thus if I was in charge of a DNS infrastructure, I would: a) NOT deploy DNSSEC on my authorities unless there was an external mandate. If there is an external mandate, I would deploy DNSSEC, and would contract with an external party to do continual validation of operation under the most strict acceptance policy, lest my DNSSEC deployment results in failures. b) NOT deploy DNSSEC checking on my resolvers unless there was an external mandate, but correctly forward DNSSEC records when queried (enabling end-systems to do their own checking if desired, eg, such as #5 which REQUIRES the end-application to check regardless of resolver behavior anyway). If there is an external mandate to have the resolver check DNSSEC, I would use the least strict acceptance policy, to reduce the probability that my DNSSEC deployment results in failures. And for those who advocate DNSSEC, this is a problem, because if you look at net SYSTEM benefit, you need to make arguments that the benefits are substantial. Finally, what do you mean by "Rely" on DNSSEC. No application that I know of can rely on DNSSEC to provide the name to address mapping yet trust the network. The only thing I'd "rely" on DNSSEC for as a developer is as an object store for key/value mappings, not addressing. -- to unsubscribe send a message to namedroppers-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 Oct 8 09:49: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 6EF9728C1BF; Wed, 8 Oct 2008 09:49:43 -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 m2FBF5cImcFT; Wed, 8 Oct 2008 09:49:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7184A28C1BE; Wed, 8 Oct 2008 09:49:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Knc7p-0009JI-Lt for namedroppers-data@psg.com; Wed, 08 Oct 2008 16:43:01 +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 1Knc7b-0009I0-Bu for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 16:42:53 +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 m98GkZTh006853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Oct 2008 09:46:38 -0700 Date: Wed, 8 Oct 2008 12:42:43 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? Message-ID: <20081008164243.GH44963@commandprompt.com> References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> <20081007035550.C33BA6B5D8D@kilo.rtfm.com> <20081007201153.137A850846@romeo.rtfm.com> 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]); Wed, 08 Oct 2008 09:46:38 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [no hat] On Tue, Oct 07, 2008 at 04:25:21PM -0400, Edward Lewis wrote: > How do you decide between a bogus signature due to maliciousness and a > bogus signature due to misconfiguration and a bogus signature due to a > disagreement over policy, etc.? You don't, from the point of view of an application. In my reading, validation failure is validation failure, full stop. This is related to my belief that there are no levels of trust in DNSSEC, and that if we want to add that gewgaw, we have some work to do. 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 Wed Oct 8 10:44: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 23AA73A685C; Wed, 8 Oct 2008 10:44:02 -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=[AWL=0.000, 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 8pYKDzixHWty; Wed, 8 Oct 2008 10:44:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 108553A6832; Wed, 8 Oct 2008 10:44:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KncvW-000EAi-Mh for namedroppers-data@psg.com; Wed, 08 Oct 2008 17:34:22 +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 1KncvO-000E3M-RD for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 17:34:18 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m98HWY7E021057; Wed, 8 Oct 2008 17:32:34 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m98HWXkx021056; Wed, 8 Oct 2008 17:32:33 GMT Date: Wed, 8 Oct 2008 17:32:33 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Cc: Nicholas Weaver , Brian Dickson , Eric Rescorla , bmanning@vacation.karoshi.com, mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? Message-ID: <20081008173233.GA20991@vacation.karoshi.com.> References: <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> <20081007035550.C33BA6B5D8D@kilo.rtfm.com> <20081007201153.137A850846@romeo.rtfm.com> <48EBCBDE.2040408@ca.afilias.info> 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 Wed, Oct 08, 2008 at 07:36:41AM -0400, Edward Lewis wrote: > At 14:21 -0700 10/7/08, Nicholas Weaver wrote: > >So if DNSSEC results in more tech support calls because items don't > >resolve, > >through fault of the authorities and not the ISP's resolver, no ISP in its > >right mind would support it! Or if support is mandated, it will be set to > >"well, fail open anyway so it doesn't matter, but we can say we > >support DNSSEC" > > That's not a foregone conclusion though. As much work as it is for > an ISP and as much of a chance that there may be hard work to avoid > problems, ISPs do have the incentive to make sure that the DNS > servers they operate give accurate answers to their customers. indeed they do, since they are the folks holding the liability. > There are ISPs interested in DNSSEC. ISPs in Sweden are using it. > Recently this too: http://www.dnssec.comcast.net/. all really good stuff. > And this relates a story about galve.se and an error. In this case > DNSSEC was on-off-on. > http://www.aptld.org/taipeifebruary2008/20-dnssec_2008_APTLD.pdf. > Unfortunately the slides are not numbered, the three pertinent slides > are towards the end. Just look for "galve.se". so - back to my original point. I think that for -now- having DNSSEC fail-open is a much more credible stance than taking a hardline - fail-closed - model. Lets save fail-closed until after we get some more traction. what was that Postel credo? --bill > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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 Oct 8 10:44: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 006DB3A684B; Wed, 8 Oct 2008 10:44:13 -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=[AWL=0.000, 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 5sjc9XN3HR9w; Wed, 8 Oct 2008 10:44:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 214C23A6832; Wed, 8 Oct 2008 10:44:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Knd1u-000Ek7-E7 for namedroppers-data@psg.com; Wed, 08 Oct 2008 17:40:58 +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 1Knd1o-000Ecl-9R for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 17:40:55 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m98HdR7E021136; Wed, 8 Oct 2008 17:39:27 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m98HdRE1021135; Wed, 8 Oct 2008 17:39:27 GMT Date: Wed, 8 Oct 2008 17:39:27 +0000 From: bmanning@vacation.karoshi.com To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? Message-ID: <20081008173927.GB20991@vacation.karoshi.com.> References: <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> <20081007035550.C33BA6B5D8D@kilo.rtfm.com> <20081007201153.137A850846@romeo.rtfm.com> <20081008164243.GH44963@commandprompt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081008164243.GH44963@commandprompt.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Oct 08, 2008 at 12:42:43PM -0400, Andrew Sullivan wrote: > [no hat] > > On Tue, Oct 07, 2008 at 04:25:21PM -0400, Edward Lewis wrote: > > > How do you decide between a bogus signature due to maliciousness and a > > bogus signature due to misconfiguration and a bogus signature due to a > > disagreement over policy, etc.? > > You don't, from the point of view of an application. In my reading, > validation failure is validation failure, full stop. This is related > to my belief that there are no levels of trust in DNSSEC, and that if > we want to add that gewgaw, we have some work to do. > > A > oh... we need to change your beliefs then :) sure, validation failure is validation failure... but when and from whom? Ed leaves out transient network failure as areason for validation failure... when validation fails, how often do you retry? --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 Oct 8 11:01: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 B73923A68D3; Wed, 8 Oct 2008 11:01:29 -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 r1UJtLrKQEAh; Wed, 8 Oct 2008 11:01:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 11E053A6894; Wed, 8 Oct 2008 11:01:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KndDB-000Fud-Dk for namedroppers-data@psg.com; Wed, 08 Oct 2008 17:52:37 +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 1KndD1-000Fkp-1K for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 17:52: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 m98HoY7E021298; Wed, 8 Oct 2008 17:50:34 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m98HoYGU021297; Wed, 8 Oct 2008 17:50:34 GMT Date: Wed, 8 Oct 2008 17:50:34 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Cc: Eric Rescorla , bmanning@vacation.karoshi.com, Nicholas Weaver , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? Message-ID: <20081008175034.GA21206@vacation.karoshi.com.> References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.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, Oct 06, 2008 at 11:08:02AM -0400, Edward Lewis wrote: > At 18:40 -0700 10/1/08, Eric Rescorla wrote: > >At Wed, 1 Oct 2008 23:08:22 +0000, > >bmanning@vacation.karoshi.com wrote: > > >> the other option is to "fail open" ... eg. things are > >> just like they are now. > > > >This seems plausible in some cases but not others. I.e., if the > >signature is expired, that's probably fine. However, if the > >signature is totally broken, doesn't accepting it kind of obviate > >the point of DNSSEC? > > Smoothing over bumps in security is a fine way to let operational > issues fester unnoticed. Absent proof of widespread, successful, > attacks on DNS caches today (I am told there are many attacks that > don't get air time), I bet that the majority of DNSSEC "positives" > will be the result of misconfigurations. I remember the first pass @ DNSSEC ... the primary drivers were from security folks looking for perfect security. And what we got was not operationally deployable. DNS - as it exists - is full of operational issues and yet it works well enough that it has become a serious core technology. I expect that - in this pass - we will also have many operational issues w/ DNSSEC deployment that will be smoothed over - if only to keep things working in/through transition. wrt yoru bet - i'll not take it. > A common one will be maladjusted clocks on verifiers, especially if a > user machine attempts to take validation into it's own hands. I base > this on our experience in the early workshops before NTP was on all > our machines (because we were so burned by time). (I once had a > machine that had the right time of day and month/day, but the year > was off by one. That took a lot of squinting at screens and paper > before I noticed it.) Ah yes - DNS aquires a dependence on an external application. > There are five entities involved in an canonical verification - user, > ISP, root, TLD, enterprise. While errors may be rare, I bet errors > will still outpace attacks. Especially after DNSSEC has been running > for some time. actually, I think there are only three entities in canonical validation. the validator, the publisher(s) e.g. authoritative and caching servers, and the zone key holder(s). > So failing open is probably a bad strategy, neglecting the security > implications, for operational reasons much less obviating the point > of DNSSEC. likely true, but it is better than any of the alternatives. --bill > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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 Oct 8 11:01: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 6E6863A6929; Wed, 8 Oct 2008 11:01:55 -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 sQDof7wD5n8x; Wed, 8 Oct 2008 11:01:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D30493A6894; Wed, 8 Oct 2008 11:01:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KndEZ-000G5F-Ur for namedroppers-data@psg.com; Wed, 08 Oct 2008 17:54:03 +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 1KndEP-000Fti-Qz for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 17:54:01 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m98HqG7E021311; Wed, 8 Oct 2008 17:52:16 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m98HqGrk021310; Wed, 8 Oct 2008 17:52:16 GMT Date: Wed, 8 Oct 2008 17:52:16 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Cc: Eric Rescorla , bmanning@vacation.karoshi.com, Nicholas Weaver , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? Message-ID: <20081008175216.GB21206@vacation.karoshi.com.> References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> <20081007035550.C33BA6B5D8D@kilo.rtfm.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 Tue, Oct 07, 2008 at 12:56:19PM -0400, Edward Lewis wrote: > At 20:55 -0700 10/6/08, Eric Rescorla wrote: > > >I totally agree with this claim, but if your resolver > >accepts bogus signatures, then what's the point of having > >signatures at all? > > Perhaps my "is a fine way" and "fester unnoticed" weren't taken > sarcastically enough. ;) > > If data accompanied by a signature that is proven to be invalid is > accepted at all, then the effort is a waste. And what I meant was, > in addition, if you do you are enabling poor operational practices > and other poor habits. > > The only time a DNS verifier/iterator should pass on data that failed > verification is within a debugging/reporting context. I disagree... but that kind of depends on what is ment by "reporting". --bill > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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 Oct 8 11:06: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 31E763A6894; Wed, 8 Oct 2008 11:06:10 -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 7-xIXIAZn30P; Wed, 8 Oct 2008 11:06:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 679373A6765; Wed, 8 Oct 2008 11:06:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KndMI-000Gyu-OD for namedroppers-data@psg.com; Wed, 08 Oct 2008 18:02:02 +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 1KndM9-000Gxl-J0 for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 18:02:00 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:57203) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:fanf2) id 1KndM6-0001ka-JC (Exim 4.70) (return-path ); Wed, 08 Oct 2008 19:01:50 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1KndM6-0003PJ-UG (Exim 4.67) (return-path ); Wed, 08 Oct 2008 19:01:50 +0100 Date: Wed, 8 Oct 2008 19:01:50 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: bmanning@vacation.karoshi.com cc: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? In-Reply-To: <20081008173927.GB20991@vacation.karoshi.com.> Message-ID: References: <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> <20081007035550.C33BA6B5D8D@kilo.rtfm.com> <20081007201153.137A850846@romeo.rtfm.com> <20081008164243.GH44963@commandprompt.com> <20081008173927.GB20991@vacation.karoshi.com.> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, 8 Oct 2008, bmanning@vacation.karoshi.com wrote: > > sure, validation failure is validation failure... but when and > from whom? Ed leaves out transient network failure as areason > for validation failure... when validation fails, how often do > you retry? A SERVFAIL because of network breakage is not really a DNSSEC problem. Tony. -- f.anthony.n.finch http://dotat.at/ VIKING NORTH UTSIRE SOUTH UTSIRE FORTIES: NORTHWESTERLY 4 OR 5, INCREASING 6 FOR A TIME IN SOUTH UTSIRE, BACKING SOUTHERLY 5 TO 7 LATER. MODERATE OR ROUGH. SHOWERS, RAIN LATER IN VIKING AND FORTIES. MODERATE OR GOOD, OCCASIONALLY POOR LATER IN VIKING AND FORTIES. -- to unsubscribe send a message to namedroppers-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 Oct 8 11:09: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 18C0E3A68D3; Wed, 8 Oct 2008 11:09:14 -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.110, 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 YSMA+gnwG+PB; Wed, 8 Oct 2008 11:09:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 435633A6956; Wed, 8 Oct 2008 11:09:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KndQP-000HWD-Eu for namedroppers-data@psg.com; Wed, 08 Oct 2008 18:06:17 +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 1KndQD-000HTm-QV for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 18:06:11 +0000 Received: from [10.31.201.38] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m98I5Uwk052028; Wed, 8 Oct 2008 14:05:33 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20081008175034.GA21206@vacation.karoshi.com.> References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> <20081008175034.GA21206@vacation.karoshi.com.> Date: Wed, 8 Oct 2008 14:03:08 -0400 To: bmanning@vacation.karoshi.com From: Edward Lewis Subject: Re: [dnsext] Re: Protecting caches? Cc: Edward Lewis , Eric Rescorla , bmanning@vacation.karoshi.com, Nicholas Weaver , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org 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: At 17:50 +0000 10/8/08, bmanning@vacation.karoshi.com wrote: > actually, I think there are only three entities in canonical >validation. > the validator, the publisher(s) e.g. authoritative and caching servers, > and the zone key holder(s). You are counting "publisher(s)" as one when you should be counting it as at least 3. That's why you don't get a 5. The root zone manager, the tld manager, and the enterprise are three independent organizations that may need to be consulted to see why a certain DS RR wasn't uploaded in a certain zone. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 8 11:12: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 EE5443A68B3; Wed, 8 Oct 2008 11:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[AWL=-0.104, 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 CuN3GcLX8CQF; Wed, 8 Oct 2008 11:12:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D30943A67DF; Wed, 8 Oct 2008 11:12:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KndQX-000HWq-R9 for namedroppers-data@psg.com; Wed, 08 Oct 2008 18:06:25 +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 1KndQO-000HVr-6e for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 18:06:18 +0000 Received: from [10.31.201.38] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m98I5Uwi052028; Wed, 8 Oct 2008 14:05:31 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20081008173233.GA20991@vacation.karoshi.com.> References: <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> <20081007035550.C33BA6B5D8D@kilo.rtfm.com> <20081007201153.137A850846@romeo.rtfm.com> <48EBCBDE.2040408@ca.afilias.info> <20081008173233.GA20991@vacation.karoshi.com.> Date: Wed, 8 Oct 2008 13:59:02 -0400 To: bmanning@vacation.karoshi.com From: Edward Lewis Subject: Re: [dnsext] Re: Protecting caches? Cc: Edward Lewis , Nicholas Weaver , Brian Dickson , Eric Rescorla , bmanning@vacation.karoshi.com, mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org 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: At 17:32 +0000 10/8/08, bmanning@vacation.karoshi.com wrote: > so - back to my original point. I think that for -now- > having DNSSEC fail-open is a much more credible stance than > taking a hardline - fail-closed - model. Lets save fail-closed > until after we get some more traction. I'm pessimistic about a plan that includes "later on, we tighten security." We thought of this back in the day. Lacking the ability to recall or disable older versions of software, the only way you can change a code base to support a new paradigm is to get users to upgrade. Upgrades only come when the user wants to upgrade. And who wants to get a new car because it has tighter seat belts? Until the model is "fail closed" DNSSEC can't be relied upon. With a fail open model letting sloppy operations habits fester unabated, we will never get to a mature state. Fail open will only get us what 6Bone got IPv6 - tools and software but not enough operational reality to get the technology deployed. (For example, making use of tunnels deferred thought about IPv6 routing/forwarding table issues.) > what was that Postel credo? (http://en.wikipedia.org/wiki/Postel's_law) We aren't taking about robustness, we are talking about security. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 8 11: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 C64B43A6929; Wed, 8 Oct 2008 11:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.594 X-Spam-Level: X-Spam-Status: No, score=-0.594 tagged_above=-999 required=5 tests=[AWL=-0.099, 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 qj7xRcPlGjiL; Wed, 8 Oct 2008 11:19:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E6D8C3A67DF; Wed, 8 Oct 2008 11:19:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KndZ5-000IZG-Cg for namedroppers-data@psg.com; Wed, 08 Oct 2008 18:15: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 1KndYx-000IXg-1i for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 18:15:13 +0000 Received: from [10.31.201.38] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m98IF1o9052190; Wed, 8 Oct 2008 14:15:02 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20081008173927.GB20991@vacation.karoshi.com.> References: <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> <20081007035550.C33BA6B5D8D@kilo.rtfm.com> <20081007201153.137A850846@romeo.rtfm.com> <20081008164243.GH44963@commandprompt.com> <20081008173927.GB20991@vacation.karoshi.com.> Date: Wed, 8 Oct 2008 14:14:52 -0400 To: bmanning@vacation.karoshi.com From: Edward Lewis Subject: Re: [dnsext] Re: Protecting caches? Cc: Andrew Sullivan , namedroppers@ops.ietf.org 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: At 17:39 +0000 10/8/08, bmanning@vacation.karoshi.com wrote: > oh... we need to change your beliefs then :) > > sure, validation failure is validation failure... but when and > from whom? Ed leaves out transient network failure as areason > for validation failure... when validation fails, how often do > you retry? If there is a transient network failure lasting longer than the maximum allowed time to answer a question - it's unlikely that it is DNSSEC validation that is the bottleneck. If there is such a failure, you'd probably not get the answer either. That's why I don't consider it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 8 11: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 D89813A6890; Wed, 8 Oct 2008 11:41:49 -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=[AWL=0.000, 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 tqrFU+PpDoLS; Wed, 8 Oct 2008 11:41:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 986593A6838; Wed, 8 Oct 2008 11:41:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kndv7-000LZm-1y for namedroppers-data@psg.com; Wed, 08 Oct 2008 18:38:01 +0000 Received: from [2001:478:6::80df:3c18] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Knduz-000LMR-Kn for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 18:37:57 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m98IaP7E021754; Wed, 8 Oct 2008 18:36:25 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m98IaPcT021753; Wed, 8 Oct 2008 18:36:25 GMT Date: Wed, 8 Oct 2008 18:36:25 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Cc: bmanning@vacation.karoshi.com, Eric Rescorla , Nicholas Weaver , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? Message-ID: <20081008183625.GB21338@vacation.karoshi.com.> References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> <20081008175034.GA21206@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 Wed, Oct 08, 2008 at 02:03:08PM -0400, Edward Lewis wrote: > At 17:50 +0000 10/8/08, bmanning@vacation.karoshi.com wrote: > > > actually, I think there are only three entities in canonical > >validation. > > the validator, the publisher(s) e.g. authoritative and caching > > servers, > > and the zone key holder(s). > > You are counting "publisher(s)" as one when you should be counting it > as at least 3. That's why you don't get a 5. The root zone manager, > the tld manager, and the enterprise are three independent > organizations that may need to be consulted to see why a certain DS > RR wasn't uploaded in a certain zone. kind of depends on where you get your TA's. I still say three. --bill > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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 Oct 8 11:41: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 C655E3A680E; Wed, 8 Oct 2008 11:41:57 -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=[AWL=0.000, 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 834e94cQ1Vi1; Wed, 8 Oct 2008 11:41:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 52D8E3A6838; Wed, 8 Oct 2008 11:41:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KndsC-000L65-Lz for namedroppers-data@psg.com; Wed, 08 Oct 2008 18: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 1Knds6-000KoQ-4x for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 18:34:57 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m98IXQ7E021717; Wed, 8 Oct 2008 18:33:26 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m98IXPHO021716; Wed, 8 Oct 2008 18:33:25 GMT Date: Wed, 8 Oct 2008 18:33:25 +0000 From: bmanning@vacation.karoshi.com To: Nicholas Weaver Cc: bmanning@vacation.karoshi.com, mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? Message-ID: <20081008183325.GA21338@vacation.karoshi.com.> References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081002123733.GA13334@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 Thu, Oct 02, 2008 at 08:10:02AM -0700, Nicholas Weaver wrote: > > >>The fundamental problem with DNSSEC is how the application USES > >>getaddrinfo(): it either trusts the name or it doesn't. > > > > again, you are conflating resoultion w/ validation. > > getaddrinfo() returns data ... w/o any warrantees on > > accuracy or integrity. if you want that, then you have > > to involke a validator. the "trust" does not lie w/ the systemcall. > > I don't get the distinction. > > Pardon my ignorance, but the resolution process in DNSSEC should > include validation. Unless the recursive resolver is told otherwise, > it validates DNSSEC signatures before returning a value. Unless the > stub resolver is misconfigured, it validates DNSSEC signatures before > returning the value. resolution != validation your assertion that it should is based on fervant wish, not analytical review. a resolver is a series of system calls. no state, totally ephemeral. a "full resolver" or "caching resolver" is a DNS server sitting on a resolver. in this case, the DNS server has no authoritative data, it just maintains cache. And in that case, you -might- put a validator with that DNS server - since you are already committed to maintain cache/state. is the distinction clearer? > getaddrinfo() is a wrapper around a call to the local stub resolver. > Thus if the stub resolver validates as part of the lookup process, > getaddrinfo() validates as part of the lookup process. ANd if you > trust the operating system, you can trust the operating system's stub > resolver to do this properly. a stub resolver is, by definition, just the set of system calls. it can't validate, since there is no local cache. > >>If its an end-to-end secure application, it never actually trusted > >>the > >>name, because the application doesn't trust the network, so DNSSEC > >>bought nothing. Zippo. Zilch. Nada. > > > > unless the application under discussion is DNS. > > and even then, DNSSEC doesn't care abt trusting the > > network or the intermediate nodes that might hold the > > data. > > How many end-host lookups are "DNS is the application"? Almost none. actually - 100% of them. the DNS application will almost always pass the results of a lookup back to some other application. > Actually, trust is transitive all the time. Your application trusts > the underlying operating system, for example. let me run that by several of the Security Area directorate. last I checked, just because the DNS data has not been tampered with in transit, is no assurance that the target host is clean or any of the applications running thereon are safe. > > I belive validation can and should be done asyncronously from > > resolution. And it is true that a validator API is sadly > > lacking - although there have been several efforts over the > > years to bring something forward. > > Why should validation be done independently? Why should separate > validation be done at all? why not? doing validation independently of resolution may be required for a number of reasons - for example the endnodes may be constrained by power, number of transistors, etc for running a userspace cache. lightweight system calls may be all that fit. > In fact, I will argue that independent validation is EXACTLY the wrong > answer for almost all applications: thats a point of view. not a universally held pov, but one you can hold. [prognostications held forth] > In fact, the big use for DNSSEC, I believe, is NOT for securing DNS > names against a man-in-the-middle (a useless endeavor), but as a "item > respository with cryptographic integrity", where NON-naming > information is stored. thats not a new idea either - but fraught w/ transient trust problems. > Not because its a particularly good one (the size limits make it a > particularly BAD one in fact), but because there is no other off the > shelf existing secure distributed database code that is readily > avaliable, unlike transport . Yowsa... put everything in the DNS 'cause thats all we got? > And for this, the API could just be a piece of resolver code as a > library in the application or a standalone application, like TLS and > ssh are today for anyone who uses it. And would want to be this way, > because the desired policies on failures etc should not be relying on > the end host's stub resolver code anyway. not sure what this means. --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 Oct 8 11:47: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 EBE453A680E; Wed, 8 Oct 2008 11:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.727 X-Spam-Level: X-Spam-Status: No, score=0.727 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=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 ZAOUiW5OJeSl; Wed, 8 Oct 2008 11:47:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1F58F3A6801; Wed, 8 Oct 2008 11:47:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kndyo-000M2Z-SY for namedroppers-data@psg.com; Wed, 08 Oct 2008 18:41:50 +0000 Received: from [209.85.200.172] (helo=wf-out-1314.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kndyj-000M1r-Ij for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 18:41:48 +0000 Received: by wf-out-1314.google.com with SMTP id 26so4300496wfd.32 for ; Wed, 08 Oct 2008 11:41:45 -0700 (PDT) Received: by 10.141.52.5 with SMTP id e5mr5324696rvk.125.1223491304778; Wed, 08 Oct 2008 11:41:44 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Wed, 8 Oct 2008 11:41:44 -0700 (PDT) Message-ID: Date: Wed, 8 Oct 2008 11:41:44 -0700 From: "Matthew Dempsky" To: bmanning@vacation.karoshi.com Subject: Re: [dnsext] Re: Protecting caches? Cc: namedroppers@ops.ietf.org In-Reply-To: <20081008173233.GA20991@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081001181558.2BAE050846@romeo.rtfm.com> <20081007035550.C33BA6B5D8D@kilo.rtfm.com> <20081007201153.137A850846@romeo.rtfm.com> <48EBCBDE.2040408@ca.afilias.info> <20081008173233.GA20991@vacation.karoshi.com.> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Oct 8, 2008 at 10:32 AM, wrote: > what was that Postel credo? I just tried ssh'ing to root@karoshi.com. Why didn't it accept "opensesame" as the password? Your server's not being very liberal in what it accepts. :-( -- to unsubscribe send a message to namedroppers-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 Oct 8 11:57: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 72A1A3A6960; Wed, 8 Oct 2008 11:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.04 X-Spam-Level: X-Spam-Status: No, score=-5.04 tagged_above=-999 required=5 tests=[AWL=0.008, 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 PpbgPgjUplpu; Wed, 8 Oct 2008 11:57:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 306663A6832; Wed, 8 Oct 2008 11:57:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kne9d-000NKn-Hf for namedroppers-data@psg.com; Wed, 08 Oct 2008 18:53:01 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kne9X-000NJm-LP for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 18:52:58 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m98IqIwg014814; Wed, 8 Oct 2008 11:52:42 -0700 (PDT) Cc: Nicholas Weaver , mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Message-Id: <836029DF-1D70-4638-A4EF-441CB48C0073@ICSI.Berkeley.EDU> From: Nicholas Weaver To: bmanning@vacation.karoshi.com In-Reply-To: <20081008183325.GA21338@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 v929.2) Subject: Re: [dnsext] Re: Protecting caches? Date: Wed, 8 Oct 2008 11:52:18 -0700 References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081002123733.GA13334@vacation.karoshi.com.> <20081008183325.GA21338@vacation.karoshi.com.> X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Oct 8, 2008, at 11:33 AM, bmanning@vacation.karoshi.com wrote: > On Thu, Oct 02, 2008 at 08:10:02AM -0700, Nicholas Weaver wrote: >> >>>> The fundamental problem with DNSSEC is how the application USES >>>> getaddrinfo(): it either trusts the name or it doesn't. >>> >>> again, you are conflating resoultion w/ validation. >>> getaddrinfo() returns data ... w/o any warrantees on >>> accuracy or integrity. if you want that, then you have >>> to involke a validator. the "trust" does not lie w/ the systemcall. >> >> I don't get the distinction. >> >> Pardon my ignorance, but the resolution process in DNSSEC should >> include validation. Unless the recursive resolver is told otherwise, >> it validates DNSSEC signatures before returning a value. Unless the >> stub resolver is misconfigured, it validates DNSSEC signatures before >> returning the value. > > resolution != validation your assertion that it should > is based on fervant wish, not analytical review. > > a resolver is a series of system calls. no state, totally ephemeral. > > a "full resolver" or "caching resolver" is a DNS server sitting on > a resolver. in this case, the DNS server has no authoritative data, > it just maintains cache. And in that case, you -might- put a > validator with that DNS server - since you are already committed > to maintain cache/state. > > is the distinction clearer? I'm afraid I just don't get it. The whole point of DNSSEC is to insure that the object returned by a query has an integrity guarentee associated with it, not that you can do a separate integrity check. I can't find anything that suggests otherwise. >> getaddrinfo() is a wrapper around a call to the local stub resolver. >> Thus if the stub resolver validates as part of the lookup process, >> getaddrinfo() validates as part of the lookup process. ANd if you >> trust the operating system, you can trust the operating system's stub >> resolver to do this properly. > > a stub resolver is, by definition, just the set of system calls. > it can't validate, since there is no local cache. Actually, this is incorrect. Many MANY end system stub resolvers maintain cache state. Try it out for yourself with a TCPdump and multiple invocations of ping. getaddrinfo() is hardly stateless on most systems. >> How many end-host lookups are "DNS is the application"? Almost none. > > actually - 100% of them. the DNS application will > almost always pass the results of a lookup back to some > other application. Thats exactly my point. DNS is not the application! The final application is the application, DNS is simply a tool USED by the application to provide a convenient mapping of name -> address. You can attack the final application by attacking the name -> address mapping or many other ways. DNS only needs to not provide ADDITIONAL ways to attack the final application. This is why I don't believe the MitM is the proper threat model for DNS. >>> I belive validation can and should be done asyncronously from >>> resolution. And it is true that a validator API is sadly >>> lacking - although there have been several efforts over the >>> years to bring something forward. >> >> Why should validation be done independently? Why should separate >> validation be done at all? > > why not? doing validation independently of resolution may be > required for a number of reasons - for example the endnodes may > be constrained by power, number of transistors, etc for running > a userspace cache. lightweight system calls may be all that fit. If thats the case, why is the stub resolver not implementing this? Separate validation is USELESS: Apps either won't validate or they will. If the app doesn't validate it, it gains no protection from DNSSEC. If the app would have validated it, dollars to doughnuts says it doesn't actually bother validating it because its going to do a subsequent cryptographic validation of the other party anyway. >> In fact, the big use for DNSSEC, I believe, is NOT for securing DNS >> names against a man-in-the-middle (a useless endeavor), but as a >> "item >> respository with cryptographic integrity", where NON-naming >> information is stored. > > thats not a new idea either - but fraught w/ transient trust > problems. Its the same transient trust problem present in TLS's CA structure, or any PKI infrastructure. And it doesn't add any MORE transient trust problems than any other PKI infrastructure. In fact, in both cases you have to trust Verisign. >> Not because its a particularly good one (the size limits make it a >> particularly BAD one in fact), but because there is no other off the >> shelf existing secure distributed database code that is readily >> avaliable, unlike transport . > > Yowsa... put everything in the DNS 'cause thats all we got? No, put it in DNSSEC because its code that works. Lesson #1: never reimplement crypto when there is an off-the-shelf solution. >> And for this, the API could just be a piece of resolver code as a >> library in the application or a standalone application, like TLS and >> ssh are today for anyone who uses it. And would want to be this way, >> because the desired policies on failures etc should not be relying on >> the end host's stub resolver code anyway. > > not sure what this means. That if you actually DO want this, you include library code that interfaces with DNS directly, bypassing gethostbyname() completely, because the policy you want for the gray cases is probably not the policy the stub resolver wants. -- to unsubscribe send a message to namedroppers-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 Oct 8 11:59: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 7839D3A680E; Wed, 8 Oct 2008 11:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 5Oi8bwrua19I; Wed, 8 Oct 2008 11:59:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AB4493A6989; Wed, 8 Oct 2008 11:59:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kne9p-000NMy-PT for namedroppers-data@psg.com; Wed, 08 Oct 2008 18:53:13 +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 1Kne9j-000NCM-JB for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 18:53:10 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m98Ipc7E022024; Wed, 8 Oct 2008 18:51:38 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m98IpcLE022023; Wed, 8 Oct 2008 18:51:38 GMT Date: Wed, 8 Oct 2008 18:51:38 +0000 From: bmanning@vacation.karoshi.com To: Matthew Dempsky Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? Message-ID: <20081008185138.GA21933@vacation.karoshi.com.> References: <20081007035550.C33BA6B5D8D@kilo.rtfm.com> <20081007201153.137A850846@romeo.rtfm.com> <48EBCBDE.2040408@ca.afilias.info> <20081008173233.GA20991@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 Wed, Oct 08, 2008 at 11:41:44AM -0700, Matthew Dempsky wrote: > On Wed, Oct 8, 2008 at 10:32 AM, wrote: > > what was that Postel credo? > > I just tried ssh'ing to root@karoshi.com. Why didn't it accept > "opensesame" as the password? Your server's not being very liberal in > what it accepts. :-( well, if you were more conservative in what you sent... :) --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 Oct 8 12:36: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 9CC5728C168; Wed, 8 Oct 2008 12:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.541 X-Spam-Level: X-Spam-Status: No, score=-4.541 tagged_above=-999 required=5 tests=[AWL=-1.275, 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 N3NPap8ciSnq; Wed, 8 Oct 2008 12:36:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 96EDD3A6765; Wed, 8 Oct 2008 12:36:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Knelg-0001wC-RI for namedroppers-data@psg.com; Wed, 08 Oct 2008 19:32:20 +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 1Knelc-0001vV-Ao for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 19:32:18 +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 1KnelO-0000h9-3m; Wed, 08 Oct 2008 19:32:02 +0000 Message-ID: <48ED0AB5.6040903@ca.afilias.info> Date: Wed, 08 Oct 2008 15:32:05 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Nicholas Weaver CC: bmanning@vacation.karoshi.com, mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081002123733.GA13334@vacation.karoshi.com.> <20081008183325.GA21338@vacation.karoshi.com.> <836029DF-1D70-4638-A4EF-441CB48C0073@ICSI.Berkeley.EDU> In-Reply-To: <836029DF-1D70-4638-A4EF-441CB48C0073@ICSI.Berkeley.EDU> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated: True Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Nicholas Weaver wrote: > You can attack the final application by attacking the name -> address > mapping or many other ways. DNS only needs to not provide ADDITIONAL > ways to attack the final application. > You are perilously close to "getting it". ;-) The simplest viewpoint can be reached by considering a system consisting of just a control plane and a data plane. In such a system: * if neither the control plane nor data plane is secured against tampering, you have no (end-to-end) security * if the data plane is secured but the control plane is not secured, you have (at best) the illusion of security * if the control plane is secured but the data plane is not secured, you also have (at best) the illusion of security * only if both the control plane and data plane are secured, can you have (at least theoretical) end-to-end security SSL/TLS can protect the data channel, i.e. the data plane from our model. However, without DNSSEC or some similar method of protecting the name->address mapping, the data protection is at best of limited use. (You really should review Dan Kaminsky's Black Hat presentation, and Anton Kapella's Black Hat presentation, to understand why.) I don't believe any reasonable advocates of DNSSEC are also anti-SSL/TLS. DNS without DNSSEC *is* an additional way to attack the final application. > This is why I don't believe the MitM is the proper threat model for DNS. See the above. MitM protection is necessary, but not sufficient, to provide security for any system that relies on DNS, e.g., what most people think of when they refer to "The Internet". 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 Wed Oct 8 13:32: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 9B9303A6BEE; Wed, 8 Oct 2008 13:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 v49JPsvH0glF; Wed, 8 Oct 2008 13:32:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 852383A6BED; Wed, 8 Oct 2008 13:32:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Knfdd-0007PP-DE for namedroppers-data@psg.com; Wed, 08 Oct 2008 20:28: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 1KnfdU-0007I6-Up for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 20:28:01 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m98KQT7E022961; Wed, 8 Oct 2008 20:26:29 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m98KQSms022960; Wed, 8 Oct 2008 20:26:28 GMT Date: Wed, 8 Oct 2008 20:26:28 +0000 From: bmanning@vacation.karoshi.com To: Nicholas Weaver Cc: bmanning@vacation.karoshi.com, mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? Message-ID: <20081008202628.GA22716@vacation.karoshi.com.> References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081002123733.GA13334@vacation.karoshi.com.> <20081008183325.GA21338@vacation.karoshi.com.> <836029DF-1D70-4638-A4EF-441CB48C0073@ICSI.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <836029DF-1D70-4638-A4EF-441CB48C0073@ICSI.Berkeley.EDU> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Oct 08, 2008 at 11:52:18AM -0700, Nicholas Weaver wrote: > > On Oct 8, 2008, at 11:33 AM, bmanning@vacation.karoshi.com wrote: > > >On Thu, Oct 02, 2008 at 08:10:02AM -0700, Nicholas Weaver wrote: > > I'm afraid I just don't get it. > > The whole point of DNSSEC is to insure that the object returned by a > query has an integrity guarentee associated with it, not that you can > do a separate integrity check. I can't find anything that suggests > otherwise. has the ability to have an integrity guarentee. a priora, it (DNSSEC) does not ensure that a reply to a query has an integrity guarentee - it simply provides the framework on which such auarentees can be made. > >>getaddrinfo() is a wrapper around a call to the local stub resolver. > >>Thus if the stub resolver validates as part of the lookup process, > >>getaddrinfo() validates as part of the lookup process. ANd if you > >>trust the operating system, you can trust the operating system's stub > >>resolver to do this properly. > > > > a stub resolver is, by definition, just the set of system calls. > > it can't validate, since there is no local cache. > > Actually, this is incorrect. Many MANY end system stub resolvers > maintain cache state. Try it out for yourself with a TCPdump and > multiple invocations of ping. then they are not stub resolvers. > >>How many end-host lookups are "DNS is the application"? Almost none. > > > > actually - 100% of them. the DNS application will > > almost always pass the results of a lookup back to some > > other application. > > Thats exactly my point. DNS is not the application! the DNS is AN application. a host-lookup is a DNS lookup, e.g. the DNS application. the results may be used by other applications. > > You can attack the final application by attacking the name -> address > mapping or many other ways. DNS only needs to not provide ADDITIONAL > ways to attack the final application. w/o DNSSEC, there are ADDITIONAL ways to attack, regardless of the target application. you can and should still use other security methods like TLS or SSL or other application specific techniques. > > This is why I don't believe the MitM is the proper threat model for DNS. then take it up w/ the authors of the DNS risk/threat RFC. > Separate validation is USELESS: Apps either won't validate or they > will. If the app doesn't validate it, it gains no protection from > DNSSEC. thats your claim. we'll see how things pan out. > > > > thats not a new idea either - but fraught w/ transient trust > > problems. > > Its the same transient trust problem present in TLS's CA structure, or > any PKI infrastructure. And it doesn't add any MORE transient trust > problems than any other PKI infrastructure. In fact, in both cases > you have to trust Verisign. er, not quite the same. stuffing SSH keys or any other application key into the DNS presumes that the application owner controls the contents of the DNS zone... which is not true in most cases. the one case that the IETF retained was storing x509 certificates in CERT rrs. > > Yowsa... put everything in the DNS 'cause thats all we got? > > No, put it in DNSSEC because its code that works. that argument has been used before w/ limited efficacy. > Lesson #1: never reimplement crypto when there is an off-the-shelf > solution. not quite what I learned but close. ) never reimplement crypto that works for your intended use. ** unless you are a crypto person and know what the heck you are doing. > > > not sure what this means. > > That if you actually DO want this, you include library code that > interfaces with DNS directly, bypassing gethostbyname() completely, > because the policy you want for the gray cases is probably not the > policy the stub resolver wants. so you are talking about a validator API independent of the resolver API? --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 Oct 8 13:52: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 930993A6817; Wed, 8 Oct 2008 13:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 SQkpS5Kes41k; Wed, 8 Oct 2008 13:52:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B21EA3A6B92; Wed, 8 Oct 2008 13:52:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Knfy4-0009Jc-5I for namedroppers-data@psg.com; Wed, 08 Oct 2008 20:49:12 +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 1Knfxy-00099i-6L for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 20:49:09 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m98KlL7E023227; Wed, 8 Oct 2008 20:47:26 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m98KlIOa023225; Wed, 8 Oct 2008 20:47:18 GMT Date: Wed, 8 Oct 2008 20:47:18 +0000 From: bmanning@vacation.karoshi.com To: Tony Finch Cc: bmanning@vacation.karoshi.com, Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? Message-ID: <20081008204718.GA23216@vacation.karoshi.com.> References: <20081001181558.2BAE050846@romeo.rtfm.com> <20081002014030.C266C50846@romeo.rtfm.com> <20081007035550.C33BA6B5D8D@kilo.rtfm.com> <20081007201153.137A850846@romeo.rtfm.com> <20081008164243.GH44963@commandprompt.com> <20081008173927.GB20991@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 Wed, Oct 08, 2008 at 07:01:50PM +0100, Tony Finch wrote: > On Wed, 8 Oct 2008, bmanning@vacation.karoshi.com wrote: > > > > sure, validation failure is validation failure... but when and > > from whom? Ed leaves out transient network failure as areason > > for validation failure... when validation fails, how often do > > you retry? > > A SERVFAIL because of network breakage is not really a DNSSEC problem. > > Tony. how do you tell? --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 Oct 8 14:41: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 763133A67DB; Wed, 8 Oct 2008 14:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.17 X-Spam-Level: X-Spam-Status: No, score=-0.17 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_41=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 0n1gzESitXVs; Wed, 8 Oct 2008 14:41:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D69B13A68A1; Wed, 8 Oct 2008 14:41:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kngh1-000DKn-Qj for namedroppers-data@psg.com; Wed, 08 Oct 2008 21:35:39 +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 1Knggu-000DKC-Ph for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 21:35:36 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m98LZUBb054123 for ; Wed, 8 Oct 2008 17:35:30 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m98LZUPC054122 for namedroppers@ops.ietf.org; Wed, 8 Oct 2008 17:35:30 -0400 (EDT) (envelope-from namedroppers) Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KngDg-000Anm-T5 for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 21:05:24 +0000 Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id m98L4fNu031897 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 8 Oct 2008 17:04:42 -0400 Date: Wed, 8 Oct 2008 17:04:40 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Brian Dickson cc: Nicholas Weaver , , , Andrew Sullivan , Subject: Re: [dnsext] Re: Protecting caches? In-Reply-To: <48ED0AB5.6040903@ca.afilias.info> Message-ID: 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: [ Note: Post was moderated. ] On Wed, 8 Oct 2008, Brian Dickson wrote: > However, without DNSSEC or some similar method of protecting the > name->address mapping, the data protection is at best of limited use. The above is not true, as I recently explained on the DJBDNS list. The point is that there is only two categories: One category of attack that can come from anywhere, and the other category of attack can only come from the middle. DNS over TCP eliminates the first category, so no further effort is needed to eliminate that category. TLS, properly verified, completely eliminates the second category, so no further effort is needed to eliminate that category. All done. No more changes to DNS are needed. > (You really should review Dan Kaminsky's Black Hat presentation, and > Anton Kapella's Black Hat presentation, to understand why.) Kaminsky's claims have been discredited; he didn't discover or even rediscover forgotton attacks. The attack kaminsky describes was described as recently as 2006 to the IETF, and was pointed out by Dr. Bernstein in the 1990s when the 'balliwick' changes were being discussed. The Kaminsky report created "urgency"; A frequent element of a scam is to have such urgency that one can't stop to think about whether the claims are legitimate or make sense. Professor Bruce Wedlock often repeated "Always ask yourself 'Does this make sense?'" Of course, the attack could have been forgotten and 'rediscovered', but that isn't the case, either. I found a design report for Unbound (developed by Nominet, Verisign, NLnet Labs, EP.NET (Bill Manning)) http://www.unbound.net/documentation/ietf67-design-02.pdf in which they describe that "spoofed NS additionals confuse iterator". This paper was discussed at IETF 67, in November 2006, so one can't even say that DJB discovered the attack in the 90's but it was forgotten and rediscovered by Kaminsky. Kaminsky just created a lot of "urgency", with the result of scaring people into adopting DNSSEC. I've recently been discussing a problem Kaminsky and Kevin Day reported (at blackhat) to exist in DJBDNS. They still have not revealed precisely what the bug is, months later, and many in the DJBDNS community are getting fed up with the delay. After criticizing Kaminsky and Day for failing to talk to the DJBDNS community about the problems, Kaminsky and Day began to talk a bit more about their mathematical assumptions. To put it bluntly, their math was complete BS. And after I analyzed the math a bit (discrediting their analysis), I did discover some few things that could be smarter in DJBDNS, that apparently they had previously seen but not reported. They proposed (to me, at least) changes to DJBDNS to re-use ports. (no patches, just the idea of doing this). Their proposal has the effect that any port coincidence would then have multiple possible QIDs instead of exactly one. This actually harms security, but they don't see that. Instead of probability of port coincidence * 1/65536 QIDs as currently a response received must have the correct query, port and QID, it becomes probability of port coincidence * probability of QID coincidence. The CRC handbook of Applied Cryptography gives the formulas needed in section 2.1.5, Birthday problems. On a regular unix system, the first 1025 ports usually won't be assigned to a socket, leaving 64510 ports available for use. The math for the first case: model B (2 urns, no replacement) p4(64510, 200, 200) exact formula: 1 - (perm(m, n1+n2) / (perm(m, n1) * perm(m, n2)) simplified (n1 = n2): 1 - (perm(m, 2n) / (perm(m,n) ^ 2)) (%i48) float( 1 - ( 64510! / ( 64510 - 400)! ) / ( ( 64510! / ( 64510 - 200)! ) ^ 2 ) ); (%o48) 0.46312147260386 (%i49) % * (1/65536); (%o49) 7.066672860776713E-6 (%i50) 1 / %; (%o50) 141509.3099258154 (%i51) 200 * %; (%o51) 2.830186198516307E+7 So, as is, one must repeat 141509 times before success, expect to send 28,301,862 packets against DJBDNS. Yet Kaminsky asserts the birthday attack is carried out in 65536 * 65536 / 200 = ~21474837 packets. While within an order of magnitude, Kaminsky calculates and incorrect number and uses an incorrect formala for a birthday attack. After the Kaminsky/Day proposed changes to DJBDNS (and possibly other DNS servers), there would be two birthday attacks that combine resulting in: model B (2 urns, no replacement) (port coincidence as above) p4(64510, 200, 200) exact formula: 1 - (perm(m, n1+n2) / (perm(m, n1) * perm(m, n2)) simplified (n1 = n2): 1 - (perm(m, 2n) / (perm(m,n) ^ 2)) (%i48) float( 1 - ( 64510! / ( 64510 - 400)! ) / ( ( 64510! / ( 64510 - 200)! ) ^ 2 ) ); (%o48) 0.46312147260386 model B (2 urns, no replacement) (QID coincidence) p4(65536, 200, 200) (%i73) float( 1 - ( 65536! / ( 65536 - 400)! ) / ( ( 65536! / ( 65536 - 200)! ) ^ 2 ) ); (%o73) 0.4578519611075 (%i75) %o48 * %o73; (%o75) 0.21204107446267 (%i76) 1 / %; (%o76) 4.716067405968776 (%i77) 200 * %; (%o77) 943.2134811937551 So, if you have 200 outstanding ports, with 200 outstanding QIDs, and any correct port can have a coincidence on the 200 QIDs, the cache is spoofed in just under under 5 tries, or in about 943 packets!!! Holy added-security flaws! > I don't believe any reasonable advocates of DNSSEC are also anti-SSL/TLS. > > DNS without DNSSEC *is* an additional way to attack the final application. DNS *with* DNSSEC is an additional way to attack the final application. DNSSEC caches can still be poisoned by setting the CD bit so that the cache does not verify the data, then spoofing by ordinary means with the appropriatly set DO and CD bits. The cache won't verify the data, and so will cache invalid data that it hands to the stub resolver for verification. The resolver that tries to verify the data will reject the invalid signature, but can't get past the cache with the bad data. Result: DOS. And of course, don't forget that spoofed DNSSEC queries of TLDs or significant domains can result in an upto 8KB response that can't be easily mitigated. > > This is why I don't believe the MitM is the proper threat model for DNS. > > See the above. MitM protection is necessary, but not sufficient, to > provide security for any system that relies on DNS, e.g., what most > people think of when they refer to "The Internet". DNSSEC does not protect an application against a MITM attack. Even getting the right domain name, if the application does not use TLS or if the application does not properly verify the certificates, it is still vulnerable to a MITM attack. If the application gets bad domain data, TLS and proper verification will detect this. DNS 'security' is not necessary to avoid MITM attacks. There are also some other crypto problems with DNSSEC, in that they didn't follow the recommendations for adding a random salt before the signatures, and so are vulnerable to low encryption coefficient attack, etc. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-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 Oct 8 15:25: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 038613A6878; Wed, 8 Oct 2008 15:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.427 X-Spam-Level: X-Spam-Status: No, score=0.427 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 n+gSmAxb8PjR; Wed, 8 Oct 2008 15:25:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 331C63A6817; Wed, 8 Oct 2008 15:25:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnhO1-000Ghj-TV for namedroppers-data@psg.com; Wed, 08 Oct 2008 22:20:05 +0000 Received: from [209.85.198.224] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnhNw-000Gg7-CR for namedroppers@ops.ietf.org; Wed, 08 Oct 2008 22:20:03 +0000 Received: by rv-out-0506.google.com with SMTP id b25so3902080rvf.41 for ; Wed, 08 Oct 2008 15:19:59 -0700 (PDT) Received: by 10.141.146.4 with SMTP id y4mr5557186rvn.272.1223504399426; Wed, 08 Oct 2008 15:19:59 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Wed, 8 Oct 2008 15:19:59 -0700 (PDT) Message-ID: Date: Wed, 8 Oct 2008 15:19:59 -0700 From: "Matthew Dempsky" To: "Dean Anderson" Subject: Re: [dnsext] Re: Protecting caches? Cc: namedroppers@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48ED0AB5.6040903@ca.afilias.info> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Oct 8, 2008 at 2:04 PM, Dean Anderson wrote: > The point is that there is only two categories: One category of attack > that can come from anywhere, and the other category of attack can only > come from the middle. DNS over TCP eliminates the first category, so no > further effort is needed to eliminate that category. This is not entirely true. DNS over TCP is vulnerable to TCP RST denial-of-service attacks (like any TCP service). Of course, if you switch to sending your encrypted/authenticated queries over UDP (e.g., using a scheme like DNSCurve), then you can defend against these attacks also eliminating the extra round for the TCP handshake. -- to unsubscribe send a message to namedroppers-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 Oct 8 17:23: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 C0F7E28C144; Wed, 8 Oct 2008 17:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.04 X-Spam-Level: X-Spam-Status: No, score=-5.04 tagged_above=-999 required=5 tests=[AWL=0.008, 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 8aSw153mO2jq; Wed, 8 Oct 2008 17:23:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BFC4E28C129; Wed, 8 Oct 2008 17:23:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnjEf-0000RT-4b for namedroppers-data@psg.com; Thu, 09 Oct 2008 00:18:33 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnjEa-0000Qt-ME for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 00:18:30 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m990IIdf022235; Wed, 8 Oct 2008 17:18:18 -0700 (PDT) Cc: Nicholas Weaver , "Dean Anderson" , namedroppers@ops.ietf.org Message-Id: <0C8C40C4-F46E-4BD2-880F-478DC8DAE55A@icsi.berkeley.edu> From: Nicholas Weaver To: Matthew Dempsky 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 v929.2) Subject: Re: [dnsext] Re: Protecting caches? Date: Wed, 8 Oct 2008 17:18:20 -0700 References: <48ED0AB5.6040903@ca.afilias.info> X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Oct 8, 2008, at 3:19 PM, Matthew Dempsky wrote: > On Wed, Oct 8, 2008 at 2:04 PM, Dean Anderson wrote: >> The point is that there is only two categories: One category of >> attack >> that can come from anywhere, and the other category of attack can >> only >> come from the middle. DNS over TCP eliminates the first category, >> so no >> further effort is needed to eliminate that category. > > This is not entirely true. DNS over TCP is vulnerable to TCP RST > denial-of-service attacks (like any TCP service). Of course, if you > switch to sending your encrypted/authenticated queries over UDP (e.g., > using a scheme like DNSCurve), then you can defend against these > attacks also eliminating the extra round for the TCP handshake. TCP RST injection in a blind mode is not effective if your end host is finniky about packet acceptance. Additionally, since DNS messages are short and the protocol is effectively stateless, just start up a new connection: it leaves a very low timeout window for an attack to do any 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 Wed Oct 8 17:36: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 520513A6C12; Wed, 8 Oct 2008 17:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.277 X-Spam-Level: X-Spam-Status: No, score=0.277 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 6ANXQ1J0rgTY; Wed, 8 Oct 2008 17:36:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 867443A6C13; Wed, 8 Oct 2008 17:36:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnjSU-0001XH-5M for namedroppers-data@psg.com; Thu, 09 Oct 2008 00:32:50 +0000 Received: from [209.85.198.237] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnjSO-0001WY-3G for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 00:32:47 +0000 Received: by rv-out-0506.google.com with SMTP id b25so3951417rvf.41 for ; Wed, 08 Oct 2008 17:32:42 -0700 (PDT) Received: by 10.140.165.21 with SMTP id n21mr5614976rve.244.1223512362348; Wed, 08 Oct 2008 17:32:42 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Wed, 8 Oct 2008 17:32:42 -0700 (PDT) Message-ID: Date: Wed, 8 Oct 2008 17:32:42 -0700 From: "Matthew Dempsky" To: "Nicholas Weaver" Subject: Re: [dnsext] Re: Protecting caches? Cc: "Dean Anderson" , namedroppers@ops.ietf.org In-Reply-To: <0C8C40C4-F46E-4BD2-880F-478DC8DAE55A@icsi.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48ED0AB5.6040903@ca.afilias.info> <0C8C40C4-F46E-4BD2-880F-478DC8DAE55A@icsi.berkeley.edu> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Oct 8, 2008 at 5:18 PM, Nicholas Weaver wrote: > TCP RST injection in a blind mode is not effective if your end host is > finniky about packet acceptance. Yeah, but not all attackers have to operate blind. -- to unsubscribe send a message to namedroppers-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 Oct 8 17:45: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 8C1D63A6C15; Wed, 8 Oct 2008 17:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.041 X-Spam-Level: X-Spam-Status: No, score=-5.041 tagged_above=-999 required=5 tests=[AWL=0.007, 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 1Nu+tNIHskVj; Wed, 8 Oct 2008 17:45:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9AB573A6C0C; Wed, 8 Oct 2008 17:45:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnjbF-0002MV-P9 for namedroppers-data@psg.com; Thu, 09 Oct 2008 00:41:53 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnjbA-0002Lz-QH for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 00:41:51 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m990fiT3024866; Wed, 8 Oct 2008 17:41:44 -0700 (PDT) Cc: Nicholas Weaver , "Dean Anderson" , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: "Matthew Dempsky" 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 v929.2) Subject: Re: [dnsext] Re: Protecting caches? Date: Wed, 8 Oct 2008 17:41:44 -0700 References: <48ED0AB5.6040903@ca.afilias.info> <0C8C40C4-F46E-4BD2-880F-478DC8DAE55A@icsi.berkeley.edu> X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Oct 8, 2008, at 5:32 PM, Matthew Dempsky wrote: > On Wed, Oct 8, 2008 at 5:18 PM, Nicholas Weaver > wrote: >> TCP RST injection in a blind mode is not effective if your end host >> is >> finniky about packet acceptance. > > Yeah, but not all attackers have to operate blind. But a non-blind attacker can ALWAYS screw you up by attacking the final application as a MitM: Why waste the effort DoSing the DNS TCP connection? -- to unsubscribe send a message to namedroppers-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 Oct 8 19:36: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 4E38A3A6BA2; Wed, 8 Oct 2008 19:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.227 X-Spam-Level: X-Spam-Status: No, score=0.227 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 tbQ-KMukt14Q; Wed, 8 Oct 2008 19:36:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5BB463A696B; Wed, 8 Oct 2008 19:36:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnlIw-000Fid-Av for namedroppers-data@psg.com; Thu, 09 Oct 2008 02:31:06 +0000 Received: from [209.85.198.234] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnlIr-000Fh5-Af for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 02:31:03 +0000 Received: by rv-out-0506.google.com with SMTP id b25so3995448rvf.41 for ; Wed, 08 Oct 2008 19:31:00 -0700 (PDT) Received: by 10.140.192.9 with SMTP id p9mr5682346rvf.193.1223519460452; Wed, 08 Oct 2008 19:31:00 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Wed, 8 Oct 2008 19:31:00 -0700 (PDT) Message-ID: Date: Wed, 8 Oct 2008 19:31:00 -0700 From: "Matthew Dempsky" To: "Nicholas Weaver" Subject: Re: [dnsext] Re: Protecting caches? Cc: "Dean Anderson" , namedroppers@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48ED0AB5.6040903@ca.afilias.info> <0C8C40C4-F46E-4BD2-880F-478DC8DAE55A@icsi.berkeley.edu> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Oct 8, 2008 at 5:41 PM, Nicholas Weaver wrote: > But a non-blind attacker can ALWAYS screw you up by attacking the final > application as a MitM: Why waste the effort DoSing the DNS TCP connection? If you already know the other host's public key through another channel secure against the attacker (e.g., public keys known a priori for the root servers or securely retrieved from parent name servers), then the attacker cannot forge any application-level data. They're limited to corrupting the TLS stream or resetting the TCP connection; i.e., denial of service attacks. Using UDP prevents sniffing attackers from being able to mount denial of service attacks. Forged UDP responses can be detected and discarded while continuing to wait for an authentic response. (Of course, routers between the two hosts can still deny service by dropping packets, but this is unavoidable.) -- to unsubscribe send a message to namedroppers-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 Oct 8 20:24: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 082F13A67FF; Wed, 8 Oct 2008 20:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.575 X-Spam-Level: X-Spam-Status: No, score=-0.575 tagged_above=-999 required=5 tests=[AWL=-0.080, 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 IUOXiz0hHpl2; Wed, 8 Oct 2008 20:24:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 10FB83A6959; Wed, 8 Oct 2008 20:24:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Knm4l-000Mmt-5Y for namedroppers-data@psg.com; Thu, 09 Oct 2008 03:20:31 +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 1Knm4g-000Mm0-9Z for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 03:20:28 +0000 Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id AA5986BA63E; Wed, 8 Oct 2008 20:20:24 -0700 (PDT) Date: Wed, 08 Oct 2008 20:20:24 -0700 From: Eric Rescorla To: "Matthew Dempsky" Cc: "Nicholas Weaver" , "Dean Anderson" , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? In-Reply-To: References: <48ED0AB5.6040903@ca.afilias.info> <0C8C40C4-F46E-4BD2-880F-478DC8DAE55A@icsi.berkeley.edu> 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: <20081009032024.AA5986BA63E@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Wed, 8 Oct 2008 19:31:00 -0700, Matthew Dempsky wrote: > Using UDP prevents sniffing attackers from being able to mount denial > of service attacks. Forged UDP responses can be detected and > discarded while continuing to wait for an authentic response. (Of > course, routers between the two hosts can still deny service by > dropping packets, but this is unavoidable.) As a nit: I'm not sure this is really true. Let's say that Alice wants to connect to Bob and a priori knows Bob's public key. The MITM intercepts the handshake and generates invalid protocol data (e.g., if you're doing TLS it pretends not to speak a compatible cipher suite). This looks like a protocol error. Maybe you retry later, maybe you don't, but I suspect for most well-behaved stacks this wouldbe a reasonably effective DoS. -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 Wed Oct 8 21:06: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 13E0F3A69D9; Wed, 8 Oct 2008 21:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 zPcHqkdTbqPv; Wed, 8 Oct 2008 21:06:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F7F23A6934; Wed, 8 Oct 2008 21:06:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnmjP-00050k-4M for namedroppers-data@psg.com; Thu, 09 Oct 2008 04:02:31 +0000 Received: from [209.85.198.229] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnmjD-0004ze-1y for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 04:02:26 +0000 Received: by rv-out-0506.google.com with SMTP id b25so4028351rvf.41 for ; Wed, 08 Oct 2008 21:02:18 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=gC1ZW8MVpISjEO42sEiA5Ft88+cluDrQaHhTaPScjx8=; b=LhMX3MhZBK1TK+9yR1PeZasMzJFaPlJwBxQiHq3a7WN0ctlQ6yyiNzeApDgM3/4AYa REEn57OKcaefcb4ZwgIc5v5h2dhU10a0Sq/lMhKsDhW+DHyMcR2gXRbKSJJdsBhW8q+H UM0+FCMaht0tFQxfoygRNf2UVDpq6Lvd/CcD0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=CWqd/WoOy9OBkfHZm56ar8LCOh9WALyeduSXkziAj91SGXiExJpVRaFvYjBiRund51 oIr9c6367PJ3Bu23ZI7noo7h0GNSjggf3+oAMSzIfDvIyUhWx5/19qxwcjO3PcvPWTQd vsTfSF0uHT1sRQDtMlQoOQ3b3s0J75OoLpSCs= Received: by 10.141.204.20 with SMTP id g20mr5723984rvq.230.1223524937598; Wed, 08 Oct 2008 21:02:17 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Wed, 8 Oct 2008 21:02:17 -0700 (PDT) Message-ID: <396556a20810082102t161559dcl1f347ee76a891aed@mail.gmail.com> Date: Wed, 8 Oct 2008 21:02:17 -0700 From: "Adam Langley" To: "Eric Rescorla" Subject: Re: [dnsext] Re: Protecting caches? Cc: "Matthew Dempsky" , "Nicholas Weaver" , "Dean Anderson" , namedroppers@ops.ietf.org In-Reply-To: <20081009032024.AA5986BA63E@kilo.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48ED0AB5.6040903@ca.afilias.info> <0C8C40C4-F46E-4BD2-880F-478DC8DAE55A@icsi.berkeley.edu> <20081009032024.AA5986BA63E@kilo.rtfm.com> X-Google-Sender-Auth: 8225992d8705f887 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Oct 8, 2008 at 8:20 PM, Eric Rescorla wrote: > Let's say that Alice wants to connect to Bob and a priori knows > Bob's public key. The MITM intercepts the handshake and generates > invalid protocol data (e.g., if you're doing TLS it pretends not > to speak a compatible cipher suite). This looks like a protocol > error. Maybe you retry later, maybe you don't, but I suspect > for most well-behaved stacks this wouldbe a reasonably effective > DoS. For the specific case of DNSCurve (which I suspect is what Matthew had in mind), that doesn't work. An attacker can observe the request and then fabricate replies with the correct TXID and port, all of which will be rejected in only a few thousand CPU cycles until the real one comes in. The attacker may destroy the request in transit and cause a DoS, but the client will never accept an unauthenticated reply if a parent DNS believes that the DNS server should be DNSCurve capable. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.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 Oct 8 21:28: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 CD7F13A6C35; Wed, 8 Oct 2008 21:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.568 X-Spam-Level: X-Spam-Status: No, score=-0.568 tagged_above=-999 required=5 tests=[AWL=-0.073, 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 vGpByGBRTisO; Wed, 8 Oct 2008 21:28:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ECC423A69A5; Wed, 8 Oct 2008 21:28:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Knn4H-0008rH-Q2 for namedroppers-data@psg.com; Thu, 09 Oct 2008 04:24:05 +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 1Knn4B-0008op-Or for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 04:24:03 +0000 Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 62E176BA9B9; Wed, 8 Oct 2008 21:23:57 -0700 (PDT) Date: Wed, 08 Oct 2008 21:23:56 -0700 From: Eric Rescorla To: "Adam Langley" Cc: "Eric Rescorla" , "Matthew Dempsky" , "Nicholas Weaver" , "Dean Anderson" , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? In-Reply-To: <396556a20810082102t161559dcl1f347ee76a891aed@mail.gmail.com> References: <48ED0AB5.6040903@ca.afilias.info> <0C8C40C4-F46E-4BD2-880F-478DC8DAE55A@icsi.berkeley.edu> <20081009032024.AA5986BA63E@kilo.rtfm.com> <396556a20810082102t161559dcl1f347ee76a891aed@mail.gmail.com> 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: <20081009042357.62E176BA9B9@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Wed, 8 Oct 2008 21:02:17 -0700, Adam Langley wrote: > > On Wed, Oct 8, 2008 at 8:20 PM, Eric Rescorla wrote: > > Let's say that Alice wants to connect to Bob and a priori knows > > Bob's public key. The MITM intercepts the handshake and generates > > invalid protocol data (e.g., if you're doing TLS it pretends not > > to speak a compatible cipher suite). This looks like a protocol > > error. Maybe you retry later, maybe you don't, but I suspect > > for most well-behaved stacks this wouldbe a reasonably effective > > DoS. > > For the specific case of DNSCurve (which I suspect is what Matthew had > in mind), that doesn't work. An attacker can observe the request and > then fabricate replies with the correct TXID and port, all of which > will be rejected in only a few thousand CPU cycles until the real one > comes in. The attacker may destroy the request in transit and cause a > DoS, but the client will never accept an unauthenticated reply if a > parent DNS believes that the DNS server should be DNSCurve capable. I really don't see how this situation differs from TLS/DTLS in any appreciable way. Yes, the client believes that the server speaks the secure protocol, but the attacker removes the server's response (or the client's request) from the wire and impersonates a *broken* server. Sure, the client could just keep banging on the server, even though it appears to be broken, but that's rude behavior. Well-behaved clients will back off. Instant DoS. -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 Wed Oct 8 21:40: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 25FA23A6C44; Wed, 8 Oct 2008 21:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.202 X-Spam-Level: X-Spam-Status: No, score=0.202 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 t5V2psZgtFrx; Wed, 8 Oct 2008 21:40:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 55BB53A68A8; Wed, 8 Oct 2008 21:40:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnnGe-000B69-Qz for namedroppers-data@psg.com; Thu, 09 Oct 2008 04:36:52 +0000 Received: from [209.85.198.229] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnnGa-000B5g-1o for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 04:36:50 +0000 Received: by rv-out-0506.google.com with SMTP id b25so4039091rvf.41 for ; Wed, 08 Oct 2008 21:36:47 -0700 (PDT) Received: by 10.140.164.1 with SMTP id m1mr5768454rve.69.1223527007890; Wed, 08 Oct 2008 21:36:47 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Wed, 8 Oct 2008 21:36:47 -0700 (PDT) Message-ID: Date: Wed, 8 Oct 2008 21:36:47 -0700 From: "Matthew Dempsky" To: "Eric Rescorla" Subject: Re: [dnsext] Re: Protecting caches? Cc: "Adam Langley" , "Nicholas Weaver" , "Dean Anderson" , namedroppers@ops.ietf.org In-Reply-To: <20081009042357.62E176BA9B9@kilo.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48ED0AB5.6040903@ca.afilias.info> <0C8C40C4-F46E-4BD2-880F-478DC8DAE55A@icsi.berkeley.edu> <20081009032024.AA5986BA63E@kilo.rtfm.com> <396556a20810082102t161559dcl1f347ee76a891aed@mail.gmail.com> <20081009042357.62E176BA9B9@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Oct 8, 2008 at 9:23 PM, Eric Rescorla wrote: > I really don't see how this situation differs from TLS/DTLS in any > appreciable way. It differs for attackers that can only sniff traffic as opposed to control it. There's obviously no way to prevent denial of service from attackers who can simply disconnect you from parts of the Internet. -- to unsubscribe send a message to namedroppers-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 Oct 8 22:02: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 D100C3A68A8; Wed, 8 Oct 2008 22:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.187 X-Spam-Level: X-Spam-Status: No, score=0.187 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 ZfTI-i0lN+AX; Wed, 8 Oct 2008 22:02:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 01D173A684D; Wed, 8 Oct 2008 22:02:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Knnby-000Fu5-KJ for namedroppers-data@psg.com; Thu, 09 Oct 2008 04:58:54 +0000 Received: from [209.85.198.231] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Knnbu-000Fta-2h for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 04:58:52 +0000 Received: by rv-out-0506.google.com with SMTP id b25so4046080rvf.41 for ; Wed, 08 Oct 2008 21:58:49 -0700 (PDT) Received: by 10.141.79.12 with SMTP id g12mr5781618rvl.87.1223528329415; Wed, 08 Oct 2008 21:58:49 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Wed, 8 Oct 2008 21:58:49 -0700 (PDT) Message-ID: Date: Wed, 8 Oct 2008 21:58:49 -0700 From: "Matthew Dempsky" To: "Eric Rescorla" Subject: Re: [dnsext] Re: Protecting caches? Cc: "Adam Langley" , "Nicholas Weaver" , "Dean Anderson" , namedroppers@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48ED0AB5.6040903@ca.afilias.info> <0C8C40C4-F46E-4BD2-880F-478DC8DAE55A@icsi.berkeley.edu> <20081009032024.AA5986BA63E@kilo.rtfm.com> <396556a20810082102t161559dcl1f347ee76a891aed@mail.gmail.com> <20081009042357.62E176BA9B9@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Oct 8, 2008 at 9:36 PM, Matthew Dempsky wrote: > It differs for attackers that can only sniff traffic as opposed to > control it. To be more explicit, DNSCurve has no handshake step for a sniffing attacker to interrupt. A DNSCurve-enabled server announces its public key and supported cipher suites through its DNSCurve-encoded NS record name. When a DNSCurve-enabled client wants to send a DNS query to this server, it generates a standard DNS query, computes a shared secret using Diffie-Hellman, encrypts and authenticates the query, and sends it along with its own public key to the server as a DNSCurve query. The server detects the DNSCurve formatted query, extracts the public key, computes the shared secret as well, verifies and decrypts the standard DNS query, generates a standard DNS response, encrypts and authenticates the response, and sends it back to the client as a DNSCurve response. The client receives the DNSCurve response, verifies and decrypts the response, and processes the embedded standard DNS response. Clients and servers simply discard any DNSCurve packets that don't verify correctly. E.g., if a client sends a DNSCurve query, sets a one second timeout for the response, and receives a bogus DNSCurve response half a second later, then it discards that response after the authenticator fails to verify and continues to wait out the remainder of the second for a legitimate response. If an attacker can only sniff traffic and forge responses, eventually the legitimate query will reach the server and eventually the legitimate response will reach the client. If an attacker can reliably mangle and/or drop traffic, then there's nothing cryptography can do to help prevent a denial of service attack. (Of course, DNSCurve clients will retry DNSCurve queries the same as regular DNS queries to deal with intermitent network failures.) -- to unsubscribe send a message to namedroppers-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 Oct 8 22:04: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 D142D3A68EC; Wed, 8 Oct 2008 22:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.562 X-Spam-Level: X-Spam-Status: No, score=-0.562 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 fFswlKr4OrqO; Wed, 8 Oct 2008 22:04:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E1CA73A684D; Wed, 8 Oct 2008 22:04:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Knne4-000GPT-Fy for namedroppers-data@psg.com; Thu, 09 Oct 2008 05:01:04 +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 1Knndz-000GN2-Ls for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 05:01:01 +0000 Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 437096BABE4; Wed, 8 Oct 2008 22:00:58 -0700 (PDT) Date: Wed, 08 Oct 2008 22:00:57 -0700 From: Eric Rescorla To: "Matthew Dempsky" Cc: "Eric Rescorla" , "Adam Langley" , "Nicholas Weaver" , "Dean Anderson" , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? In-Reply-To: References: <48ED0AB5.6040903@ca.afilias.info> <0C8C40C4-F46E-4BD2-880F-478DC8DAE55A@icsi.berkeley.edu> <20081009032024.AA5986BA63E@kilo.rtfm.com> <396556a20810082102t161559dcl1f347ee76a891aed@mail.gmail.com> <20081009042357.62E176BA9B9@kilo.rtfm.com> 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: <20081009050058.437096BABE4@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Wed, 8 Oct 2008 21:36:47 -0700, Matthew Dempsky wrote: > > On Wed, Oct 8, 2008 at 9:23 PM, Eric Rescorla wrote: > > I really don't see how this situation differs from TLS/DTLS in any > > appreciable way. > > It differs for attackers that can only sniff traffic as opposed to > control it. Again, how is this different from TLS/DTLS? If you can't inject traffic, you can't DoS TLS/DTLS either. Is your argument that an attacker who can both sniff and inject traffic can DoS a TLS/DTLS connection, but that it's possible to design a new protocol that doesn't have this property (I still haven't seen a DNScurve spec, so I can't comment on whether it has that property). This may well be true, but it's not clear to me that there are actually a significant number of threat environments where an attacker can sniff, inject, but not block or gag at all. Can you name one? -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 Wed Oct 8 22:13: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 869AC3A6C44; Wed, 8 Oct 2008 22:13:30 -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=[AWL=-0.062, 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 escmYkVWxfhW; Wed, 8 Oct 2008 22:13:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB34E3A6922; Wed, 8 Oct 2008 22:13:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnnkN-000I5r-5y for namedroppers-data@psg.com; Thu, 09 Oct 2008 05:07:35 +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 1KnnkI-000I4h-AR for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 05:07:32 +0000 Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id D9F886BAC68; Wed, 8 Oct 2008 22:07:27 -0700 (PDT) Date: Wed, 08 Oct 2008 22:07:27 -0700 From: Eric Rescorla To: "Matthew Dempsky" Cc: "Eric Rescorla" , "Adam Langley" , "Nicholas Weaver" , "Dean Anderson" , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? In-Reply-To: References: <48ED0AB5.6040903@ca.afilias.info> <0C8C40C4-F46E-4BD2-880F-478DC8DAE55A@icsi.berkeley.edu> <20081009032024.AA5986BA63E@kilo.rtfm.com> <396556a20810082102t161559dcl1f347ee76a891aed@mail.gmail.com> <20081009042357.62E176BA9B9@kilo.rtfm.com> 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: <20081009050727.D9F886BAC68@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Wed, 8 Oct 2008 21:58:49 -0700, Matthew Dempsky wrote: > > On Wed, Oct 8, 2008 at 9:36 PM, Matthew Dempsky wrote: > > It differs for attackers that can only sniff traffic as opposed to > > control it. > > To be more explicit, DNSCurve has no handshake step for a sniffing > attacker to interrupt. A DNSCurve-enabled server announces its public > key and supported cipher suites through its DNSCurve-encoded NS record > name. Per Paul Hoffman's suggestion, I'd rather not get into a long discussion of DNSCurve until there's a real I-D describing it. That said, this seems like a feature that could trivially be added to DTLS/TLS, simply by announcing the same information in an NS record. > If an attacker can only sniff traffic and forge responses, Can you name a threat environment that actually matches this description? -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 Wed Oct 8 23:52: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 6404D3A6C64; Wed, 8 Oct 2008 23:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.177 X-Spam-Level: X-Spam-Status: No, score=0.177 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 1djyV0Dg9bvt; Wed, 8 Oct 2008 23:52:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A7AFF3A6C63; Wed, 8 Oct 2008 23:52:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnpJB-000GJ8-Ix for namedroppers-data@psg.com; Thu, 09 Oct 2008 06:47:37 +0000 Received: from [209.85.198.235] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnpIz-000GHe-2e for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 06:47:26 +0000 Received: by rv-out-0506.google.com with SMTP id b25so4079514rvf.41 for ; Wed, 08 Oct 2008 23:47:24 -0700 (PDT) Received: by 10.141.76.21 with SMTP id d21mr5823180rvl.242.1223534844000; Wed, 08 Oct 2008 23:47:24 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Wed, 8 Oct 2008 23:47:23 -0700 (PDT) Message-ID: Date: Wed, 8 Oct 2008 23:47:23 -0700 From: "Matthew Dempsky" To: "Eric Rescorla" Subject: Re: [dnsext] Re: Protecting caches? Cc: "Adam Langley" , "Nicholas Weaver" , "Dean Anderson" , namedroppers@ops.ietf.org In-Reply-To: <20081009050727.D9F886BAC68@kilo.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48ED0AB5.6040903@ca.afilias.info> <20081009032024.AA5986BA63E@kilo.rtfm.com> <396556a20810082102t161559dcl1f347ee76a891aed@mail.gmail.com> <20081009042357.62E176BA9B9@kilo.rtfm.com> <20081009050727.D9F886BAC68@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Oct 8, 2008 at 10:07 PM, Eric Rescorla wrote: > At Wed, 8 Oct 2008 21:58:49 -0700, > Matthew Dempsky wrote: >> If an attacker can only sniff traffic and forge responses, > > Can you name a threat environment that actually matches > this description? I'm willing to concede that I cannot. (After some reconsideration, for the scenarios I originally had in mind, I suspect the attacker could additionally hijack control of the victim's traffic, escalating his powers.) However, I'm currently not convinced that such an attacker can *never* exist. So if we have a way to defend against one at no extra cost, it makes sense to do so and then not have to worry about it. -- to unsubscribe send a message to namedroppers-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 Oct 9 03:09: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 B09D53A6A84; Thu, 9 Oct 2008 03:09:54 -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 VYftNLxWU4Nn; Thu, 9 Oct 2008 03:09:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8FF363A6A81; Thu, 9 Oct 2008 03:09:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnsLU-000ChY-M5 for namedroppers-data@psg.com; Thu, 09 Oct 2008 10:02:12 +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 1KnsLG-000CeU-MW for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 10:02:06 +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.3/8.14.3) with ESMTP id m99A1Zdm063043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Oct 2008 12:01:36 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <48EDD67F.60902@nlnetlabs.nl> Date: Thu, 09 Oct 2008 12:01:35 +0200 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Dean Anderson CC: Brian Dickson , Nicholas Weaver , bmanning@vacation.karoshi.com, mayer@gis.net, Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 09 Oct 2008 12:01:37 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Dean, Dean Anderson wrote: > [ Note: Post was moderated. ] >> (You really should review Dan Kaminsky's Black Hat presentation, and >> Anton Kapella's Black Hat presentation, to understand why.) > > Kaminsky's claims have been discredited; he didn't discover or even > rediscover forgotton attacks. The attack kaminsky describes was > described as recently as 2006 to the IETF, and was pointed out by Dr. > Bernstein in the 1990s when the 'balliwick' changes were being > discussed. The Kaminsky report created "urgency"; A frequent element of > a scam is to have such urgency that one can't stop to think about > whether the claims are legitimate or make sense. Professor Bruce Wedlock > often repeated "Always ask yourself 'Does this make sense?'" Of course, > the attack could have been forgotten and 'rediscovered', but that isn't > the case, either. I found a design report for Unbound (developed by > Nominet, Verisign, NLnet Labs, EP.NET (Bill Manning)) > http://www.unbound.net/documentation/ietf67-design-02.pdf in which they > describe that "spoofed NS additionals confuse iterator". This paper was > discussed at IETF 67, in November 2006, so one can't even say that DJB > discovered the attack in the 90's but it was forgotten and rediscovered > by Kaminsky. Kaminsky just created a lot of "urgency", with the result > of scaring people into adopting DNSSEC. The thing that Kaminsky added was the retry for a different (previously unseen) query name, which delivers the race-to-win and no wait for TTLs. The rest is indeed the same. The race-to-win made the problem very urgent. > So, if you have 200 outstanding ports, with 200 outstanding QIDs, and > any correct port can have a coincidence on the 200 QIDs, the cache is > spoofed in just under under 5 tries, or in about 943 packets!!! Holy > added-security flaws! Are you saying that using multiple ports at the same time creates birthday attack problems? Or do you assume in the above that this is the same query that is sent out with multiple outstanding ports/multiple outstanding QIDs? > DNS *with* DNSSEC is an additional way to attack the final application. > > DNSSEC caches can still be poisoned by setting the CD bit so that the > cache does not verify the data, then spoofing by ordinary means with the > appropriatly set DO and CD bits. The cache won't verify the data, and so > will cache invalid data that it hands to the stub resolver for > verification. The resolver that tries to verify the data will reject the > invalid signature, but can't get past the cache with the bad data. > Result: DOS. Unbound has a cache of 'bad' data. This is data that it considers bogus. This data can be retrieved by setting the CD bit, that is the purpose of the CD bit. This data is not returned to regular stub resolvers (withholding the bad data). The stub resolver can then choose via the CD bit to verify that data itself, with its own security policy. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjt1n8ACgkQkDLqNwOhpPgCtQCgqzbSuD3kD8JTOl4qC5mTYy+Y 6goAnRm6UDzjS+leRaGXF2GcRkFBwyua =XSBa -----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 Thu Oct 9 03:38: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 5F8273A6A5C; Thu, 9 Oct 2008 03:38:42 -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 9ONC9tNTVHDd; Thu, 9 Oct 2008 03:38:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 70E073A6A81; Thu, 9 Oct 2008 03:38:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Knsr6-000Fm5-CX for namedroppers-data@psg.com; Thu, 09 Oct 2008 10:34:52 +0000 Received: from [68.142.225.206] (helo=smtp108.rog.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Knsqv-000Fjr-0j for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 10:34:46 +0000 Received: (qmail 98584 invoked from network); 9 Oct 2008 10:34:39 -0000 Received: from unknown (HELO connotech.com) (thierry.moreau@209.148.165.15 with plain) by smtp108.rog.mail.re2.yahoo.com with SMTP; 9 Oct 2008 10:34:38 -0000 X-YMail-OSG: TrPxVggVM1nLLs1QbPgIRfll3NJp4OftiIa1B.R77w_R06eFkg2X6541FMVu970jGA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48EDDF95.8060008@connotech.com> Date: Thu, 09 Oct 2008 05:40:21 -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: Adam Langley CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Rabin-Williams signatures for DNSSEC References: <396556a20810071331n42b933dfn6836e79a7c658e80@mail.gmail.com> In-Reply-To: <396556a20810071331n42b933dfn6836e79a7c658e80@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear Adam, To me personally, it's refreshing to see the R-W (Rabin-Williams) cryptosystem being proposed for standard body adoption. However, the dnsext wg audience is perhaps not ready to read the arguments and appreciate them as if the mathematical properties could be rationally assessed. If I may rephrase your proposal, you are basically making three points: (1) the R-W cryptosystem has better mathematical proofs than RSA, (2) thanks to a recent development, the R-W signatures in the proposed variant are about half the size of RSA, and (3) ietf dnsext should consider this for DNSSEC purposes. Item (1) has been around for decades, with very little, if any, standards body adoption of the R-W for protocol applications. In part, this is due to the 4:1 ambiguity that is handled differently in the many R-W variants (the mathematical symbols e and f in your draft). In part, the mathematical proofs, paradoxically, appear in retrospect as not so good selling point as one would initially expect. Item (2) is new to me, so I presume it would be new to many cryptographic experts influencing the IETF/IESG adoption of standards. ECC (Elliptic Curve Cryptography) also offers smaller signatures, which inevitably will bring lengthy discussions as to the relative merits (...). Item (3) is challenging. You need not only to revise your draft (which is fine as a revision-00 as it makes the point for readers with previous knowledge of R-W mathematics) to speak to implementors in a language that they understand. You probably need to show an implementation as an openssl and/or gnutls source code contribution. And above all, you need to overcome power-of-the-installed-base resistance and inertia in the IETF processes. But yes indeed, smaller signatures would be fine for DNSSEC. And I see the benefits of R-W signatures. So, good luck with this initiative. Regards, - Thierry Moreau Adam Langley wrote: > I had the pleasure of chatting with Paul Vixie recently and he > described some of the cryptographic issues with DNSSEC, specifically > that smaller signatures would be very nice. > > So I wrote up [1] and [2]. [1] is in the form of an ID, although I've > not actually submitted it as such yet. [2] contains the full > (executable) specification of the signature scheme described in [1] > > Abstract: > > This document describes how to use Rabin-Williams public keys and > signatures in DNSSEC. Rabin-Williams signatures provide for faster > verification and smaller signatures than an equivalent RSA scheme, yet > a hash-generic attack is provably equivalent to factoring. > > Introduction: > > DNSSEC seeks to secure the Domain Name System by using signatures that > are precomputable to avoid requiring nameservers to perform a public > key operation for each request. Thus, for DNSSEC, verification speed > is vastly more important than signing speed. > > However, DNSSEC still uses UDP as the primary transport layer > protocol and, despite increasing the maximum payload size, large > signatures are problematic both because of bandwidth and because of > the amplification possibilities in a denial of service attack. > > This would suggest that elliptic curve signature schemes should be > attractive. By using a group of points of an elliptic curve rather > than a multiplicative group, index calculus (and related) attacks are > much less effective and a smaller group is still sufficiently secure. > > Using the ECDSA scheme on the NIST P192 curve results in 384-bit > signatures. However, the verification operation is nearly 25x slower > than 1024-bit RSA (2.33GHz Core2). > > A 1024-bit Rabin-Williams scheme (B=0, fixed, unprincipled, > compressed) results in 512-bit signatures and the verification speed > is about 4x faster than 1024-bit RSA. Due to Bernstein, we have a > proof that a hash generic attack on such a scheme is equivalent to > factoring. > > > [1] http://www.imperialviolet.org/binary/draft-agl-dnsext-rwb0fuz.html > [2] http://github.com/agl/rwb0fuz1024/tree/master%2Frwb0fuz1024.pdf?raw=true > > > Cheers > -- - 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 Thu Oct 9 04:46: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 E061B3A6A94; Thu, 9 Oct 2008 04:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 EGMbNUfwwiEU; Thu, 9 Oct 2008 04:46:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CE8EE3A6A80; Thu, 9 Oct 2008 04:46:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnttX-000M1p-Pi for namedroppers-data@psg.com; Thu, 09 Oct 2008 11:41:27 +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 1KnttN-000LrO-K2 for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 11:41:21 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m99Bdr7E030329; Thu, 9 Oct 2008 11:39:53 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m99BdrTR030328; Thu, 9 Oct 2008 11:39:53 GMT Date: Thu, 9 Oct 2008 11:39:53 +0000 From: bmanning@vacation.karoshi.com To: namedroppers@ops.ietf.org Subject: [dnsext] Notice of Inquiry regarding DNSSEC] Message-ID: <20081009113953.GA30095@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ----- Forwarded message from Ray Plzak ----- NTIA has issued a Notice of Inquiry regarding DNSSEC, with comments due November 24, 2008. Here is the link: http://frwebgate3.access.gpo.gov/cgi-bin/PDFgate.cgi?WAISdocID=54850327964+0+1+0&WAISaction=retrieve Ray ----- End forwarded message ----- -- to unsubscribe send a message to namedroppers-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 Oct 9 07: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 45CF83A68FB; Thu, 9 Oct 2008 07:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 DYo3NwfzonWu; Thu, 9 Oct 2008 07:03:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6B4F13A68AD; Thu, 9 Oct 2008 07:03:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Knvyj-000Bli-E1 for namedroppers-data@psg.com; Thu, 09 Oct 2008 13:54:57 +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 1Knvyd-000Bl0-Iv for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 13:54:54 +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 m99DsmlO059606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Oct 2008 06:54:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <48ED0AB5.6040903@ca.afilias.info> <0C8C40C4-F46E-4BD2-880F-478DC8DAE55A@icsi.berkeley.edu> <20081009032024.AA5986BA63E@kilo.rtfm.com> <396556a20810082102t161559dcl1f347ee76a891aed@mail.gmail.com> <20081009042357.62E176BA9B9@kilo.rtfm.com> Date: Thu, 9 Oct 2008 06:54:44 -0700 To: "Matthew Dempsky" From: Paul Hoffman Subject: [dnsext] No spec for DNSCurve Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 9:58 PM -0700 10/8/08, Matthew Dempsky wrote: >To be more explicit, DNSCurve has no handshake step for a sniffing >attacker to interrupt. How do you know that? DNSCurve is essentially unspecified. We really should wait for Dan (or someone) to write a stable document that says what DNSCurve really means before we make such bold statements. I am far from convinced that, when we see the working protocol, that the above statement will necessarily be true. I would be happy to be wrong. --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 Oct 9 07:06: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 91A253A68FB; Thu, 9 Oct 2008 07:06:59 -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 HdmVU4wjYKKq; Thu, 9 Oct 2008 07:06:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8518D3A68AD; Thu, 9 Oct 2008 07:06:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Knw6M-000Chz-Kz for namedroppers-data@psg.com; Thu, 09 Oct 2008 14:02:50 +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 1Knw67-000Cfb-L7 for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 14:02:43 +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 m99E2Xx5060211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Oct 2008 07:02:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20081009113953.GA30095@vacation.karoshi.com.> References: <20081009113953.GA30095@vacation.karoshi.com.> Date: Thu, 9 Oct 2008 07:02:30 -0700 To: namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] Notice of Inquiry regarding DNSSEC] Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: A more resolvable URL is ; also see . --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 Oct 9 07:29: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 1C86128C118; Thu, 9 Oct 2008 07:29:58 -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 upJ-WEPXja3P; Thu, 9 Oct 2008 07:29:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 34E6828C102; Thu, 9 Oct 2008 07:29:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnwSw-000Fa1-5g for namedroppers-data@psg.com; Thu, 09 Oct 2008 14:26:10 +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 1KnwSm-000FX7-MR for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 14:26:03 +0000 Received: from monsoon.verisignlabs.com (scooter.bo.verisignlabs.com [172.25.170.10]) by cliffie.verisignlabs.com (Postfix) with ESMTP id AF27E1367F5 for ; Thu, 9 Oct 2008 10:25:59 -0400 (EDT) Received: from dul1mcmlarson-l1.verisignlabs.com (dul1mcmlarson-l1.verisignlabs.com [10.131.244.205]) by monsoon.verisignlabs.com (Postfix) with ESMTP id A9BF52420C1 for ; Thu, 9 Oct 2008 10:25:59 -0400 (EDT) Date: Thu, 9 Oct 2008 10:25:55 -0400 From: Matt Larson To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Notice of Inquiry regarding DNSSEC] Message-ID: <20081009142555.GK7094@dul1mcmlarson-l1.verisignlabs.com> References: <20081009113953.GA30095@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, 09 Oct 2008, Paul Hoffman wrote: > A more resolvable URL is ; also see . And http://www.ntia.doc.gov/DNS/DNSSEC.html. Matt -- to unsubscribe send a message to namedroppers-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 Oct 9 08:01: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 56D4B3A69B9; Thu, 9 Oct 2008 08:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 tQ8-jK5kxSDp; Thu, 9 Oct 2008 08:01:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 46B2E3A6972; Thu, 9 Oct 2008 08:01:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnwtS-000IrD-6c for namedroppers-data@psg.com; Thu, 09 Oct 2008 14:53: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 1KnwtB-000Id0-8a for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 14:53:27 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m99Epq7E032537; Thu, 9 Oct 2008 14:51:52 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m99EpqPn032536; Thu, 9 Oct 2008 14:51:52 GMT Date: Thu, 9 Oct 2008 14:51:52 +0000 From: bmanning@vacation.karoshi.com To: Shane Kerr Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? Message-ID: <20081009145152.GA32406@vacation.karoshi.com.> References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081002123733.GA13334@vacation.karoshi.com.> <1222955255.19380.305.camel@shane-macbook-pro> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1222955255.19380.305.camel@shane-macbook-pro> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Oct 02, 2008 at 03:47:35PM +0200, Shane Kerr wrote: > Bill, > > On Thu, 2008-10-02 at 12:37 +0000, bmanning@vacation.karoshi.com wrote: > > its not that hard - many folks are signing their data. > > i remain unconvinced that stub resolvers need to be updated. > > I belive validation can and should be done asyncronously from > > resolution. And it is true that a validator API is sadly > > lacking - although there have been several efforts over the > > years to bring something forward. > > Can you point us to some of these? this might be what you are looking for. http://www.rs.net/rva/index.html --bill > > Too bad the IETF does not "do APIs". (Except when it does, of course.) > > -- > Shane -- to unsubscribe send a message to namedroppers-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 Oct 9 08:26: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 C88243A6A1D; Thu, 9 Oct 2008 08:26:11 -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 yxlHLJQ9CI9S; Thu, 9 Oct 2008 08:26:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D1ED23A6921; Thu, 9 Oct 2008 08:26:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnxIe-000MKh-FT for namedroppers-data@psg.com; Thu, 09 Oct 2008 15:19:36 +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 1KnxIT-000MJY-FL for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 15:19:33 +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.3/8.14.3) with ESMTP id m99FJBh7054873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Oct 2008 17:19:12 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <48EE20EF.7010704@nlnetlabs.nl> Date: Thu, 09 Oct 2008 17:19:11 +0200 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: Shane Kerr , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Protecting caches? References: <20080827170822.GH18946@commandprompt.com> <48E2FAC3.7070509@gis.net> <4D2610E6-48BB-4B41-8042-21389E9A6E46@icsi.berkeley.edu> <20081002123733.GA13334@vacation.karoshi.com.> <1222955255.19380.305.camel@shane-macbook-pro> <20081009145152.GA32406@vacation.karoshi.com.> In-Reply-To: <20081009145152.GA32406@vacation.karoshi.com.> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 09 Oct 2008 17:19:12 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 bmanning@vacation.karoshi.com wrote: > On Thu, Oct 02, 2008 at 03:47:35PM +0200, Shane Kerr wrote: >> Bill, >> >> On Thu, 2008-10-02 at 12:37 +0000, bmanning@vacation.karoshi.com wrote: >>> its not that hard - many folks are signing their data. >>> i remain unconvinced that stub resolvers need to be updated. >>> I belive validation can and should be done asyncronously from >>> resolution. And it is true that a validator API is sadly >>> lacking - although there have been several efforts over the >>> years to bring something forward. >> Can you point us to some of these? > > this might be what you are looking for. > > http://www.rs.net/rva/index.html There is a draft, I think it has seen a lot of effort. http://tools.ietf.org/html/draft-hayatnagarkar-dnsext-validator-api-06 But it was too featurefull for me. The API that lib unbound exposes when validating to an application - one borne out of implementation, simplified and not backwards compatible is http://unbound.net/documentation/libunbound.html I am not suggesting just one implementations API should be a standard, but it could be a useful input. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjuIO8ACgkQkDLqNwOhpPjQfwCeIBc3LnLfNwXOViIQ/aD6KV22 WAUAn3Bsf2qN1DMUJ3c84RuSez3ogtMT =OmP/ -----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 Thu Oct 9 08:39: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 5793028C134; Thu, 9 Oct 2008 08:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.552 X-Spam-Level: X-Spam-Status: No, score=-0.552 tagged_above=-999 required=5 tests=[AWL=-0.057, 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 JzXTsYXxoJXg; Thu, 9 Oct 2008 08:39:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 25E2A3A6A41; Thu, 9 Oct 2008 08:39:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnxVk-000O33-IV for namedroppers-data@psg.com; Thu, 09 Oct 2008 15:33:08 +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 1KnxVX-000O0Q-HD for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 15:33:01 +0000 Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 4058F6BB2C5; Thu, 9 Oct 2008 08:32:53 -0700 (PDT) Date: Thu, 09 Oct 2008 08:32:53 -0700 From: Eric Rescorla To: "Adam Langley" Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Rabin-Williams signatures for DNSSEC In-Reply-To: <396556a20810071331n42b933dfn6836e79a7c658e80@mail.gmail.com> References: <396556a20810071331n42b933dfn6836e79a7c658e80@mail.gmail.com> 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: <20081009153253.4058F6BB2C5@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Tue, 7 Oct 2008 13:31:19 -0700, Adam Langley wrote: > > I had the pleasure of chatting with Paul Vixie recently and he > described some of the cryptographic issues with DNSSEC, specifically > that smaller signatures would be very nice. > > So I wrote up [1] and [2]. [1] is in the form of an ID, although I've > not actually submitted it as such yet. [2] contains the full > (executable) specification of the signature scheme described in [1] > > Abstract: > > This document describes how to use Rabin-Williams public keys and > signatures in DNSSEC. Rabin-Williams signatures provide for faster > verification and smaller signatures than an equivalent RSA scheme, yet > a hash-generic attack is provably equivalent to factoring. > > Introduction: > > DNSSEC seeks to secure the Domain Name System by using signatures that > are precomputable to avoid requiring nameservers to perform a public > key operation for each request. Thus, for DNSSEC, verification speed > is vastly more important than signing speed. > > However, DNSSEC still uses UDP as the primary transport layer > protocol and, despite increasing the maximum payload size, large > signatures are problematic both because of bandwidth and because of > the amplification possibilities in a denial of service attack. > > This would suggest that elliptic curve signature schemes should be > attractive. By using a group of points of an elliptic curve rather > than a multiplicative group, index calculus (and related) attacks are > much less effective and a smaller group is still sufficiently secure. > > Using the ECDSA scheme on the NIST P192 curve results in 384-bit > signatures. However, the verification operation is nearly 25x slower > than 1024-bit RSA (2.33GHz Core2). > > A 1024-bit Rabin-Williams scheme (B=0, fixed, unprincipled, > compressed) results in 512-bit signatures and the verification speed > is about 4x faster than 1024-bit RSA. Due to Bernstein, we have a > proof that a hash generic attack on such a scheme is equivalent to > factoring. First, let me observe that this all has a very strong whiff of premature optimization. Given that there has been next to no deployment of DNSSEC, I think the evidence that either signature size *or* signature verification performance is going to be an issue is fairly weak. With that in mind, it's even less clear to me that R-W is the right choice here. 1. The performance comparison you're making here isn't really that useful because 192-bit ECDSA is much more comparable to 1776-bit RSA (see http://www.keylength.com/en/3/), which is rather slower (I'm guessing 3-4x) than 1024-bit RSA. 128-bit ECDSA would be a more accurate comparison. 2. There's a tradeoff between signature size and performance. BLS allows you to get signatures down to 160 bits (at the 80-bit security level comparable to ECC-160) but at the cost of a much slower verification. It incidentally also allows aggregating multiple signatures into one. So, we should be clear on what it is we value the most. 3. I did a little looking and it doesn't seem to me that anyone has standardized R-W. I generally prefer to see [and I think is more or less common practice] IETF only adopt algorithms which have been vetted by one of the more crypto-oriented standards bodies (IEEE, NIST, etc.) -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 Thu Oct 9 09:21: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 475A03A6A83; Thu, 9 Oct 2008 09:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.25 X-Spam-Level: X-Spam-Status: No, score=0.25 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, 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 n7PXb0hMrcSu; Thu, 9 Oct 2008 09:21:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 693C93A6983; Thu, 9 Oct 2008 09:21:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kny9C-0003bx-2x for namedroppers-data@psg.com; Thu, 09 Oct 2008 16:13:54 +0000 Received: from [206.190.53.30] (helo=smtp125.rog.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kny95-0003Zb-Pg for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 16:13:50 +0000 Received: (qmail 6505 invoked from network); 9 Oct 2008 16:13:45 -0000 Received: from unknown (HELO connotech.com) (thierry.moreau@209.148.165.15 with plain) by smtp125.rog.mail.re2.yahoo.com with SMTP; 9 Oct 2008 16:13:45 -0000 X-YMail-OSG: EBmCRWUVM1kAqOlUBY3sj1evnAwvAxJinS1KVJZSs7L._AIAqmseiNaGSOQJQ3luOQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48EE2F0F.9030107@connotech.com> Date: Thu, 09 Oct 2008 11:19:27 -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 CC: agl@imperialviolet.org, namedroppers@ops.ietf.org Subject: Re: [dnsext] Rabin-Williams signatures for DNSSEC References: <396556a20810071331n42b933dfn6836e79a7c658e80@mail.gmail.com> <20081009153253.4058F6BB2C5@kilo.rtfm.com> In-Reply-To: <20081009153253.4058F6BB2C5@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 Tue, 7 Oct 2008 13:31:19 -0700, > Adam Langley wrote: > >>This document describes how to use Rabin-Williams public keys and >>signatures in DNSSEC. > > 3. I did a little looking and it doesn't seem to me that > anyone has standardized R-W. At least ISO/9796:1991 did. I would be surprised IEEE P1363 does not include some R-W variant. Granted that no *protocol* standard can be readily identified where R-W is an option. (How we got to this point is besides the point.) Regards, -- - Thierry Moreau -- to unsubscribe send a message to namedroppers-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 Oct 9 09:27: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 C29153A6A3F; Thu, 9 Oct 2008 09:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.224 X-Spam-Level: X-Spam-Status: No, score=-0.224 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 T85Dh2YRbBYi; Thu, 9 Oct 2008 09:27:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E3B8B3A68FF; Thu, 9 Oct 2008 09:27:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnyG0-0004Yv-1q for namedroppers-data@psg.com; Thu, 09 Oct 2008 16:20:56 +0000 Received: from [209.85.200.175] (helo=wf-out-1314.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnyFi-0004Wh-L1 for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 16:20:45 +0000 Received: by wf-out-1314.google.com with SMTP id 26so162784wfd.32 for ; Thu, 09 Oct 2008 09:20:38 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=MQkq568osdWKUtaI8TfaiHDAmycMImSzp2MZmrmH/L4=; b=o6EnOKglck5tsFHsTT9uFGRGyEsqtf6cRGUgpypewiS/MZCDNtH7cAunhjADXX9SIz u3RRV5xrCPO/wbY3UL4kDHl1wvtNKfa++xrhWCezr0kULDb3tigpsSwyI2bhDtjxJBuZ sHx056XawU3rcn3wkezvy76UBdAJ9+LrILfCg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=uPbwd3x6OBjFImQRoilLcv8rHOQxqLngEsgMim6vlmrgPee0D5WcWYdXJ4/1kxkmqi 7Aa34Y37ah0obeOmcUxU9Mq+cULV8DS//G0Ojf21lYBaZXcudlk+z3RxjAClYU2Qw0U/ fv6PH+TCIxpbuPx6c/+SXWuTLBiLIEb6SOka0= Received: by 10.141.29.18 with SMTP id g18mr254592rvj.162.1223569238016; Thu, 09 Oct 2008 09:20:38 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Thu, 9 Oct 2008 09:20:37 -0700 (PDT) Message-ID: <396556a20810090920q54b465fcg9ef744b675cac9a1@mail.gmail.com> Date: Thu, 9 Oct 2008 09:20:37 -0700 From: "Adam Langley" To: "Thierry Moreau" Subject: Re: [dnsext] Rabin-Williams signatures for DNSSEC Cc: namedroppers@ops.ietf.org In-Reply-To: <48EDDF95.8060008@connotech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <396556a20810071331n42b933dfn6836e79a7c658e80@mail.gmail.com> <48EDDF95.8060008@connotech.com> X-Google-Sender-Auth: f74a2348442cce89 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Oct 9, 2008 at 3:40 AM, Thierry Moreau wrote: > If I may rephrase your proposal, you are basically making three points: > Item (3) is challenging. You need not only to revise your draft (which is > fine as a revision-00 as it makes the point for readers with previous > knowledge of R-W mathematics) to speak to implementors in a language that > they understand. You probably need to show an implementation as an openssl > and/or gnutls source code contribution. And above all, you need to overcome > power-of-the-installed-base resistance and inertia in the IETF processes. Well, I'm only here to help, I'm not starting a RW crusade within the IETF ;) The referenced document[1] is actually an example of literate programming and contains a functional implementation of the scheme. Although it does use GMP rather than OpenSSL due to GMP's superb square root algorithm. The source code is at [2]. The source should also be considered a -00, although several people, including Dan Bleichenbacher, were kind enough to review it. [1] http://github.com/agl/rwb0fuz1024/tree/master%2Frwb0fuz1024.pdf?raw=true [2] http://github.com/agl/rwb0fuz1024 AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.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 Thu Oct 9 09:40: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 6857F3A6AC0; Thu, 9 Oct 2008 09:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.136 X-Spam-Level: X-Spam-Status: No, score=-0.136 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 CNnrGnKa-pon; Thu, 9 Oct 2008 09:39:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9F0903A6B0E; Thu, 9 Oct 2008 09:39:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnyUR-0006ju-3w for namedroppers-data@psg.com; Thu, 09 Oct 2008 16:35:51 +0000 Received: from [209.85.200.170] (helo=wf-out-1314.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnyUB-0006hu-6P for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 16:35:42 +0000 Received: by wf-out-1314.google.com with SMTP id 26so173515wfd.32 for ; Thu, 09 Oct 2008 09:35:34 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=AmxF1NvvnUkaDPf66a6g4//yycWy817AKdIoshEUyzY=; b=NSKn9XXngjZAPEdo25EIFY3wne8yV23PMht3o2oheni0V60bqlya4jkkXCjb+lBXst pU8jf2qWlivdNtntxcuKvNUQp3sq492WX3Ls7X21pah4K76KIMjP+IdcB/gZBwoILunW 0nOJk9i0KZfGSH1pb+Q22QCo8vjYclrOlQKSw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=H2jx64X6c4fSRC4/uVAw2mmNbVWV9vqkqQ8jI1PnZUOUXWlqfCk9N6kC1yywE+Qj1T UL4brKQEHHIwqiYRZqBOtyvHal9X3Blmb03uQpM7lNaSWXIFu5xex5XQ5Uz4oYhNKxZ+ HVjtYgcbEb0fCWJvtMcHu34E5r/RdTGlaJ40k= Received: by 10.141.79.19 with SMTP id g19mr279535rvl.67.1223570134023; Thu, 09 Oct 2008 09:35:34 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Thu, 9 Oct 2008 09:35:33 -0700 (PDT) Message-ID: <396556a20810090935j768573f8ge96aebb92d8f5055@mail.gmail.com> Date: Thu, 9 Oct 2008 09:35:33 -0700 From: "Adam Langley" To: "Eric Rescorla" Subject: Re: [dnsext] Rabin-Williams signatures for DNSSEC Cc: namedroppers@ops.ietf.org In-Reply-To: <20081009153253.4058F6BB2C5@kilo.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <396556a20810071331n42b933dfn6836e79a7c658e80@mail.gmail.com> <20081009153253.4058F6BB2C5@kilo.rtfm.com> X-Google-Sender-Auth: ae3ce9c1b0de9a5d Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Oct 9, 2008 at 8:32 AM, Eric Rescorla wrote: > 1. The performance comparison you're making here isn't really > that useful because 192-bit ECDSA is much more comparable > to 1776-bit RSA (see http://www.keylength.com/en/3/), which > is rather slower (I'm guessing 3-4x) than 1024-bit RSA. > 128-bit ECDSA would be a more accurate comparison. Thanks for the pointer, it seems that ECRYPT put 1024-bit multiplicative at about 144-bit EC. However, NIST don't define a curve over a prime field < 192-bits. They do have a binary curve of 163 bits, but, with OpenSSL, it's no quicker[2] and NIST suggests[1] that it's the same strength as the 192-bit prime curve. However, a curve with a 128 or 144-bit prime field should be quicker, if one were defined. [1] http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf , table on page 2. [2] ECRYPT benchmarks: http://bench.cr.yp.to > 2. There's a tradeoff between signature size and performance. > BLS allows you to get signatures down to 160 bits (at the > 80-bit security level comparable to ECC-160) but at the > cost of a much slower verification. It incidentally also > allows aggregating multiple signatures into one. So, > we should be clear on what it is we value the most. Perfectly true, I did this only because Vixie suggested that it might be useful. It's a tool that DNSSEC could make use of. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.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 Thu Oct 9 09:59: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 9D8AB3A69B9; Thu, 9 Oct 2008 09:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[AWL=-0.601, 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 k1aQYgNak-Ib; Thu, 9 Oct 2008 09:59:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AEE3228C15A; Thu, 9 Oct 2008 09:59:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnymD-0009AA-G0 for namedroppers-data@psg.com; Thu, 09 Oct 2008 16:54: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 1Knyly-00096n-6L for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 16:54:06 +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 m99GqsCc063601; Thu, 9 Oct 2008 12:52:55 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200810091652.m99GqsCc063601@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 09 Oct 2008 12:52:50 -0400 To: Nicholas Weaver , ietf@ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: Re: [dnsext] Last Call: draft-ietf-dnsext-forgery-resilience (Measures for making DNS more resilient against forged answers) to Proposed Standard Cc: namedroppers@ops.ietf.org, Nicholas Weaver In-Reply-To: <9D4D9C40-3503-4C85-9236-BE75F4139019@icsi.berkeley.edu> References: <20081002221539.DDFBB3A690B@core3.amsl.com> <9D4D9C40-3503-4C85-9236-BE75F4139019@icsi.berkeley.edu> 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: Speaking as Document Shepherd: Process history: DNSEXT WG determined that the scope of this document was to "make it harder to have spoofed answer packet accepted as legitimate answer", thus the word "resiliency" in the draft name, thus the focus of the document is 'packet acceptance'. The topic of 'data acceptance' was judged to be outside the scope of the document. At 19:17 02/10/2008, Nicholas Weaver wrote: >I believe this draft is insufficient: > >4.1: Frankly speaking, with all the mechanisms out there, you must >assume that an attacker can force queries of the attacker's choosing >at times of the attacker's choosing, within a fraction of a second in >almost all cases. This is not by directly generating a request to the >server, but by performing some application operation (eg, mail request >where the SMTP resolver checks it, a Javascript loaded in a victim's >browser, etc. Preventing external recursive queries is about as an >effective defense as a chalk line on the ground saying "do not cross". While this is true in general, there are number of situations where not allowing "out-side" queries helps. For example: - Sites that run separate DNS recursive resolvers/caches for mail servers than are used by user population in general. - Sites that are able to keep malware off internal hosts limit the ability of attackers to issue queries from the inside. >More importantly, Time to Live ONLY applies if the cache policy is >such that there are no Race until win attacks. In order to eliminate >race-until-win cases on a particular name, different cache behavior is >necessary over how currently it is specified in RFC2181. See >http://www.ietf.org/internet-drafts/draft-weaver-dnsext-comprehensive-resolver-00.txt >section 10 for details on one such cache policy which can prevent >all race-until-win attacks. See >http://tools.ietf.org/id/draft-wijngaards-dnsext-resolver-side-mitigation-00.txt >section 3.3/3.4 for an approximation of such a policy. This is outside the scope of the current document, but the WG is starting work on the 'data acceptance' topic. >Section 4 also excludes two significant additional entropy sources >which can't always be used but can often be used: 0x20 matching and >duplication, since ~32b entropy is only marginally sufficient, but >40b + (achievable through 0x20 and/or duplication) is for protecting the >cache. > After some discussion in the WG this was explicitly ruled outside the scope of the document. For the record most of the attacks I'm seeing are trying to spoof the root and TLD's using "mostly numeric" domain names, in these cases x20 provides limited defense. >Likewise, section 7-8 explicitly ignore the effects of "race until >win". As long as a resolver will accept any additional data from a >result into the cache, even when in scope (section 6's recommendations >enable race-until-win attacks), TTL becomes 0 regardless of the actual >TTL of the record. This is the real power of the Kaminski attack: it >is not a reduction in packet-work for the attacker, but a reduction in >time. This is also in the 'data admission' category not the 'packet acceptance' but it supports one of my favorite saying: "Optimization is the root cause of most problems". In this case people were hoping to decrease the number of queries by learning by a side effect. >Thus, the paragraph in section 10 is also incorrect: Long TTLs from >the authority provide no protection unless the recursive resolver >implements the conservative acceptance policy. Long TTLs should not >be encouraged as a security measure, because unless resolver cache >acceptance is changed, they are not a security measure, but could >instead cause more failures/difficulties. This is correct and an important observation. The document should be updated to reflect this. >And without changing cache acceptance, you must assume that TTL = W in >sections 7-8. also correct, Good observation Thank you for the review. Olafur >On Oct 2, 2008, at 3:15 PM, The IESG wrote: > >>The IESG has received a request from the DNS Extensions WG (dnsext) to >>consider the following document: >> >>- 'Measures for making DNS more resilient against forged answers ' >> as a Proposed Standard >> >>The IESG plans to make a decision in the next few weeks, and solicits >>final comments on this action. Please send substantive comments to >>the >>ietf@ietf.org mailing lists by 2008-10-16. Exceptionally, >>comments may be sent to iesg@ietf.org instead. In either case, please >>retain the beginning of the Subject line to allow automated sorting. >> >>The file can be obtained via >>http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-07.txt >> >> >>IESG discussion can be tracked via >>https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15593&rfc_flag=0 -- to unsubscribe send a message to namedroppers-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 Oct 9 10:58: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 A38943A689D; Thu, 9 Oct 2008 10:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.926 X-Spam-Level: X-Spam-Status: No, score=-4.926 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 FXpXlyL2Dc63; Thu, 9 Oct 2008 10:58:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6EB443A66B4; Thu, 9 Oct 2008 10:58:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnzeU-000GMy-SN for namedroppers-data@psg.com; Thu, 09 Oct 2008 17:50:18 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnzeH-000GKz-D7 for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 17:50:12 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m99Hm1H7027648; Thu, 9 Oct 2008 10:48:25 -0700 (PDT) Cc: Nicholas Weaver , ietf@ietf.org, namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT_chair?= In-Reply-To: <200810091652.m99GqsCc063601@stora.ogud.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [dnsext] Last Call: draft-ietf-dnsext-forgery-resilience (Measures for making DNS more resilient against forged answers) to Proposed Standard Date: Thu, 9 Oct 2008 10:48:00 -0700 References: <20081002221539.DDFBB3A690B@core3.amsl.com> <9D4D9C40-3503-4C85-9236-BE75F4139019@icsi.berkeley.edu> <200810091652.m99GqsCc063601@stora.ogud.com> X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Oct 9, 2008, at 9:52 AM, =D3lafur Gu=F0mundsson /DNSEXT chair wrote: > At 19:17 02/10/2008, Nicholas Weaver wrote: >> I believe this draft is insufficient: >> >> 4.1: Frankly speaking, with all the mechanisms out there, you must >> assume that an attacker can force queries of the attacker's choosing >> at times of the attacker's choosing, within a fraction of a second in >> almost all cases. This is not by directly generating a request to =20= >> the >> server, but by performing some application operation (eg, mail =20 >> request >> where the SMTP resolver checks it, a Javascript loaded in a victim's >> browser, etc. Preventing external recursive queries is about as an >> effective defense as a chalk line on the ground saying "do not =20 >> cross". > > While this is true in general, there are number of situations where > not allowing "out-side" queries helps. > For example: > - Sites that run separate DNS recursive resolvers/caches > for mail servers than are used by user population in general. > - Sites that are able to keep malware off internal hosts limit the > ability of attackers to issue queries from the inside. Sites that don't allow their users to visit ANY external web sites... =20= An attacker who can get a user to visit a web site of the attacker's =20 choosing can cause the DNS resolvers to issue an arbitrary stream of =20 requests, EVEN without javascript, just iframes and redirections. When developing a defensive posture for a DNS resolver, you MUST (in =20 the strict standard sense, capitalization is deliberate!) assume the =20 attacker can generate an arbitrary request stream: there are simply =20 too many vectors which an attacker can do so to consider it plausible =20= to shut them down. Although it may be a good idea for other reasons to prevent external =20 use of your institution's recursive resolver, the net security gain is =20= negligible. >> Section 4 also excludes two significant additional entropy sources >> which can't always be used but can often be used: 0x20 matching and >> duplication, since ~32b entropy is only marginally sufficient, but =20= >> 40b + (achievable through 0x20 and/or duplication) is for =20 >> protecting the >> cache. >> > > After some discussion in the WG this was explicitly ruled outside the > scope of the document. > For the record most of the attacks I'm seeing are trying to spoof the > root and TLD's using "mostly numeric" domain names, in these cases > x20 provides limited defense. However, those attacks are only able to work because of the race-until-=20= win properties. The TTLs for these records are relatively long, thus without race =20 until win, the attack window is very narrow. Where 0x20 provides protection is on names with short/0 TTL, which =20 includes many rather important sites (googlemail.l.google.com, =20 login.yahoo.akadns.net) which also happen to have rather long names. More important I think is the lack of discussing the semantics of =20 duplication. Duplication is a really powerful tool for increasing =20 entropy if you believe 32b of entropy is insufficient and there isn't =20= enough additional entropy obtained by 0x20. Additionally, since you CAN detect that you are under a generic attack =20= if you have at least 32b of entropy (just count unsolicited =20 responses), you can respond with duplication to effectively double =20 your entropy to 64b during the period in which you are under attack. Thus if the document EXCLUDES 0x20 and duplication, it should =20 explicitly state something to the effect: There are additional =20 mechanisms which can be used to increase query entropy in most (but =20 not necessarily all) cases, such as 0x20 randomization [cite] and =20 packet duplication. They are deliberately excluded from this document =20= for reasons X,Y,Z. >> Likewise, section 7-8 explicitly ignore the effects of "race until >> win". As long as a resolver will accept any additional data from a >> result into the cache, even when in scope (section 6's =20 >> recommendations >> enable race-until-win attacks), TTL becomes 0 regardless of the =20 >> actual >> TTL of the record. This is the real power of the Kaminski attack: it >> is not a reduction in packet-work for the attacker, but a reduction =20= >> in >> time. > > This is also in the 'data admission' category not the 'packet =20 > acceptance' > but it supports one of my favorite saying: "Optimization is the root =20= > cause > of most problems". In this case people were hoping to decrease the > number of queries by learning by a side effect. Then there needs to be an explicit reference of the sort: These equations depend not only on the packet acceptance policy, but =20 also the data admission policy. Unless data admission policies are =20 changed to be significantly more restrictive than the current standard =20= specifies, race-until-win attacks are possible where an attacker can =20 keep attempting to poison a target name regardless of TTL. As long as =20= race-until-win attacks are possible, one MUST assume that TTL =3D W for =20= all defensive calculations. There is also an assumption that there is duplicate-outstanding-=20 request supression (no birthday attacks), which I don't believe is =20 explicitly stated. -- to unsubscribe send a message to namedroppers-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 Oct 9 11: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 428BE3A6AF6; Thu, 9 Oct 2008 11:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.17 X-Spam-Level: X-Spam-Status: No, score=0.17 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 VnY1k0dI4-tY; Thu, 9 Oct 2008 11:06:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C1BBE3A6969; Thu, 9 Oct 2008 11:06:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnzqB-000HiI-VA for namedroppers-data@psg.com; Thu, 09 Oct 2008 18:02:23 +0000 Received: from [209.85.198.230] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Knzq5-000HhX-QE for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 18:02:20 +0000 Received: by rv-out-0506.google.com with SMTP id b25so111489rvf.41 for ; Thu, 09 Oct 2008 11:02:17 -0700 (PDT) Received: by 10.141.29.21 with SMTP id g21mr349748rvj.225.1223575336886; Thu, 09 Oct 2008 11:02:16 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Thu, 9 Oct 2008 11:02:16 -0700 (PDT) Message-ID: Date: Thu, 9 Oct 2008 11:02:16 -0700 From: "Matthew Dempsky" To: "Paul Hoffman" Subject: [dnsext] Re: No spec for DNSCurve Cc: namedroppers@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48ED0AB5.6040903@ca.afilias.info> <20081009032024.AA5986BA63E@kilo.rtfm.com> <396556a20810082102t161559dcl1f347ee76a891aed@mail.gmail.com> <20081009042357.62E176BA9B9@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Oct 9, 2008 at 6:54 AM, Paul Hoffman wrote: > How do you know that? Because the current specification doesn't use a handshake. > DNSCurve is essentially unspecified. It's specified enough that Adam Langley and I have independently implemented server and client functionality that communicate using DNSCurve protected packets. > We really should wait for Dan (or someone) to write a stable document that says what DNSCurve really means before we make such bold statements. http://dnscurve.org/impl.html has an outline of DNSCurve for implementers, and the main ideas have not changed. The only changes that I've known of are changing the base32 encoding character set from [0-9a-v] to [0-9b-df-hj-np-z], expanding the nonce size, and adding the streamlined packet format. I can imagine a few more encoding changes along these lines, but I expect the rest of the spec to remain stable. -- to unsubscribe send a message to namedroppers-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 Oct 9 11: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 066C73A6AE3; Thu, 9 Oct 2008 11:18:03 -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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScY-CbWnrKPx; Thu, 9 Oct 2008 11:17:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EB3C43A6A3B; Thu, 9 Oct 2008 11:17:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Knzzo-000IuZ-5V for namedroppers-data@psg.com; Thu, 09 Oct 2008 18:12:20 +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 1Knzzg-000Itd-Id for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 18:12:16 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 114A3AC6CF; Thu, 9 Oct 2008 18:11:44 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Eric Rescorla cc: "Adam Langley" , namedroppers@ops.ietf.org In-Reply-To: Your message of "Thu, 09 Oct 2008 08:32:53 MST." <20081009153253.4058F6BB2C5@kilo.rtfm.com> References: <396556a20810071331n42b933dfn6836e79a7c658e80@mail.gmail.com> <20081009153253.4058F6BB2C5@kilo.rtfm.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Thu, 09 Oct 2008 18:11:44 +0000 Message-ID: <58627.1223575904@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 114A3AC6CF.7F26E X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: [dnsext] Rabin-Williams signatures for DNSSEC Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > First, let me observe that this all has a very strong whiff of premature > optimization. Given that there has been next to no deployment of DNSSEC, > I think the evidence that either signature size *or* signature > verification performance is going to be an issue is fairly weak. i remain very concerned about signature sizes due to packet size issues related to IP fragmentation in EDNS, and due to round trip delays and fragility in TCP/53. i think it's very worthwhile to pursue smaller signature sizes, and any counterargument of the form "but algorythm agility is an unsolved problem" should be dismissed with prejudice. -- to unsubscribe send a message to namedroppers-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 Oct 9 11:40: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 26D133A69B8; Thu, 9 Oct 2008 11:40:53 -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.400, 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 Mc0Dv7dU4OXd; Thu, 9 Oct 2008 11:40:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7AE483A68DC; Thu, 9 Oct 2008 11:40:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ko0Jv-000LSD-NW for namedroppers-data@psg.com; Thu, 09 Oct 2008 18:33:07 +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 1Ko0Jp-000LQK-2h for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 18:33:04 +0000 Received: from [10.20.30.152] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m99IWvMJ089003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Oct 2008 11:32:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <48ED0AB5.6040903@ca.afilias.info> <20081009032024.AA5986BA63E@kilo.rtfm.com> <396556a20810082102t161559dcl1f347ee76a891aed@mail.gmail.com> <20081009042357.62E176BA9B9@kilo.rtfm.com> Date: Thu, 9 Oct 2008 11:32:56 -0700 To: "Matthew Dempsky" From: Paul Hoffman Subject: [dnsext] Re: No spec for DNSCurve Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 11:02 AM -0700 10/9/08, Matthew Dempsky wrote: >http://dnscurve.org/impl.html has an outline of DNSCurve for >implementers, and the main ideas have not changed. That page is *significantly* different than it was a few weeks ago. It is much more complete, which is good, but it is obviously not stable. Your idea of "main ideas" may be different than other people's ideas. That's part of the protocol development process. It sounds like you are quite interested in this protocol. Could you take the time to instantiate some current version of the protocol into an Internet Draft? That would *really* help this discussion. --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 Oct 9 11:51: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 D40BD28C187; Thu, 9 Oct 2008 11:51: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 JpviAgofsvyW; Thu, 9 Oct 2008 11:51:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5B08F28C1C2; Thu, 9 Oct 2008 11:50:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ko0SP-000MWv-OA for namedroppers-data@psg.com; Thu, 09 Oct 2008 18:41:53 +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 1Ko0SK-000MWG-KG for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 18:41:50 +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 m99IjbeA026071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Oct 2008 11:45:40 -0700 Date: Thu, 9 Oct 2008 14:41:44 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: No spec for DNSCurve Message-ID: <20081009184143.GJ46922@commandprompt.com> References: <20081009032024.AA5986BA63E@kilo.rtfm.com> <396556a20810082102t161559dcl1f347ee76a891aed@mail.gmail.com> <20081009042357.62E176BA9B9@kilo.rtfm.com> 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]); Thu, 09 Oct 2008 11:45:41 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Oct 09, 2008 at 11:02:16AM -0700, Matthew Dempsky wrote: > > DNSCurve is essentially unspecified. > > It's specified enough that Adam Langley and I have independently > implemented server and client functionality that communicate using > DNSCurve protected packets. "Running code" does not a specification make. It would be quite valuable to the rest of us if you would summarize your and Adam Langley's understanding of DNSCurve in an Internet-Draft that the rest of us can read and try to understand. In the absence of such a document, as we've noted on this list before, there is nothing for the DNS Extensions Working Group to talk about. In the absence of a formal specification either as an I-D or in some other format, the discussion of DNSCurve on this list is a distraction. DNSCurve is interesting, but this is not a forum for discussing all things DNS. This is a list for an IETF working group, and therefore, we need to focus the discussion to things that can plausibly be entertained as WG work items, and to actual WG items. Therefore, I remind participants that Olafur and I have already asked for some formal draft about DNSCurve. We encourage the creation of such a draft, either as an I-D under the auspices of the IETF, or in some other forum. But until such a draft appears, we ask that participants consider carefully the value of further speculation about DNSCurve before posting any more remarks about it. Thanks, 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 Oct 9 11: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 EB4FC28C0EF; Thu, 9 Oct 2008 11:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[AWL=-0.054, 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 KYxLPvotYbt9; Thu, 9 Oct 2008 11:55:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ECA4E3A679F; Thu, 9 Oct 2008 11:55:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ko0YX-000NL4-O6 for namedroppers-data@psg.com; Thu, 09 Oct 2008 18:48:13 +0000 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 1Ko0YR-000NJi-R2 for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 18:48:10 +0000 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 859E550846; Thu, 9 Oct 2008 12:01:36 -0700 (PDT) Date: Thu, 09 Oct 2008 12:01:36 -0700 From: Eric Rescorla To: Paul Vixie Cc: Eric Rescorla , "Adam Langley" , namedroppers@ops.ietf.org Subject: Re: [dnsext] Rabin-Williams signatures for DNSSEC In-Reply-To: <58627.1223575904@nsa.vix.com> References: <396556a20810071331n42b933dfn6836e79a7c658e80@mail.gmail.com> <20081009153253.4058F6BB2C5@kilo.rtfm.com> <58627.1223575904@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: <20081009190136.859E550846@romeo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Thu, 09 Oct 2008 18:11:44 +0000, Paul Vixie wrote: > > > First, let me observe that this all has a very strong whiff of premature > > optimization. Given that there has been next to no deployment of DNSSEC, > > I think the evidence that either signature size *or* signature > > verification performance is going to be an issue is fairly weak. > > i remain very concerned about signature sizes due to packet size issues > related to IP fragmentation in EDNS, and due to round trip delays and > fragility in TCP/53. i think it's very worthwhile to pursue smaller > signature sizes, and any counterargument of the form "but algorythm > agility is an unsolved problem" should be dismissed with prejudice. How convenient that I didn't make any such argument, then. What I said was that this was premature optimization and that if one *was* really concerned about signature size that one could do quite a bit better than the R-W signature that Adam proposed, though at the expense of computational performance. Incidentally, the argument for an aggregatable signature scheme such as BLS becomes for stronger in cases where a packet will contain multiple RRSIGs. Again, I'm not necessarily arguing against introducing another signature scheme. What I am arguing is that we should really understand the performance parameters and what we're trying to optimize for before we select a scheme based on "performance", since there are a series of tradeoffs which must be made. -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 Thu Oct 9 12:17: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 047E528C187; Thu, 9 Oct 2008 12:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.589 X-Spam-Level: X-Spam-Status: No, score=-0.589 tagged_above=-999 required=5 tests=[AWL=-0.094, 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 LVHdo5aYlqvm; Thu, 9 Oct 2008 12:17:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1D14828C190; Thu, 9 Oct 2008 12:17:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ko0rT-00005g-Jx for namedroppers-data@psg.com; Thu, 09 Oct 2008 19:07: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 1Ko0rK-000045-CD for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 19:07:44 +0000 Received: from [10.31.201.38] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m99J7VlQ064926; Thu, 9 Oct 2008 15:07:31 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <48ED0AB5.6040903@ca.afilias.info> <20081009032024.AA5986BA63E@kilo.rtfm.com> <396556a20810082102t161559dcl1f347ee76a891aed@mail.gmail.com> <20081009042357.62E176BA9B9@kilo.rtfm.com> Date: Thu, 9 Oct 2008 15:07:02 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Why an ID? was [dnsext] Re: No spec for DNSCurve Cc: ed.lewis@neustar.biz 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: At 11:32 -0700 10/9/08, Paul Hoffman wrote: >It sounds like you are quite interested in this protocol. Could you take >the time to instantiate some current version of the protocol into an >Internet Draft? That would *really* help this discussion. Why does it have to be an Internet Draft? The author of the mechanism hasn't asked for IETF review nor RFC Editor for publication. If the DNSEXT WG wants to discuss someone else's work, the onus is on the group, not the other person. (Yes, I am just causing trouble here. But historically we have recognized a non-IETF document in the definition of the protocol, so there's precedent. See the ATMA resource record definition.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Thu Oct 9 12:53: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 8A58F3A6843; Thu, 9 Oct 2008 12:53:16 -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 BwCKpNRwBkGm; Thu, 9 Oct 2008 12:53:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8913B3A686A; Thu, 9 Oct 2008 12:53:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ko1UL-0005aV-AL for namedroppers-data@psg.com; Thu, 09 Oct 2008 19:47:57 +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 1Ko1UF-0005Zf-B3 for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 19:47:54 +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 m99JpexU030989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Oct 2008 12:51:43 -0700 Date: Thu, 9 Oct 2008 15:47:46 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: Why an ID? was [dnsext] Re: No spec for DNSCurve Message-ID: <20081009194746.GK46922@commandprompt.com> References: <20081009032024.AA5986BA63E@kilo.rtfm.com> <396556a20810082102t161559dcl1f347ee76a891aed@mail.gmail.com> <20081009042357.62E176BA9B9@kilo.rtfm.com> 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]); Thu, 09 Oct 2008 12:51:43 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Oct 09, 2008 at 03:07:02PM -0400, Edward Lewis wrote: > Why does it have to be an Internet Draft? The author of the mechanism > hasn't asked for IETF review nor RFC Editor for publication. If the DNSEXT > WG wants to discuss someone else's work, the onus is on the group, not the > other person. I agree. And if we want to discuss it _here_, in this working group, we need to do that in keeping with the practices of the IETF. The way documents are processed in the IETF is with I-Ds. We can of course recognise non-IETF documents in the definitions of the protocol. If a specification for DNSCurve stabilizes outside the DNS Extensions working group, that's fine: we can deal with it then. But if we want to discuss how the protocol is going to be defined, and work out its details, we either need to let that happen outside this working group (which means on some other list, please) or else do the development inside the IETF according to IETF conventions. The IETF has enough problems with procedure without this working group inventing new, ad hoc mechanisms for protocol document review. 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 Oct 9 13:21: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 5EC543A6A48; Thu, 9 Oct 2008 13:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.584 X-Spam-Level: X-Spam-Status: No, score=-0.584 tagged_above=-999 required=5 tests=[AWL=-0.089, 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 wv89Jl6KlLL6; Thu, 9 Oct 2008 13:21:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D61F3A69C1; Thu, 9 Oct 2008 13:21:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ko1yP-0008dT-SF for namedroppers-data@psg.com; Thu, 09 Oct 2008 20:19: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 1Ko1yK-0008d2-Dt for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 20:18:59 +0000 Received: from [10.31.201.38] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m99KIq5b065672; Thu, 9 Oct 2008 16:18:52 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20081009194746.GK46922@commandprompt.com> References: <20081009032024.AA5986BA63E@kilo.rtfm.com> <396556a20810082102t161559dcl1f347ee76a891aed@mail.gmail.com> <20081009042357.62E176BA9B9@kilo.rtfm.com> <20081009194746.GK46922@commandprompt.com> Date: Thu, 9 Oct 2008 16:12:42 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Why an ID? was [dnsext] Re: No spec for DNSCurve Cc: ed.lewis@neustar.biz 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: At 15:47 -0400 10/9/08, Andrew Sullivan wrote: >But if we want to discuss how the protocol is going to be defined, and >work out its details, we either need to let that happen outside this >working group (which means on some other list, please) or else do the >development inside the IETF according to IETF conventions. The IETF >has enough problems with procedure without this working group >inventing new, ad hoc mechanisms for protocol document review. The crux of the matter is, to chop up your words, "if we want to ... work out its details." I don't think that is a decision that is up to us. We may want to work out its details but it isn't ours to play with. I think that we can consider the work when trying to decide our own agenda. In that context, discussing it here is germane even without it existing in an IETF approved format. It is not up to us to demand that it be brought here. We aren't reviewing the work. No one has asked the IETF for a review. But that doesn't mean we can't discuss it. I don't want to get into a fuss over us trying to "copy" the work into the group. Whether or not there are intellectual property concerns (but as I am not a lawyer, eeeek, I'm not going to guess). For those that haven't been around this group for a long time, the author of this work, Dan Bernstein, has had a strained relationship with the IETF. Rightly or wrongly, it doesn't matter. Given history I suspect it is unlikely that he would submit his work for IETF review. That doesn't mean we should therefore ignore it. We can form group opinions of the work, but we have no change control over it - it is not our work. (And, yes, I am still just causing trouble here.) My point is that we have something to talk over now. The web page description has the details needed. Its not an ID, but, then again, how well written is RFC 1034/1035? ;) There's no change control there? So what, we aren't approving or rubber stamping anything, we are just examining the engineering in it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Thu Oct 9 13:24: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 120AB3A6ACE; Thu, 9 Oct 2008 13:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.545 X-Spam-Level: X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 KrPkcsu5E+RC; Thu, 9 Oct 2008 13:24:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3B7E13A6A66; Thu, 9 Oct 2008 13:24:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ko1ya-0008eP-Oz for namedroppers-data@psg.com; Thu, 09 Oct 2008 20:19:12 +0000 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 1Ko1yS-0008dd-Nh for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 20:19:09 +0000 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 893E450846; Thu, 9 Oct 2008 13:32:33 -0700 (PDT) Date: Thu, 09 Oct 2008 13:32:33 -0700 From: Eric Rescorla To: "Adam Langley" Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Rabin-Williams signatures for DNSSEC In-Reply-To: <20081009153253.4058F6BB2C5@kilo.rtfm.com> References: <396556a20810071331n42b933dfn6836e79a7c658e80@mail.gmail.com> <20081009153253.4058F6BB2C5@kilo.rtfm.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: <20081009203233.893E450846@romeo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Thu, 09 Oct 2008 08:32:53 -0700, Eric Rescorla wrote: > 2. There's a tradeoff between signature size and performance. > BLS allows you to get signatures down to 160 bits (at the I may have mentioned this already, but I believe BLS is patented, though I can't seem to find the patent right now. If people start taking BLS seriously and I can find the patent, I'll file a disclosure. -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 Thu Oct 9 13:26: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 0923828C0EF; Thu, 9 Oct 2008 13:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.067 X-Spam-Level: X-Spam-Status: No, score=-5.067 tagged_above=-999 required=5 tests=[AWL=-0.019, 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 zFHD+KWZz4As; Thu, 9 Oct 2008 13:26:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 08AA63A6A66; Thu, 9 Oct 2008 13:26:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ko1vc-0008MN-PU for namedroppers-data@psg.com; Thu, 09 Oct 2008 20:16:08 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ko1vW-0008Lt-CU for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 20:16:05 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m99KEopl016130; Thu, 9 Oct 2008 13:14:55 -0700 (PDT) Cc: Nicholas Weaver , Wouter Wijngaards , Brian Dickson , , , Andrew Sullivan , Message-Id: From: Nicholas Weaver To: Dean Anderson 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 v929.2) Subject: Re: [dnsext] Re: Protecting caches? Date: Thu, 9 Oct 2008 13:14:50 -0700 References: X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Oct 9, 2008, at 12:47 PM, Dean Anderson wrote: > On Thu, 9 Oct 2008, Wouter Wijngaards wrote: > >> >> The thing that Kaminsky added was the retry for a different >> (previously >> unseen) query name, which delivers the race-to-win and no wait for >> TTLs. >> The rest is indeed the same. The race-to-win made the problem very >> urgent. > > I don't think Kaminsky added this. This 'race-to-win' was only > remotely > relevant after NXDOMAIN was added in 1998, after the balliwick issue. > When the balliwick issue was being discussed, queries for non-existant > names were not cached. I don't recall anyone ever proposing TTL as a > solution to spoofing attacks, so I don't think it can be a big > surprise > that it wasn't a valid security assumption protecting one from > spoofing > attacks. How could it be surprising when no one ever said that? > > NXDOMAIN was a offered as a performance enhancement, not a security > fix. > (see the abstract of RFC2308). Indeed, RFC2308 security considerations > section actually describes spoofing attacks using NXDOMAIN. > > There is nothing 'urgent' in what Kaminsky describes, because there is > nothing new or novel in what Kaminsky describes. Not even the > 'race-to-win'. I don't believe NXDOMAIN behavior has anything to do with this. It is caching the ADDITIONAL records (usually the authoritative nameserver records) on what appears to be a VALID (albeit spoofed) reply. Without the ability to target a name for replacement that is not the name being queried (the Kaminski innovation: an ancillatory data attack), you are limited in time even with just 16b of entropy, and can't effectively attack things like the NS RRSet for .com, even with the dinky 16b of entropy. But with race until win, you can practically attack the NS RRSet for .com, in a short amount of time without source port randomization, and even in reasonable-effort on the local network WITH source port randomization. Race-until-win is a significant attack innovation. And I have yet to see anything that suggests that race-until-win attacks were known prior to Kaminski's work. -- to unsubscribe send a message to namedroppers-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 Oct 9 14:26: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 E67613A67FC; Thu, 9 Oct 2008 14:26:23 -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 UC7ll6luQPF7; Thu, 9 Oct 2008 14:26:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E7B933A6A5F; Thu, 9 Oct 2008 14:26:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ko2wd-000Fh5-8n for namedroppers-data@psg.com; Thu, 09 Oct 2008 21:21:15 +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 1Ko2wX-000FgS-G6 for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 21:21:12 +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 m99LOwGc005447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Oct 2008 14:25:00 -0700 Date: Thu, 9 Oct 2008 17:21:04 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: Why an ID? was [dnsext] Re: No spec for DNSCurve Message-ID: <20081009212104.GL46922@commandprompt.com> References: <396556a20810082102t161559dcl1f347ee76a891aed@mail.gmail.com> <20081009042357.62E176BA9B9@kilo.rtfm.com> <20081009194746.GK46922@commandprompt.com> 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]); Thu, 09 Oct 2008 14:25:01 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [No hat] On Thu, Oct 09, 2008 at 04:12:42PM -0400, Edward Lewis wrote: > We aren't reviewing the work. No one has asked the IETF for a review. But > that doesn't mean we can't discuss it. I don't see what there is to discuss _in this working group_. This is an IETF working group, and we have work to do. If someone wants to propose a work item that derives from any of this, then the way to do that in the IETF is to write an I-D and ask the WG for feedback. As you note, nobody has done that. Therefore, we haven't anything to discuss here, now. I know that DNSCurve is interesting, and I think that it probably does need to be discussed somewhere. But I think it is important that the WG focus on the tasks we do have before us, and not ones that we might like to have, think could be interesting, or whatever. 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: From owner-namedroppers@ops.ietf.org Thu Oct 9 17:13: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 8094A3A68C1; Thu, 9 Oct 2008 17:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.58 X-Spam-Level: X-Spam-Status: No, score=-0.58 tagged_above=-999 required=5 tests=[AWL=-0.085, 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 SwmMoHbGc-rm; Thu, 9 Oct 2008 17:13:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 579473A68AC; Thu, 9 Oct 2008 17:13:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ko5Wd-0005Rq-Ik for namedroppers-data@psg.com; Fri, 10 Oct 2008 00:06:35 +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 1Ko5WX-0005QU-Gq for namedroppers@ops.ietf.org; Fri, 10 Oct 2008 00:06:32 +0000 Received: from [192.168.1.101] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m9A06Mqi067200; Thu, 9 Oct 2008 20:06:23 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20081009212104.GL46922@commandprompt.com> References: <396556a20810082102t161559dcl1f347ee76a891aed@mail.gmail.com> <20081009042357.62E176BA9B9@kilo.rtfm.com> <20081009194746.GK46922@commandprompt.com> <20081009212104.GL46922@commandprompt.com> Date: Thu, 9 Oct 2008 20:06:19 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Why an ID? was [dnsext] Re: No spec for DNSCurve Cc: ed.lewis@neustar.biz 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: At 17:21 -0400 10/9/08, Andrew Sullivan wrote: >I don't see what there is to discuss _in this working group_. I guess the (and this is probably too far from real work to care about) question is - is the mailing list only open to WG agenda items. Namedroppers preceeded DNSEXT and probably will live on after the WG is closed. Maybe there isn't anymore to be said. But as someone interested in the development of the DNS protocol it is helpful to know about all of the tricks of the trade being employed in the off chance they might roll into the mainstream protocol. There are many ways in which DNS is operated that have shaped the protocol. There are significant elements of the de jure protocol that have never come into the IETF for (complete) review. (Split DNS for one.) There are folks that take for granted that "views" are an essential part of the protocol, not simply a feature started in one implementation (and possibly copied to others - I only assume). I'm cranky when I see "please don't talk about that here" talk because that is shutting out what made the IETF interesting, you know, the hundred flowers and all (yeah, 1000 flowers, but the origin[0] was 100). If you think a topic is boring, ignore it - I admit I ignore a lot of things on namedroppers (in the sense of "I've heard all that before - but not everyone else has - the curse of long term subscribing I guess"). It's interesting to see DNSCurve, especially a fairly detailed specification of it[1]. The author has been ahead of the curve (no pun intended) before. Not that I think that DNSCurve is going to save the day or stave off DNSSEC at this point but nevertheless it's something. And not that I always agree with the author's engineering. (E.g., truncating messages mid RR, not answering lame questions at all, tsk, tsk.) Still it's input to the process of engineering a better protocol. Maybe not this protocol but perhaps someday when DNS 2.0 is produced. Slap, finger snap, wake up --- sorry - I got into some of Bill's meds again. Demanding an IETF formatted document from people not participating in the IETF just because somefolks wanted to talk about it on a mailing list run by the IETF shows a lot of http://en.wikipedia.org/wiki/Chutzpa. I want to keep this group relevant to the protocol and how it is used, not see it creep off into an ivory tower of protocol purity. Gotta be "keeping it real." [0] http://en.wikipedia.org/wiki/Hundred_Flowers_Campaign [1] http://dnscurve.org/impl.html -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Fri Oct 10 03:10: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 742303A6ACD; Fri, 10 Oct 2008 03:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.557 X-Spam-Level: X-Spam-Status: No, score=-5.557 tagged_above=-999 required=5 tests=[AWL=-0.859, 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 PUQxQHXPGwzI; Fri, 10 Oct 2008 03:10:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 50FAF3A684C; Fri, 10 Oct 2008 03:10:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoEq7-0008pF-0w for namedroppers-data@psg.com; Fri, 10 Oct 2008 10:03:19 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoEq0-0008of-JN for namedroppers@ops.ietf.org; Fri, 10 Oct 2008 10:03:15 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 4B5191C012F for ; Fri, 10 Oct 2008 12:03:11 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 46D181C011F for ; Fri, 10 Oct 2008 12:03:11 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 450B1A1DA63 for ; Fri, 10 Oct 2008 12:03:11 +0200 (CEST) Date: Fri, 10 Oct 2008 12:03:11 +0200 From: Stephane Bortzmeyer To: namedroppers@ops.ietf.org Subject: Re: Why an ID? was [dnsext] Re: No spec for DNSCurve Message-ID: <20081010100311.GA24571@nic.fr> References: <20081009194746.GK46922@commandprompt.com> <20081009212104.GL46922@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux lenny/sid X-Kernel: Linux 2.6.26-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, Oct 09, 2008 at 08:06:19PM -0400, Edward Lewis wrote a message of 61 lines which said: > Demanding an IETF formatted document from people not participating > in the IETF just because somefolks wanted to talk about it on a > mailing list run by the IETF shows a lot of > http://en.wikipedia.org/wiki/Chutzpa. I want to keep this group > relevant to the protocol and how it is used, not see it creep off > into an ivory tower of protocol purity. Gotta be "keeping it real." I mostly agree with Ed Lewis here but, if the chairs insist we should not discuss a protocol which is not an IETF protocol, what are the other solutions? I am not aware of a mailing list dedicated to the evolutions of the DNS besides namedroppers. Should someone create a "dns-future@example.net"? -- to unsubscribe send a message to namedroppers-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 Oct 10 07:19: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 9987F3A6A6B; Fri, 10 Oct 2008 07:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 KaZRt+uBwNjY; Fri, 10 Oct 2008 07:19:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4C1F3A69AB; Fri, 10 Oct 2008 07:19:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoIiN-00092b-I7 for namedroppers-data@psg.com; Fri, 10 Oct 2008 14:11:35 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoIiB-00091D-6p for namedroppers@ops.ietf.org; Fri, 10 Oct 2008 14:11:28 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 9A0B9FC7C6; Fri, 10 Oct 2008 14:11:04 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Stephane Bortzmeyer cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 10 Oct 2008 12:03:11 +0200." <20081010100311.GA24571@nic.fr> References: <20081009194746.GK46922@commandprompt.com> <20081009212104.GL46922@commandprompt.com> <20081010100311.GA24571@nic.fr> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 10 Oct 2008 14:11:04 +0000 Message-ID: <27747.1223647864@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 9A0B9FC7C6.8712E X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: Why an ID? was [dnsext] Re: No spec for DNSCurve Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > I mostly agree with Ed Lewis here but, if the chairs insist we should > not discuss a protocol which is not an IETF protocol, what are the > other solutions? I am not aware of a mailing list dedicated to the > evolutions of the DNS besides namedroppers. Should someone create a > "dns-future@example.net"? is the future of dns not an ietf topic, then? -- to unsubscribe send a message to namedroppers-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 Oct 10 07:34: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 061FE3A6AD1; Fri, 10 Oct 2008 07:34:08 -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 k4AKknglCEZL; Fri, 10 Oct 2008 07:34:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2940C3A69FE; Fri, 10 Oct 2008 07:34:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoIya-000ApH-AO for namedroppers-data@psg.com; Fri, 10 Oct 2008 14:28: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 1KoIyR-000Ao6-Ho for namedroppers@ops.ietf.org; Fri, 10 Oct 2008 14:28:16 +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 m9AEW0dN015323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Oct 2008 07:32:03 -0700 Date: Fri, 10 Oct 2008 10:28:06 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: Why an ID? was [dnsext] Re: No spec for DNSCurve Message-ID: <20081010142806.GL49140@commandprompt.com> References: <20081009194746.GK46922@commandprompt.com> <20081009212104.GL46922@commandprompt.com> 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, 10 Oct 2008 07:32:04 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [no hat] On Thu, Oct 09, 2008 at 08:06:19PM -0400, Edward Lewis wrote: > I guess the (and this is probably too far from real work to care about) > question is - is the mailing list only open to WG agenda items. In my personal view, no, it's not only open to WG agenda items. But we had a fair amount of discussion; and as Paul already pointed out, the web page does not seem to be a stable specification (it's changing, or at least has changed considerably and doesn't have any commitment of stability. So, from my point of view, we don't have something stable to discuss. That's all I've been trying to say. But I feel strongly that a bottomless rathole about administration of the group is even less interesting to participants than speculation about a fluid proposal for new DNS functionality, so I'm going to stop talking about what's appropriate on the list and leave that decision to the good judgement of the participants (as I suggested in my moderation note). I'd personally prefer a stable thing to discuss, rather than a sketchy outline on a web page, but maybe that just reflects my personal working style. 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 Oct 10 07: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 253053A6A50; Fri, 10 Oct 2008 07:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.066 X-Spam-Level: X-Spam-Status: No, score=-5.066 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 UkmwUrLDYgYo; Fri, 10 Oct 2008 07:58:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4A8473A69FF; Fri, 10 Oct 2008 07:58:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoJMR-000DOJ-OG for namedroppers-data@psg.com; Fri, 10 Oct 2008 14:52:59 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoJME-000DMT-3q for namedroppers@ops.ietf.org; Fri, 10 Oct 2008 14:52:51 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9AEq2ZV017639; Fri, 10 Oct 2008 07:52:26 -0700 (PDT) Cc: Nicholas Weaver , Stephane Bortzmeyer , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Paul Vixie In-Reply-To: <27747.1223647864@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 v929.2) Subject: Re: Why an ID? was [dnsext] Re: No spec for DNSCurve Date: Fri, 10 Oct 2008 07:52:01 -0700 References: <20081009194746.GK46922@commandprompt.com> <20081009212104.GL46922@commandprompt.com> <20081010100311.GA24571@nic.fr> <27747.1223647864@nsa.vix.com> X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Oct 10, 2008, at 7:11 AM, Paul Vixie wrote: >> I mostly agree with Ed Lewis here but, if the chairs insist we should >> not discuss a protocol which is not an IETF protocol, what are the >> other solutions? I am not aware of a mailing list dedicated to the >> evolutions of the DNS besides namedroppers. Should someone create a >> "dns-future@example.net"? > > is the future of dns not an ietf topic, then? I think a better argument/question is "What NEW is there to say about DNSCurve that hasn't already been posted to the list?" I dare say DNSCurve was already done-to-death in previous threads, as understanding the systemic advantages and disadvantages didn't need much of a specification anyway. Also, really, DNSCurve has nothing to do really with DNS except it uses DNS as a key distribution mechanism. Its really a datagram-based transport-layer security in the same category as DTLS, but with a single RTT handshake and using a particular elliptic curve. -- to unsubscribe send a message to namedroppers-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 Oct 10 09:10: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 2A26E3A63D2; Fri, 10 Oct 2008 09:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 VrmVJ-RYNZjh; Fri, 10 Oct 2008 09:10:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E4A2A28C15F; Fri, 10 Oct 2008 09:10:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoKVl-000LBZ-Jn for namedroppers-data@psg.com; Fri, 10 Oct 2008 16:06:41 +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 1KoKVc-000L9P-8q for namedroppers@ops.ietf.org; Fri, 10 Oct 2008 16:06:38 +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 m9AG6TKN098759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Oct 2008 09:06:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20081009194746.GK46922@commandprompt.com> <20081009212104.GL46922@commandprompt.com> <20081010100311.GA24571@nic.fr> <27747.1223647864@nsa.vix.com> Date: Fri, 10 Oct 2008 09:06:11 -0700 To: namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: Why an ID? was [dnsext] Re: No spec for DNSCurve Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 7:52 AM -0700 10/10/08, Nicholas Weaver wrote: >I dare say DNSCurve was already done-to-death in previous threads, as understanding the systemic advantages and disadvantages didn't need much of a specification anyway. We fully disagree here. Looking at the diffs in just the last month on the web site, and talking with Dan off-list, I see low-level ideas that were far from clear in earlier versions of the web site. >Also, really, DNSCurve has nothing to do really with DNS except it uses DNS as a key distribution mechanism. Its really a datagram-based transport-layer security in the same category as DTLS, but with a single RTT handshake and using a particular elliptic curve. DTLS for long-term key distribution is different than DTLS for protecting a single query-and-response. DTLS with a PKIX hierarchy is different than DTLS with an alternate trust model. And so on. I think it is unwise to say "we can predict what will be said in the first draft of the protocol", much less what might come out of a group with diverse interests working on that 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 Fri Oct 10 09:12: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 20B1B28C189; Fri, 10 Oct 2008 09:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 0rw8NWe2N6qZ; Fri, 10 Oct 2008 09:12:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 313EF3A687E; Fri, 10 Oct 2008 09:12:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoKVi-000LAW-PX for namedroppers-data@psg.com; Fri, 10 Oct 2008 16:06: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 1KoKVd-000L9b-31 for namedroppers@ops.ietf.org; Fri, 10 Oct 2008 16:06:35 +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 m9AG6TKL098759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Oct 2008 09:06:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <48ED0AB5.6040903@ca.afilias.info> <20081009032024.AA5986BA63E@kilo.rtfm.com> <396556a20810082102t161559dcl1f347ee76a891aed@mail.gmail.com> <20081009042357.62E176BA9B9@kilo.rtfm.com> Date: Fri, 10 Oct 2008 08:58:55 -0700 To: Edward Lewis , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: Why an ID? was [dnsext] Re: No spec for DNSCurve Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 3:07 PM -0400 10/9/08, Edward Lewis wrote: >At 11:32 -0700 10/9/08, Paul Hoffman wrote: > >>It sounds like you are quite interested in this protocol. Could you take >>the time to instantiate some current version of the protocol into an >>Internet Draft? That would *really* help this discussion. > >Why does it have to be an Internet Draft? It doesn't; I proposed that as the simplest method for the group to have a stable document to look at. If the authors want to do something more difficult to get a stable document for us to look at, that's probably fine too. >The author of the mechanism hasn't asked for IETF review nor RFC Editor for publication. But others have. Note that I did not say Dan Bernstein had to write the draft; I proposed it to others who wanted to discuss the protocol in the IETF. >If the DNSEXT WG wants to discuss someone else's work, the onus is on the group, not the other person. How can we tell if we want to discuss some work if we don't know what the work is? As I said in my earlier message, Dan has changed (improved, in my opinion) DNScurve since it was introduced. --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 Fri Oct 10 09:45: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 C63F93A68D4; Fri, 10 Oct 2008 09:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[AWL=0.080, 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 dazBTuWb0FFd; Fri, 10 Oct 2008 09:45:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9A8673A676A; Fri, 10 Oct 2008 09:45:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoL3x-000PhP-GV for namedroppers-data@psg.com; Fri, 10 Oct 2008 16:42: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 1KoL3r-000PgI-KL for namedroppers@ops.ietf.org; Fri, 10 Oct 2008 16:41:58 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m9AGfsQ0074888 for ; Fri, 10 Oct 2008 12:41:54 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m9AGfsXa074887 for namedroppers@ops.ietf.org; Fri, 10 Oct 2008 12:41:54 -0400 (EDT) (envelope-from namedroppers) Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoKoM-000Nv9-B8 for namedroppers@ops.ietf.org; Fri, 10 Oct 2008 16:25:56 +0000 Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id m9AGPV3c012317 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 10 Oct 2008 12:25:31 -0400 Date: Fri, 10 Oct 2008 12:25:30 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Nicholas Weaver cc: Wouter Wijngaards , Brian Dickson , , , Andrew Sullivan , Subject: Re: [dnsext] Re: Protecting caches? In-Reply-To: Message-ID: 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: [ Note: Post was moderated. ] On Thu, 9 Oct 2008, Nicholas Weaver wrote: > I don't believe NXDOMAIN behavior has anything to do with this. It is > caching the ADDITIONAL records (usually the authoritative nameserver > records) on what appears to be a VALID (albeit spoofed) reply. No, you're not following the attack. Additional NS records are spoofed, resulting in all further queries going to another Nameserver. (Before balliwick, this used to be very common; balliwick was invented to make that harder. But as was pointed out back then, still not impossible. NXDOMAIN has historical relevance to the 'TTL race-to-win' argument. The race-to-win argument in proper historical context, is complete BS. You need to re-read my message. > Race-until-win is a significant attack innovation. And I have yet to > see anything that suggests that race-until-win attacks were known > prior to Kaminski's work. There is nothing novel in the race-to-win argument. Every spoofing attack was always assumed to take place before the correct response arrived, and before NXDOMAIN, there was no correct response. Even the NXDOMAIN draft discusses NXDOMAIN being spoofed. If one looks at the spoofing descriptions, you see brute force described as "One only needs to send 65k packets before the correct packet arrives". TTL has nothing to do with anything related to spoofing. Kaminsky's only 'invention' was the notion that somehow, before Kaminsky, people thought that TTL was a defense against spoofing. But that notion was BS to begin with; no one ever thought that. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-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 Oct 10 09:45: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 28E653A68AA; Fri, 10 Oct 2008 09:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.428 X-Spam-Level: X-Spam-Status: No, score=-0.428 tagged_above=-999 required=5 tests=[AWL=0.067, 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 HbsafVS2qVKK; Fri, 10 Oct 2008 09:45:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A223B3A68D4; Fri, 10 Oct 2008 09:45:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoL3J-000Pcc-5K for namedroppers-data@psg.com; Fri, 10 Oct 2008 16:41: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 1KoL37-000Pbg-Lz for namedroppers@ops.ietf.org; Fri, 10 Oct 2008 16:41:18 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m9AGf6bk074864 for ; Fri, 10 Oct 2008 12:41: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 m9AGf6DC074863 for namedroppers@ops.ietf.org; Fri, 10 Oct 2008 12:41:06 -0400 (EDT) (envelope-from namedroppers) Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ko1V2-0005hE-Ju for namedroppers@ops.ietf.org; Thu, 09 Oct 2008 19:48:44 +0000 Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id m99JloqH008781 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 9 Oct 2008 15:47:53 -0400 Date: Thu, 9 Oct 2008 15:47:48 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Wouter Wijngaards cc: Brian Dickson , Nicholas Weaver , , , Andrew Sullivan , Subject: Re: [dnsext] Re: Protecting caches? In-Reply-To: <48EDD67F.60902@nlnetlabs.nl> Message-ID: 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: [ Note: Post was moderated. ] On Thu, 9 Oct 2008, Wouter Wijngaards wrote: > > The thing that Kaminsky added was the retry for a different (previously > unseen) query name, which delivers the race-to-win and no wait for TTLs. > The rest is indeed the same. The race-to-win made the problem very urgent. I don't think Kaminsky added this. This 'race-to-win' was only remotely relevant after NXDOMAIN was added in 1998, after the balliwick issue. When the balliwick issue was being discussed, queries for non-existant names were not cached. I don't recall anyone ever proposing TTL as a solution to spoofing attacks, so I don't think it can be a big surprise that it wasn't a valid security assumption protecting one from spoofing attacks. How could it be surprising when no one ever said that? NXDOMAIN was a offered as a performance enhancement, not a security fix. (see the abstract of RFC2308). Indeed, RFC2308 security considerations section actually describes spoofing attacks using NXDOMAIN. There is nothing 'urgent' in what Kaminsky describes, because there is nothing new or novel in what Kaminsky describes. Not even the 'race-to-win'. > > So, if you have 200 outstanding ports, with 200 outstanding QIDs, > > and any correct port can have a coincidence on the 200 QIDs, the > > cache is spoofed in just under under 5 tries, or in about 943 > > packets!!! Holy added-security flaws! > > Are you saying that using multiple ports at the same time creates > birthday attack problems? Yes. But that isn't the big issue. It requires about 28 million packets to be successful, and there are some things I have proposed to make this even harder (see posts on dns@list.cr.yp.to). But Kaminsky's idea makes it trivially easy. I haven't checked to see if these ideas were included in the 'urgent' patches. The way DJBDNS (DNScache) works now, a new random port is allocated for each recursive query, a random QID is selected, and the query is sent. Packets recieved on that port are checked by a function callled 'irrelevant()', which ensures that the QID and the query are the same. What was proposed was to reuse ports; that is one port may have multiple outstanding query ids. To implement that, one would have to keep track of all the valid outstanding query ids (probably over all ports), and check any incoming packet on a valid port to see if its query id matches one of the valid outstanding query ids. So one may also have a coincidence over the query ids. The combination of two coincidences drastically reduce the strength of using random port numbers and random QID, as the math shows. > Or do you assume in the above that this is the same query that is sent > out with multiple outstanding ports/multiple outstanding QIDs? If you reuse the port, presumably, it is for different queries; but the same query could be repeated by different clients. So all outstanding queries could be arranged to be the same textual query. Follow? > > DNS *with* DNSSEC is an additional way to attack the final application. > > > > DNSSEC caches can still be poisoned by setting the CD bit so that the > > cache does not verify the data, then spoofing by ordinary means with the > > appropriatly set DO and CD bits. The cache won't verify the data, and so > > will cache invalid data that it hands to the stub resolver for > > verification. The resolver that tries to verify the data will reject the > > invalid signature, but can't get past the cache with the bad data. > > Result: DOS. > > Unbound has a cache of 'bad' data. This is data that it considers > bogus. This data can be retrieved by setting the CD bit, that is the > purpose of the CD bit. This data is not returned to regular stub > resolvers (withholding the bad data). The stub resolver can then choose > via the CD bit to verify that data itself, with its own security policy. I don't think this is completely correct. If the site intends to offload verification on the stub resolver, then the stub has to set the CD bit. Such cache setups can be poisoned. I seem to recall (but haven't verified in the RFCs), that when unverified data is cached in the 'bad cache', and the stub doesn't set the CD bit, that the cache is supposed to return an error in that case. And of course, if the cache does verify, it is vulnerable to attacks in which many hard to verify records are requested at a high rate. And of course, I didn't mention before that in either case, cryptographically valid (but replaced) records can be used to poison the cache, too. Indeed, in some cases, (specially nsec with unverified delegations), spoofed delegations can be _created_ in secure zones using the replaced (but still crypto valid) NSEC records. The stub resolver will conclude these are valid records. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-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 Oct 10 10:03: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 A9DB13A63D2; Fri, 10 Oct 2008 10:03:19 -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 aVjpsrybdxoU; Fri, 10 Oct 2008 10:03:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B63593A6B16; Fri, 10 Oct 2008 10:03:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoLL0-0001cT-4d for namedroppers-data@psg.com; Fri, 10 Oct 2008 16:59:38 +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 1KoLKn-0001aw-Fn for namedroppers@ops.ietf.org; Fri, 10 Oct 2008 16:59:30 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 27FC5A1018 for ; Fri, 10 Oct 2008 16:59:16 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 10 Oct 2008 10:28:06 -0400." <20081010142806.GL49140@commandprompt.com> References: <20081009194746.GK46922@commandprompt.com> <20081009212104.GL46922@commandprompt.com> <20081010142806.GL49140@commandprompt.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 10 Oct 2008 16:59:16 +0000 Message-ID: <50025.1223657956@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 27FC5A1018.6370B X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: Why an ID? was [dnsext] Re: No spec for DNSCurve Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > I guess the (and this is probably too far from real work to care about) > > question is - is the mailing list only open to WG agenda items. > > In my personal view, no, it's not only open to WG agenda items. ... in my personal view, dnscurve competes with dnssec in that if either is deployed the other will be a curiousity. i don't mind seeing this mailing list used to discuss experimental topics, the greatest minds of dns are all here and it's a good way to reach them. what i want from ietf is not a shutdown of the dnscurve discussion but rather a clear statement that ietf is not reopening the debate as to whether dnssec is our chosen solution. i want this for the simple reason that we will otherwise never complete any task that takes more than a generation, since every new generation of dns protocol architects will want to throw out the mistakes of the past and just do what makes sense to them. saying "where's the I-D?" is just a way of backing into the question that's actually important which is: "is ietf willing to change its direction?" and it's important that we actually ask and answer that real question since we will otherwise confuse and terrify the people who have deployment decisions to make. so if ietf can periodically and strongly reiterate its position on dnssec's viability and desireability, then discussions of dnscurve or other new ideas will be nondisruptive and the participants of this mailing list can either read, reply, or killfile, as they see fit. the way a country puts a man on the moon is that one president says we ought to do it and the next president says ok even though i'd rather go to mars we will go to the moon since that's the multigenerational project we're in the middle of right now. -- to unsubscribe send a message to namedroppers-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 Oct 10 10:12: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 2305A3A6A64; Fri, 10 Oct 2008 10:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.065 X-Spam-Level: X-Spam-Status: No, score=-5.065 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 unQYnc6CvdPH; Fri, 10 Oct 2008 10:12:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CE3CB3A68D4; Fri, 10 Oct 2008 10:12:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoLTh-0002pY-4m for namedroppers-data@psg.com; Fri, 10 Oct 2008 17:08:37 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoLTY-0002ok-47 for namedroppers@ops.ietf.org; Fri, 10 Oct 2008 17:08:30 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9AH8Qlt006802; Fri, 10 Oct 2008 10:08:26 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Paul Hoffman 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 v929.2) Subject: Re: Why an ID? was [dnsext] Re: No spec for DNSCurve Date: Fri, 10 Oct 2008 10:08:26 -0700 References: <20081009194746.GK46922@commandprompt.com> <20081009212104.GL46922@commandprompt.com> <20081010100311.GA24571@nic.fr> <27747.1223647864@nsa.vix.com> X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Oct 10, 2008, at 9:06 AM, Paul Hoffman wrote: > At 7:52 AM -0700 10/10/08, Nicholas Weaver wrote: >> I dare say DNSCurve was already done-to-death in previous threads, >> as understanding the systemic advantages and disadvantages didn't >> need much of a specification anyway. > > We fully disagree here. Looking at the diffs in just the last month > on the web site, and talking with Dan off-list, I see low-level > ideas that were far from clear in earlier versions of the web site. The differences are ones in terms of implementation details. The high level structure and tradeoffs of channel confidentiality & integrity vs object integrity are the key distinction for purposes of "Does DNSCurve make sense as an alternative/addition to DNSSEC". And for purposes of securing DNS transactions against an adversary, channel integrity is STRICTLY less powerful than object integrity (look at the problems of corrupted recursive resolvers, which DNSSEC can address but DNSCurve can not), while channel confidentiality is almost nonexistant in the face of traffic analysis for DNS. Likewise, the transitivity of trust and trust heirarchy still remains completely unchanged from DNSSEC, the only difference there is rather than having the key explicitly signed by the +1 domain up, the key is implicitly "signed" by being returned by the +1 domain up as the nameserver's name. This simply means you have an implicit short-lived certificate who's expiration is equal to the TTL rather than an explicit longer-lived certificate. Nothing in the different drafts have changed these primary properties, and for "Is DNSCurve a viable alternative to DNSSEC", it is these properties, not details on the encoding of keys in names or the computational and network overhead of signatures, that is the problem, and these aspects have been discussed to death. >> Also, really, DNSCurve has nothing to do really with DNS except it >> uses DNS as a key distribution mechanism. Its really a datagram- >> based transport-layer security in the same category as DTLS, but >> with a single RTT handshake and using a particular elliptic curve. > > DTLS for long-term key distribution is different than DTLS for > protecting a single query-and-response. > > > DTLS with a PKIX hierarchy is different than DTLS with an alternate > trust model. DNSCurve has a PKI heirarchy, it is just implicit (and sometimes lacking signing if the upstream DNS provider doesn't support DNSCurve) rather than explicit, and is forced to follow the DNS trust heirarchy (the same heirarchy that DNSSEC follows). > I think it is unwise to say "we can predict what will be said in the > first draft of the protocol", much less what might come out of a > group with diverse interests working on that protocol. For the HIGH LEVEL viewpoint, you can: DNSCurve is a channel confidentiality and integrity protocol, with a key distribution mechanism which uses the DNS as an implicit PKI. Period. Anything that changes this you can't really call DNSCurve anymore. And the implementation details/items of interest really belong in a transport-layer security working group. Apart from an implicit PKI based on DNS rather than a separate explicit PKI, DNSCurve really has nothing to do with DNS but everything to do with datagram-oriented channel integrity & confidentiality. So why should such details be discussed here? -- to unsubscribe send a message to namedroppers-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 Oct 10 11:51: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 103F73A67F3; Fri, 10 Oct 2008 11:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.325 X-Spam-Level: X-Spam-Status: No, score=-99.325 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, 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 lz4DAL5r1XRt; Fri, 10 Oct 2008 11:51:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3E3AB3A6846; Fri, 10 Oct 2008 11:51:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoMzI-000CLT-MP for namedroppers-data@psg.com; Fri, 10 Oct 2008 18:45:20 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoMzD-000CKx-5M for namedroppers@ops.ietf.org; Fri, 10 Oct 2008 18:45:17 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id CEF5633C5A; Fri, 10 Oct 2008 11:45:14 -0700 (PDT) Date: Fri, 10 Oct 2008 11:45:14 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Nicholas Weaver Cc: IETF DNSEXT WG Subject: Re: [dnsext] One other argument for local scope... In-Reply-To: <80CAC5D9-7BDD-44E1-ACC0-90A6D585B5C6@icsi.berkeley.edu> References: <80CAC5D9-7BDD-44E1-ACC0-90A6D585B5C6@icsi.berkeley.edu> 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=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Mon, 6 Oct 2008 09:09:48 -0700, Nicholas Weaver wrote: > > I've made the argument that there should be a separate notion of local > scope (data which is only valid for resolving an individual > outstanding query) and global scope (the cache), because of the > ability to prevent race-until-win attacks by limiting what gets > included into the global scope. [snip] > Thoughts? Comments? The idea seems to be very similar to, if not same as, what Ohta-san has been proposing, see, e.g.: http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01212.html I think this type of defense is generally a good idea. It may not be easy or trivial to actually implement it for existing caching server code, though. At least it won't be easy to implement it for BIND9. --- 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 Fri Oct 10 15:34: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 5D1C63A6AB0; Fri, 10 Oct 2008 15:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.164 X-Spam-Level: X-Spam-Status: No, score=0.164 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 o9ZPtz7spd+l; Fri, 10 Oct 2008 15:34:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8BFA23A6901; Fri, 10 Oct 2008 15:34:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoQRf-000Hhx-3v for namedroppers-data@psg.com; Fri, 10 Oct 2008 22:26:51 +0000 Received: from [209.85.198.235] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoQRW-000HhF-U4 for namedroppers@ops.ietf.org; Fri, 10 Oct 2008 22:26:45 +0000 Received: by rv-out-0506.google.com with SMTP id b25so640069rvf.41 for ; Fri, 10 Oct 2008 15:26:42 -0700 (PDT) Received: by 10.141.66.16 with SMTP id t16mr1569841rvk.168.1223677602062; Fri, 10 Oct 2008 15:26:42 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Fri, 10 Oct 2008 15:26:42 -0700 (PDT) Message-ID: Date: Fri, 10 Oct 2008 15:26:42 -0700 From: "Matthew Dempsky" To: namedroppers@ops.ietf.org Subject: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Is anyone aware of any common firewalls that reject DNS packets (or all UDP packets to/from port 53) longer than 512 bytes or DNS packets that contain domain names longer than 255 bytes? E.g., [1] and [2] have suggested the former has caused problems for EDNS0, but I was curious if anyone had specific/recent experiences with such firewalls and knowledge about how prevalent they are today. I am especially interested in any cases where these firewalls may not be under control of either the client or server's admin. My motivation for this question is the current DNSCurve spec requires clients and servers to support packets up to 4096 bytes and names over 255 bytes, but a client or server may be behind firewalls that prevent these packets from reaching their destination. Thanks. [1] http://homepages.tesco.net/J.deBoynePollard/FGA/dns-edns0-and-firewalls.html [2] http://en.wikipedia.org/wiki/EDNS#EDNS_in_practice -- to unsubscribe send a message to namedroppers-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 Oct 10 16:05: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 692FC3A6901; Fri, 10 Oct 2008 16:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.592 X-Spam-Level: X-Spam-Status: No, score=-4.592 tagged_above=-999 required=5 tests=[AWL=0.456, 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 KZ+q3F9hFGx8; Fri, 10 Oct 2008 16:05:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5A3253A680F; Fri, 10 Oct 2008 16:05:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoQwY-000KUv-Cl for namedroppers-data@psg.com; Fri, 10 Oct 2008 22:58:46 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoQwT-000KUM-PJ for namedroppers@ops.ietf.org; Fri, 10 Oct 2008 22:58:43 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9AMwXMA017549; Fri, 10 Oct 2008 15:58:34 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: "Matthew Dempsky" 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 v929.2) Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Date: Fri, 10 Oct 2008 15:58:32 -0700 References: X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Oct 10, 2008, at 3:26 PM, Matthew Dempsky wrote: > Is anyone aware of any common firewalls that reject DNS packets (or > all UDP packets to/from port 53) longer than 512 bytes or DNS packets > that contain domain names longer than 255 bytes? E.g., [1] and [2] > have suggested the former has caused problems for EDNS0, but I was > curious if anyone had specific/recent experiences with such firewalls > and knowledge about how prevalent they are today. I am especially > interested in any cases where these firewalls may not be under control > of either the client or server's admin. > > My motivation for this question is the current DNSCurve spec requires > clients and servers to support packets up to 4096 bytes and names over > 255 bytes, but a client or server may be behind firewalls that prevent > these packets from reaching their destination. > > Thanks. Just detect and do a fallback. Note, however, that for UDP, you really want to set max size to 1450B or so: We've seen cases where mpls errors will silently drop a default MTU packet (but not MTU-4B) out in the middle of the Internet. Relying on the Internet transport layer to process 4000B packets is unwise. -- to unsubscribe send a message to namedroppers-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 Oct 10 16:26: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 0E4773A6965; Fri, 10 Oct 2008 16:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.235, 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 eItT1gGMQmeS; Fri, 10 Oct 2008 16:26:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 980ED3A67AC; Fri, 10 Oct 2008 16:26:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoRJe-000MKt-En for namedroppers-data@psg.com; Fri, 10 Oct 2008 23:22:38 +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 1KoRJV-000MKE-Ve for namedroppers@ops.ietf.org; Fri, 10 Oct 2008 23:22:35 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id m9ANMOcM028982; Sat, 11 Oct 2008 10:22:24 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> To: "Matthew Dempsky" Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? In-reply-to: Your message of "Fri, 10 Oct 2008 15:26:42 PDT." Date: Sat, 11 Oct 2008 10:22:24 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , "Matth ew Dempsky" writes: > Is anyone aware of any common firewalls that reject DNS packets (or > all UDP packets to/from port 53) longer than 512 bytes or DNS packets > that contain domain names longer than 255 bytes? E.g., [1] and [2] > have suggested the former has caused problems for EDNS0, but I was > curious if anyone had specific/recent experiences with such firewalls > and knowledge about how prevalent they are today. I am especially > interested in any cases where these firewalls may not be under control > of either the client or server's admin. > > My motivation for this question is the current DNSCurve spec requires > clients and servers to support packets up to 4096 bytes and names over > 255 bytes, but a client or server may be behind firewalls that prevent > these packets from reaching their destination. Names over 255 bytes are a non-starter. > Thanks. > > [1] http://homepages.tesco.net/J.deBoynePollard/FGA/dns-edns0-and-firewalls.h > tml > [2] http://en.wikipedia.org/wiki/EDNS#EDNS_in_practice > > -- > to 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 Oct 10 16:37: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 997D43A6AA0; Fri, 10 Oct 2008 16:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.16 X-Spam-Level: X-Spam-Status: No, score=0.16 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 tqvxU8bHEKQR; Fri, 10 Oct 2008 16:37:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A47723A6A8E; Fri, 10 Oct 2008 16:37:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoRUm-000NJr-7c for namedroppers-data@psg.com; Fri, 10 Oct 2008 23:34:08 +0000 Received: from [209.85.198.225] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoRUh-000NJL-QI for namedroppers@ops.ietf.org; Fri, 10 Oct 2008 23:34:05 +0000 Received: by rv-out-0506.google.com with SMTP id b25so659615rvf.41 for ; Fri, 10 Oct 2008 16:34:03 -0700 (PDT) Received: by 10.141.163.12 with SMTP id q12mr1592945rvo.265.1223681643599; Fri, 10 Oct 2008 16:34:03 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Fri, 10 Oct 2008 16:34:03 -0700 (PDT) Message-ID: Date: Fri, 10 Oct 2008 16:34:03 -0700 From: "Matthew Dempsky" To: "Mark Andrews" Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Cc: namedroppers@ops.ietf.org In-Reply-To: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Oct 10, 2008 at 4:22 PM, Mark Andrews wrote: > Names over 255 bytes are a non-starter. Can you elaborate on this? -- to unsubscribe send a message to namedroppers-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 Oct 10 17:11: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 C53BD3A6965; Fri, 10 Oct 2008 17:11: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 UP1eNcXLrChG; Fri, 10 Oct 2008 17:11:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F3C1D3A685A; Fri, 10 Oct 2008 17:11:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoS2O-0000Zi-CL for namedroppers-data@psg.com; Sat, 11 Oct 2008 00:08:52 +0000 Received: from [129.9.40.27] (helo=odbmap02.extra.chrysler.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoS2H-0000V4-Eb for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 00:08:48 +0000 Received: from odmsp099.oddc.chrysler.com (unknown [129.9.32.254]) by odbmap02.extra.chrysler.com (Symantec Mail Security) with ESMTP id 964274E4002 for ; Fri, 10 Oct 2008 20:08:41 -0400 (EDT) X-AuditID: 8109281a-a9ba9bb000000b83-7b-48efee894aa6 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.98.85]) by odmsp099.oddc.chrysler.com (Symantec Mail Security) with ESMTP id 4FB4D1D06 for ; Fri, 10 Oct 2008 20:08:41 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by wokcdts1.is.chrysler.com (8.13.6/8.9.1) with ESMTP id m9B08fQ0009569 for ; Fri, 10 Oct 2008 20:08:41 -0400 (EDT) Message-ID: <48EFEE89.7070407@chrysler.com> Date: Fri, 10 Oct 2008 20:08:41 -0400 From: Kevin Darcy User-Agent: Thunderbird 2.0.0.6 (X11/20070802) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Matthew Dempsky wrote: > On Fri, Oct 10, 2008 at 4:22 PM, Mark Andrews wrote: > >> Names over 255 bytes are a non-starter. >> > > Can you elaborate on this? > > RFC 1034, Section 3.1 "To simplify implementations, the total number of octets that represent a domain name (i.e., the sum of all label octets and label lengths) is limited to 255." - Kevin -- to unsubscribe send a message to namedroppers-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 Oct 10 17:11: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 ADD113A6ADC; Fri, 10 Oct 2008 17:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.58 X-Spam-Level: X-Spam-Status: No, score=-104.58 tagged_above=-999 required=5 tests=[AWL=2.019, 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 iNjXyvBNW5Wq; Fri, 10 Oct 2008 17:11:34 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 389903A69DD; Fri, 10 Oct 2008 17:11:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoS1M-0000PP-PA for namedroppers-data@psg.com; Sat, 11 Oct 2008 00:07:48 +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 1KoS1D-0000FQ-Jk for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 00:07:44 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m9B04jdG013465; Sat, 11 Oct 2008 00:04:45 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m9B04j4i013464; Sat, 11 Oct 2008 00:04:45 GMT Date: Sat, 11 Oct 2008 00:04:45 +0000 From: bmanning@vacation.karoshi.com To: Matthew Dempsky Cc: Mark Andrews , namedroppers@ops.ietf.org Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Message-ID: <20081011000445.GA13417@vacation.karoshi.com.> References: <200810102322.m9ANMOcM028982@drugs.dv.isc.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 Fri, Oct 10, 2008 at 04:34:03PM -0700, Matthew Dempsky wrote: > On Fri, Oct 10, 2008 at 4:22 PM, Mark Andrews wrote: > > Names over 255 bytes are a non-starter. > > Can you elaborate on this? > well, if you care to look at the IETF DNS specs, say RFC 1034, you will find the following text: "To simplify implementations, the total number of octets that represent a domain name (i.e., the sum of all label octets and label lengths) is limited to 255." your DNS spec might have a different max length. --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 Fri Oct 10 17:20: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 303EA3A6967; Fri, 10 Oct 2008 17:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.157 X-Spam-Level: X-Spam-Status: No, score=0.157 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 mA20FWghLF73; Fri, 10 Oct 2008 17:20:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5D09E3A6767; Fri, 10 Oct 2008 17:20:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoSBQ-0001QU-3m for namedroppers-data@psg.com; Sat, 11 Oct 2008 00:18:12 +0000 Received: from [209.85.198.238] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoSBK-0001Pv-KK for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 00:18:09 +0000 Received: by rv-out-0506.google.com with SMTP id b25so671045rvf.41 for ; Fri, 10 Oct 2008 17:18:06 -0700 (PDT) Received: by 10.140.250.14 with SMTP id x14mr1026589rvh.1.1223684286124; Fri, 10 Oct 2008 17:18:06 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Fri, 10 Oct 2008 17:18:06 -0700 (PDT) Message-ID: Date: Fri, 10 Oct 2008 17:18:06 -0700 From: "Matthew Dempsky" To: bmanning@vacation.karoshi.com Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Cc: "Mark Andrews" , namedroppers@ops.ietf.org In-Reply-To: <20081011000445.GA13417@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> <20081011000445.GA13417@vacation.karoshi.com.> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Oct 10, 2008 at 5:04 PM, wrote: > well, if you care to look at the IETF DNS specs, say RFC 1034, > you will find the following text: > > "To simplify implementations, the total number of octets that represent a > domain name (i.e., the sum of all label octets and label lengths) is > limited to 255." RFC 1035 says "Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers)." Did this make EDNS0's support of UDP packets greater than 512 bytes a non-starter? To clarify, the current DNSCurve spec only requires support for domain names greater than 255 bytes long as a possible encapsulation method for protected queries. Clients and servers do not otherwise need to support domain names greater than 255 bytes. The only concern is intermediaries dropping DNS packets containing domain names greater than 255 bytes. -- to unsubscribe send a message to namedroppers-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 Oct 10 17: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 5A56A3A6AAC; Fri, 10 Oct 2008 17:52:35 -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 BPjiNHrEIxMF; Fri, 10 Oct 2008 17:51:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E3CB83A6851; Fri, 10 Oct 2008 17:51:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoSdl-0003rM-Se for namedroppers-data@psg.com; Sat, 11 Oct 2008 00:47:29 +0000 Received: from [129.9.168.37] (helo=shbmap02.extra.chrysler.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoSdg-0003qs-Q6 for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 00:47:26 +0000 Received: from odmsp099.oddc.chrysler.com (unknown [129.9.32.254]) by shbmap02.extra.chrysler.com (Symantec Mail Security) with ESMTP id DFA5A4E4002 for ; Fri, 10 Oct 2008 20:47:23 -0400 (EDT) X-AuditID: 8109a824-ada2abb000000bb5-58-48eff79bfb70 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.98.85]) by odmsp099.oddc.chrysler.com (Symantec Mail Security) with ESMTP id 9EA0A1CF8 for ; Fri, 10 Oct 2008 20:47:23 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by wokcdts1.is.chrysler.com (8.13.6/8.9.1) with ESMTP id m9B0lNYp009616 for ; Fri, 10 Oct 2008 20:47:23 -0400 (EDT) Message-ID: <48EFF79B.1000505@chrysler.com> Date: Fri, 10 Oct 2008 20:47:23 -0400 From: Kevin Darcy User-Agent: Thunderbird 2.0.0.6 (X11/20070802) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> <20081011000445.GA13417@vacation.karoshi.com.> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Matthew Dempsky wrote: > On Fri, Oct 10, 2008 at 5:04 PM, wrote: > >> well, if you care to look at the IETF DNS specs, say RFC 1034, >> you will find the following text: >> >> "To simplify implementations, the total number of octets that represent a >> domain name (i.e., the sum of all label octets and label lengths) is >> limited to 255." >> > > RFC 1035 says "Messages carried by UDP are restricted to 512 bytes > (not counting the IP or UDP headers)." Did this make EDNS0's support > of UDP packets greater than 512 bytes a non-starter? > RFC 2671 (proposed standard) clearly updated RFC 1035 in this respect, even if that is not technically acknowledged in the RFC database. - Kevin -- to unsubscribe send a message to namedroppers-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 Oct 10 18:23: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 2345F3A6A62; Fri, 10 Oct 2008 18:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.154 X-Spam-Level: X-Spam-Status: No, score=0.154 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 fvBf0ias3u7H; Fri, 10 Oct 2008 18:23:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5AC553A67F1; Fri, 10 Oct 2008 18:23:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoT9K-0006M1-PZ for namedroppers-data@psg.com; Sat, 11 Oct 2008 01:20:06 +0000 Received: from [209.85.198.233] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoT9C-0006Kh-8D for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 01:20:00 +0000 Received: by rv-out-0506.google.com with SMTP id b25so686123rvf.41 for ; Fri, 10 Oct 2008 18:19:56 -0700 (PDT) Received: by 10.141.53.4 with SMTP id f4mr1678496rvk.82.1223687996605; Fri, 10 Oct 2008 18:19:56 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Fri, 10 Oct 2008 18:19:56 -0700 (PDT) Message-ID: Date: Fri, 10 Oct 2008 18:19:56 -0700 From: "Matthew Dempsky" To: "Kevin Darcy" Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Cc: namedroppers@ops.ietf.org In-Reply-To: <48EFF79B.1000505@chrysler.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> <20081011000445.GA13417@vacation.karoshi.com.> <48EFF79B.1000505@chrysler.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Oct 10, 2008 at 5:47 PM, Kevin Darcy wrote: > RFC 2671 (proposed standard) clearly updated RFC 1035 in this respect, even > if that is not technically acknowledged in the RFC database. So you agree there's precedent for letting an RFC loosen a size limitation? You're okay then with an RFC that would allow a client to send a query for a domain name longer than 255 bytes to a server that has announced its ability to handle such names? -- to unsubscribe send a message to namedroppers-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 Oct 10 19:40: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 384A93A69A3; Fri, 10 Oct 2008 19:40:56 -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 UlNpkLKQYdWv; Fri, 10 Oct 2008 19:40:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 508ED3A6935; Fri, 10 Oct 2008 19:40:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoUKu-000CIE-Nm for namedroppers-data@psg.com; Sat, 11 Oct 2008 02:36:08 +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 1KoUKn-000CAE-6Y for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 02:36: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 m9B2X6dG014190; Sat, 11 Oct 2008 02:33:06 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m9B2X6IR014189; Sat, 11 Oct 2008 02:33:06 GMT Date: Sat, 11 Oct 2008 02:33:06 +0000 From: bmanning@vacation.karoshi.com To: Matthew Dempsky Cc: bmanning@vacation.karoshi.com, Mark Andrews , namedroppers@ops.ietf.org Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Message-ID: <20081011023306.GA14167@vacation.karoshi.com.> References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> <20081011000445.GA13417@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 Fri, Oct 10, 2008 at 05:18:06PM -0700, Matthew Dempsky wrote: > On Fri, Oct 10, 2008 at 5:04 PM, wrote: > > well, if you care to look at the IETF DNS specs, say RFC 1034, > > you will find the following text: > > > > "To simplify implementations, the total number of octets that represent a > > domain name (i.e., the sum of all label octets and label lengths) is > > limited to 255." > > RFC 1035 says "Messages carried by UDP are restricted to 512 bytes > (not counting the IP or UDP headers)." Did this make EDNS0's support > of UDP packets greater than 512 bytes a non-starter? nope - EDNS changed that requirement. EDNS was defined in an IETF RFC. > To clarify, the current DNSCurve spec only requires support for domain > names greater than 255 bytes long as a possible encapsulation method > for protected queries. Clients and servers do not otherwise need to > support domain names greater than 255 bytes. The only concern is > intermediaries dropping DNS packets containing domain names greater > than 255 bytes. DNSCurve website hints at a way to support >255 bytes and if the website is the spec, then you might be right. anything larger than 255 octets will be dropped by virtually every other DNS implementation. --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 Fri Oct 10 19:57: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 3DF1B28C13B; Fri, 10 Oct 2008 19:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 LZhswTYjF4A2; Fri, 10 Oct 2008 19:57:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6DCC53A699E; Fri, 10 Oct 2008 19:57:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoUcL-000E1H-IU for namedroppers-data@psg.com; Sat, 11 Oct 2008 02:54:09 +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 1KoUcF-000E0h-8a for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 02:54:06 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 6FC7EA1017; Sat, 11 Oct 2008 02:53:54 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: bmanning@vacation.karoshi.com cc: Matthew Dempsky , Mark Andrews , namedroppers@ops.ietf.org In-Reply-To: Your message of "Sat, 11 Oct 2008 02:33:06 GMT." <20081011023306.GA14167@vacation.karoshi.com.> References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> <20081011000445.GA13417@vacation.karoshi.com.> <20081011023306.GA14167@vacation.karoshi.com.> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sat, 11 Oct 2008 02:53:54 +0000 Message-ID: <30037.1223693634@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 6FC7EA1017.897D9 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > DNSCurve website hints at a way to support >255 bytes > and if the website is the spec, then you might be right. > anything larger than 255 octets will be dropped by virtually > every other DNS implementation. s/other// -- to unsubscribe send a message to namedroppers-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 Oct 10 22:01: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 247833A6898; Fri, 10 Oct 2008 22:01:48 -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 C+EDTKR6099f; Fri, 10 Oct 2008 22:01:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E401C3A6B19; Fri, 10 Oct 2008 22:01:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoWXA-000MtU-Nm for namedroppers-data@psg.com; Sat, 11 Oct 2008 04:56:56 +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 1KoWX1-000Mnj-Qu for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 04:56:52 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m9B4rqdG015356; Sat, 11 Oct 2008 04:53:52 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m9B4rnB5015354; Sat, 11 Oct 2008 04:53:49 GMT Date: Sat, 11 Oct 2008 04:53:49 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: bmanning@vacation.karoshi.com, Matthew Dempsky , Mark Andrews , namedroppers@ops.ietf.org Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Message-ID: <20081011045349.GA15299@vacation.karoshi.com.> References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> <20081011000445.GA13417@vacation.karoshi.com.> <20081011023306.GA14167@vacation.karoshi.com.> <30037.1223693634@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30037.1223693634@nsa.vix.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sat, Oct 11, 2008 at 02:53:54AM +0000, Paul Vixie wrote: > > DNSCurve website hints at a way to support >255 bytes > > and if the website is the spec, then you might be right. > > anything larger than 255 octets will be dropped by virtually > > every other DNS implementation. > > s/other// er... almost. DNSCurve(*) talking to DNSCurve(*) could - conceptually - pass names larger than 255 octets... then there is the little nit of bytes != octets in all cases. (which is why octets were used in 1034 instead of bytes) for any practical purpose, you are correct. for theoretical accuracy, you are not. * based on the wayback machine archive of the web pages from 10oct2008 for DNSCurve and not the 27oct2008 or 13nov2008 pages - noting that the 25dec2008 web page suggests an incompatable change w/ implementations done from previous versions of the web pages(#) # presuming no web page defacement has occured. punting to another vector... why does DNSCurve remind me of a functional replacement for the SIG(0)/TSIG tools? --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 Fri Oct 10 23:05: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 6F02128C16F; Fri, 10 Oct 2008 23:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.152 X-Spam-Level: X-Spam-Status: No, score=0.152 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 ERWmxgXCumtu; Fri, 10 Oct 2008 23:05:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9057B28C16D; Fri, 10 Oct 2008 23:05:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoXXY-0001gv-Pp for namedroppers-data@psg.com; Sat, 11 Oct 2008 06:01:24 +0000 Received: from [209.85.198.230] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoXXU-0001gF-3d for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 06:01:21 +0000 Received: by rv-out-0506.google.com with SMTP id b25so744037rvf.41 for ; Fri, 10 Oct 2008 23:01:19 -0700 (PDT) Received: by 10.141.170.10 with SMTP id x10mr1831455rvo.140.1223704878941; Fri, 10 Oct 2008 23:01:18 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Fri, 10 Oct 2008 23:01:18 -0700 (PDT) Message-ID: Date: Fri, 10 Oct 2008 23:01:18 -0700 From: "Matthew Dempsky" To: bmanning@vacation.karoshi.com Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Cc: "Mark Andrews" , namedroppers@ops.ietf.org In-Reply-To: <20081011023306.GA14167@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> <20081011000445.GA13417@vacation.karoshi.com.> <20081011023306.GA14167@vacation.karoshi.com.> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Oct 10, 2008 at 7:33 PM, wrote: > nope - EDNS changed that requirement. EDNS was defined > in an IETF RFC. You miss the point. There was a brief, 12-year period between RFC 1034 and RFC 2671 where the most recent RFC limited that DNS packets sent over UDP to 512 bytes or less. *During this time period*, why was the proposal to allow new clients and new servers to communicate using larger packets not a "non-starter" as well? -- to unsubscribe send a message to namedroppers-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 Oct 11 03:26: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 B27E53A6918; Sat, 11 Oct 2008 03:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, 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 VwTfW1Y1CCjw; Sat, 11 Oct 2008 03:26:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB4A53A691F; Sat, 11 Oct 2008 03:26:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KobRb-000PRZ-WF for namedroppers-data@psg.com; Sat, 11 Oct 2008 10:11:32 +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 1KobRV-000PQw-TT for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 10:11:28 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id m9BABI4m031207; Sat, 11 Oct 2008 21:11:18 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200810111011.m9BABI4m031207@drugs.dv.isc.org> To: "Matthew Dempsky" Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? In-reply-to: Your message of "Fri, 10 Oct 2008 17:18:06 PDT." Date: Sat, 11 Oct 2008 21:11:18 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , "Matt hew Dempsky" writes: > On Fri, Oct 10, 2008 at 5:04 PM, wrote: > > well, if you care to look at the IETF DNS specs, say RFC 1034, > > you will find the following text: > > > > "To simplify implementations, the total number of octets that represent a > > domain name (i.e., the sum of all label octets and label lengths) is > > limited to 255." > > RFC 1035 says "Messages carried by UDP are restricted to 512 bytes > (not counting the IP or UDP headers)." Did this make EDNS0's support > of UDP packets greater than 512 bytes a non-starter? EDNS0's packet size is hop-by-hop. Nameserver name size is end-to-end. > To clarify, the current DNSCurve spec only requires support for domain > names greater than 255 bytes long as a possible encapsulation method > for protected queries. Clients and servers do not otherwise need to > support domain names greater than 255 bytes. The only concern is > intermediaries dropping DNS packets containing domain names greater > than 255 bytes. -- 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 Sat Oct 11 06:09: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 A0FA03A6861; Sat, 11 Oct 2008 06:09:42 -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 8zGJ6TfSSLwg; Sat, 11 Oct 2008 06:09:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A860C3A682C; Sat, 11 Oct 2008 06:09:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Koe9p-000HOe-GH for namedroppers-data@psg.com; Sat, 11 Oct 2008 13:05:21 +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 1Koe9i-000HCd-P0 for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 13:05:18 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m9BD2LdG018490; Sat, 11 Oct 2008 13:02:21 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m9BD2Lge018489; Sat, 11 Oct 2008 13:02:21 GMT Date: Sat, 11 Oct 2008 13:02:21 +0000 From: bmanning@vacation.karoshi.com To: Matthew Dempsky Cc: bmanning@vacation.karoshi.com, Mark Andrews , namedroppers@ops.ietf.org Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Message-ID: <20081011130221.GA18440@vacation.karoshi.com.> References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> <20081011000445.GA13417@vacation.karoshi.com.> <20081011023306.GA14167@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 Fri, Oct 10, 2008 at 11:01:18PM -0700, Matthew Dempsky wrote: > On Fri, Oct 10, 2008 at 7:33 PM, wrote: > > nope - EDNS changed that requirement. EDNS was defined > > in an IETF RFC. > > You miss the point. There was a brief, 12-year period between RFC > 1034 and RFC 2671 where the most recent RFC limited that DNS packets > sent over UDP to 512 bytes or less. *During this time period*, why > was the proposal to allow new clients and new servers to communicate > using larger packets not a "non-starter" as well? you appear to be refereing to a proposal that emerged sometime between RFC 1034 and RFC 2671 which would allow DNS packets over UDP to exceed 512 bytes. to make sure we are all on the same page, could you provide a reference to that proposal? --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 Oct 11 07:14: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 DE5FF3A6774; Sat, 11 Oct 2008 07:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 pcRrNH3FpXml; Sat, 11 Oct 2008 07:14:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D7BEE3A659A; Sat, 11 Oct 2008 07:14:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kof9k-000P1g-Tx for namedroppers-data@psg.com; Sat, 11 Oct 2008 14:09:20 +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 1Kof9d-000P16-Ul for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 14:09:17 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 354FAFC7C9; Sat, 11 Oct 2008 14:08:47 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: bmanning@vacation.karoshi.com cc: Matthew Dempsky , Mark Andrews , namedroppers@ops.ietf.org In-Reply-To: Your message of "Sat, 11 Oct 2008 13:02:21 GMT." <20081011130221.GA18440@vacation.karoshi.com.> References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> <20081011000445.GA13417@vacation.karoshi.com.> <20081011023306.GA14167@vacation.karoshi.com.> <20081011130221.GA18440@vacation.karoshi.com.> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sat, 11 Oct 2008 14:08:47 +0000 Message-ID: <23076.1223734127@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 354FAFC7C9.B8EE3 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > You miss the point. There was a brief, 12-year period between RFC > > 1034 and RFC 2671 where the most recent RFC limited that DNS packets > > sent over UDP to 512 bytes or less. *During this time period*, why > > was the proposal to allow new clients and new servers to communicate > > using larger packets not a "non-starter" as well? > > you appear to be refereing to a proposal that emerged > sometime between RFC 1034 and RFC 2671 which would allow > DNS packets over UDP to exceed 512 bytes. > > to make sure we are all on the same page, could you provide > a reference to that proposal? more to the point, edns0 as defined in rfc 2671 only allows one case where a new kind of data can be expressed, that being extended label types, and that is the part that hasn't worked out, and that's why. i think a proposal to change the maximum label length would be viewed as "very controversial" and that an option to signal one's readiness to accept such labels would not be accepted by the standards body. furthermore it's been nine years since rfc 2671 came out and we're still fighting the deployment battle, and the hotels and isp's of the world who rewrite dns packets in flight are growing not shrinking. -- to unsubscribe send a message to namedroppers-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 Oct 11 07:16: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 4978A3A6AA2; Sat, 11 Oct 2008 07:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 l64kkMsJ+eEB; Sat, 11 Oct 2008 07:16:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 80BB83A690A; Sat, 11 Oct 2008 07:16:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KofBD-000P9z-UH for namedroppers-data@psg.com; Sat, 11 Oct 2008 14:10: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 1KofB7-000P9J-Rt for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 14:10:48 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 08F24A66AF; Sat, 11 Oct 2008 14:10:22 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "Matthew Dempsky" cc: bmanning@vacation.karoshi.com, "Mark Andrews" , namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 10 Oct 2008 23:01:18 MST." References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> <20081011000445.GA13417@vacation.karoshi.com.> <20081011023306.GA14167@vacation.karoshi.com.> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sat, 11 Oct 2008 14:10:22 +0000 Message-ID: <23433.1223734222@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 08F24A66AF.E80BF X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > nope - EDNS changed that requirement. EDNS was defined > > in an IETF RFC. > > You miss the point. There was a brief, 12-year period between RFC > 1034 and RFC 2671 where the most recent RFC limited that DNS packets > sent over UDP to 512 bytes or less. *During this time period*, why > was the proposal to allow new clients and new servers to communicate > using larger packets not a "non-starter" as well? it was an option negotiation, defined by the standards body. -- to unsubscribe send a message to namedroppers-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 Oct 11 08:44: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 069073A6B0E; Sat, 11 Oct 2008 08:44:56 -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=[AWL=0.000, 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 j8VZ7u3a57aD; Sat, 11 Oct 2008 08:44:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F42023A6774; Sat, 11 Oct 2008 08:44:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KogYr-0008Ak-Ru for namedroppers-data@psg.com; Sat, 11 Oct 2008 15:39:22 +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 1KogYk-00080J-VA for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 15:39:18 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m9BFaNdG019711; Sat, 11 Oct 2008 15:36:23 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m9BFaNkl019710; Sat, 11 Oct 2008 15:36:23 GMT Date: Sat, 11 Oct 2008 15:36:23 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: bmanning@vacation.karoshi.com, Matthew Dempsky , Mark Andrews , namedroppers@ops.ietf.org Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Message-ID: <20081011153623.GB19624@vacation.karoshi.com.> References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> <20081011000445.GA13417@vacation.karoshi.com.> <20081011023306.GA14167@vacation.karoshi.com.> <20081011130221.GA18440@vacation.karoshi.com.> <23076.1223734127@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23076.1223734127@nsa.vix.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sat, Oct 11, 2008 at 02:08:47PM +0000, Paul Vixie wrote: > > > You miss the point. There was a brief, 12-year period between RFC > > > 1034 and RFC 2671 where the most recent RFC limited that DNS packets > > > sent over UDP to 512 bytes or less. *During this time period*, why > > > was the proposal to allow new clients and new servers to communicate > > > using larger packets not a "non-starter" as well? > > > > you appear to be refereing to a proposal that emerged > > sometime between RFC 1034 and RFC 2671 which would allow > > DNS packets over UDP to exceed 512 bytes. > > > > to make sure we are all on the same page, could you provide > > a reference to that proposal? > > more to the point, edns0 as defined in rfc 2671 only allows one case > where a new kind of data can be expressed, that being extended label > types, and that is the part that hasn't worked out, and that's why. > > i think a proposal to change the maximum label length would be viewed > as "very controversial" and that an option to signal one's readiness > to accept such labels would not be accepted by the standards body. > > furthermore it's been nine years since rfc 2671 came out and we're > still fighting the deployment battle, and the hotels and isp's of the > world who rewrite dns packets in flight are growing not shrinking. Paul, The question on the table here is "what proposal - between RFC 1034 and RFC 2671 - allowed DNS packets over UDP to exceed 512 bytes? Do you remember any such proposal in circulation in that time period? --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 Oct 11 12:01: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 462A03A687B; Sat, 11 Oct 2008 12:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 FrCnHq-dovNJ; Sat, 11 Oct 2008 12:01:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B483B3A6B48; Sat, 11 Oct 2008 12:01:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KojdM-0007j0-Ou for namedroppers-data@psg.com; Sat, 11 Oct 2008 18:56:12 +0000 Received: from [209.85.198.225] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KojdH-0007hE-Fi for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 18:56:09 +0000 Received: by rv-out-0506.google.com with SMTP id b25so910123rvf.41 for ; Sat, 11 Oct 2008 11:56:06 -0700 (PDT) Received: by 10.140.165.21 with SMTP id n21mr2275615rve.244.1223751366416; Sat, 11 Oct 2008 11:56:06 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Sat, 11 Oct 2008 11:56:06 -0700 (PDT) Message-ID: Date: Sat, 11 Oct 2008 11:56:06 -0700 From: "Matthew Dempsky" To: bmanning@vacation.karoshi.com Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Cc: "Paul Vixie" , "Mark Andrews" , namedroppers@ops.ietf.org In-Reply-To: <20081011153623.GB19624@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> <20081011000445.GA13417@vacation.karoshi.com.> <20081011023306.GA14167@vacation.karoshi.com.> <20081011130221.GA18440@vacation.karoshi.com.> <23076.1223734127@nsa.vix.com> <20081011153623.GB19624@vacation.karoshi.com.> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sat, Oct 11, 2008 at 8:36 AM, wrote: > The question on the table here is "what proposal - between > RFC 1034 and RFC 2671 - allowed DNS packets over UDP to exceed > 512 bytes? Do you remember any such proposal in circulation > in that time period? Are you serious? Is there some sort of inside joke I'm missing out on? Are you suggesting the IETF accepted RFC 2671 as a standard without it ever being proposed by someone? -- to unsubscribe send a message to namedroppers-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 Oct 11 12: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 E7C273A6942; Sat, 11 Oct 2008 12:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.148 X-Spam-Level: X-Spam-Status: No, score=0.148 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 19jIXSq8iQmD; Sat, 11 Oct 2008 12:56:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 168C33A680E; Sat, 11 Oct 2008 12:56:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KokSm-000EQy-6d for namedroppers-data@psg.com; Sat, 11 Oct 2008 19:49:20 +0000 Received: from [209.85.198.226] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KokSg-000EQT-U6 for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 19:49:17 +0000 Received: by rv-out-0506.google.com with SMTP id b25so922207rvf.41 for ; Sat, 11 Oct 2008 12:49:14 -0700 (PDT) Received: by 10.141.29.8 with SMTP id g8mr2329680rvj.62.1223754554356; Sat, 11 Oct 2008 12:49:14 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Sat, 11 Oct 2008 12:49:14 -0700 (PDT) Message-ID: Date: Sat, 11 Oct 2008 12:49:14 -0700 From: "Matthew Dempsky" To: "Paul Vixie" Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Cc: bmanning@vacation.karoshi.com, "Mark Andrews" , namedroppers@ops.ietf.org In-Reply-To: <23076.1223734127@nsa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> <20081011000445.GA13417@vacation.karoshi.com.> <20081011023306.GA14167@vacation.karoshi.com.> <20081011130221.GA18440@vacation.karoshi.com.> <23076.1223734127@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sat, Oct 11, 2008 at 7:08 AM, Paul Vixie wrote: > i think a proposal to change the maximum label length would be viewed > as "very controversial" Fortunately, DNSCurve needs no such proposal. It only needs support for names whose total size exceeds 255 bytes and only when protecting DNS packets that already contain a name greater than about 100 bytes in length in the questions section. -- to unsubscribe send a message to namedroppers-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 Oct 11 14:46: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 3CB7B3A682D; Sat, 11 Oct 2008 14:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 pHUsX5QEStFg; Sat, 11 Oct 2008 14:46:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 84F6B3A659B; Sat, 11 Oct 2008 14:46:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KomD9-0001ER-J2 for namedroppers-data@psg.com; Sat, 11 Oct 2008 21:41:19 +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 1KomD2-0001DJ-0m for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 21:41:16 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id m9BLeo0e041538; Sun, 12 Oct 2008 08:40:50 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200810112140.m9BLeo0e041538@drugs.dv.isc.org> To: bmanning@vacation.karoshi.com Cc: Paul Vixie , Matthew Dempsky , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? In-reply-to: Your message of "Sat, 11 Oct 2008 15:36:23 -0000." <20081011153623.GB19624@vacation.karoshi.com.> Date: Sun, 12 Oct 2008 08:40:50 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <20081011153623.GB19624@vacation.karoshi.com.>, bmanning@vacation.ka roshi.com writes: > On Sat, Oct 11, 2008 at 02:08:47PM +0000, Paul Vixie wrote: > > > > You miss the point. There was a brief, 12-year period between RFC > > > > 1034 and RFC 2671 where the most recent RFC limited that DNS packets > > > > sent over UDP to 512 bytes or less. *During this time period*, why > > > > was the proposal to allow new clients and new servers to communicate > > > > using larger packets not a "non-starter" as well? > > > > > > you appear to be refereing to a proposal that emerged > > > sometime between RFC 1034 and RFC 2671 which would allow > > > DNS packets over UDP to exceed 512 bytes. > > > > > > to make sure we are all on the same page, could you provide > > > a reference to that proposal? > > > > more to the point, edns0 as defined in rfc 2671 only allows one case > > where a new kind of data can be expressed, that being extended label > > types, and that is the part that hasn't worked out, and that's why. > > > > i think a proposal to change the maximum label length would be viewed > > as "very controversial" and that an option to signal one's readiness > > to accept such labels would not be accepted by the standards body. > > > > furthermore it's been nine years since rfc 2671 came out and we're > > still fighting the deployment battle, and the hotels and isp's of the > > world who rewrite dns packets in flight are growing not shrinking. > > Paul, > > The question on the table here is "what proposal - between > RFC 1034 and RFC 2671 - allowed DNS packets over UDP to exceed > 512 bytes? Do you remember any such proposal in circulation > in that time period? There were servers that sent UDP responses that exceeded 512 bytes as part of some modifications for HS support by MIT I believe. We had to put code in to named to detect such responses and treat them as if TC had been set. As to a formal proposal, I'm not aware of any myself. > --bill -- 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 Sat Oct 11 14:53: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 D7CA83A67E4; Sat, 11 Oct 2008 14:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.147 X-Spam-Level: X-Spam-Status: No, score=0.147 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 Nm1yx37REEBH; Sat, 11 Oct 2008 14:53:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0CC3E3A659B; Sat, 11 Oct 2008 14:53:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KomLD-00025c-TI for namedroppers-data@psg.com; Sat, 11 Oct 2008 21:49:39 +0000 Received: from [209.85.198.238] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KomL8-000254-NL for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 21:49:36 +0000 Received: by rv-out-0506.google.com with SMTP id b25so947804rvf.41 for ; Sat, 11 Oct 2008 14:49:33 -0700 (PDT) Received: by 10.141.168.2 with SMTP id v2mr2401405rvo.55.1223761773471; Sat, 11 Oct 2008 14:49:33 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Sat, 11 Oct 2008 14:49:33 -0700 (PDT) Message-ID: Date: Sat, 11 Oct 2008 14:49:33 -0700 From: "Matthew Dempsky" To: "Mark Andrews" Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Cc: bmanning@vacation.karoshi.com, "Paul Vixie" , namedroppers@ops.ietf.org In-Reply-To: <200810112140.m9BLeo0e041538@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081011153623.GB19624@vacation.karoshi.com.> <200810112140.m9BLeo0e041538@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sat, Oct 11, 2008 at 2:40 PM, Mark Andrews wrote: > As to a formal proposal, I'm not aware of any myself. Really? No one ever formally proposed EDNS0? How did it become an RFC? Did it just magically appear on the IETF servers one night? Is this some sort of hazing ritual for new subscribers to namedroppers? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Oct 11 15:03: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 0D0693A6808; Sat, 11 Oct 2008 15:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.542 X-Spam-Level: X-Spam-Status: No, score=-0.542 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 ooV0fzUhhwH6; Sat, 11 Oct 2008 15:03:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 35CDA3A67B5; Sat, 11 Oct 2008 15:03:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KomUM-00038T-CM for namedroppers-data@psg.com; Sat, 11 Oct 2008 21:59:06 +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 1KomUG-00037W-3S for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 21:59:03 +0000 Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id A3A136BE02F; Sat, 11 Oct 2008 14:59:03 -0700 (PDT) Date: Sat, 11 Oct 2008 14:59:03 -0700 From: Eric Rescorla To: "Matthew Dempsky" Cc: "Kevin Darcy" , namedroppers@ops.ietf.org Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? In-Reply-To: References: <200810102322.m9ANMOcM028982@drugs.dv.isc.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: <20081011215903.A3A136BE02F@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Fri, 10 Oct 2008 18:19:56 -0700, Matthew Dempsky wrote: > > On Fri, Oct 10, 2008 at 5:47 PM, Kevin Darcy wrote: > > RFC 2671 (proposed standard) clearly updated RFC 1035 in this respect, even > > if that is not technically acknowledged in the RFC database. > > So you agree there's precedent for letting an RFC loosen a size > limitation? You're okay then with an RFC that would allow a client to > send a query for a domain name longer than 255 bytes to a server that > has announced its ability to handle such names? I'm finding this discussion a bit puzzling. I think it's clear that loosening the size limitation---regardless of the merits of this idea---would require a new RFC. Is the suggestion that DNSCurve should be made an RFC? If so, it seems to me that a clear prerequisite to that discussion would be the existence of DNSCurve I-D. Barring that, why exactly are we having a discussion about the practicality of a specific design decision in DNSCurve? -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 Sat Oct 11 15:45: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 8D43E3A67F6; Sat, 11 Oct 2008 15:45:57 -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 XdtqI3ndzW2X; Sat, 11 Oct 2008 15:45:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 92AAA3A67D2; Sat, 11 Oct 2008 15:45:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kon9q-0007YO-8D for namedroppers-data@psg.com; Sat, 11 Oct 2008 22:41:58 +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 1Kon9j-0007PY-N4 for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 22:41:55 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m9BMcrdG022600; Sat, 11 Oct 2008 22:38:58 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m9BMcr2O022599; Sat, 11 Oct 2008 22:38:53 GMT Date: Sat, 11 Oct 2008 22:38:53 +0000 From: bmanning@vacation.karoshi.com To: Matthew Dempsky Cc: Mark Andrews , bmanning@vacation.karoshi.com, Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Message-ID: <20081011223853.GB21500@vacation.karoshi.com.> References: <20081011153623.GB19624@vacation.karoshi.com.> <200810112140.m9BLeo0e041538@drugs.dv.isc.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 Sat, Oct 11, 2008 at 02:49:33PM -0700, Matthew Dempsky wrote: > On Sat, Oct 11, 2008 at 2:40 PM, Mark Andrews wrote: > > As to a formal proposal, I'm not aware of any myself. > > Really? No one ever formally proposed EDNS0? How did it become an > RFC? Did it just magically appear on the IETF servers one night? > > Is this some sort of hazing ritual for new subscribers to namedroppers? not really - its just making sure you understand. the EDNS activities were documented in an Internet Draft, discussed and debated in the DNSEXT working group as part of the IETF process. if and when other interesting ideas emerge -and- they are expected to become part of or interoperable with the IETF DNS spec, this communuity expects to see the ideas documented in an Internet Draft as a stable repository for discussion and debate. Just like the EDNS0 ideas that became RFC 2671. as to whether EDNS0 conflated lable length >255 octets -AND- DNS UDP packets >512 bytes should be answered by the author. One could also quote chapter/verse from the RFC. my feeble recollection was that EDNS0 was primarily to extend the number of flags since we were down to two bits. Once new flags existed, it became possible to signal divergent capabilities - and as Paul has already said, negotiation for label lengths larger than 255 octets has not been seen as a high value proposition. on the other hand, negotiation for UDP packet sizes larger than 512 bytes has proven useful. --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 Oct 11 15:54: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 1F4C33A67D2; Sat, 11 Oct 2008 15:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.146 X-Spam-Level: X-Spam-Status: No, score=0.146 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 F2C6sHUsLZ+V; Sat, 11 Oct 2008 15:54:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 48F7C3A679C; Sat, 11 Oct 2008 15:54:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KonGp-0008Eb-OH for namedroppers-data@psg.com; Sat, 11 Oct 2008 22:49:11 +0000 Received: from [209.85.198.230] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KonGk-0008DP-7p for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 22:49:08 +0000 Received: by rv-out-0506.google.com with SMTP id b25so958900rvf.41 for ; Sat, 11 Oct 2008 15:49:05 -0700 (PDT) Received: by 10.141.153.16 with SMTP id f16mr1816546rvo.17.1223765345458; Sat, 11 Oct 2008 15:49:05 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Sat, 11 Oct 2008 15:49:05 -0700 (PDT) Message-ID: Date: Sat, 11 Oct 2008 15:49:05 -0700 From: "Matthew Dempsky" To: bmanning@vacation.karoshi.com Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Cc: "Mark Andrews" , "Paul Vixie" , namedroppers@ops.ietf.org In-Reply-To: <20081011223853.GB21500@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081011153623.GB19624@vacation.karoshi.com.> <200810112140.m9BLeo0e041538@drugs.dv.isc.org> <20081011223853.GB21500@vacation.karoshi.com.> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sat, Oct 11, 2008 at 3:38 PM, wrote: > label lengths larger than 255 octets I have consistently asked about *names* larger than 255 bytes. It's even in the subject line of your latest email still. DNSCurve only uses labels up to 53 bytes in length. -- to unsubscribe send a message to namedroppers-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 Oct 11 15: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 8D7503A689E; Sat, 11 Oct 2008 15:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, 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 YZyFSwYc1g+G; Sat, 11 Oct 2008 15:57:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 462583A679C; Sat, 11 Oct 2008 15:57:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KonMb-00095f-4X for namedroppers-data@psg.com; Sat, 11 Oct 2008 22:55:09 +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 1KonMV-000949-0V for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 22:55:05 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id m9BMshiH042286; Sun, 12 Oct 2008 09:54:43 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200810112254.m9BMshiH042286@drugs.dv.isc.org> To: bmanning@vacation.karoshi.com Cc: Matthew Dempsky , Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? In-reply-to: Your message of "Sat, 11 Oct 2008 22:38:53 -0000." <20081011223853.GB21500@vacation.karoshi.com.> Date: Sun, 12 Oct 2008 09:54:43 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <20081011223853.GB21500@vacation.karoshi.com.>, bmanning@vacation.ka roshi.com writes: > On Sat, Oct 11, 2008 at 02:49:33PM -0700, Matthew Dempsky wrote: > > On Sat, Oct 11, 2008 at 2:40 PM, Mark Andrews wrote: > > > As to a formal proposal, I'm not aware of any myself. > > > > Really? No one ever formally proposed EDNS0? How did it become an > > RFC? Did it just magically appear on the IETF servers one night? > > > > Is this some sort of hazing ritual for new subscribers to namedroppers? > > > not really - its just making sure you understand. > > the EDNS activities were documented in an Internet > Draft, discussed and debated in the DNSEXT working group > as part of the IETF process. > > if and when other interesting ideas emerge -and- they are > expected to become part of or interoperable with the IETF > DNS spec, this communuity expects to see the ideas documented > in an Internet Draft as a stable repository for discussion and > debate. Just like the EDNS0 ideas that became RFC 2671. > > as to whether EDNS0 conflated lable length >255 octets > -AND- DNS UDP packets >512 bytes should be answered by > the author. One could also quote chapter/verse from > the RFC. > > my feeble recollection was that EDNS0 was primarily to > extend the number of flags since we were down to two bits. > Once new flags existed, it became possible to signal divergent > capabilities - and as Paul has already said, negotiation for > label lengths larger than 255 octets has not been seen as a > high value proposition. on the other hand, negotiation for > UDP packet sizes larger than 512 bytes has proven useful. And bit-string labels were a disaster as they required all the parent servers as well any other servers involved in servicing the request to understand bit-string labels. Mark > --bill -- 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 Sat Oct 11 16: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 6B9CC3A67C0; Sat, 11 Oct 2008 16:13:02 -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 d0aNKADhw5yJ; Sat, 11 Oct 2008 16:13:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 861643A679C; Sat, 11 Oct 2008 16:13:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KonbC-000BKd-Q5 for namedroppers-data@psg.com; Sat, 11 Oct 2008 23:10:14 +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 1Konb4-000BHu-2y for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 23:10:12 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:38633) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:cet1) id 1Konb2-0000lh-2Q (Exim 4.70) (return-path ); Sun, 12 Oct 2008 00:10:04 +0100 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1Konb2-0007gZ-Ns (Exim 4.67) (return-path ); Sun, 12 Oct 2008 00:10:04 +0100 From: Chris Thompson To: Matthew Dempsky Cc: namedroppers@ops.ietf.org Reply-To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Date: 12 Oct 2008 00:10:04 +0100 X-Mailer: Prayer v1.3.0 X-Originating-IP: [131.111.11.225] In-Reply-To: Message-ID: References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> <20081011000445.GA13417@vacation.karoshi.com.> <20081011023306.GA14167@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Oct 11 2008, Matthew Dempsky wrote: >On Fri, Oct 10, 2008 at 7:33 PM, wrote: >> nope - EDNS changed that requirement. EDNS was defined >> in an IETF RFC. > >You miss the point. There was a brief, 12-year period between RFC >1034 and RFC 2671 where the most recent RFC limited that DNS packets >sent over UDP to 512 bytes or less. *During this time period*, why >was the proposal to allow new clients and new servers to communicate >using larger packets not a "non-starter" as well? Of course it is not impossible, in *theory*, to imagine negotiated protocol extensions that would allow names longer than (in internal expanded format) 255 octets. But the EDNS extensions to increase UDP packet size have been problematic enough to deploy, in practice, with all sorts of operational issues and work-arounds. And this was just a point-to-point issue, as has been pointed out. You are talking about an end-to-end one. To be clear: pretty much all existing implementations treat the occurrence of a name that expands to >255 octets as a format error, invalidating the whole query/response packet. That is your starting point. -- Chris Thompson Email: cet1@cam.ac.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 Sat Oct 11 16:13: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 E17743A685C; Sat, 11 Oct 2008 16:13:58 -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=[AWL=0.000, 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 Ofx-H5A1clJD; Sat, 11 Oct 2008 16:13:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EE5FF3A679C; Sat, 11 Oct 2008 16:13:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kond7-000BYp-66 for namedroppers-data@psg.com; Sat, 11 Oct 2008 23:12:13 +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 1Kond1-000BNV-0D for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 23:12:10 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m9BN96dG022788; Sat, 11 Oct 2008 23:09:06 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m9BN95kD022787; Sat, 11 Oct 2008 23:09:05 GMT Date: Sat, 11 Oct 2008 23:09:05 +0000 From: bmanning@vacation.karoshi.com To: Mark Andrews Cc: bmanning@vacation.karoshi.com, Matthew Dempsky , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Message-ID: <20081011230905.GA22754@vacation.karoshi.com.> References: <20081011223853.GB21500@vacation.karoshi.com.> <200810112254.m9BMshiH042286@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200810112254.m9BMshiH042286@drugs.dv.isc.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sun, Oct 12, 2008 at 09:54:43AM +1100, Mark Andrews wrote: > > > as to whether EDNS0 conflated lable length >255 octets > > -AND- DNS UDP packets >512 bytes should be answered by > > the author. One could also quote chapter/verse from > > the RFC. > > > > my feeble recollection was that EDNS0 was primarily to > > extend the number of flags since we were down to two bits. > > Once new flags existed, it became possible to signal divergent > > capabilities - and as Paul has already said, negotiation for > > label lengths larger than 255 octets has not been seen as a > > high value proposition. on the other hand, negotiation for > > UDP packet sizes larger than 512 bytes has proven useful. > > And bit-string labels were a disaster as they required all the > parent servers as well any other servers involved in servicing > the request to understand bit-string labels. > > Mark actually, bit-strings were one of the reasons we tested the 255 limit... 128 bits in a v6 address, separated by "." == 256 bits... no room left for the ip6.int anchor. But no doubt Olafur remembers this better than I - I do remember hashing this out w/ him in some hallway conversation there were implementations at the time which never thought anything approching 255 would ever exist. :) and last I checked, there are still deployments of said code... --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 Oct 11 16:14: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 CFAA23A67DB; Sat, 11 Oct 2008 16:14:37 -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.018, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 EzWBPYufXJxS; Sat, 11 Oct 2008 16:14:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DD8943A679C; Sat, 11 Oct 2008 16:14:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KondU-000Bbv-8w for namedroppers-data@psg.com; Sat, 11 Oct 2008 23:12:36 +0000 Received: from [209.85.198.238] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KondP-000BbO-CQ for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 23:12:33 +0000 Received: by rv-out-0506.google.com with SMTP id b25so963008rvf.41 for ; Sat, 11 Oct 2008 16:12:31 -0700 (PDT) Received: by 10.141.153.16 with SMTP id f16mr1829723rvo.17.1223766751235; Sat, 11 Oct 2008 16:12:31 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Sat, 11 Oct 2008 16:12:31 -0700 (PDT) Message-ID: Date: Sat, 11 Oct 2008 16:12:31 -0700 From: "Matthew Dempsky" To: "Eric Rescorla" Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Cc: "Kevin Darcy" , namedroppers@ops.ietf.org In-Reply-To: <20081011215903.A3A136BE02F@kilo.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> <20081011215903.A3A136BE02F@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sat, Oct 11, 2008 at 2:59 PM, Eric Rescorla wrote: > Is the suggestion that DNSCurve should be made an RFC? If so, it > seems to me that a clear prerequisite to that discussion would be > the existence of DNSCurve I-D. Yes. I've been working on a DNSCurve Internet-Draft since it was brought up on Thursday, and I hope to have a publicly available draft soon. > Barring that, why exactly are we having a discussion about the > practicality of a specific design decision in DNSCurve? I initially brought it up because I wanted to know if anyone knew of *operational* issues with these limitations. I was well aware that the RFCs limited names to 255 bytes. Did Bill Manning, Kevin Darcy, or anyone else think I just coincidentally picked this number to ask about? I hoped that some DNS implementors might be subscribed to this mailing list and able to share specific knowledge of their implementations' limitations. E.g., I know OpenBSD's relayd software that supports load-balancing DNS queries does not inspect DNS packets past the 20 byte header, so it can handle TXT format DNSCurve queries that use names greater than 255 bytes. Can anyone speak on how common it is for other firewalls to reject packets with names greater than 255 bytes and whether its possible for administrators to disable this behavior for these firewalls? Can anyone suggest a better mailing list to ask such a question? -- to unsubscribe send a message to namedroppers-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 Oct 11 16:15: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 414F43A67DB; Sat, 11 Oct 2008 16:15:26 -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=[AWL=0.000, 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 sywdfjNhdG6u; Sat, 11 Oct 2008 16:15:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 71F173A679C; Sat, 11 Oct 2008 16:15:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoneQ-000BkO-03 for namedroppers-data@psg.com; Sat, 11 Oct 2008 23:13: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 1KoneK-000BX9-CX for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 23:13: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 m9BNAfdG022798; Sat, 11 Oct 2008 23:10:41 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m9BNAf8P022797; Sat, 11 Oct 2008 23:10:41 GMT Date: Sat, 11 Oct 2008 23:10:41 +0000 From: bmanning@vacation.karoshi.com To: Matthew Dempsky Cc: bmanning@vacation.karoshi.com, Mark Andrews , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Message-ID: <20081011231041.GB22754@vacation.karoshi.com.> References: <20081011153623.GB19624@vacation.karoshi.com.> <200810112140.m9BLeo0e041538@drugs.dv.isc.org> <20081011223853.GB21500@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 Sat, Oct 11, 2008 at 03:49:05PM -0700, Matthew Dempsky wrote: > On Sat, Oct 11, 2008 at 3:38 PM, wrote: > > label lengths larger than 255 octets > > I have consistently asked about *names* larger than 255 bytes. It's > even in the subject line of your latest email still. indeed - thank you for the correction. > DNSCurve only uses labels up to 53 bytes in length. why only 53 bytes? --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 Oct 11 16:22: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 C197C3A679C; Sat, 11 Oct 2008 16:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 5531v8SPT9IQ; Sat, 11 Oct 2008 16:22:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EBE453A67D1; Sat, 11 Oct 2008 16:22:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KonjF-000CQe-L1 for namedroppers-data@psg.com; Sat, 11 Oct 2008 23:18:33 +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 1KonjA-000CQ1-RI for namedroppers@ops.ietf.org; Sat, 11 Oct 2008 23:18:31 +0000 Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 86C156BE34B; Sat, 11 Oct 2008 16:18:27 -0700 (PDT) Date: Sat, 11 Oct 2008 16:18:27 -0700 From: Eric Rescorla To: "Matthew Dempsky" Cc: "Eric Rescorla" , "Kevin Darcy" , namedroppers@ops.ietf.org Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? In-Reply-To: References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> <20081011215903.A3A136BE02F@kilo.rtfm.com> 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: <20081011231827.86C156BE34B@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Sat, 11 Oct 2008 16:12:31 -0700, Matthew Dempsky wrote: > > On Sat, Oct 11, 2008 at 2:59 PM, Eric Rescorla wrote: > > Is the suggestion that DNSCurve should be made an RFC? If so, it > > seems to me that a clear prerequisite to that discussion would be > > the existence of DNSCurve I-D. > > Yes. I've been working on a DNSCurve Internet-Draft since it was > brought up on Thursday, and I hope to have a publicly available draft > soon. Good. I look forward to reading the draft. -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 Sat Oct 11 17: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 B32F73A659B; Sat, 11 Oct 2008 17:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.144 X-Spam-Level: X-Spam-Status: No, score=0.144 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 wFtLiYIEna1u; Sat, 11 Oct 2008 17:19:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EA5403A67D2; Sat, 11 Oct 2008 17:19:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoobI-000IHq-AU for namedroppers-data@psg.com; Sun, 12 Oct 2008 00:14:24 +0000 Received: from [209.85.198.227] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoobC-000IHB-HA for namedroppers@ops.ietf.org; Sun, 12 Oct 2008 00:14:21 +0000 Received: by rv-out-0506.google.com with SMTP id b25so973710rvf.41 for ; Sat, 11 Oct 2008 17:14:17 -0700 (PDT) Received: by 10.140.166.21 with SMTP id o21mr2450752rve.254.1223770457264; Sat, 11 Oct 2008 17:14:17 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Sat, 11 Oct 2008 17:14:17 -0700 (PDT) Message-ID: Date: Sat, 11 Oct 2008 17:14:17 -0700 From: "Matthew Dempsky" To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> <20081011000445.GA13417@vacation.karoshi.com.> <20081011023306.GA14167@vacation.karoshi.com.> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sat, Oct 11, 2008 at 4:10 PM, Chris Thompson wrote: > And this was just a point-to-point issue, as has been pointed > out. You are talking about an end-to-end one. I think I misunderstood these terms at first. "hop" means a DNS query packet from one host to another and the DNS response packet in the other direction; "point-to-point" means something spanning a single "hop"; "end-to-end" means something spanning multiple "hops". Is this right? (I was still thinking of these terms in the layer 2/3 sense.) Assuming my understanding of this terminology is correct, then DNSCurve is only intended for use in "point-to-point" contexts as well. It does not require "end-to-end" support for names >255 bytes. -- to unsubscribe send a message to namedroppers-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 Oct 11 17:51: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 11B2C3A659B; Sat, 11 Oct 2008 17:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.143 X-Spam-Level: X-Spam-Status: No, score=0.143 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 2bMZNDCzAAWs; Sat, 11 Oct 2008 17:51:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4E71E3A679C; Sat, 11 Oct 2008 17:51:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kop8o-000NLJ-98 for namedroppers-data@psg.com; Sun, 12 Oct 2008 00:49:02 +0000 Received: from [209.85.198.229] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kop8j-000NKj-7O for namedroppers@ops.ietf.org; Sun, 12 Oct 2008 00:48:59 +0000 Received: by rv-out-0506.google.com with SMTP id b25so979423rvf.41 for ; Sat, 11 Oct 2008 17:48:56 -0700 (PDT) Received: by 10.141.123.4 with SMTP id a4mr2478869rvn.172.1223772536158; Sat, 11 Oct 2008 17:48:56 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Sat, 11 Oct 2008 17:48:56 -0700 (PDT) Message-ID: Date: Sat, 11 Oct 2008 17:48:56 -0700 From: "Matthew Dempsky" To: bmanning@vacation.karoshi.com Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Cc: "Mark Andrews" , "Paul Vixie" , namedroppers@ops.ietf.org In-Reply-To: <20081011231041.GB22754@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081011153623.GB19624@vacation.karoshi.com.> <200810112140.m9BLeo0e041538@drugs.dv.isc.org> <20081011223853.GB21500@vacation.karoshi.com.> <20081011231041.GB22754@vacation.karoshi.com.> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sat, Oct 11, 2008 at 4:10 PM, wrote: > On Sat, Oct 11, 2008 at 03:49:05PM -0700, Matthew Dempsky wrote: >> DNSCurve only uses labels up to 53 bytes in length. > > why only 53 bytes? Not sure, that's just what the current spec says. The TXT format for queries could use labels up to 63 bytes, but the difference would be negligible for most packets. It might save a byte or two of space. People concerned about the space savings, though, would gain more by switching to the streamlined format though. However, please don't misunderstand my statement to mean users cannot use DNSCurve to safely query names that contain labels longer than 53 bytes. -- to unsubscribe send a message to namedroppers-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 Oct 11 18:45: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 5AD013A67D2; Sat, 11 Oct 2008 18:45:24 -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 R6n-9Pa3Flyr; Sat, 11 Oct 2008 18:45:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 821FB3A659B; Sat, 11 Oct 2008 18:45:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KopxE-0002wh-IL for namedroppers-data@psg.com; Sun, 12 Oct 2008 01:41:08 +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 1Kopx6-0002no-VX for namedroppers@ops.ietf.org; Sun, 12 Oct 2008 01:41:05 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m9C1c7dG023644; Sun, 12 Oct 2008 01:38:07 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m9C1c7q4023643; Sun, 12 Oct 2008 01:38:07 GMT Date: Sun, 12 Oct 2008 01:38:07 +0000 From: bmanning@vacation.karoshi.com To: Matthew Dempsky Cc: bmanning@vacation.karoshi.com, Mark Andrews , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Message-ID: <20081012013807.GA23611@vacation.karoshi.com.> References: <20081011153623.GB19624@vacation.karoshi.com.> <200810112140.m9BLeo0e041538@drugs.dv.isc.org> <20081011223853.GB21500@vacation.karoshi.com.> <20081011231041.GB22754@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 Sat, Oct 11, 2008 at 05:48:56PM -0700, Matthew Dempsky wrote: > On Sat, Oct 11, 2008 at 4:10 PM, wrote: > > On Sat, Oct 11, 2008 at 03:49:05PM -0700, Matthew Dempsky wrote: > >> DNSCurve only uses labels up to 53 bytes in length. > > > > why only 53 bytes? > > Not sure, that's just what the current spec says. The TXT format for > queries could use labels up to 63 bytes, but the difference would be > negligible for most packets. It might save a byte or two of space. > People concerned about the space savings, though, would gain more by > switching to the streamlined format though. my copy of the DNS spec sez lables may not exeed 64 bytes. where in the spec does it say 53 bytes? > However, please don't misunderstand my statement to mean users cannot > use DNSCurve to safely query names that contain labels longer than 53 > bytes. i have no idea what DNSCurve will let people do. waiting to see the DNSCurve spec. --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 Oct 11 19:14: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 293D63A67D2; Sat, 11 Oct 2008 19:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.142 X-Spam-Level: X-Spam-Status: No, score=0.142 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 bNUypq63z5Ju; Sat, 11 Oct 2008 19:14:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 49EDD3A659B; Sat, 11 Oct 2008 19:14:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoqQn-0006Lr-S8 for namedroppers-data@psg.com; Sun, 12 Oct 2008 02:11:41 +0000 Received: from [209.85.198.224] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoqQi-0006LQ-6Y for namedroppers@ops.ietf.org; Sun, 12 Oct 2008 02:11:39 +0000 Received: by rv-out-0506.google.com with SMTP id b25so993487rvf.41 for ; Sat, 11 Oct 2008 19:11:33 -0700 (PDT) Received: by 10.140.193.16 with SMTP id q16mr2516520rvf.173.1223777493610; Sat, 11 Oct 2008 19:11:33 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Sat, 11 Oct 2008 19:11:33 -0700 (PDT) Message-ID: Date: Sat, 11 Oct 2008 19:11:33 -0700 From: "Matthew Dempsky" To: bmanning@vacation.karoshi.com Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Cc: "Mark Andrews" , "Paul Vixie" , namedroppers@ops.ietf.org In-Reply-To: <20081012013807.GA23611@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081011153623.GB19624@vacation.karoshi.com.> <200810112140.m9BLeo0e041538@drugs.dv.isc.org> <20081011223853.GB21500@vacation.karoshi.com.> <20081011231041.GB22754@vacation.karoshi.com.> <20081012013807.GA23611@vacation.karoshi.com.> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sat, Oct 11, 2008 at 6:38 PM, wrote: > my copy of the DNS spec sez lables may not exeed 64 bytes. > where in the spec does it say 53 bytes? Sorry, by "the current spec" I meant "the current [DNSCurve] spec". > i have no idea what DNSCurve will let people do. > waiting to see the DNSCurve spec. No need to wait. If you go to http://dnscurve.org/impl.html, you can find the most relevant details already. -- to unsubscribe send a message to namedroppers-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 Oct 11 20:45: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 65F7B3A6827; Sat, 11 Oct 2008 20:45:37 -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 WJBUcN6JL-IF; Sat, 11 Oct 2008 20:45:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 18D213A680E; Sat, 11 Oct 2008 20:45:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Korp9-000FJn-Qb for namedroppers-data@psg.com; Sun, 12 Oct 2008 03:40: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 1Korp2-000FA8-V2 for namedroppers@ops.ietf.org; Sun, 12 Oct 2008 03:40:52 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m9C3brdG024269; Sun, 12 Oct 2008 03:37:53 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m9C3bo6n024268; Sun, 12 Oct 2008 03:37:50 GMT Date: Sun, 12 Oct 2008 03:37:50 +0000 From: bmanning@vacation.karoshi.com To: Matthew Dempsky Cc: bmanning@vacation.karoshi.com, Mark Andrews , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Message-ID: <20081012033750.GA24235@vacation.karoshi.com.> References: <20081011153623.GB19624@vacation.karoshi.com.> <200810112140.m9BLeo0e041538@drugs.dv.isc.org> <20081011223853.GB21500@vacation.karoshi.com.> <20081011231041.GB22754@vacation.karoshi.com.> <20081012013807.GA23611@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 Sat, Oct 11, 2008 at 07:11:33PM -0700, Matthew Dempsky wrote: > On Sat, Oct 11, 2008 at 6:38 PM, wrote: > > my copy of the DNS spec sez lables may not exeed 64 bytes. > > where in the spec does it say 53 bytes? > > Sorry, by "the current spec" I meant "the current [DNSCurve] spec". so DNSCurve is not compliant w/ the DNS spec. thats useful to know. > > > i have no idea what DNSCurve will let people do. > > waiting to see the DNSCurve spec. > > No need to wait. If you go to http://dnscurve.org/impl.html, you can > find the most relevant details already. a web page of "the most relevent details" does not a spec make. I'll wait, like ekr, for an ID on DNSCurve before continuing this discussion on an IETF mailing list. If there is a non-IETF mailing list where DNSCurve is being discussed and the default rule is the web page snapshot o' the day is the working spec - I'd like to know where that is. from what little can be gleaned from the URL provided, this looks like interesting technology. No one has yet answered one of my questions about DNSCurve and I'd like to ask it in a more relevent fora. --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 Oct 11 21:55: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 36B813A67A6; Sat, 11 Oct 2008 21:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.141 X-Spam-Level: X-Spam-Status: No, score=0.141 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 NhmjJkcskuQa; Sat, 11 Oct 2008 21:55:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 349843A67EC; Sat, 11 Oct 2008 21:55:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kosu5-000MdU-VC for namedroppers-data@psg.com; Sun, 12 Oct 2008 04:50:05 +0000 Received: from [209.85.198.230] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kostz-000McM-Sl for namedroppers@ops.ietf.org; Sun, 12 Oct 2008 04:50:03 +0000 Received: by rv-out-0506.google.com with SMTP id b25so1019833rvf.41 for ; Sat, 11 Oct 2008 21:49:58 -0700 (PDT) Received: by 10.141.198.2 with SMTP id a2mr2584483rvq.219.1223786998748; Sat, 11 Oct 2008 21:49:58 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Sat, 11 Oct 2008 21:49:58 -0700 (PDT) Message-ID: Date: Sat, 11 Oct 2008 21:49:58 -0700 From: "Matthew Dempsky" To: bmanning@vacation.karoshi.com Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Cc: "Mark Andrews" , "Paul Vixie" , namedroppers@ops.ietf.org In-Reply-To: <20081012033750.GA24235@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081011153623.GB19624@vacation.karoshi.com.> <200810112140.m9BLeo0e041538@drugs.dv.isc.org> <20081011223853.GB21500@vacation.karoshi.com.> <20081011231041.GB22754@vacation.karoshi.com.> <20081012013807.GA23611@vacation.karoshi.com.> <20081012033750.GA24235@vacation.karoshi.com.> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sat, Oct 11, 2008 at 8:37 PM, wrote: > so DNSCurve is not compliant w/ the DNS spec. > thats useful to know. DNSCurve occasionally needs safe "point-to-point" transit for DNS packets longer than 512 bytes and/or containing names longer than 255 bytes in the questions section (which is exactly the motivation for the question starting this thread). However, otherwise TXT format packets are compliant with RFC 1034 and 1035. In what way do you think DNSCurve is not compliant with the DNS spec? Did you miss when I said: However, please don't misunderstand my statement to mean users cannot use DNSCurve to safely query names that contain labels longer than 53 bytes. (I also have to apologize that I misstated; it does not use labels longer than 54 bytes, not 53 bytes. The above statement still applies otherwise.) > from what little can be gleaned from the URL provided, this > looks like interesting technology. No one has yet answered > one of my questions about DNSCurve and I'd like to ask it > in a more relevent fora. I'm happy to answer any DNSCurve questions you still have, here or over private email. -- to unsubscribe send a message to namedroppers-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 Oct 11 22:33: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 51BA83A67F2; Sat, 11 Oct 2008 22:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 lVBvcVIpwKIb; Sat, 11 Oct 2008 22:33:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 725453A677C; Sat, 11 Oct 2008 22:33:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KotY2-00013F-MF for namedroppers-data@psg.com; Sun, 12 Oct 2008 05:31:22 +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 1KotXx-00012r-SE for namedroppers@ops.ietf.org; Sun, 12 Oct 2008 05:31:20 +0000 Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 9FF5C6BED9B; Sat, 11 Oct 2008 22:31:16 -0700 (PDT) Date: Sat, 11 Oct 2008 22:31:16 -0700 From: Eric Rescorla To: "Matthew Dempsky" Cc: bmanning@vacation.karoshi.com, "Mark Andrews" , "Paul Vixie" , namedroppers@ops.ietf.org Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? In-Reply-To: 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: <20081012053116.9FF5C6BED9B@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Sat, 11 Oct 2008 21:49:58 -0700, Matthew Dempsky wrote: > > from what little can be gleaned from the URL provided, this > > looks like interesting technology. No one has yet answered > > one of my questions about DNSCurve and I'd like to ask it > > in a more relevent fora. > > I'm happy to answer any DNSCurve questions you still have, here or > over private email. Rather than playing 20 questions about DNSCurve, it would be far more useful for those who want the WG to consider it to describe what architectural properties they are trying to achieve. With that in hand, we can have a discussion about whether those properties are ones the WG is interested in pursuing. If the consensus of the WG is that some different set of architectural properties than those provided by DNSSEC are desirable, *then* we can have a discussion about what protocol mechanisms best achieve them. -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 Oct 12 03:36: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 39F693A697E; Sun, 12 Oct 2008 03:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.902 X-Spam-Level: ** X-Spam-Status: No, score=2.902 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Np38lDeqSLav; Sun, 12 Oct 2008 03:36:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D77A3A695F; Sun, 12 Oct 2008 03:36:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoyDR-0006dL-94 for namedroppers-data@psg.com; Sun, 12 Oct 2008 10:30:25 +0000 Received: from [195.188.213.5] (helo=smtp-out2.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoyDM-0006cr-47 for namedroppers@ops.ietf.org; Sun, 12 Oct 2008 10:30:22 +0000 Received: from [172.23.170.143] (helo=anti-virus02-10) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1KoyDJ-00066K-9l for namedroppers@ops.ietf.org; Sun, 12 Oct 2008 11:30:17 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with esmtpa (Exim 4.52) id 1KoyDE-0005ro-13 for namedroppers@ops.ietf.org; Sun, 12 Oct 2008 11:30:12 +0100 Message-ID: From: "George Barwood" To: Subject: [dnsext] draft-barwood-dnsext-fr-resolver-mitigations-03 Date: Sun, 12 Oct 2008 11:30:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I have revised my draft at http://www.ietf.org/internet-drafts/draft-barwood-dnsext-fr-resolver-mitigations-03.txt ( Latest version at : https://datatracker.ietf.org/drafts/draft-barwood-dnsext-fr-resolver-mitigations/ ) Abstract: Describes mitigations against spoofing attacks on DNS, including: (1) Repeating the query, including techniques for handling non-deterministic responses. (2) Prepending a random nonce to the question where a referral is probable. (3) Estimating the entropy available, taking into account (a) Observed packets with incorrect IDs. (b) Records where the owner name does not match the question. (c) The previous content of the cache. New is that port randomization must not be combined with query repetition, and a revised treatment of convergence of non-determistic responsese that preserves RRset integrity ( although this can be spoofed ). My point of view is that cache policy ( as described by Nicholas Weaver ) is not the cleanest approach, and that simple repetition, while boring, is the best approach for a general purpose recursive resolver. Other tricks ( such as 0x20, port randomization, a random nonce ) can be used to reduce the number of queries needed, but are not essential. George Barwood -- to unsubscribe send a message to namedroppers-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 Oct 12 03:58: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 1C5C33A68D5; Sun, 12 Oct 2008 03:58:46 -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 P1MUi7+Uy85a; Sun, 12 Oct 2008 03:58:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 063953A68BF; Sun, 12 Oct 2008 03:58:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoyZW-0008o2-C4 for namedroppers-data@psg.com; Sun, 12 Oct 2008 10:53:14 +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 1KoyZL-0008lS-0I for namedroppers@ops.ietf.org; Sun, 12 Oct 2008 10:53: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 1KoyZF-00035q-IV for namedroppers@ops.ietf.org; Sun, 12 Oct 2008 12:52:57 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 529F353CCF; Sun, 12 Oct 2008 12:53:03 +0200 (CEST) Date: Sun, 12 Oct 2008 12:53:02 +0200 From: bert hubert To: Matthew Dempsky Cc: Eric Rescorla , Kevin Darcy , namedroppers@ops.ietf.org Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? Message-ID: <20081012105302.GC3979@outpost.ds9a.nl> References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> <20081011215903.A3A136BE02F@kilo.rtfm.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 Sat, Oct 11, 2008 at 04:12:31PM -0700, Matthew Dempsky wrote: > I initially brought it up because I wanted to know if anyone knew of > *operational* issues with these limitations. I was well aware that > the RFCs limited names to 255 bytes. Did Bill Manning, Kevin Darcy, > or anyone else think I just coincidentally picked this number to ask > about? In practice, and this is deviating from DNSEXT territory, almost anything that is a tiny bit 'special' a DNS packet will cause widespread failure. This applies both to DNSSEC's huge (4kbyte) packets and 'new flags', as well as to any DNSCURVE packets with >255 byte names. See for example the recent DNSSEC report on common routers/modems, plus heed http://blog.netherlabs.nl/articles/2006/04/13/the-general-mediocrity-of-the-world (scroll down to 'go read the rfc already'). DNSCURVE <255 bytes names should not trigger anything special as far as I can see. 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 Sun Oct 12 08:59: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 C0B7F3A69CF; Sun, 12 Oct 2008 08:59:54 -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 pWt00NoyErIY; Sun, 12 Oct 2008 08:59:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 93B8E3A69B1; Sun, 12 Oct 2008 08:59:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kp3FQ-000Frh-An for namedroppers-data@psg.com; Sun, 12 Oct 2008 15:52:48 +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 1Kp3FL-000FqQ-Fu for namedroppers@ops.ietf.org; Sun, 12 Oct 2008 15:52:45 +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 1Kp3F0-0000Od-Mw; Sun, 12 Oct 2008 17:52:22 +0200 Received: from fweimer by bfk.de with local id 1Kp3FA-00007u-MG; Sun, 12 Oct 2008 17:52:32 +0200 To: "Matthew Dempsky" Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? References: From: Florian Weimer Date: Sun, 12 Oct 2008 17:52:32 +0200 In-Reply-To: (Matthew Dempsky's message of "Fri, 10 Oct 2008 15:26:42 -0700") Message-ID: <82hc7hbykf.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: * Matthew Dempsky: > Is anyone aware of any common firewalls that reject DNS packets (or > all UDP packets to/from port 53) longer than 512 bytes or DNS packets > that contain domain names longer than 255 bytes? Seriously, use a different UDP port. As an added bonus, you don't have to use a separate IP address for the reverse proxy. --=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 Sun Oct 12 22:42: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 F33883A6A27; Sun, 12 Oct 2008 22:42:19 -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 nHOg9rWh4lcB; Sun, 12 Oct 2008 22:42:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C58E63A69AC; Sun, 12 Oct 2008 22:42:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpG6A-000AUe-LP for namedroppers-data@psg.com; Mon, 13 Oct 2008 05:36:06 +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 1KpG64-000AT0-2G for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 05:36:04 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 1635633C1E; Mon, 13 Oct 2008 06:37:21 +0100 (BST) Message-ID: <48F2DE42.1060209@links.org> Date: Mon, 13 Oct 2008 06:36: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: Edward Lewis CC: Michael StJohns , namedroppers@ops.ietf.org Subject: Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> In-Reply-To: X-Enigmail-Version: 0.95.7 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: >> ps - anyone want to take a whack at documenting how various applications >> should handle various DNSSEC outcomes? The ones I can think of off >> the top >> of my head that should be done are: SMTP (both submitter to MTA and MTA >> to MTA), HTTP (what the browser does *before* the user gets involved - >> pretty sure just exposing the DNSSEC resolution state isn't the best >> answer), SSH, peer-to-peer. > > DNSSEC was built ("repeat chorus") to stem cache poisoning, i.e., > protect the admission of DNS data to the cache. It wasn't meant to > protect the applications making use of the data. If an application > wants to act like a cache with a verifier, fine. Then it asks for > everything with CD, gets as much raw data, and does it's own check. If > it can't reach the source (because of firewalls, forwarders, etc.,), > well it's up a creek anyway. > > To an application - either their is an answer in DNS or not. The grey > area is too hard to make use of, a general solution isn't useful. It's > like with lame delegation testing in the reverse map. There are a lot of > screw ups there, a lot follow certain pathologies that, even common, > make up a small percentage of the total problems. It isn't worth trying > to diagnose for the few predictable misconfigurations. Surely the point is that DNSSEC changes the possible answers from: 1. RR exists and here it is. 2. RR does not exist. 3. Server not reachable (or otherwise broken). to 1. RR exists and here it is. 2. RR does not exist. 3. RR exists but is broken in some way. 4. Server not reachable (or otherwise broken). The question is: what should applications do for state 3? My answer would be to treat it like state 4, I think, but there's room for debate. Cheers, Ben. -- 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 Oct 13 04:49: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 EF01528C0CE; Mon, 13 Oct 2008 04:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[AWL=-0.796, 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 ioLIHj2wq3jm; Mon, 13 Oct 2008 04:49:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8A5DF28B56A; Mon, 13 Oct 2008 04:49:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpLkt-000HQ3-Is for namedroppers-data@psg.com; Mon, 13 Oct 2008 11:38:31 +0000 Received: from [76.96.30.56] (helo=QMTA06.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpLki-000HP8-5t for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 11:38:27 +0000 Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id SBAX1a0041GXsucA6BeK0w; Mon, 13 Oct 2008 11:38:19 +0000 Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id SBeG1a0042P9w058TBeG8h; Mon, 13 Oct 2008 11:38:18 +0000 X-Authority-Analysis: v=1.0 c=1 a=dmE0DmLRt_UA:10 a=-5nm-dUE1uIA:10 a=hqaSkvWfAAAA:8 a=OzSqGtDSAAAA:8 a=wqbdNty1zbVcSD4603AA:9 a=gLl_VnppeIIuTdCRfu0A:7 a=QCny88gLYKFV97fMi5OhdfwdHVgA:4 a=Ly75NXeMEyIA:10 a=B-GU5LaGV7AA:10 a=8peU3wBK19oA:10 a=h9s5Ru71U4oA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Oct 2008 07:38:16 -0400 To: Ben Laurie ,Edward Lewis From: Michael StJohns Subject: Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: namedroppers@ops.ietf.org In-Reply-To: <48F2DE42.1060209@links.org> References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: At 01:36 AM 10/13/2008, Ben Laurie wrote: >Edward Lewis wrote: >>> ps - anyone want to take a whack at documenting how various applications >>> should handle various DNSSEC outcomes? The ones I can think of off >>> the top >>> of my head that should be done are: SMTP (both submitter to MTA and MTA >>> to MTA), HTTP (what the browser does *before* the user gets involved - >>> pretty sure just exposing the DNSSEC resolution state isn't the best >>> answer), SSH, peer-to-peer. >> >> DNSSEC was built ("repeat chorus") to stem cache poisoning, i.e., >> protect the admission of DNS data to the cache. It wasn't meant to >> protect the applications making use of the data. If an application >> wants to act like a cache with a verifier, fine. Then it asks for >> everything with CD, gets as much raw data, and does it's own check. If >> it can't reach the source (because of firewalls, forwarders, etc.,), >> well it's up a creek anyway. >> >> To an application - either their is an answer in DNS or not. The grey >> area is too hard to make use of, a general solution isn't useful. It's >> like with lame delegation testing in the reverse map. There are a lot of >> screw ups there, a lot follow certain pathologies that, even common, >> make up a small percentage of the total problems. It isn't worth trying >> to diagnose for the few predictable misconfigurations. > >Surely the point is that DNSSEC changes the possible answers from: > >1. RR exists and here it is. >2. RR does not exist. >3. Server not reachable (or otherwise broken). > >to > >1. RR exists and here it is. >2. RR does not exist. >3. RR exists but is broken in some way. >4. Server not reachable (or otherwise broken). I don't think its this simple... really. Basic DNS has the 3 answers in your first group - although I'd categorize the last one as "I can't make any determination about whether or not the answer exists for any of a number of reasons" - what Marc describes as "indeterminate". DNSSEC add 4 (actually maybe even 5) security states that are somewhat orthogonal to the DNS states: 1. Unknown - I've got no superior trust anchor so I can't make any definite statement about whether or not the answer is secure. 2. Secure - I've gotten a chain of signatures covering which allow me to determine the answer is securely valid. 3. Unsecure - I've gotten a chain of signature plus certain other data which tells me in a secure manner that I have no security information about the final answer. 4. Bogus - I've gotten all the information I've asked for from the system, but I was unable to prove the security - bad signatures, missing keys, etc. 5. Insecure transition from secure - I've got valid signatures as far as a CNAME or DNAME, but the CNAME or DNAME point into an area of the tree with Unknown trust. Those three DNS states matrix (somewhat) with the 5 security states to actually give you 15 distinct intersections - but a number of those substates collapse into each other. (E.g., secure/exist, secure/non-exist, bogus/exist, bogus/non-exist, any/indeterminate, unsecure/any, unknown/any). You might also consider that DNSSEC extends the original 3 dns resolution states to 4 by adding a "data determinate/dnssec indeterminate" - but those may collapse mostly into the bogus entries. I'm not trying to be difficult here - but considering each of these intersections and figuring out what to do for each application seems to be a reasonable approach. Taking specifically email MTA-MTA interactions. It seems to me that you'd treat (secure | unsecure | indeterminate)/exist as states where you'd allow the MTA to connect and deliver, that you'd treat bogus/any as a reportable security error condition and not deliver (- but would you retry?), that you'd treat any/indeterminate as a retry error condition (e.g. temporary failure), and that you'd treat secure/non-exist as a permanent mail delivery failure. What would you do with unknown/non-exist - would you treat as a permanent failure or retry after a long or short interval? Going back to the DNAME/CNAME stuff - DNSSEC provides a mechanism to indicate to a resolver securely that a chain of trust is being turned off (is ending securely?) (secure delegation to an unsecure zone). CNAME and DNAME do not have any way of indicating the expected security state of the zone to which they point. It seems to me that an application might actually care about this when trying to figure out what to do. Let's pretend for a moment that DNAME has a way of indicating its target status as one of either - must be secure, or don't care. If the must be secure bit is set and the target can't be validated (either as secure or as delegated to unsecure), then the answer for the whole chain is bogus. If the bit isn't set, then security resolution for the target restarts with the target - e.g. if the target is under a trust anchor then it must validate or the chain is bogus. Obviously, this bit doesn't exist - should it? And finishing up with MTA-MTA - if I use the current model and have a lookup chain to a DNAME that validates, but that the target of the DNAME isn't under a trust anchor - should I deliver the mail? If so, why? If not, why? What do I do if the MX look up is secure, but the A lookup is unsecure or unknown? Vice versa? What markings if any should go on an email (header notation) to indicate a forwarding routing was based on data with an "unsecure" or "unknown" trust state? or if the MX was secure and the A wasn't or vice versa? Should a downstream receiver do anything special for messages marked as above? Would this ever be a reasonable filtering criteria? >The question is: what should applications do for state 3? My answer >would be to treat it like state 4, I think, but there's room for debate. > >Cheers, > >Ben. > >-- >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 Oct 13 05:23: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 448623A6BA1; Mon, 13 Oct 2008 05:23:08 -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 IKMqJnVjt1nd; Mon, 13 Oct 2008 05:23:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 492AE3A6B9D; Mon, 13 Oct 2008 05:23:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpMMI-000M5K-54 for namedroppers-data@psg.com; Mon, 13 Oct 2008 12:17:10 +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 1KpMMA-000M4U-Rh for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 12:17:05 +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.3/8.14.3) with ESMTP id m9DCGq03077323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 14:16:53 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <48F33C34.3010901@nlnetlabs.nl> Date: Mon, 13 Oct 2008 14:16:52 +0200 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Michael StJohns CC: Ben Laurie , Edward Lewis , namedroppers@ops.ietf.org Subject: Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 13 Oct 2008 14:16:53 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael, I think it is much simpler than that. The application is interested in what is known with certainty. 1. It is certain the data is valid (secure) 2. It is certain that security checks failed (bogus) 3. whatever (insecure). Thus, your numbers 1, 3, 5 are folded into insecure (or maybe more accurately, 'no security available'). A mail application could deliver 1 and 3, but not 2(bogus). Or it might examine the AD bit on replies and only deliver 1. When a DNAME or CNAME chain crosses a BOGUS entry, the DNAME or CNAME chain result is bogus. When a DNAME or CNAME chain has all items secure, the DNAME or CNAME chain result is secure. All other cases are insecure (i.e. the chain has one insecure element and the other elements are insecure or secure). I do not think a 'must be secure' bit is needed. Only when all items in the chain are secure is the result secure, and does the AD bit get set. Best regards, Wouter Michael StJohns wrote: > At 01:36 AM 10/13/2008, Ben Laurie wrote: >> 1. RR exists and here it is. >> 2. RR does not exist. >> 3. Server not reachable (or otherwise broken). >> >> to >> >> 1. RR exists and here it is. >> 2. RR does not exist. >> 3. RR exists but is broken in some way. >> 4. Server not reachable (or otherwise broken). > > I don't think its this simple... really. > > Basic DNS has the 3 answers in your first group - although I'd categorize the last one as "I can't make any determination about whether or not the answer exists for any of a number of reasons" - what Marc describes as "indeterminate". > > DNSSEC add 4 (actually maybe even 5) security states that are somewhat orthogonal to the DNS states: > > 1. Unknown - I've got no superior trust anchor so I can't make any definite statement about whether or not the answer is secure. > 2. Secure - I've gotten a chain of signatures covering which allow me to determine the answer is securely valid. > 3. Unsecure - I've gotten a chain of signature plus certain other data which tells me in a secure manner that I have no security information about the final answer. > 4. Bogus - I've gotten all the information I've asked for from the system, but I was unable to prove the security - bad signatures, missing keys, etc. > 5. Insecure transition from secure - I've got valid signatures as far as a CNAME or DNAME, but the CNAME or DNAME point into an area of the tree with Unknown trust. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjzPDQACgkQkDLqNwOhpPg4hgCfZJrXXhwSeXgeZiU9W4FZ5Wwi O84AoKnIBWKPbaVGzxeCueQWk5L0WslT =tjtc -----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 Oct 13 05:23: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 881F228C0CE; Mon, 13 Oct 2008 05:23:36 -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 Yu-n-VexwEvl; Mon, 13 Oct 2008 05:23:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A33DF3A6BA0; Mon, 13 Oct 2008 05:23:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpMKj-000LvB-7A for namedroppers-data@psg.com; Mon, 13 Oct 2008 12:15:33 +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 1KpMKa-000LuD-L9 for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 12:15:28 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id C3EEF33C1E; Mon, 13 Oct 2008 13:16:45 +0100 (BST) Message-ID: <48F33BDF.6020304@links.org> Date: Mon, 13 Oct 2008 13:15: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: Michael StJohns CC: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <20081013113946.D7DAA33C1E@mail.links.org> In-Reply-To: <20081013113946.D7DAA33C1E@mail.links.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Michael StJohns wrote: > At 01:36 AM 10/13/2008, Ben Laurie wrote: >> Edward Lewis wrote: >>>> ps - anyone want to take a whack at documenting how various >>>> applications should handle various DNSSEC outcomes? The ones I >>>> can think of off the top of my head that should be done are: >>>> SMTP (both submitter to MTA and MTA to MTA), HTTP (what the >>>> browser does *before* the user gets involved - pretty sure just >>>> exposing the DNSSEC resolution state isn't the best answer), >>>> SSH, peer-to-peer. >>> DNSSEC was built ("repeat chorus") to stem cache poisoning, i.e., >>> protect the admission of DNS data to the cache. It wasn't meant >>> to protect the applications making use of the data. If an >>> application wants to act like a cache with a verifier, fine. >>> Then it asks for everything with CD, gets as much raw data, and >>> does it's own check. If it can't reach the source (because of >>> firewalls, forwarders, etc.,), well it's up a creek anyway. >>> >>> To an application - either their is an answer in DNS or not. The >>> grey area is too hard to make use of, a general solution isn't >>> useful. It's like with lame delegation testing in the reverse >>> map. There are a lot of screw ups there, a lot follow certain >>> pathologies that, even common, make up a small percentage of the >>> total problems. It isn't worth trying to diagnose for the few >>> predictable misconfigurations. >> Surely the point is that DNSSEC changes the possible answers from: >> >> 1. RR exists and here it is. 2. RR does not exist. 3. Server not >> reachable (or otherwise broken). >> >> to >> >> 1. RR exists and here it is. 2. RR does not exist. 3. RR exists but >> is broken in some way. 4. Server not reachable (or otherwise >> broken). > > I don't think its this simple... really. > > Basic DNS has the 3 answers in your first group - although I'd > categorize the last one as "I can't make any determination about > whether or not the answer exists for any of a number of reasons" - > what Marc describes as "indeterminate". > > DNSSEC add 4 (actually maybe even 5) security states that are > somewhat orthogonal to the DNS states: > > 1. Unknown - I've got no superior trust anchor so I can't make any > definite statement about whether or not the answer is secure. > 2. > Secure - I've gotten a chain of signatures covering which allow me to > determine the answer is securely valid. 3. Unsecure - I've gotten a > chain of signature plus certain other data which tells me in a secure > manner that I have no security information about the final answer. 4. > Bogus - I've gotten all the information I've asked for from the > system, but I was unable to prove the security - bad signatures, > missing keys, etc. 5. Insecure transition from secure - I've got > valid signatures as far as a CNAME or DNAME, but the CNAME or DNAME > point into an area of the tree with Unknown trust. I don't quite see the point of state 5 - why treat that differently from 1? (Oh, I do now, having read below more carefully) But you do have a point. > Those three DNS states matrix (somewhat) with the 5 security states > to actually give you 15 distinct intersections - but a number of > those substates collapse into each other. (E.g., secure/exist, > secure/non-exist, bogus/exist, bogus/non-exist, any/indeterminate, > unsecure/any, unknown/any). You might also consider that DNSSEC > extends the original 3 dns resolution states to 4 by adding a "data > determinate/dnssec indeterminate" - but those may collapse mostly > into the bogus entries. We should actually figure out what all the distinct states are, rather than handwave. > I'm not trying to be difficult here - but considering each of these > intersections and figuring out what to do for each application seems > to be a reasonable approach. > > Taking specifically email MTA-MTA interactions. It seems to me that > you'd treat (secure | unsecure | indeterminate)/exist as states where > you'd allow the MTA to connect and deliver, that you'd treat > bogus/any as a reportable security error condition and not deliver (- > but would you retry?), that you'd treat any/indeterminate as a retry > error condition (e.g. temporary failure), and that you'd treat > secure/non-exist as a permanent mail delivery failure. What would > you do with unknown/non-exist - would you treat as a permanent > failure or retry after a long or short interval? As with many security decisions, this would depend on requirements. I can imagine running an MTA in an environment that only wants to trust DNSSEC (or in a mythical future where everything is IPv6, sorry, I mean DNSSEC), and so configuring this to "retry but eventually fail" in the usual way. For most people transitioning to DNSSEC, then I'd treat this as a permanent failure. > > Going back to the DNAME/CNAME stuff - DNSSEC provides a mechanism to > indicate to a resolver securely that a chain of trust is being turned > off (is ending securely?) (secure delegation to an unsecure zone). > CNAME and DNAME do not have any way of indicating the expected > security state of the zone to which they point. It seems to me that > an application might actually care about this when trying to figure > out what to do. Let's pretend for a moment that DNAME has a way of > indicating its target status as one of either - must be secure, or > don't care. If the must be secure bit is set and the target can't be > validated (either as secure or as delegated to unsecure), then the > answer for the whole chain is bogus. If the bit isn't set, then > security resolution for the target restarts with the target - e.g. if > the target is under a trust anchor then it must validate or the chain > is bogus. Obviously, this bit doesn't exist - should it? Interesting question. Perhaps it should. > And finishing up with MTA-MTA - if I use the current model and have a > lookup chain to a DNAME that validates, but that the target of the > DNAME isn't under a trust anchor - should I deliver the mail? If so, > why? If not, why? > > What do I do if the MX look up is secure, but the A lookup is > unsecure or unknown? Vice versa? > > What markings if any should go on an email (header notation) to > indicate a forwarding routing was based on data with an "unsecure" or > "unknown" trust state? or if the MX was secure and the A wasn't or > vice versa? Routing headers aren't very rigidly defined now, so this seems orthogonal. > Should a downstream receiver do anything special for messages marked > as above? Would this ever be a reasonable filtering criteria? > > > >> The question is: what should applications do for state 3? My answer >> would be to treat it like state 4, I think, but there's room for >> debate. >> >> Cheers, >> >> Ben. >> >> -- 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 > > > -- 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 Oct 13 06:48: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 1B39628C11E; Mon, 13 Oct 2008 06:48:03 -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 UIX0gQ3wWPEK; Mon, 13 Oct 2008 06:48:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1D72928C0E9; Mon, 13 Oct 2008 06:48:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpNga-0005Pr-9a for namedroppers-data@psg.com; Mon, 13 Oct 2008 13:42:12 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpNgQ-0005MO-Co for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 13:42:05 +0000 Received: from [192.168.100.15] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 6EF2DC2DAF; Mon, 13 Oct 2008 14:41:54 +0100 (BST) Date: Mon, 13 Oct 2008 14:41:52 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Wouter Wijngaards , Michael StJohns cc: Ben Laurie , Edward Lewis , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Message-ID: In-Reply-To: <48F33C34.3010901@nlnetlabs.nl> References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <48F33C34.3010901@nlnetlabs.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 13 October 2008 14:16:52 +0200 Wouter Wijngaards wrote: > I think it is much simpler than that. The application is interested in > what is known with certainty. > 1. It is certain the data is valid (secure) > 2. It is certain that security checks failed (bogus) > 3. whatever (insecure). One of the merits of Ben's list was it attempted to list the states "as a user might see them" without associating them in the first instance to the workings and terminology of the protocol. >From the user's point of view, I think you (and, I think Ben) have missed at least one. Using your numbering above here is what a DNSSEC aware application might find when looking up the name: 1. We have data, which we know is correct & secure (DNSSEC signatures verify) 2. We have data, which we know is invalid (DNSSEC shows insecure) 3. We have data, but we are uncertain as to the correctness of the data (e.g. no DNSSEC information for that zone, or missing DLV or whatever). 4. We have no data, e.g. we got a SERVFAIL. As I understand, we can't tell this is secure or not (willing to be corrected here). Non-DNSSEC-aware resolver stacks return (3) or (4). As far as I can tell, treating (2) like (4) at the application layer seems sensible (i.e. I can't see any/many applications distinguishing) (*). However, an application might handle (1), (3) and [(2)/(4)] at least as different states (even if only colouring a browser address bar yet another shade of the rainbow). Compatibility reasons suggest that legacy applications (non-DNSSEC aware) get to treat (1) and (3) the same, or every such application will fail when a DNSSEC compliant library is installed. Given evidence to date suggests adoption of DNSSEC will be non-instantaneous, this seems mandatory. (*) interesting nit: state 2 includes secure denial of existence. I am arguing here secure denial of existence gets treated at the application layer just like an insecure failure in every circumstance I can think of. IE, you can spoof a SERVFAIL, DoS the resolver so it times out, or whatever and it will be treated the same way as a guaranteed denial of existence through NSEC/NSEC3 at the application layer. I know there are people who think that maintaining the difference between an authenticated denial and a failure is useful for more than debugging purposes, or we wouldn't have spent so long ensuring NSEC's successor maintained authenticated denial of existence. This implies that they must see a need for (2) and (4) to be different. 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 Oct 13 06:52: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 46A3E3A6947; Mon, 13 Oct 2008 06:52:15 -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 v7IC+ttjX+SP; Mon, 13 Oct 2008 06:52:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4052F3A67E3; Mon, 13 Oct 2008 06:52:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpNlp-00063U-2Q for namedroppers-data@psg.com; Mon, 13 Oct 2008 13:47:37 +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 1KpNla-00062B-MU for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 13:47:29 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2314833C1F; Mon, 13 Oct 2008 14:48:46 +0100 (BST) Message-ID: <48F35170.30900@links.org> Date: Mon, 13 Oct 2008 14:47:28 +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: Wouter Wijngaards , Michael StJohns , Edward Lewis , namedroppers@ops.ietf.org Subject: Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <48F33C34.3010901@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 0.95.7 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: > > > --On 13 October 2008 14:16:52 +0200 Wouter Wijngaards > wrote: > >> I think it is much simpler than that. The application is interested in >> what is known with certainty. >> 1. It is certain the data is valid (secure) >> 2. It is certain that security checks failed (bogus) >> 3. whatever (insecure). > > One of the merits of Ben's list was it attempted to list the states "as > a user might see them" without associating them in the first instance > to the workings and terminology of the protocol. > >> From the user's point of view, I think you (and, I think Ben) have missed > at least one. Using your numbering above here is what a DNSSEC aware > application might find when looking up the name: > > 1. We have data, which we know is correct & secure (DNSSEC signatures > verify) > 2. We have data, which we know is invalid (DNSSEC shows insecure) > 3. We have data, but we are uncertain as to the correctness of the > data (e.g. no DNSSEC information for that zone, or missing DLV > or whatever). > 4. We have no data, e.g. we got a SERVFAIL. As I understand, we can't > tell this is secure or not (willing to be corrected here). > > Non-DNSSEC-aware resolver stacks return (3) or (4). > > As far as I can tell, treating (2) like (4) at the application layer > seems sensible (i.e. I can't see any/many applications distinguishing) (*). > However, an application might handle (1), (3) and [(2)/(4)] at least > as different states (even if only colouring a browser address bar > yet another shade of the rainbow). Compatibility reasons suggest > that legacy applications (non-DNSSEC aware) get to treat (1) and (3) > the same, or every such application will fail when a DNSSEC compliant > library is installed. Given evidence to date suggests adoption of > DNSSEC will be non-instantaneous, this seems mandatory. > > (*) interesting nit: state 2 includes secure denial of existence. I am > arguing here secure denial of existence gets treated at the application > layer just like an insecure failure in every circumstance I can think > of. IE, you can spoof a SERVFAIL, DoS the resolver so it times out, > or whatever and it will be treated the same way as a guaranteed denial > of existence through NSEC/NSEC3 at the application layer. I know there > are people who think that maintaining the difference between an > authenticated denial and a failure is useful for more than debugging > purposes, or we wouldn't have spent so long ensuring NSEC's successor > maintained authenticated denial of existence. This implies that they > must see a need for (2) and (4) to be different. No. If I am delivering mail, and the domain does not exist, I bounce it. If I get SERVFAIL, I hold on to it and try again later. -- 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 Oct 13 06:58: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 6AF4D28C10B; Mon, 13 Oct 2008 06:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[AWL=-0.082, 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 TQrO31RsFPVT; Mon, 13 Oct 2008 06:58:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E6B133A67E3; Mon, 13 Oct 2008 06:58:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpNr6-0006h4-57 for namedroppers-data@psg.com; Mon, 13 Oct 2008 13:53:04 +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 1KpNqt-0006eD-1B for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 13:52:57 +0000 Received: from [192.168.1.101] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m9DDoq66004694; Mon, 13 Oct 2008 09:52:35 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> Date: Mon, 13 Oct 2008 09:45:20 -0400 To: Michael StJohns From: Edward Lewis Subject: CNAME/DNAME - Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: Ben Laurie , Edward Lewis , namedroppers@ops.ietf.org 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: At 7:38 -0400 10/13/08, Michael StJohns wrote: >...CNAME and DNAME do not have any way of indicating the expected security >state of the zone to which they point. ... Yes they do. For X CNAME Y, you can determine the security state of X by flowing down from the root and you can tell the security state of Y by flowing down from the root. Just as X is not "delegating" to Y in the sense of NS's, X is not transferring any security state to Y. X is simply referring to Y. Ditto if this is a DNAME situation. . (assume a "signed" root) ------/ | \------ / | \ S S S (S=secure zone) | | | S S S | | | S U S (U=insecure zone) | | | X CNAME Y DNAME Z | W In this case, X has a secured reference to Y. Y isn't protected and has a rewrite rule to Z. Z is secured. You see from inspection from a (signed) root down that there is no break in the chain to X and Z, but there is the break to Y. DNSSEC is protecting the querier in that you get to validate what you can (where there is data). But does that help the application? Not really. This is why I think DNSSEC is there just to benefit the DNS, not the application. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 13 06:59: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 1B8C03A6AB9; Mon, 13 Oct 2008 06:59:16 -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 VopXZ3UKjAf4; Mon, 13 Oct 2008 06:59:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C0713A6947; Mon, 13 Oct 2008 06:59:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpNu7-00075n-NR for namedroppers-data@psg.com; Mon, 13 Oct 2008 13:56:11 +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 1KpNu1-000757-UC for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 13:56:08 +0000 Received: from bmp-336-ms506.wa.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1KpNtv-000637-3R; Mon, 13 Oct 2008 13:55:59 +0000 Subject: Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME From: Shane Kerr To: Ben Laurie Cc: namedroppers@ops.ietf.org In-Reply-To: <48F2DE42.1060209@links.org> References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> Content-Type: text/plain Date: Mon, 13 Oct 2008 15:55:59 +0200 Message-Id: <1223906159.19039.251.camel@shane-macbook-pro> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-Authenticated: True Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ben, On Mon, 2008-10-13 at 06:36 +0100, Ben Laurie wrote: > Surely the point is that DNSSEC changes the possible answers from: > > 1. RR exists and here it is. > 2. RR does not exist. > 3. Server not reachable (or otherwise broken). > > to > > 1. RR exists and here it is. > 2. RR does not exist. > 3. RR exists but is broken in some way. > 4. Server not reachable (or otherwise broken). > > The question is: what should applications do for state 3? My answer > would be to treat it like state 4, I think, but there's room for debate. I think there are some applications who are willing to accept a "broken" answer. For instance, if I am going to use an application level certificate, then I would probably choose to accept a RR with an expired signature (perhaps bounded in some way) rather than fail a connection completely. I think some way to expose this information to the application layer would be good, so the application layer could make informed decisions when this makes sense. -- Shane -- to unsubscribe send a message to namedroppers-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 Oct 13 07: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 9BA143A68C3; Mon, 13 Oct 2008 07: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 hRdBruG44qF2; Mon, 13 Oct 2008 07:21:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C78553A67E3; Mon, 13 Oct 2008 07:21:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpOFp-0009lj-Qy for namedroppers-data@psg.com; Mon, 13 Oct 2008 14:18:37 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpOFg-0009l0-W3 for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 14:18:35 +0000 Received: from [192.168.100.15] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id D29ACC2DA3; Mon, 13 Oct 2008 15:18:22 +0100 (BST) Date: Mon, 13 Oct 2008 15:18:20 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Ben Laurie cc: Wouter Wijngaards , Michael StJohns , Edward Lewis , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Message-ID: <4B27E2458EBA97669B259355@Ximines.local> In-Reply-To: <48F35170.30900@links.org> References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <48F33C34.3010901@nlnetlabs.nl> <48F35170.30900@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: Ben, --On 13 October 2008 14:47:28 +0100 Ben Laurie wrote: > If I am delivering mail, and the domain does not exist, I bounce it. If > I get SERVFAIL, I hold on to it and try again later. Ah yes. Agreed. So that makes the states: 1. We have data, which we know is correct & secure (DNSSEC signatures verify) 2. We have data, which we know is invalid (DNSSEC signature failure) 3. We have data, but we are uncertain as to the correctness of the data (e.g. no DNSSEC information for that zone, or missing DLV or whatever). 4. We have a failure, e.g. we got a SERVFAIL. As I understand, we can't tell this is secure or not (willing to be corrected here). 5. We have no data, and the absence of data is correctly authenticated (e.g. by NSEC/NSEC3) 6. We have no data, but the response is invalid (DNS signature failure on NSEC/NSEC3 proof of denial of existence) 7. We have no data, but we are uncertain as to its correctness (e.g. NXDOMAIN in vanilla DNS) I think 2 and 4 in the above are (at an application layer) the same, in that if I spoof by sending bogus answers, that should result in the same action as DoS and timeout, or spoofing SERVFAIL or whatever. That would suggest treating 6 the same as these two as well. By the same logic that a non-DNSSEC-aware application should treat 1 and 3 the same, it should treat 5 and 7 the same I presume. 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 Oct 13 08:05: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 ED6B63A6A00; Mon, 13 Oct 2008 08:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.573 X-Spam-Level: X-Spam-Status: No, score=-0.573 tagged_above=-999 required=5 tests=[AWL=-0.078, 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 AB9ezFmoz-gK; Mon, 13 Oct 2008 08:05:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A56613A67F1; Mon, 13 Oct 2008 08:05:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpOtt-000ELo-H2 for namedroppers-data@psg.com; Mon, 13 Oct 2008 15:00: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 1KpOtW-000EJW-Js for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 14:59:45 +0000 Received: from [10.31.201.38] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m9DEx7aa005375; Mon, 13 Oct 2008 10:59:08 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <4B27E2458EBA97669B259355@Ximines.local> References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <48F33C34.3010901@nlnetlabs.nl> <48F35170.30900@links.org> <4B27E2458EBA97669B259355@Ximines.local> Date: Mon, 13 Oct 2008 10:57:30 -0400 To: Alex Bligh From: Edward Lewis Subject: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: Ben Laurie , Wouter Wijngaards , Michael StJohns , Edward Lewis , namedroppers@ops.ietf.org, Alex Bligh 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: At 15:18 +0100 10/13/08, Alex Bligh wrote: >1. We have data, which we know is correct & secure (DNSSEC signatures > verify) >3. We have data, but we are uncertain as to the correctness of the > data (e.g. no DNSSEC information for that zone, or missing DLV > or whatever). DNSSEC says nothing about "correctness." If the IP address is typed wrong by the zone admin, DNSSEC will sign the result. "Missing DLV" is something that cannot be diagnosed from the packet arriving on port 53. If you have no trust anchor for a name and you get signed data owned by that name, it is indistinguishable whether the name has a key and you don't know it ("missing DLV") versus someone inserting falsely signed data just so you deduce it is missing. DNSSEC only says "this answer looks good" or "doesn't look good." Trying to figure out whether the answer's disposition is temporary/permanent, correct/incorrect, trustworthy/not takes more than just the DNS data and more than just the query at hand. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 13 08:13: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 203C53A68AC; Mon, 13 Oct 2008 08:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.611 X-Spam-Level: X-Spam-Status: No, score=-4.611 tagged_above=-999 required=5 tests=[AWL=0.437, 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 uT3+NsyhHJO5; Mon, 13 Oct 2008 08:13:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 21B513A6358; Mon, 13 Oct 2008 08:13:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpP2j-000FPH-7a for namedroppers-data@psg.com; Mon, 13 Oct 2008 15:09:09 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpP2V-000FML-Tu for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 15:09:01 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9DF8Yae013312; Mon, 13 Oct 2008 08:08:39 -0700 (PDT) Cc: Nicholas Weaver , Ben Laurie , Edward Lewis , namedroppers@ops.ietf.org Message-Id: <966FC948-2490-4CD9-8EC2-03998A3BA2CC@icsi.berkeley.edu> From: Nicholas Weaver To: Michael StJohns 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 v929.2) Subject: Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Date: Mon, 13 Oct 2008 08:08:38 -0700 References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Oct 13, 2008, at 4:38 AM, Michael StJohns wrote: > > I don't think its this simple... really. > > Basic DNS has the 3 answers in your first group - although I'd > categorize the last one as "I can't make any determination about > whether or not the answer exists for any of a number of reasons" - > what Marc describes as "indeterminate". > > DNSSEC add 4 (actually maybe even 5) security states that are > somewhat orthogonal to the DNS states: Possibly: 6: Leap-of-faith. Its "unknown" but its the same trust anchor that I have previously seen for this domain at some long time previously. 7: Leap-of-faith failure. Its "unknown" and different from the first time I've seen the trust anchor for this domain. > I'm not trying to be difficult here - but considering each of these > intersections and figuring out what to do for each application seems > to be a reasonable approach. The problem with relying on end-application validation of the states is that there is really only three possible answers, and none of them really rely on the detailed answers that the resolver gives: 1: The network is not trusted by the application, thus you need to verify end-to-end the other side. Once the application makes this decision, DNS for purposes of name- >address mapping is irrelevant for security purposes, although DNSSEC does matter if you care about a name->public_key mapping because you are using DNSSEC as a CA instead of any other CA or leap-of-faith key- exchange mechanisms. 2: The Network is trusted by the application. Once the application makes this decision, it might as well accept everything as long as the resolver implements the defenses against OUT- of-path attacks, which is orthoginal to what you do in several of the key-failure corner-cases. 3: The Network is trusted by the application, but the recursive resolver belonging to the ?ISP? isn't. (The Rogue resolution- authority problem) IF the application makes this decision, it should simply use its own non-DNSSEC recursive resolver to make queries and bypass the external recursive resolver altogether, because such a recursive resolver can always just say "uhh, no DNSSEC here". -- to unsubscribe send a message to namedroppers-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 Oct 13 08:36: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 3272C3A6A5C; Mon, 13 Oct 2008 08:36: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 gMmNm93t6l9F; Mon, 13 Oct 2008 08:36:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 390983A69FE; Mon, 13 Oct 2008 08:36:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpPQV-000Hyz-LI for namedroppers-data@psg.com; Mon, 13 Oct 2008 15:33:43 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpPQN-000Hy5-Iw for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 15:33:39 +0000 Received: from [192.168.100.15] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id A578FC2DA3; Mon, 13 Oct 2008 16:33:27 +0100 (BST) Date: Mon, 13 Oct 2008 16:33:24 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Edward Lewis cc: Ben Laurie , Wouter Wijngaards , Michael StJohns , Edward Lewis , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Message-ID: <17111087C181D66AE22EFDA0@Ximines.local> In-Reply-To: References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <48F33C34.3010901@nlnetlabs.nl> <48F35170.30900@links.org> <4B27E2458EBA97669B259355@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 13 October 2008 10:57:30 -0400 Edward Lewis wrote: > DNSSEC says nothing about "correctness." If the IP address is typed wrong > by the zone admin, DNSSEC will sign the result. Sorry - I was using 'correct' as a term without any prior terminological commitments to mean "not only is there data but it is signed but all the signatures match" (I believe this corresponds to DNSSEC's 'secure' status but that also covers for instance secure denial). > "Missing DLV" is something that cannot be diagnosed from the packet > arriving on port 53. If you have no trust anchor for a name and you get > signed data owned by that name, it is indistinguishable whether the name > has a key and you don't know it ("missing DLV") versus someone inserting > falsely signed data just so you deduce it is missing. My point was that it is (I think) possible to distinguish between faults where a resolver cannot verify a signature presented (e.g. signature added promiscuously to signed data, no trust anchor found) and where the signature doesn't match the data (e.g. data tampered with on the wire). In the former case (number 3 in my email), it seems to me one doesn't know whether the signature is added as some form of attempted attack (where one might think one should trust the data less) or whether one just doesn't have the right trust anchors configured (where one might think one should just treat the data as if it weren't signed at all), so treating the data as if it were unsigned (the rest of my case 3) seems fine. In the latter class of errors, there is no proper explanation for that, and best ignore the data entirely. > DNSSEC only says "this answer looks good" or "doesn't look good." Trying > to figure out whether the answer's disposition is temporary/permanent, > correct/incorrect, trustworthy/not takes more than just the DNS data and > more than just the query at hand. I was under the misapprehension that this was precisely what this thread was concerned with! DNSSEC doesn't only say the answer looks good, or does not look good. It also occasionally fails entirely (e.g. SERVFAIL). Further, a DNSSEC aware resolver will also occasionally give results found through vanilla (non-DNSSEC) DNS. That, plus there is clearly a differentiation between results and no results for a DNSSEC aware version of (e.g.) gethostbyname. 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 Oct 13 09:21: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 23F2928C164; Mon, 13 Oct 2008 09:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.184 X-Spam-Level: X-Spam-Status: No, score=-1.184 tagged_above=-999 required=5 tests=[AWL=-0.747, 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 DX2h7U-dluOS; Mon, 13 Oct 2008 09:21:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C08D328C17F; Mon, 13 Oct 2008 09:21:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpQ4X-000MBk-NG for namedroppers-data@psg.com; Mon, 13 Oct 2008 16:15:05 +0000 Received: from [76.96.62.64] (helo=QMTA07.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpQ4F-000M7V-UN for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 16:14:54 +0000 Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA07.westchester.pa.mail.comcast.net with comcast id SFWy1a00416LCl057GEmmz; Mon, 13 Oct 2008 16:14:46 +0000 Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA06.westchester.pa.mail.comcast.net with comcast id SGEm1a0042P9w053SGEmmD; Mon, 13 Oct 2008 16:14:46 +0000 X-Authority-Analysis: v=1.0 c=1 a=dmE0DmLRt_UA:10 a=-5nm-dUE1uIA:10 a=hqaSkvWfAAAA:8 a=OzSqGtDSAAAA:8 a=-90TJPE8zmM4IHy4HNsA:9 a=Q_SJ-4H7ap5jBwhSmQsA:7 a=Z59Ha5NdSBBGVJcUQHBUBl6G-6wA:4 a=Ly75NXeMEyIA:10 a=B-GU5LaGV7AA:10 a=h9s5Ru71U4oA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Oct 2008 12:14:46 -0400 To: Ben Laurie From: Michael StJohns Subject: Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: Edward Lewis ,namedroppers@ops.ietf.org In-Reply-To: <48F33BDF.6020304@links.org> References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <20081013113946.D7DAA33C1E@mail.links.org> <48F33BDF.6020304@links.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: At 08:15 AM 10/13/2008, Ben Laurie wrote: >Michael StJohns wrote: >>> missing keys, etc. 5. Insecure transition from secure - I've got >> valid signatures as far as a CNAME or DNAME, but the CNAME or DNAME >> point into an area of the tree with Unknown trust. > >I don't quite see the point of state 5 - why treat that differently from >1? (Oh, I do now, having read below more carefully) > >But you do have a point. Yup. More on this in my response to Ed's note which follows. >> Those three DNS states matrix (somewhat) with the 5 security states >> to actually give you 15 distinct intersections - but a number of >> those substates collapse into each other. (E.g., secure/exist, >> secure/non-exist, bogus/exist, bogus/non-exist, any/indeterminate, >> unsecure/any, unknown/any). You might also consider that DNSSEC >> extends the original 3 dns resolution states to 4 by adding a "data >> determinate/dnssec indeterminate" - but those may collapse mostly >> into the bogus entries. > >We should actually figure out what all the distinct states are, rather >than handwave. That's really all I'm saying. If we want DNSSEC to be useful at the application level we need to do something like this. >> I'm not trying to be difficult here - but considering each of these >> intersections and figuring out what to do for each application seems >> to be a reasonable approach. >> >> Taking specifically email MTA-MTA interactions. It seems to me that >> you'd treat (secure | unsecure | indeterminate)/exist as states where >> you'd allow the MTA to connect and deliver, that you'd treat >> bogus/any as a reportable security error condition and not deliver (- >> but would you retry?), that you'd treat any/indeterminate as a retry >> error condition (e.g. temporary failure), and that you'd treat >> secure/non-exist as a permanent mail delivery failure. What would >> you do with unknown/non-exist - would you treat as a permanent >> failure or retry after a long or short interval? > >As with many security decisions, this would depend on requirements. I >can imagine running an MTA in an environment that only wants to trust >DNSSEC (or in a mythical future where everything is IPv6, sorry, I mean >DNSSEC), and so configuring this to "retry but eventually fail" in the >usual way. > >For most people transitioning to DNSSEC, then I'd treat this as a >permanent failure. Right. That's probably a reasonable approach... now to get it standardized... :-) >> >> Going back to the DNAME/CNAME stuff - DNSSEC provides a mechanism to >> indicate to a resolver securely that a chain of trust is being turned >> off (is ending securely?) (secure delegation to an unsecure zone). >> CNAME and DNAME do not have any way of indicating the expected >> security state of the zone to which they point. It seems to me that >> an application might actually care about this when trying to figure >> out what to do. Let's pretend for a moment that DNAME has a way of >> indicating its target status as one of either - must be secure, or >> don't care. If the must be secure bit is set and the target can't be >> validated (either as secure or as delegated to unsecure), then the >> answer for the whole chain is bogus. If the bit isn't set, then >> security resolution for the target restarts with the target - e.g. if >> the target is under a trust anchor then it must validate or the chain >> is bogus. Obviously, this bit doesn't exist - should it? > >Interesting question. Perhaps it should. > >> And finishing up with MTA-MTA - if I use the current model and have a >> lookup chain to a DNAME that validates, but that the target of the >> DNAME isn't under a trust anchor - should I deliver the mail? If so, >> why? If not, why? >> >> What do I do if the MX look up is secure, but the A lookup is >> unsecure or unknown? Vice versa? >> >> What markings if any should go on an email (header notation) to >> indicate a forwarding routing was based on data with an "unsecure" or >> "unknown" trust state? or if the MX was secure and the A wasn't or >> vice versa? > >Routing headers aren't very rigidly defined now, so this seems orthogonal. Each hop in email routing adds a Received-From line. Would it make sense to tag that line in some manner or to add a different element related to DNSSEC? Not saying that we should or not - but that the discussion is part of DNSSEC plus MTA-MTA handling standardization. Mike >> Should a downstream receiver do anything special for messages marked >> as above? Would this ever be a reasonable filtering criteria? >> >> >> >>> The question is: what should applications do for state 3? My answer >>> would be to treat it like state 4, I think, but there's room for >>> debate. >>> >>> Cheers, >>> >>> Ben. >>> >>> -- 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 >> >> >> > > >-- >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 Oct 13 09:26: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 83C553A68BA; Mon, 13 Oct 2008 09:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[AWL=-0.703, 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 87Fblo6jWSR2; Mon, 13 Oct 2008 09:26:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 55F433A683A; Mon, 13 Oct 2008 09:26:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpQD3-000NAr-3l for namedroppers-data@psg.com; Mon, 13 Oct 2008 16:23:53 +0000 Received: from [76.96.30.80] (helo=QMTA08.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpQCv-000NA5-Eg for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 16:23:47 +0000 Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id SF1x1a00y0cQ2SLA8GPUwR; Mon, 13 Oct 2008 16:23:28 +0000 Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id SGPR1a00E2P9w058WGPSHJ; Mon, 13 Oct 2008 16:23:28 +0000 X-Authority-Analysis: v=1.0 c=1 a=dmE0DmLRt_UA:10 a=-5nm-dUE1uIA:10 a=wCfa3VrZFAKm5OSuh3wA:9 a=ASmL2TMms_bRjqjcFbD9HZaKs1gA:4 a=h9s5Ru71U4oA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Oct 2008 12:23:25 -0400 To: Wouter Wijngaards From: Michael StJohns Subject: Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: Ben Laurie ,Edward Lewis , namedroppers@ops.ietf.org In-Reply-To: <48F33C34.3010901@nlnetlabs.nl> References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <48F33C34.3010901@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: At 08:16 AM 10/13/2008, Wouter Wijngaards wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi Michael, > >I think it is much simpler than that. The application is interested in >what is known with certainty. >1. It is certain the data is valid (secure) >2. It is certain that security checks failed (bogus) >3. whatever (insecure). > >Thus, your numbers 1, 3, 5 are folded into insecure (or maybe more >accurately, 'no security available'). This is why doing the bigger matrix and trying to do the decomposition into handling states is probably the right approach - your later email changes this based on further discussion but still doesn't quite get all the states covered. >A mail application could deliver 1 and 3, but not 2(bogus). Or it might >examine the AD bit on replies and only deliver 1. > >When a DNAME or CNAME chain crosses a BOGUS entry, the DNAME or CNAME >chain result is bogus. When a DNAME or CNAME chain has all items secure, >the DNAME or CNAME chain result is secure. All other cases are insecure >(i.e. the chain has one insecure element and the other elements are >insecure or secure). > >I do not think a 'must be secure' bit is needed. Only when all items in >the chain are secure is the result secure, and does the AD bit get set. The AD bit gets set (or not) when you return data from a recursive nameserver, but that doesn't really describe how an application doing its own DNSSEC validation should handle this type of data. It may be that your approach of if anything is bogus its all bogus, else if everything is secure its all secure, else its unsecure is correct. BUT - this seems at odds with the general DNSSEC contract that says we don't transition to an unsecure state unless we do it securely. If I'm the zone owner of the zone with the DNAME, and I'd doing a reference to another zone that - at the time I did the delegation - I knew to be secure, shouldn't I expect that DNSSEC should flag it if someone tries to resolve this and finds an unsecure zone? Again if not, why not? And why isn't this as much of a downgrade attack as all the other various schemes that have been described to me? Mike >Best regards, > Wouter > >Michael StJohns wrote: >> At 01:36 AM 10/13/2008, Ben Laurie wrote: >>> 1. RR exists and here it is. >>> 2. RR does not exist. >>> 3. Server not reachable (or otherwise broken). >>> >>> to >>> >>> 1. RR exists and here it is. >>> 2. RR does not exist. >>> 3. RR exists but is broken in some way. >>> 4. Server not reachable (or otherwise broken). >> >> I don't think its this simple... really. >> >> Basic DNS has the 3 answers in your first group - although I'd categorize the last one as "I can't make any determination about whether or not the answer exists for any of a number of reasons" - what Marc describes as "indeterminate". >> >> DNSSEC add 4 (actually maybe even 5) security states that are somewhat orthogonal to the DNS states: >> >> 1. Unknown - I've got no superior trust anchor so I can't make any definite statement about whether or not the answer is secure. >> 2. Secure - I've gotten a chain of signatures covering which allow me to determine the answer is securely valid. >> 3. Unsecure - I've gotten a chain of signature plus certain other data which tells me in a secure manner that I have no security information about the final answer. >> 4. Bogus - I've gotten all the information I've asked for from the system, but I was unable to prove the security - bad signatures, missing keys, etc. >> 5. Insecure transition from secure - I've got valid signatures as far as a CNAME or DNAME, but the CNAME or DNAME point into an area of the tree with Unknown trust. >> >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.9 (GNU/Linux) > >iEYEARECAAYFAkjzPDQACgkQkDLqNwOhpPg4hgCfZJrXXhwSeXgeZiU9W4FZ5Wwi >O84AoKnIBWKPbaVGzxeCueQWk5L0WslT >=tjtc >-----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 Oct 13 09:34: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 152C83A69AF; Mon, 13 Oct 2008 09:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[AWL=-0.664, 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 2-ez-iSSvi72; Mon, 13 Oct 2008 09:34:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C84BD28C118; Mon, 13 Oct 2008 09:34:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpQK1-000ODs-Qi for namedroppers-data@psg.com; Mon, 13 Oct 2008 16:31:05 +0000 Received: from [76.96.62.24] (helo=QMTA02.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpQJt-000OBe-B7 for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 16:31:01 +0000 Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA02.westchester.pa.mail.comcast.net with comcast id SEkd1a01L0cZkys52GWLci; Mon, 13 Oct 2008 16:30:20 +0000 Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA10.westchester.pa.mail.comcast.net with comcast id SGWv1a00G2P9w053WGWvDZ; Mon, 13 Oct 2008 16:30:56 +0000 X-Authority-Analysis: v=1.0 c=1 a=-SHtGfL_fv4A:10 a=4POudkrwpe0A:10 a=n4SiwN4SXGBhdsoNf64A:9 a=SfpSF_YbBcTc9UogXGcA:7 a=s47zCaeStkiMffbd4cju-7v0QJUA:4 a=9k6G2--EmesA:10 a=3SmO1NJXDBsA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Oct 2008 12:30:56 -0400 To: Edward Lewis From: Michael StJohns Subject: Re: CNAME/DNAME - Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: Ben Laurie ,Edward Lewis , namedroppers@ops.ietf.org In-Reply-To: References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: Hi Ed - I agree that you can determine the security state of X and the security state of Y by examining trust anchors, dlv etc. But that's not the question. The question is "What is the security state of the compound answer XY?" From Marc Andrew's and somewhat from Wouter's email, it could be a new state "unauthenticated" - because the response out of an intermediate resolver is to return the data but not set the AD bit. I say new, because it's different than unknown, secure, and bogus and wouldn't be returned for the same reasons that you would return it for unsecure data under a single trust anchor. But even that begs the question of what an application should do with it. Later, Mike At 09:45 AM 10/13/2008, Edward Lewis wrote: >At 7:38 -0400 10/13/08, Michael StJohns wrote: > >>...CNAME and DNAME do not have any way of indicating the expected security >>state of the zone to which they point. ... > >Yes they do. For X CNAME Y, you can determine the security state of X by flowing down from the root and you can tell the security state of Y by flowing down from the root. Just as X is not "delegating" to Y in the sense of NS's, X is not transferring any security state to Y. X is simply referring to Y. Ditto if this is a DNAME situation. > > > . (assume a "signed" root) > ------/ | \------ > / | \ > S S S (S=secure zone) > | | | > S S S > | | | > S U S (U=insecure zone) > | | | > X CNAME Y DNAME Z > | > W > >In this case, X has a secured reference to Y. Y isn't protected and has a rewrite rule to Z. Z is secured. You see from inspection from a (signed) root down that there is no break in the chain to X and Z, but there is the break to Y. > >DNSSEC is protecting the querier in that you get to validate what you can (where there is data). But does that help the application? Not really. This is why I think DNSSEC is there just to benefit the DNS, not the application. >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >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 Oct 13 09:44: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 601BE3A6A55; Mon, 13 Oct 2008 09:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[AWL=-0.629, 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 T8Osv-KC45oX; Mon, 13 Oct 2008 09:44:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 63F533A69F6; Mon, 13 Oct 2008 09:44:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpQRA-000PEb-Dg for namedroppers-data@psg.com; Mon, 13 Oct 2008 16:38:28 +0000 Received: from [76.96.62.80] (helo=QMTA08.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpQR3-000PDu-Dv for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 16:38:25 +0000 Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA08.westchester.pa.mail.comcast.net with comcast id SEhE1a0081GhbT858GeHLy; Mon, 13 Oct 2008 16:38:17 +0000 Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA07.westchester.pa.mail.comcast.net with comcast id SGeK1a00H2P9w053TGeLeb; Mon, 13 Oct 2008 16:38:20 +0000 X-Authority-Analysis: v=1.0 c=1 a=gjHhN06smIIA:10 a=liyGigqBEMQA:10 a=NllN8NON1xZY598_ZlMA:9 a=Z39TrXq8B40Odwm60kBjy3g18q8A:4 a=h9s5Ru71U4oA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Oct 2008 12:38:20 -0400 To: Edward Lewis ,Alex Bligh From: Michael StJohns Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: Ben Laurie ,Wouter Wijngaards , Edward Lewis ,namedroppers@ops.ietf.org, Alex Bligh In-Reply-To: References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <48F33C34.3010901@nlnetlabs.nl> <48F35170.30900@links.org> <4B27E2458EBA97669B259355@Ximines.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: At 10:57 AM 10/13/2008, Edward Lewis wrote: >DNSSEC only says "this answer looks good" or "doesn't look good." Trying to figure out whether the answer's disposition is temporary/permanent, correct/incorrect, trustworthy/not takes more than just the DNS data and more than just the query at hand. DNSSEC says the answer looks good - SECURE or doesn't look good - BOGUS or DNSSEC told me I shouldn't care about DNSSEC past some point - UNSECURE or I have no information which would let me determine what DNSSEC thinks about the data - UNKNOWN "Trustworthy" begs a definition here for what "looks good" means in relationship to "trusting" DNS 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 Mon Oct 13 09:51: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 496283A6BA6; Mon, 13 Oct 2008 09:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.034 X-Spam-Level: X-Spam-Status: No, score=-1.034 tagged_above=-999 required=5 tests=[AWL=-0.597, 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 Bkpt5jWSFQrD; Mon, 13 Oct 2008 09:51:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7920F3A6BA8; Mon, 13 Oct 2008 09:51:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpQYV-0000DH-Lv for namedroppers-data@psg.com; Mon, 13 Oct 2008 16:46:03 +0000 Received: from [76.96.30.56] (helo=QMTA06.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpQYN-0000A4-Pj for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 16:46:00 +0000 Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id SCmb1a0071GXsucA6Glsty; Mon, 13 Oct 2008 16:45:53 +0000 Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id SGlq1a0052P9w058TGlrvq; Mon, 13 Oct 2008 16:45:52 +0000 X-Authority-Analysis: v=1.0 c=1 a=dmE0DmLRt_UA:10 a=-5nm-dUE1uIA:10 a=oq2BURO-OUWyydgafRQA:9 a=hrMOMGvLtFLXL6PDEC-T6wGs44YA:4 a=oqs56FR1YJwA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Oct 2008 12:45:50 -0400 To: Wouter Wijngaards From: Michael StJohns Subject: Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: Ben Laurie ,Edward Lewis , namedroppers@ops.ietf.org In-Reply-To: <7.1.0.9.2.20081013121525.053103c0@comcast.net> References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <48F33C34.3010901@nlnetlabs.nl> <7.1.0.9.2.20081013121525.053103c0@comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: Sorry - note in line At 12:23 PM 10/13/2008, Michael StJohns wrote: >At 08:16 AM 10/13/2008, Wouter Wijngaards wrote: >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >>Hi Michael, >> >>I think it is much simpler than that. The application is interested in >>what is known with certainty. >>1. It is certain the data is valid (secure) >>2. It is certain that security checks failed (bogus) >>3. whatever (insecure). >> >>Thus, your numbers 1, 3, 5 are folded into insecure (or maybe more >>accurately, 'no security available'). > >This is why doing the bigger matrix and trying to do the decomposition into handling states is probably the right approach - your later email changes this based on further discussion but still doesn't quite get all the states covered. .... confused you with a later email by Alex. >>A mail application could deliver 1 and 3, but not 2(bogus). Or it might >>examine the AD bit on replies and only deliver 1. >> >>When a DNAME or CNAME chain crosses a BOGUS entry, the DNAME or CNAME >>chain result is bogus. When a DNAME or CNAME chain has all items secure, >>the DNAME or CNAME chain result is secure. All other cases are insecure >>(i.e. the chain has one insecure element and the other elements are >>insecure or secure). >> >>I do not think a 'must be secure' bit is needed. Only when all items in >>the chain are secure is the result secure, and does the AD bit get set. > >The AD bit gets set (or not) when you return data from a recursive nameserver, but that doesn't really describe how an application doing its own DNSSEC validation should handle this type of data. > >It may be that your approach of if anything is bogus its all bogus, else if everything is secure its all secure, else its unsecure is correct. BUT - this seems at odds with the general DNSSEC contract that says we don't transition to an unsecure state unless we do it securely. If I'm the zone owner of the zone with the DNAME, and I'd doing a reference to another zone that - at the time I did the delegation - I knew to be secure, shouldn't I expect that DNSSEC should flag it if someone tries to resolve this and finds an unsecure zone? Again if not, why not? And why isn't this as much of a downgrade attack as all the other various schemes that have been described to me? > >Mike > > > >>Best regards, >> Wouter >> >>Michael StJohns wrote: >>> At 01:36 AM 10/13/2008, Ben Laurie wrote: >>>> 1. RR exists and here it is. >>>> 2. RR does not exist. >>>> 3. Server not reachable (or otherwise broken). >>>> >>>> to >>>> >>>> 1. RR exists and here it is. >>>> 2. RR does not exist. >>>> 3. RR exists but is broken in some way. >>>> 4. Server not reachable (or otherwise broken). >>> >>> I don't think its this simple... really. >>> >>> Basic DNS has the 3 answers in your first group - although I'd categorize the last one as "I can't make any determination about whether or not the answer exists for any of a number of reasons" - what Marc describes as "indeterminate". >>> >>> DNSSEC add 4 (actually maybe even 5) security states that are somewhat orthogonal to the DNS states: >>> >>> 1. Unknown - I've got no superior trust anchor so I can't make any definite statement about whether or not the answer is secure. >>> 2. Secure - I've gotten a chain of signatures covering which allow me to determine the answer is securely valid. >>> 3. Unsecure - I've gotten a chain of signature plus certain other data which tells me in a secure manner that I have no security information about the final answer. >>> 4. Bogus - I've gotten all the information I've asked for from the system, but I was unable to prove the security - bad signatures, missing keys, etc. >>> 5. Insecure transition from secure - I've got valid signatures as far as a CNAME or DNAME, but the CNAME or DNAME point into an area of the tree with Unknown trust. >>> >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.4.9 (GNU/Linux) >> >>iEYEARECAAYFAkjzPDQACgkQkDLqNwOhpPg4hgCfZJrXXhwSeXgeZiU9W4FZ5Wwi >>O84AoKnIBWKPbaVGzxeCueQWk5L0WslT >>=tjtc >>-----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 Oct 13 09:51: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 155FB3A68F7; Mon, 13 Oct 2008 09:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.57 X-Spam-Level: X-Spam-Status: No, score=-0.57 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 MuBe6aSo84Bt; Mon, 13 Oct 2008 09:51:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2A2A53A6BA4; Mon, 13 Oct 2008 09:51:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpQXY-00004u-Tf for namedroppers-data@psg.com; Mon, 13 Oct 2008 16:45:04 +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 1KpQXS-000025-17 for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 16:45:00 +0000 Received: from [10.31.201.38] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m9DGimfM006787; Mon, 13 Oct 2008 12:44:49 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> Date: Mon, 13 Oct 2008 12:44:43 -0400 To: Michael StJohns From: Edward Lewis Subject: Re: CNAME/DNAME - Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: Edward Lewis , Ben Laurie , namedroppers@ops.ietf.org 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: At 12:30 -0400 10/13/08, Michael StJohns wrote: >Hi Ed - > >I agree that you can determine the security state of X and the security >state of Y by examining trust anchors, dlv etc. But that's not the question. >The question is "What is the security state of the compound answer XY?" The security state - in the eyes of DNS that is easy. If the X passes the DNSSEC test, Y passes the test as being unsigned, and Z passes the DNSSEC test, the answer is "AD." IOW, there's nothing suspicious about the result as far as the DNS is concerned. It's fair to ask though "what's the value" of piecemeal checking. My answer is that "it's out of scope" for DNS. > From Marc Andrew's and somewhat from Wouter's email, it could be a new >state "unauthenticated" - because the response out of an intermediate resolver >is to return the data but not set the AD bit. I say new, because it's >different than unknown, secure, and bogus and wouldn't be returned for the >same reasons that you would return it for unsecure data under a single trust >anchor. But even that begs the question of what an application should do >with it. > >Later, Mike After the debate in Winter 2001 (SLC IETF) over the AD bit not being tied to cryptography, I'd set the AD bit in the response. I(f i)t's authenticated to the responding server. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 13 10:11: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 B0C813A67B0; Mon, 13 Oct 2008 10:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 gw1b+se7yMpL; Mon, 13 Oct 2008 10:11:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 82E933A68DC; Mon, 13 Oct 2008 10:11:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpQtC-0002tk-60 for namedroppers-data@psg.com; Mon, 13 Oct 2008 17:07:26 +0000 Received: from [76.96.62.56] (helo=QMTA06.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpQsz-0002qR-G2 for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 17:07:23 +0000 Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA06.westchester.pa.mail.comcast.net with comcast id SF421a00d0mv7h056H72U2; Mon, 13 Oct 2008 17:07:02 +0000 Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA11.westchester.pa.mail.comcast.net with comcast id SH6d1a0012P9w053XH6dGH; Mon, 13 Oct 2008 17:06:38 +0000 X-Authority-Analysis: v=1.0 c=1 a=-SHtGfL_fv4A:10 a=4POudkrwpe0A:10 a=h5gJkh8D07ueZ6VX6CAA:9 a=b7_s-70N1BbycZwfW286_QS96zQA:4 a=h9s5Ru71U4oA:10 a=fsDBreADarvPLUIPsM0A:9 a=0iJQjT4BF6hvOhkV8gJYpd5h37gA:4 a=37WNUvjkh6kA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Oct 2008 13:07:11 -0400 To: Edward Lewis From: Michael StJohns Subject: Re: CNAME/DNAME - Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: Edward Lewis ,Ben Laurie , namedroppers@ops.ietf.org In-Reply-To: References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1045147750==.ALT" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: --=====================_1045147750==.ALT Content-Type: text/plain; charset="us-ascii" At 12:44 PM 10/13/2008, Edward Lewis wrote: >At 12:30 -0400 10/13/08, Michael StJohns wrote: >>Hi Ed - >> >>I agree that you can determine the security state of X and the security >>state of Y by examining trust anchors, dlv etc. But that's not the question. >>The question is "What is the security state of the compound answer XY?" > >The security state - in the eyes of DNS that is easy. If the X passes the DNSSEC test, Y passes the test as being unsigned, and Z passes the DNSSEC test, the answer is "AD." IOW, there's nothing suspicious about the result as far as the DNS is concerned. You sure about that answer? Pretend all you're doing is looking up Y. Since Y is UNSECURE, shouldn't you get an answer with the AD bit cleared? So shouldn't the compound answer also clear the AD bit? Let's go a bit further. Let's say that the validating intermediate resolver queried without the CD bit set gets SECURE, UNSECURE and BOGUS for the three legs of the triad. Should it return the SECURE and UNSECURE parts and also do a SERVFAIL? RFC 4035 - 5.5 is unclear on this: >5.5. Resolver Behavior When Signatures Do Not Validate > > If for whatever reason none of the RRSIGs can be validated, the > response SHOULD be considered BAD. If the validation was being done > to service a recursive query, the name server MUST return RCODE 2 to > the originating client. *SOME* of the RRSIGs can be validated... *sigh* Does the response still return an RCODE 2? >It's fair to ask though "what's the value" of piecemeal checking. My answer is that "it's out of scope" for DNS. --=====================_1045147750==.ALT Content-Type: text/html; charset="us-ascii" At 12:44 PM 10/13/2008, Edward Lewis wrote:
At 12:30 -0400 10/13/08, Michael StJohns wrote:
Hi Ed -

I agree that you can determine the security state of X and the security
state of Y by examining trust anchors, dlv etc.  But that's not the question.
The question is "What is the security state of the compound answer XY?"

The security state - in the eyes of DNS that is easy.  If the X passes the DNSSEC test, Y passes the test as being unsigned, and Z passes the DNSSEC test, the answer is "AD."  IOW, there's nothing suspicious about the result as far as the DNS is concerned.

You sure about that answer?  Pretend all you're doing is looking up Y.  Since Y is UNSECURE,  shouldn't you get an answer with the AD bit cleared? So shouldn't the compound answer also clear the AD bit?

Let's go a bit further.  Let's say that the validating intermediate resolver queried without the CD bit set gets SECURE, UNSECURE and BOGUS for the three legs of the triad.  Should it return the SECURE and UNSECURE parts and also do a SERVFAIL?  RFC 4035 - 5.5 is unclear on this:


5.5.  Resolver
Behavior When Signatures Do Not Validate

   If for whatever reason none of the RRSIGs can be validated,
the
   response SHOULD be considered BAD.  If the validation
was being done
   to service a recursive query, the name server MUST return
RCODE 2 to
   the originating client.

*SOME* of the RRSIGs can be validated... *sigh*  Does the response still return an RCODE 2?




It's fair to ask though "what's the value" of piecemeal checking.  My answer is that "it's out of scope" for DNS.


--=====================_1045147750==.ALT-- -- to unsubscribe send a message to namedroppers-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 Oct 13 10:42: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 6601C3A6907; Mon, 13 Oct 2008 10:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.34 X-Spam-Level: X-Spam-Status: No, score=-99.34 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, 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 txeoNNQ9b6cZ; Mon, 13 Oct 2008 10:42:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 20EAA3A68BA; Mon, 13 Oct 2008 10:42:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpRNq-0006ud-C1 for namedroppers-data@psg.com; Mon, 13 Oct 2008 17:39:06 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpRNZ-0006qw-KI for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 17:39:03 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id 5057833C5A; Mon, 13 Oct 2008 10:38:49 -0700 (PDT) Date: Mon, 13 Oct 2008 10:38:49 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Nicholas Weaver Cc: Namedroppers Subject: Re: [dnsext] One other argument for local scope... In-Reply-To: <1F51A6D7-BFFD-42BC-9FDA-71FBF84050E9@ICSI.Berkeley.EDU> References: <80CAC5D9-7BDD-44E1-ACC0-90A6D585B5C6@icsi.berkeley.edu> <1F51A6D7-BFFD-42BC-9FDA-71FBF84050E9@ICSI.Berkeley.EDU> 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=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Fri, 10 Oct 2008 12:00:12 -0700, Nicholas Weaver wrote: > However, Ota also brings up an excellent point: DOES prevent me from > saying to verisign: > > www.mydomain.com NS ns1.google.com > ns1.google.com A 66.6.66.6 > > and then tricking a victim into visiting mydomain.com? > > A lot of my experimenting suggests that the resolvers I've testing > (I'm building a Java test applet) will accept and follow such records, > at least in the second level domain (I haven't tried attacking .com > however). Please actually try attacking .com, then:-) Seriously, I'm very much interested in whether .com or any other major top level domains would blindly accept such a bogus glue address record. If they do, it would create even much stronger motivation to implement and deploy additional defense. --- 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 Mon Oct 13 11:01: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 761463A68E3; Mon, 13 Oct 2008 11:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.567 X-Spam-Level: X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[AWL=-0.072, 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 T7d8vlfQRp2p; Mon, 13 Oct 2008 11:01:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 510E53A6820; Mon, 13 Oct 2008 11:01:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpReY-0008wR-Ij for namedroppers-data@psg.com; Mon, 13 Oct 2008 17:56:22 +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 1KpReH-0008uK-EL for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 17:56:11 +0000 Received: from [10.31.201.38] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m9DHthC7007588; Mon, 13 Oct 2008 13:55:43 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <48F33C34.3010901@nlnetlabs.nl> <48F35170.30900@links.org> <4B27E2458EBA97669B259355@Ximines.local> Date: Mon, 13 Oct 2008 13:55:27 -0400 To: Michael StJohns From: Edward Lewis Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: Edward Lewis , Alex Bligh , Ben Laurie , Wouter Wijngaards , namedroppers@ops.ietf.org 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: At 12:38 -0400 10/13/08, Michael StJohns wrote: >At 10:57 AM 10/13/2008, Edward Lewis wrote: >>DNSSEC only says "this answer looks good" or "doesn't look good." >>Trying to figure out whether the answer's disposition is >>temporary/permanent, correct/incorrect, trustworthy/not takes more >>than just the DNS data and more than just the query at hand. > > >DNSSEC says the answer looks good - SECURE >or doesn't look good - BOGUS >or DNSSEC told me I shouldn't care about DNSSEC past some point - UNSECURE >or I have no information which would let me determine what DNSSEC >thinks about the data - UNKNOWN > >"Trustworthy" begs a definition here for what "looks good" means in >relationship to "trusting" DNS data. This is the kind of debate that'll never end, judging from past incarnations of this thread. To me, an answer that is under a trust anchor and below a null DS set is "looks good" as far as DNSSEC is concerned. I.e., to me, UNSECURE == SECURE == UNKNOWN, when I consider the "bottom line" of the query-response. I guess I have a Machiavellian (ends justify the means, i.e., all that matters are the ends) streak in me. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 13 11:25: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 4C4A13A68E4; Mon, 13 Oct 2008 11:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.141 X-Spam-Level: X-Spam-Status: No, score=0.141 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 f106htONW5Wd; Mon, 13 Oct 2008 11:25:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 777A93A67B0; Mon, 13 Oct 2008 11:25:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpS31-000CAG-S5 for namedroppers-data@psg.com; Mon, 13 Oct 2008 18:21:39 +0000 Received: from [209.85.200.171] (helo=wf-out-1314.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpS2t-000C9Z-1P for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 18:21:37 +0000 Received: by wf-out-1314.google.com with SMTP id 26so1998649wfd.32 for ; Mon, 13 Oct 2008 11:21:30 -0700 (PDT) Received: by 10.140.132.3 with SMTP id f3mr4067702rvd.71.1223922090166; Mon, 13 Oct 2008 11:21:30 -0700 (PDT) Received: by 10.141.106.8 with HTTP; Mon, 13 Oct 2008 11:21:30 -0700 (PDT) Message-ID: Date: Mon, 13 Oct 2008 11:21:30 -0700 From: "Matthew Dempsky" To: "Nicholas Weaver" Subject: Re: [dnsext] One other argument for local scope... Cc: "IETF DNSEXT WG" In-Reply-To: <80CAC5D9-7BDD-44E1-ACC0-90A6D585B5C6@icsi.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <80CAC5D9-7BDD-44E1-ACC0-90A6D585B5C6@icsi.berkeley.edu> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Oct 6, 2008 at 9:09 AM, Nicholas Weaver wrote: > example.com NS ns.example2.org > ns.example2.org A 12.34.56.78 Where do the com servers get the ns.example2.org A record from? Does it resolve it like a normal cache by asking the org and example2.org name servers or does the user have to specify it? Also, rather than changing DNS clients to support the above glue, why not instead use records like example.com NS ns.example2.org._local-glue.example.com ns.example2.org._local-glue.example.com A 12.34.56.78 and work with existing DNS caches? -- to unsubscribe send a message to namedroppers-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 Oct 13 12:34: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 E19553A69D2; Mon, 13 Oct 2008 12:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.785 X-Spam-Level: ** X-Spam-Status: No, score=2.785 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mm5tnC1J2fgO; Mon, 13 Oct 2008 12:34:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E2A4A3A6B07; Mon, 13 Oct 2008 12:34:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpT8C-000L28-C9 for namedroppers-data@psg.com; Mon, 13 Oct 2008 19:31:04 +0000 Received: from [195.188.213.8] (helo=smtp-out5.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpT86-000L1S-Oi for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 19:31:01 +0000 Received: from [172.23.170.146] (helo=anti-virus03-09) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1KpT7z-0006nW-Ji; Mon, 13 Oct 2008 20:30:51 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with esmtpa (Exim 4.52) id 1KpT7k-0001RI-87; Mon, 13 Oct 2008 20:30:36 +0100 Message-ID: From: "George Barwood" To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= , "Nicholas Weaver" Cc: "Namedroppers" References: <80CAC5D9-7BDD-44E1-ACC0-90A6D585B5C6@icsi.berkeley.edu> <1F51A6D7-BFFD-42BC-9FDA-71FBF84050E9@ICSI.Berkeley.EDU> Subject: Re: [dnsext] One other argument for local scope... Date: Mon, 13 Oct 2008 20:30:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: RFC 1034, section 4.2.1 states: << In particular, if the name of the name server is itself in the subzone, we could be faced with the situation where the NS RRs tell us that in order to learn a name server's address, we should contact the server using the address we wish to learn. To fix this problem, a zone contains "glue" RRs which are not part of the authoritative data, and are address RRs for the servers.These RRs are only necessary if the name server's name is "below" the cut, and are only used as part of a referral response. >> "Only necessary" implies that resolution will occur using only this specific type of glue, where the name of the name server is in the subzone. That specifically rules out cases where other kinds of glue are required, hence the example is outside the standard, and also I would suggest common sense. ----- Original Message ----- From: "JINMEI Tatuya / 神明é”哉" To: "Nicholas Weaver" Cc: "Namedroppers" Sent: Monday, October 13, 2008 6:38 PM Subject: Re: [dnsext] One other argument for local scope... > At Fri, 10 Oct 2008 12:00:12 -0700, > Nicholas Weaver wrote: > >> However, Ota also brings up an excellent point: DOES prevent me from >> saying to verisign: >> >> www.mydomain.com NS ns1.google.com >> ns1.google.com A 66.6.66.6 >> >> and then tricking a victim into visiting mydomain.com? >> >> A lot of my experimenting suggests that the resolvers I've testing >> (I'm building a Java test applet) will accept and follow such records, >> at least in the second level domain (I haven't tried attacking .com >> however). > > Please actually try attacking .com, then:-) > > Seriously, I'm very much interested in whether .com or any other major > top level domains would blindly accept such a bogus glue address > record. If they do, it would create even much stronger motivation to > implement and deploy additional defense. > > --- > 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: > -- to unsubscribe send a message to namedroppers-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 Oct 13 13:18: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 DEDDC3A684F; Mon, 13 Oct 2008 13:18:07 -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 nyMpS+7KPiMX; Mon, 13 Oct 2008 13:18:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BEABE3A67A2; Mon, 13 Oct 2008 13:18:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpToS-0000XA-DT for namedroppers-data@psg.com; Mon, 13 Oct 2008 20:14:44 +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 1KpToM-0000WJ-OT for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 20:14:41 +0000 Received: from monsoon.verisignlabs.com (scooter.bo.verisignlabs.com [172.25.170.10]) by cliffie.verisignlabs.com (Postfix) with ESMTP id DE05F136734; Mon, 13 Oct 2008 16:14:35 -0400 (EDT) Received: from dul1mcmlarson-l1.verisignlabs.com (dul1mcmlarson-l1.verisignlabs.com [10.131.244.205]) by monsoon.verisignlabs.com (Postfix) with ESMTP id D711D2422EF; Mon, 13 Oct 2008 16:14:35 -0400 (EDT) Date: Mon, 13 Oct 2008 16:14:30 -0400 From: Matt Larson To: Nicholas Weaver Cc: JINMEI Tatuya / ???????????? , Namedroppers Subject: Re: [dnsext] One other argument for local scope... Message-ID: <20081013201430.GG21959@dul1mcmlarson-l1.verisignlabs.com> References: <80CAC5D9-7BDD-44E1-ACC0-90A6D585B5C6@icsi.berkeley.edu> <1F51A6D7-BFFD-42BC-9FDA-71FBF84050E9@ICSI.Berkeley.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1F51A6D7-BFFD-42BC-9FDA-71FBF84050E9@ICSI.Berkeley.EDU> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, 10 Oct 2008, Nicholas Weaver wrote: > However, Ota also brings up an excellent point: DOES prevent me from > saying to verisign: An important and relevant point here is that you don't communicate directly with VeriSign to make changes in the .com registry; rather, you use an ICANN-accredited registrar. The .com registry is "thin": it contains no registrant-specific information. The registry only knows which registrar owns the domain. > www.mydomain.com NS ns1.google.com > ns1.google.com A 66.6.66.6 > > and then tricking a victim into visiting mydomain.com? There are two main kinds of objects in the .com registry, domains and name servers. Only the registrar that owns mydomain.com can make any changes to it. If the name server ns1.google.com already exists, any registrar can associate that name server with any of its domains. (This isn't a cache-poisoning attack vector: at worst, it sends unwanted traffic to authoritative name server.) However, only the registrar that owns google.com can make changes to ns1.google.com. If the same registrar owns both mydomain.com and google.com, then that registrar could make the changes described above. However, one hopes that the registrar's systems--which unlike the .com registry, do have knowledge of which specific users own which domains--would prevent the owner of mydomain.com from changing one of google.com's name servers (or creating a new name server under google.com). Matt -- to unsubscribe send a message to namedroppers-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 Oct 13 13:43: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 9659F3A69C3; Mon, 13 Oct 2008 13:43:49 -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 I-TAbl+M-OTe; Mon, 13 Oct 2008 13:43:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 86CB53A6928; Mon, 13 Oct 2008 13:43:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpU8j-0003Es-EY for namedroppers-data@psg.com; Mon, 13 Oct 2008 20:35:41 +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 1KpU8a-0003E8-Uq for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 20:35:39 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2774F33C23; Mon, 13 Oct 2008 21:36:56 +0100 (BST) Message-ID: <48F3B11B.8090202@links.org> Date: Mon, 13 Oct 2008 21:35:39 +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: Edward Lewis CC: Michael StJohns , Alex Bligh , Wouter Wijngaards , namedroppers@ops.ietf.org Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <48F33C34.3010901@nlnetlabs.nl> <48F35170.30900@links.org> <4B27E2458EBA97669B259355@Ximines.local> In-Reply-To: X-Enigmail-Version: 0.95.7 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: > At 12:38 -0400 10/13/08, Michael StJohns wrote: >> At 10:57 AM 10/13/2008, Edward Lewis wrote: >>> DNSSEC only says "this answer looks good" or "doesn't look good." >>> Trying to figure out whether the answer's disposition is >>> temporary/permanent, correct/incorrect, trustworthy/not takes more >>> than just the DNS data and more than just the query at hand. >> >> >> DNSSEC says the answer looks good - SECURE >> or doesn't look good - BOGUS >> or DNSSEC told me I shouldn't care about DNSSEC past some point - >> UNSECURE >> or I have no information which would let me determine what DNSSEC >> thinks about the data - UNKNOWN >> >> "Trustworthy" begs a definition here for what "looks good" means in >> relationship to "trusting" DNS data. > > This is the kind of debate that'll never end, judging from past > incarnations of this thread. To me, an answer that is under a trust > anchor and below a null DS set is "looks good" as far as DNSSEC is > concerned. I.e., to me, UNSECURE == SECURE == UNKNOWN, when I consider > the "bottom line" of the query-response. I guess I have a Machiavellian > (ends justify the means, i.e., all that matters are the ends) streak in me. Broadly I agree, except I think you can also choose BOGUS == UNSECURE == UNKNOWN. i.e. either trust everything that isn't bogus, or trust everything that is secure. Anyone who wants anything more nuanced than that can (and will, anyway) write their own s/w :-) Cheers, Ben. -- 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 Oct 13 22:31: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 308163A6BCF; Mon, 13 Oct 2008 22:31: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 vS5fQ0nQeanB; Mon, 13 Oct 2008 22:31:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 39F453A6BC2; Mon, 13 Oct 2008 22:31:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpcOA-0009Ha-6h for namedroppers-data@psg.com; Tue, 14 Oct 2008 05:24:10 +0000 Received: from [129.9.168.37] (helo=shbmap02.extra.chrysler.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpcO3-0009Gn-Ed for namedroppers@ops.ietf.org; Tue, 14 Oct 2008 05:24:06 +0000 Received: from shmsp085.shdc.chrysler.com (unknown [129.9.158.254]) by shbmap02.extra.chrysler.com (Symantec Mail Security) with ESMTP id 132A84E4002 for ; Tue, 14 Oct 2008 01:23:54 -0400 (EDT) X-AuditID: 8109a824-a821fbb000000bb5-9a-48f42ceae31b Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.98.85]) by shmsp085.shdc.chrysler.com (Symantec Mail Security) with ESMTP id B762A48A6 for ; Tue, 14 Oct 2008 01:23:53 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by wokcdts1.is.chrysler.com (8.13.6/8.9.1) with ESMTP id m9E5NrO6014237 for ; Tue, 14 Oct 2008 01:23:53 -0400 (EDT) Message-ID: <48F42CE9.7040204@chrysler.com> Date: Tue, 14 Oct 2008 01:23:53 -0400 From: Kevin Darcy User-Agent: Thunderbird 2.0.0.6 (X11/20070802) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> <20081011215903.A3A136BE02F@kilo.rtfm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Matthew Dempsky wrote: > On Sat, Oct 11, 2008 at 2:59 PM, Eric Rescorla wrote: > >> Is the suggestion that DNSCurve should be made an RFC? If so, it >> seems to me that a clear prerequisite to that discussion would be >> the existence of DNSCurve I-D. >> > > Yes. I've been working on a DNSCurve Internet-Draft since it was > brought up on Thursday, and I hope to have a publicly available draft > soon. > > >> Barring that, why exactly are we having a discussion about the >> practicality of a specific design decision in DNSCurve? >> > > I initially brought it up because I wanted to know if anyone knew of > *operational* issues with these limitations. I was well aware that > the RFCs limited names to 255 bytes. Did Bill Manning, Kevin Darcy, > or anyone else think I just coincidentally picked this number to ask > about? > No, I didn't think it was a "coincidence", but at the same time, I didn't know if you were aware how ancient, well-defined and well-established that particular limitation is. Is there any reason why the research into the operational impact of changing the name-size limitation can't be conducted in _parallel_ with the discussions over the merits of the DNSCurve draft itself? Drafts almost always have multiple revisions anyway, whatever operational information that comes to light in this regard can be incorporated -- to the extent it needs to be -- into a later revision of the draft... - Kevin -- to unsubscribe send a message to namedroppers-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 Oct 14 05:50: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 50AA43A6BB8; Tue, 14 Oct 2008 05:50:21 -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 ctQmOa9-dQp0; Tue, 14 Oct 2008 05:50:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6C50C3A6BA6; Tue, 14 Oct 2008 05:50:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpjAz-000E0J-69 for namedroppers-data@psg.com; Tue, 14 Oct 2008 12:39:01 +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 1KpjAq-000DxG-F3 for namedroppers@ops.ietf.org; Tue, 14 Oct 2008 12:38:55 +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 1KpjAI-0002w3-1G; Tue, 14 Oct 2008 14:38:18 +0200 Received: from fweimer by bfk.de with local id 1KpjAP-0007EZ-EP; Tue, 14 Oct 2008 14:38:25 +0200 To: "George Barwood" Cc: "Brian Dickson" , "Nicholas Weaver" , "Paul Vixie" , "Namedroppers" Subject: [dnsext] Re: George Barwood's Birthday Observation... References: <0D76492B-E1D2-44C5-8028-8C90C435323F@icsi.berkeley.edu> <30376.1220461021@nsa.vix.com> <8B015B13-1468-4D29-881B-A999CAEED017@ICSI.Berkeley.EDU> <48BECAC8.2000705@ca.afilias.info> <5638830B9F384E6999BB28668D1BEFAF@localhost> From: Florian Weimer Date: Tue, 14 Oct 2008 14:38:25 +0200 In-Reply-To: <5638830B9F384E6999BB28668D1BEFAF@localhost> (George Barwood's message of "Wed, 3 Sep 2008 22:06:44 +0100") Message-ID: <82ej2j1hdq.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: * George Barwood: > Some of the observed behavior is probably just a way of working around > broken resolvers / client programs that do not properly select a > random host when more than one is available. RFC 3484 prescribes an algorithm which does not select hosts randomly. > DNS is not a good vehicle for implementing large scale load balancing, > as it imposes unreasonable loads on clients and caches. Instead > routing techniques seem more appropriate to me, such as Anycast. I disagree. Host load-balancing should not be implemented at the routing layer. (Exceptions exist for infrastructure services.) The reason is that a domain name is much cheaper than a global routing table slot. On the other hand, I don't think DNS needs to accommodate services which require fast-changing DNS data at the cost of other design goals. --=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 Oct 14 07:26: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 9047928C1D0; Tue, 14 Oct 2008 07:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.564 X-Spam-Level: X-Spam-Status: No, score=-0.564 tagged_above=-999 required=5 tests=[AWL=-0.070, 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 NEXruvPrE8Dx; Tue, 14 Oct 2008 07:26:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1B3C228C1A4; Tue, 14 Oct 2008 07:26:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpkmC-0001a3-Jg for namedroppers-data@psg.com; Tue, 14 Oct 2008 14:21:32 +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 1Kpkls-0001Xc-4j for namedroppers@ops.ietf.org; Tue, 14 Oct 2008 14:21:21 +0000 Received: from [192.168.1.101] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m9EEL28K018106; Tue, 14 Oct 2008 10:21:03 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> Date: Tue, 14 Oct 2008 10:19:41 -0400 To: Michael StJohns From: Edward Lewis Subject: Re: CNAME/DNAME - Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: Edward Lewis , Ben Laurie , namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary="============_-988128433==_ma============" X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --============_-988128433==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I'll apologize, the indenting of quotes isn't working, so if I jumble up what I'm replying to... At 13:07 -0400 10/13/08, Michael StJohns wrote: >You sure about that answer? Pretend all you're doing is looking up Y. >Since Y is UNSECURE, shouldn't you get an answer with the AD bit cleared? >So shouldn't the compound answer also clear the AD bit? Back in 2001 Brian and I went on and on about the meaning of the AD bit. To me it meant that the DNSSEC process had been completed and we were happy. He said that "we were happy." The point of contention was how an authoritative server set the bit. In the first generation, authoritative servers would validate all records as they were read from the zone file or via XFR. (I forget how we dealt with dynamic update then.) This practice got quite onerous and Brian decided it wasn't worth the effort as "well, if you can't trust your own filesystem you are hosed." I'm pinning this as Brian vs. me, but I'm just doing that for the drama. Well, he and I went at it for 100+ messages. Finally he won - the AD bit meant that the answering server was happy with what it was giving back. An AD bit and a TSIG to the server was all a stub should need - i.e., TSIG says "I trust you" and the AD bit said "well, the one I trust is happy, ergo I am happy." So - if X and Z are signed and validated and Y is determined to not have any possible chance at being validated, all three are "happy" states and the AD bit ought to be set. I realize that there is a boat load of security professionals that are uncomfortable with the notion that you can declare something checked if there is nothing to check. That represented my position in the thread long ago. Truth is, the world is not as the security folks see. Most folks are "innocent until proven guilty" types, not "guilty until proven innocent." And that was reflected in the result of the thread and the RFC 3655 (obsoleted by the last round of DNSSEC RFCs). Let's go a bit further. Let's say that the validating intermediate resolver queried without the CD bit set gets SECURE, UNSECURE and BOGUS for the three legs of the triad. Should it return the SECURE and UNSECURE parts and also do a SERVFAIL? RFC 4035 - 5.5 is unclear on this: I don't think it matters what you choose to do, i.e., per-implementation choice won't violate interoperability. If a server replies with just X and Y (as SECURE and UNSECURE), the querier would realize the answer is not complete and have to go off and try to get Z (BOGUS) and see a SERVFAIL. IF the server immediately gives back a SERVFAIL, you save a round trip but the querier won't get the SECURE and UNSECURE X and Y. 5.5. Resolver Behavior When Signatures Do Not Validate If for whatever reason none of the RRSIGs can be validated, the response SHOULD be considered BAD. If the validation was being done to service a recursive query, the name server MUST return RCODE 2 to the originating client. *SOME* of the RRSIGs can be validated... *sigh* Does the response still return an RCODE 2? It's not meant to be interpreted as "some is the opposite of none" but "none" versus "at least one (chain) works." The problem is that this section is deficient - it only thinks of looking for X (no consideration of CNAME or DNAME). The text needs to be rewritten to handle CNAME and DNAME (or any other lookup altering) processing. This ought to be marked as an issue for the DNSSECbis document. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. --============_-988128433==_ma============ Content-Type: text/html; charset="us-ascii" Re: CNAME/DNAME - Re: [dnsext] flip-flopping secure and
I'll apologize, the indenting of quotes isn't working, so if I jumble up what I'm replying to...

At 13:07 -0400 10/13/08, Michael StJohns wrote:
>You sure about that answer?  Pretend all you're doing is looking up Y.
>Since Y is UNSECURE,  shouldn't you get an answer with the AD bit cleared?
>So shouldn't the compound answer also clear the AD bit?

Back in 2001 Brian and I went on and on about the meaning of the AD bit.  To me it meant that the DNSSEC process had been completed and we were happy.  He said that "we were happy."  The point of contention was how an authoritative server set the bit.

In the first generation, authoritative servers would validate all records as they were read from the zone file or via XFR.  (I forget how we dealt with dynamic update then.)  This practice got quite onerous and Brian decided it wasn't worth the effort as "well, if you can't trust your own filesystem you are hosed."

I'm pinning this as Brian vs. me, but I'm just doing that for the drama.

Well, he and I went at it for 100+ messages.  Finally he won - the AD bit meant that the answering server was happy with what it was giving back. An AD bit and a TSIG to the server was all a stub should need - i.e., TSIG says "I trust you" and the AD bit said "well, the one I trust is happy, ergo I am happy."

So - if X and Z are signed and validated and Y is determined to not have any possible chance at being validated, all three are "happy" states and the AD bit ought to be set.

I realize that there is a boat load of security professionals that are uncomfortable with the notion that you can declare something checked if there is nothing to check.  That represented my position in the thread long ago.  Truth is, the world is not as the security folks see.

Most folks are "innocent until proven guilty" types, not "guilty until proven innocent."  And that was reflected in the result of the thread and the RFC 3655 (obsoleted by the last round of DNSSEC RFCs).

Let's go a bit further.  Let's say that the validating intermediate resolver queried without the CD bit set gets SECURE, UNSECURE and BOGUS for the three legs of the triad.  Should it return the SECURE and UNSECURE parts and also do a SERVFAIL?  RFC 4035 - 5.5 is unclear on this:

I don't think it matters what you choose to do, i.e., per-implementation choice won't violate interoperability.

If a server replies with just X and Y (as SECURE and UNSECURE), the querier would realize the answer is not complete and have to go off and try to get Z (BOGUS) and see a SERVFAIL.  IF the server immediately gives back a SERVFAIL, you save a round trip but the querier won't get the SECURE and UNSECURE X and Y.


5.5.  Resolver
Behavior When Signatures Do Not Validate

   If for whatever reason none of the RRSIGs can be validated,
the
   response SHOULD be considered BAD.  If the validation
was being done
   to service a recursive query, the name server MUST return
RCODE 2 to
   the originating client.


*SOME* of the RRSIGs can be validated... *sigh*  Does the response still return an RCODE 2?

It's not meant to be interpreted as "some is the opposite of none" but "none" versus "at least one (chain) works."  The problem is that this section is deficient - it only thinks of looking for X (no consideration of CNAME or DNAME).  The text needs to be rewritten to handle CNAME and DNAME (or any other lookup altering) processing.

This ought to be marked as an issue for the DNSSECbis document.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.
--============_-988128433==_ma============-- -- to unsubscribe send a message to namedroppers-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 Oct 14 07:30: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 47AAA28C1D8; Tue, 14 Oct 2008 07:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.182 X-Spam-Level: X-Spam-Status: No, score=0.182 tagged_above=-999 required=5 tests=[AWL=-0.812, BAYES_05=-1.11, 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 nDiaoCaQ62YF; Tue, 14 Oct 2008 07:30:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6243E28C1D6; Tue, 14 Oct 2008 07:30:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kpkrj-0002Ok-Uj for namedroppers-data@psg.com; Tue, 14 Oct 2008 14:27: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 1KpkrZ-0002NX-Ae for namedroppers@ops.ietf.org; Tue, 14 Oct 2008 14:27:08 +0000 Received: from [192.168.1.101] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m9EEQbLk018173; Tue, 14 Oct 2008 10:26:37 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <48F3B11B.8090202@links.org> References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <48F33C34.3010901@nlnetlabs.nl> <48F35170.30900@links.org> <4B27E2458EBA97669B259355@Ximines.local> <48F3B11B.8090202@links.org> Date: Tue, 14 Oct 2008 10:26:05 -0400 To: Ben Laurie From: Edward Lewis Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: Edward Lewis , Michael StJohns , Alex Bligh , Wouter Wijngaards , namedroppers@ops.ietf.org 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: At 21:35 +0100 10/13/08, Ben Laurie wrote: >Broadly I agree, except I think you can also choose BOGUS == UNSECURE == >UNKNOWN. Such a strategy is akin to (today) only using IPv6. ;) That is, most of the network is not doing DNSSEC and not doing IPv6. Equating SEURE, UNSECURE, and UNKNOWN is what I think is more to the spirit of DNSSEC and incremental deployment. It's a recognition that what can be secure is but you still have access to the legacy network. Equating BOGUS, UNSECURE, and UNKNOWN is a paranoid strategy, only trusting what you can see and touch. In some circles I can understand the paranoia. But most of the economy needs open access and a willingness to accept risk. >Anyone who wants anything more nuanced than that can (and will, anyway) >write their own s/w :-) I hope they also realize they are a, umm, niche market... ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 14 07:34: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 B63903A6B36; Tue, 14 Oct 2008 07:34: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=[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 CrjclyWhwjDC; Tue, 14 Oct 2008 07:34:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B96CE3A6B2F; Tue, 14 Oct 2008 07:34:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpksU-0002Xj-6V for namedroppers-data@psg.com; Tue, 14 Oct 2008 14:28:02 +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 1KpksL-0002WW-VO for namedroppers@ops.ietf.org; Tue, 14 Oct 2008 14:27:55 +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 m9EEVkN3018931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 14 Oct 2008 07:31:49 -0700 Date: Tue, 14 Oct 2008 10:27:47 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] DNS Extensions session scheduled Message-ID: <20081014142747.GD52988@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]); Tue, 14 Oct 2008 07:31:50 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, The proposed agenda for IETF-73 is up, and we have a one hour and forty minute slot slot on Tuesday afternoon, from 15:20-17:00. If this is a problem, please let us know as soon as possible. This is also an opportunity to ask for time on the agenda. We expect to be discussing additional forgery resilience techniques in the meeting. If you have other items that need discussing, please let Olafur and me know as soon as possible. Best, 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 Tue Oct 14 07:39: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 78B5C28C1C1; Tue, 14 Oct 2008 07:39:54 -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 GbH6mWyMK-Ui; Tue, 14 Oct 2008 07:39:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 550403A659A; Tue, 14 Oct 2008 07:39:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kpl0b-0003jZ-70 for namedroppers-data@psg.com; Tue, 14 Oct 2008 14:36:25 +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 1Kpl0I-0003gb-Uz for namedroppers@ops.ietf.org; Tue, 14 Oct 2008 14:36:15 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 3744933C1F; Tue, 14 Oct 2008 15:37:31 +0100 (BST) Message-ID: <48F4AE5E.3080606@links.org> Date: Tue, 14 Oct 2008 15:36:14 +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: Edward Lewis CC: Michael StJohns , Alex Bligh , Wouter Wijngaards , namedroppers@ops.ietf.org Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <48F33C34.3010901@nlnetlabs.nl> <48F35170.30900@links.org> <4B27E2458EBA97669B259355@Ximines.local> <48F3B11B.8090202@links.org> In-Reply-To: X-Enigmail-Version: 0.95.7 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: > At 21:35 +0100 10/13/08, Ben Laurie wrote: > >> Broadly I agree, except I think you can also choose BOGUS == UNSECURE == >> UNKNOWN. > > Such a strategy is akin to (today) only using IPv6. ;) That is, most of > the network is not doing DNSSEC and not doing IPv6. > > Equating SEURE, UNSECURE, and UNKNOWN is what I think is more to the > spirit of DNSSEC and incremental deployment. It's a recognition that > what can be secure is but you still have access to the legacy network. > > Equating BOGUS, UNSECURE, and UNKNOWN is a paranoid strategy, only > trusting what you can see and touch. > > In some circles I can understand the paranoia. But most of the economy > needs open access and a willingness to accept risk. In other words: you agree that you can also choose it. > >> Anyone who wants anything more nuanced than that can (and will, anyway) >> write their own s/w :-) > > I hope they also realize they are a, umm, niche market... ;) -- 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 Tue Oct 14 07:55: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 0632D3A6B2F; Tue, 14 Oct 2008 07:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.395 X-Spam-Level: X-Spam-Status: No, score=0.395 tagged_above=-999 required=5 tests=[AWL=-0.969, BAYES_20=-0.74, 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 r1LHuqb3M-R2; Tue, 14 Oct 2008 07:55:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E2F223A659A; Tue, 14 Oct 2008 07:55:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KplEE-00066r-8A for namedroppers-data@psg.com; Tue, 14 Oct 2008 14:50: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 1KplE2-00064V-W9 for namedroppers@ops.ietf.org; Tue, 14 Oct 2008 14:50:24 +0000 Received: from [192.168.1.101] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m9EEntux018443; Tue, 14 Oct 2008 10:49:56 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <48F4AE5E.3080606@links.org> References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <48F33C34.3010901@nlnetlabs.nl> <48F35170.30900@links.org> <4B27E2458EBA97669B259355@Ximines.local> <48F3B11B.8090202@links.org> <48F4AE5E.3080606@links.org> Date: Tue, 14 Oct 2008 10:49:49 -0400 To: Ben Laurie From: Edward Lewis Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: Edward Lewis , Michael StJohns , Alex Bligh , Wouter Wijngaards , namedroppers@ops.ietf.org 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: At 15:36 +0100 10/14/08, Ben Laurie wrote: >In other words: you agree that you can also choose it. You can choose whatever you want whenever you want. Local policy always trumps all other policies. There's what I would recommend for "general purpose implementations" and then there is what I would implement for turnkey implementations. All that matters is that they ultimately interoperate and still meet each situation's needs. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 14 08:32: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 5A59F3A6862; Tue, 14 Oct 2008 08:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.674 X-Spam-Level: X-Spam-Status: No, score=-4.674 tagged_above=-999 required=5 tests=[AWL=0.374, 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 xHFxv9P5VBFE; Tue, 14 Oct 2008 08:32:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 891E63A6A1E; Tue, 14 Oct 2008 08:32:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kpljk-000ArM-B7 for namedroppers-data@psg.com; Tue, 14 Oct 2008 15:23:04 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpljS-000Api-5N for namedroppers@ops.ietf.org; Tue, 14 Oct 2008 15:22:51 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9EFLvQ9015321; Tue, 14 Oct 2008 08:21:57 -0700 (PDT) Cc: Nicholas Weaver , Ben Laurie , Michael StJohns , Alex Bligh , Wouter Wijngaards , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Edward Lewis 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 v929.2) Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Date: Tue, 14 Oct 2008 08:21:56 -0700 References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <48F33C34.3010901@nlnetlabs.nl> <48F35170.30900@links.org> <4B27E2458EBA97669B259355@Ximines.local> <48F3B11B.8090202@links.org> X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Oct 14, 2008, at 7:26 AM, Edward Lewis wrote: > At 21:35 +0100 10/13/08, Ben Laurie wrote: > >> Broadly I agree, except I think you can also choose BOGUS == >> UNSECURE == >> UNKNOWN. > > Such a strategy is akin to (today) only using IPv6. ;) That is, > most of the network is not doing DNSSEC and not doing IPv6. > > Equating SEURE, UNSECURE, and UNKNOWN is what I think is more to the > spirit of DNSSEC and incremental deployment. It's a recognition > that what can be secure is but you still have access to the legacy > network. > > Equating BOGUS, UNSECURE, and UNKNOWN is a paranoid strategy, only > trusting what you can see and touch. > > In some circles I can understand the paranoia. But most of the > economy needs open access and a willingness to accept risk. Then why not the following: DNSSEC has two uses: Secure name lookup, and as Another CA Infrastructure Run By Verisign Combined With A Hierarchical Distributed Integrity Data Store for small datums. For "Another CA Infrastructure", the end application needs full control and full information, and a much richer API then gethostbyname(). But for secure name lookup, DNSSEC's additional protection is against in-path adversaries. The adversary on the wire is not a real concern to my mind for DNS (its a concern for the end application). But as witnessed by David Dagon's work, ISP's which wildcard failures, and even legitimate sites like OpenDNS man-in-the-middling some names ( dig www.google.com @208.67.222.222 ), the recursive resolver IS an in-path adversary and a serious concern. Thus why not the following default policy: If the host's stub resolver is actually caring about DNSSEC ("secure name lookup"), operate in the following mode: a) If the stub resolver can fully validate a complete signature chain for the record returned from the recursive resolver, accept it, cache it, return it for gethostbyname() and have a nice day. b) If, FOR ANY REASON, the stub resolver can not fully validate the complete signature chain (expired signature, bad signature, recursive resolver lying, recursive resolver stating "What's DNSSEC d00d?"), it conducts a complete recursive fetch of its own to get the value to be returned to the querying application, and does not cache any record that doesn't have a valid signature. This way, all failures of DNSSEC (or failure to USE DNSSEC) will still resolve, and, as importantly, they will resolve over what will be effectively the same path for in-path adversaries as the application will face. I will argue that this is the correct behavior, because any application which would trust the name is probably vulnerable to the MitM anyway, so you haven't increased the vulnerability to the end application generating the query, but did not act as a denial-of- service attack because of a signature failure. -- to unsubscribe send a message to namedroppers-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 Oct 14 11:15: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 BBC3F3A6B08; Tue, 14 Oct 2008 11:15:11 -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 CoNuUW5+I4MA; Tue, 14 Oct 2008 11:15:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1DC563A6B03; Tue, 14 Oct 2008 11:15:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpoIi-0009Q7-Po for namedroppers-data@psg.com; Tue, 14 Oct 2008 18:07:20 +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 1KpoIM-0009Nk-Sx for namedroppers@ops.ietf.org; Tue, 14 Oct 2008 18:07: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 m9EI6uJI020634 for ; Tue, 14 Oct 2008 14:06: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 m9EI6u2I020633 for namedroppers@ops.ietf.org; Tue, 14 Oct 2008 14:06:56 -0400 (EDT) (envelope-from namedroppers) Received: from [209.85.200.169] (helo=wf-out-1314.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KoOuo-0008nX-Ok for namedroppers@ops.ietf.org; Fri, 10 Oct 2008 20:48:53 +0000 Received: by wf-out-1314.google.com with SMTP id 26so826501wfd.32 for ; Fri, 10 Oct 2008 13:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:to:in-reply-to :content-type:content-transfer-encoding:mime-version:subject:date :references:x-mailer:from; bh=a1ikAc2k3KPJakzMDqqoAoLzv8ittOfr/efOa3zGKkM=; b=bWEnxEyzD+530PNBdEUX2VnTT2brK7Wm2a5FnANiAOlXfnqOA+iWoFWDz16ab2NDmD PScKxLSFjdYw0Mcrign0UDl4Rw9q+rxLxXtQSCgQabo7Wf4149fNXP6DbGckDwygg6Hv kdcl9MuX5x7BvQSVnR8RfMrOVCoisapPpOgkY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:to:in-reply-to:content-type:content-transfer-encoding :mime-version:subject:date:references:x-mailer:from; b=FqUzjsOgtn2CI95rLX1NJ+1QG02qe8NwV4rwU2PQ7Coqr1mJ5r6ONIvaY0kI9ff8KX d690qqG8NhkF4tsUN/1yH7rcPdHVZpPtFMGhHKoI9uf0acyVreFH1LJVzgZndpQrb1T8 OWxFDTjT3gkZLO2lLzlfYqZf5B/E8IU8uUNLE= Received: by 10.142.251.15 with SMTP id y15mr1051500wfh.39.1223671729233; Fri, 10 Oct 2008 13:48:49 -0700 (PDT) Received: from SJC-Office-NAT-220.mail-abuse.org (SJC-Office-NAT-220.mail-abuse.org [168.61.10.220]) by mx.google.com with ESMTPS id 30sm5080473wfg.9.2008.10.10.13.48.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 10 Oct 2008 13:48:47 -0700 (PDT) Cc: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT_chair?= , namedroppers@ops.ietf.org, ietf@ietf.org Message-Id: <93CDCF0E-A8B2-4039-840B-D6622630A63C@mail-abuse.org> To: Nicholas Weaver In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [dnsext] Last Call: draft-ietf-dnsext-forgery-resilience (Measures for making DNS more resilient against forged answers) to Proposed Standard Date: Fri, 10 Oct 2008 13:48:44 -0700 References: <20081002221539.DDFBB3A690B@core3.amsl.com> <9D4D9C40-3503-4C85-9236-BE75F4139019@icsi.berkeley.edu> <200810091652.m99GqsCc063601@stora.ogud.com> X-Mailer: Apple Mail (2.929.2) From: Doug Otis 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. ] On Oct 9, 2008, at 10:48 AM, Nicholas Weaver wrote: > On Oct 9, 2008, at 9:52 AM, =D3lafur Gu=F0mundsson /DNSEXT chair = wrote: >> At 19:17 02/10/2008, Nicholas Weaver wrote: >>> I believe this draft is insufficient: >>> >>> 4.1: Frankly speaking, with all the mechanisms out there, you =20 >>> must assume that an attacker can force queries of the attacker's =20 >>> choosing at times of the attacker's choosing, within a fraction of =20= >>> a second in almost all cases. This is not by directly generating =20= >>> a request to the server, but by performing some application =20 >>> operation (eg, mail request where the SMTP resolver checks it, a =20 >>> Javascript loaded in a victim's browser, etc. Preventing external =20= >>> recursive queries is about as an effective defense as a chalk line =20= >>> on the ground saying "do not cross". >> >> While this is true in general, there are number of situations where =20= >> not allowing "out-side" queries helps. >> For example: >> - Sites that run separate DNS recursive resolvers/caches for mail =20= >> servers than are used by user population in general. >> - Sites that are able to keep malware off internal hosts limit the =20= >> ability of attackers to issue queries from the inside. > > Sites that don't allow their users to visit ANY external web =20 > sites... An attacker who can get a user to visit a web site of the =20= > attacker's choosing can cause the DNS resolvers to issue an =20 > arbitrary stream of requests, EVEN without javascript, just iframes =20= > and redirections. > > When developing a defensive posture for a DNS resolver, you MUST (in =20= > the strict standard sense, capitalization is deliberate!) assume the =20= > attacker can generate an arbitrary request stream: there are simply =20= > too many vectors which an attacker can do so to consider it =20 > plausible to shut them down. > > Although it may be a good idea for other reasons to prevent external =20= > use of your institution's recursive resolver, the net security gain =20= > is negligible. Agreed. An MUA or MTA might be used to autonomously generate DNS =20 queries to both evil and victim name servers. There are MUA plugins =20 that will also attempt to resolve email path registration records with =20= a sizable series of DNS transactions for A, AAAA, or MX records. The =20= script-like resolution process can be directed by a cached resource =20 record, where subsequent transactions can be modulated by a macro =20 employing the email-address of originator's local-part (MAIL-FROM or =20 PRA). A sequence of 100 transactions can be controlled by an attacker =20= that are directed to both evil and victim name servers where neither =20 are directly referenced by the message. The sequencing process could =20= be instantiated by a routine that is bound to a UDP port, or that =20 navigates through a NAT where port diversity might be greatly =20 reduced. Both the poisoning timing and the opportunity would be =20 afforded by spam while consuming little of the attackers resources, =20 beyond the additional poison. This could poison the cache used by =20 user population as well as the cache used by the MTA. This approach =20 offers the attack two advantages, ample opportunity while also =20 overwhelming the authoritative name server. : ( >>> Section 4 also excludes two significant additional entropy sources =20= >>> which can't always be used but can often be used: 0x20 matching =20 >>> and duplication, since ~32b entropy is only marginally sufficient, =20= >>> but 40b + (achievable through 0x20 and/or duplication) is for =20 >>> protecting the cache. >> >> After some discussion in the WG this was explicitly ruled outside =20 >> the scope of the document. For the record most of the attacks I'm =20 >> seeing are trying to spoof the root and TLD's using "mostly =20 >> numeric" domain names, in these cases x20 provides limited defense. > > However, those attacks are only able to work because of the race-=20 > until-win properties. > > The TTLs for these records are relatively long, thus without race =20 > until win, the attack window is very narrow. > > Where 0x20 provides protection is on names with short/0 TTL, which =20 > includes many rather important sites (googlemail.l.google.com, =20 > login.yahoo.akadns.net) which also happen to have rather long names. DKIM provides an interesting feature. It uses arbitrary sub-domain =20 names to reference public keys. Once an attack detects success =20 through a number of techniques, poisonous keys can then validate =20 signed email sent to any recipient using the same resolver. > More important I think is the lack of discussing the semantics of =20 > duplication. Duplication is a really powerful tool for increasing =20 > entropy if you believe 32b of entropy is insufficient and there =20 > isn't enough additional entropy obtained by 0x20. There are too many situations, such as the one described, where it =20 would be wrong to assume there is 32b of entropy, where a few case =20 bits would become fairly significant. Detecting a possible attack for =20= a specific resource (or its hash) and checking for two matching =20 answers seems like a better long term solution. > Additionally, since you CAN detect that you are under a generic =20 > attack if you have at least 32b of entropy (just count unsolicited =20 > responses), you can respond with duplication to effectively double =20 > your entropy to 64b during the period in which you are under attack. The attack detection would need to resolve against each resource =20 separately, or this could double the effect of a path registration =20 DDoS attack. > Thus if the document EXCLUDES 0x20 and duplication, it should =20 > explicitly state something to the effect: There are additional =20 > mechanisms which can be used to increase query entropy in most (but =20= > not necessarily all) cases, such as 0x20 randomization [cite] and =20 > packet duplication. They are deliberately excluded from this =20 > document for reasons X,Y,Z. Agreed, with the proviso that the detection technique limits =20 duplication to that of the attacked resource. >>> Likewise, section 7-8 explicitly ignore the effects of "race until =20= >>> win". As long as a resolver will accept any additional data from =20= >>> a result into the cache, even when in scope (section 6's =20 >>> recommendations enable race-until-win attacks), TTL becomes 0 =20 >>> regardless of the actual TTL of the record. This is the real =20 >>> power of the Kaminski attack: it is not a reduction in packet-work =20= >>> for the attacker, but a reduction in time. >> >> This is also in the 'data admission' category not the 'packet =20 >> acceptance' but it supports one of my favorite saying: =20 >> "Optimization is the root cause of most problems". In this case =20 >> people were hoping to decrease the number of queries by learning by =20= >> a side effect. > > Then there needs to be an explicit reference of the sort: > > These equations depend not only on the packet acceptance policy, but =20= > also the data admission policy. Unless data admission policies are =20= > changed to be significantly more restrictive than the current =20 > standard specifies, race-until-win attacks are possible where an =20 > attacker can keep attempting to poison a target name regardless of =20 > TTL. As long as race-until-win attacks are possible, one MUST =20 > assume that TTL =3D W for all defensive calculations. > > There is also an assumption that there is duplicate-outstanding-=20 > request supression (no birthday attacks), which I don't believe is =20 > explicitly stated. Agreed. -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 Tue Oct 14 11:16: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 5274F3A67F8; Tue, 14 Oct 2008 11:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.576 X-Spam-Level: X-Spam-Status: No, score=-0.576 tagged_above=-999 required=5 tests=[AWL=-0.081, 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 zfcOXD4hIWfM; Tue, 14 Oct 2008 11:16:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 119253A6862; Tue, 14 Oct 2008 11:16:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpoIu-0009SK-1E for namedroppers-data@psg.com; Tue, 14 Oct 2008 18:07:32 +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 1KpoIh-0009Pq-MA for namedroppers@ops.ietf.org; Tue, 14 Oct 2008 18:07: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 m9EI7Afd020644 for ; Tue, 14 Oct 2008 14:07:10 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m9EI7AwA020643 for namedroppers@ops.ietf.org; Tue, 14 Oct 2008 14:07:10 -0400 (EDT) (envelope-from namedroppers) Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpmnX-000LPH-Bm for namedroppers@ops.ietf.org; Tue, 14 Oct 2008 16:31:13 +0000 Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id m9EGUQOw006237 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 14 Oct 2008 12:30:27 -0400 Date: Tue, 14 Oct 2008 12:30:25 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Florian Weimer cc: George Barwood , Brian Dickson , Nicholas Weaver , Paul Vixie , Namedroppers Subject: Re: [dnsext] Re: George Barwood's Birthday Observation... In-Reply-To: <82ej2j1hdq.fsf@mid.bfk.de> Message-ID: 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: [ Note: Post was moderated. ] On Tue, 14 Oct 2008, Florian Weimer wrote: > > Some of the observed behavior is probably just a way of working around > > broken resolvers / client programs that do not properly select a > > random host when more than one is available. > > RFC 3484 prescribes an algorithm which does not select hosts randomly. And there is no requirement in any draft that a resolver select a random host when more than one is available. > > DNS is not a good vehicle for implementing large scale load > > balancing, as it imposes unreasonable loads on clients and caches. > > Instead routing techniques seem more appropriate to me, such as > > Anycast. Anycast is not suitable for stateful services, such as those over TCP, and some UDP services are also stateful. (RFC1546 states that explicitly) > I disagree. Host load-balancing should not be implemented at the > routing layer. (Exceptions exist for infrastructure services.) The > reason is that a domain name is much cheaper than a global routing > table slot. > > On the other hand, I don't think DNS needs to accommodate services > which require fast-changing DNS data at the cost of other design > goals. Exactly right. I would add that load balancing is an application layer service. The load balancer generally has have enough application specific information to be able to keep the application state correct amount the balanced hosts. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-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 Oct 14 11: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 DA5523A6B34; Tue, 14 Oct 2008 11:58:16 -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 hukBcFFSORQG; Tue, 14 Oct 2008 11:58:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 33FD33A63EC; Tue, 14 Oct 2008 11:58:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kpp1K-000GK5-Ae for namedroppers-data@psg.com; Tue, 14 Oct 2008 18:53:26 +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 1Kpp1F-000GJR-7f for namedroppers@ops.ietf.org; Tue, 14 Oct 2008 18:53:23 +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 m9EIvEwD007963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 14 Oct 2008 11:57:17 -0700 Date: Tue, 14 Oct 2008 14:53:15 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Some notes on ipv4/ipv6 co-existence Message-ID: <20081014185314.GK54079@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]); Tue, 14 Oct 2008 11:57:18 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: {No hat] Dear colleagues, I was planning to write up these notes in a more formal way, but it seems these days that more work is going on the TODO than is coming off it, so I thought I'd better send some remarks to the list instead. In Dublin, you'll remember, the WG received a warning that "something was coming" with respect to IPv4/IPv6 co-existence, and that we'd need to keep our eyes peeled, but we didn't really know much more. I attended an interim meeting on IPv4/IPv6 co-existence in Montreal at the beginning of October. There are a number of interesting proposals on the table. You can read about the meeting at http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim. The minutes are there as well. One class of proposals tries revivifying something like NAT-PT. The reason this is important for DNS is that these proposals all involve some sort of translation of (for instance) A records into AAAA records, in order to make resolution work (just as NAT-PT itself did). Some documents that are useful reading: http://tools.ietf.org/html/draft-wing-nat-pt-replacement-comparison http://tools.ietf.org/html/draft-baker-behave-ivi http://tools.ietf.org/html/draft-xli-behave-ivi http://tools.ietf.org/html/draft-jennings-behave-nat6 http://tools.ietf.org/html/draft-bagnulo-behave-nat64 http://tools.ietf.org/html/draft-endo-v6ops-dnsproxy It's worth pointing out that many of these appear to be relying on the "dumb stub resolver" model. So they add the "translation" function to a "translation-enabled resolver" (thus avoiding the dangerous word "DNS-ALG"). The DNSSEC implication is obvious: a validating translator could validate the original response, then translate, and hand the translated answer back to the stub. This won't work for validating end points, though, so there's going to be some trouble. There are various clever answers to this being floated right now. At least some of the discussion is continuing on the v4v6interim mailing list. If you're interested in this topics, that wouldn't be a bad list to watch. One current suggestion (not in any draft I've yet read, but I believe it came from Dan Wing) is to teach a validating end node about the translation, and then allow it to "strip off" the translation and validate that way; or (what I like better) not to translate if the translator gets a signal that the end point can do it on its own. My experience at the meeting was very positive: for the most part, the people proposing solutions were very receptive to concerns raised about the potential DNS effects. One area that I think may be a potential area of some disagreement is on the very idea that middleboxes should be altering the authoritative data before responding to the client. Many people seem to think that, since split-brain has been deployed for a long time in corporate environments, this is just a small change. In any case, I think that those attempting to get v4 and v6 networks talking to one another have a clear understanding that there is potential harm that could come from this, and they are actively seeking input from people with a DNS background. Therefore, if you can spare the time, it would be very helpful to send comments and suggestions I'm not sure that namedroppers is (yet) the right venue for discussion of any of these proposals, although it's possible that they'll end up as proposed working group items. In the meantime, if you have any questions about anything I may have said (or failed to say) at the interim, please feel free to ask. Best regards, Andrew -- 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 Tue Oct 14 13:00: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 359733A68B2; Tue, 14 Oct 2008 13:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.539 X-Spam-Level: ** X-Spam-Status: No, score=2.539 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzeNt8wuexxd; Tue, 14 Oct 2008 13:00:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 495C13A6801; Tue, 14 Oct 2008 13:00:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kppxi-000PQe-VM for namedroppers-data@psg.com; Tue, 14 Oct 2008 19:53:46 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kppxb-000PPb-29 for namedroppers@ops.ietf.org; Tue, 14 Oct 2008 19:53:42 +0000 Received: from [172.23.170.146] (helo=anti-virus03-09) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1KppxF-0006cg-Iq; Tue, 14 Oct 2008 20:53:17 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with esmtpa (Exim 4.52) id 1KppxE-0005Q1-Sr; Tue, 14 Oct 2008 20:53:16 +0100 Message-ID: <75CE499753A64652A09017EB9FF40BBB@localhost> From: "George Barwood" To: "Florian Weimer" Cc: "Brian Dickson" , "Nicholas Weaver" , "Paul Vixie" , "Namedroppers" References: <0D76492B-E1D2-44C5-8028-8C90C435323F@icsi.berkeley.edu><30376.1220461021@nsa.vix.com><8B015B13-1468-4D29-881B-A999CAEED017@ICSI.Berkeley.EDU><48BECAC8.2000705@ca.afilias.info><5638830B9F384E6999BB28668D1BEFAF@localhost> <82ej2j1hdq.fsf@mid.bfk.de> Subject: [dnsext] Re: George Barwood's Birthday Observation... Date: Tue, 14 Oct 2008 20:52:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ----- Original Message ----- From: "Florian Weimer" To: "George Barwood" Cc: "Brian Dickson" ; "Nicholas Weaver" ; "Paul Vixie" ; "Namedroppers" Sent: Tuesday, October 14, 2008 1:38 PM Subject: Re: George Barwood's Birthday Observation... Florian > On the other hand, I don't think DNS needs to accommodate services Florian > which require fast-changing DNS data at the cost of other design goals. On the other hand practical recursive resolvers have to accomodate these "awkward" authorities, or they will not be useable. Today I have been experimenting as follows: if full convergence does not occur after say 10 queries, apply a weaker check that may discard unchecked RRsets where the owner name does not match the question. With Akamai ( which is the only really tricky case I have found ), this typically results in 7 out of 9 of the glue A records being cached ( as well as the NS records). The other two, if required, are fetched later with a specific query. However there is a problem : in some sense Akamai needs "whole response" integrity ( which is stronger than RRset integrity ), if the resolver is to be sure of having 9 distinct IP addresses for the name servers. I don't think it is a practical problem in the Akamai case, because the probability of getting just 1 server from nine is small, but one can make a simple hypothetical example (see below) where the resolver can end up with only 1 IP address. This is also a problem for Nicolas Weaver's "cache policy". Example: Query: www.example.com Response: example.com NS ns1.example.com example.com NS ns2.example.com ns1.example.com A 1.1.1.1 ( not cached, per cache policy ) ns2.example.com A 1.1.1.2 ( not cached, per cache policy ) Query: ns1.example.com Response: ns1.example.com A 1.1.1.1 Query: ns2.example.com Response: ns2.example.com A 1.1.1.1 ( but will return 1.1.1.2 sometimes ) Since "whole response" integrity can be expensive with Akamai ( I observed a case where 97 queries were needed for full convergence ), I'm now going to investigate the another approach : "resolving glue". For the example given, when normal convergence is slow, we cache instead example.com NSA 1.1.1.1 example.com NSA 1.1.1.2 Another fallback is verifying just the data values, rather than the full RR, on the plausible assumption that an attacker needs to inject values under his control to do any serious damage. -- to unsubscribe send a message to namedroppers-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 Oct 14 13:10: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 A3BC53A6B3F; Tue, 14 Oct 2008 13:10:05 -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 lqR+mfjBwjR6; Tue, 14 Oct 2008 13:10:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 246D03A6B42; Tue, 14 Oct 2008 13:10:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpqAF-0001mi-FU for namedroppers-data@psg.com; Tue, 14 Oct 2008 20:06:43 +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 1KpqA6-0001jB-0p for namedroppers@ops.ietf.org; Tue, 14 Oct 2008 20:06: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 m9EKASfh013709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 14 Oct 2008 13:10:31 -0700 Date: Tue, 14 Oct 2008 16:06:30 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Some notes on ipv4/ipv6 co-existence Message-ID: <20081014200629.GW54079@commandprompt.com> References: <20081014185314.GK54079@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081014185314.GK54079@commandprompt.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]); Tue, 14 Oct 2008 13:10:32 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Oct 14, 2008 at 02:53:15PM -0400, Andrew Sullivan wrote: > {No hat] > least some of the discussion is continuing on the v4v6interim mailing > list. If you're interested in this topics, that wouldn't be a bad Oh, heck, I forgot about another list as well, which is 46translation@employees.org. That's where current narrowly-focussed translation discussion is happening. When they announced it, they specifically asked for others who might be interested, so if you are, have a look. This list does not seem to be linked from any IETF pages at the moment. 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 Tue Oct 14 15:58: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 925C33A6C11; Tue, 14 Oct 2008 15:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.35 X-Spam-Level: X-Spam-Status: No, score=-99.35 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, 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 Gk+-dcfi7ZP6; Tue, 14 Oct 2008 15:58:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9C2FF3A6C03; Tue, 14 Oct 2008 15:58:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KpsiC-000MgJ-Pp for namedroppers-data@psg.com; Tue, 14 Oct 2008 22:49:56 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kpsi4-000Mfq-Bn for namedroppers@ops.ietf.org; Tue, 14 Oct 2008 22:49:51 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id 5460D33C5B; Tue, 14 Oct 2008 15:49:47 -0700 (PDT) Date: Tue, 14 Oct 2008 15:49:47 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "George Barwood" Cc: "Nicholas Weaver" , "Namedroppers" Subject: Re: [dnsext] One other argument for local scope... In-Reply-To: References: <80CAC5D9-7BDD-44E1-ACC0-90A6D585B5C6@icsi.berkeley.edu> <1F51A6D7-BFFD-42BC-9FDA-71FBF84050E9@ICSI.Berkeley.EDU> 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=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Mon, 13 Oct 2008 20:30:25 +0100, "George Barwood" wrote: > << In particular, if the name of the name server is itself in the subzone, > we could be faced with the situation where the NS RRs tell us that in order > to learn a name server's address, we should contact the server using the > address we wish to learn. To fix this problem, a zone contains "glue" RRs > which are not part of the authoritative data, and are address RRs for the > servers.These RRs are only necessary if the name server's name is "below" > the cut, and are only used as part of a referral response. >> > > "Only necessary" implies that resolution will occur using only this specific > type of glue, where the name of the name server is in the subzone. > > That specifically rules out cases where other kinds of glue are required, > hence the example is outside the standard, and also I would suggest common > sense. I'm afraid we're talking about different things. My specific comment/question in the previous response was about domain registration phase, where the name resolution rules defined in RFC1034 don't matter. --- 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 Wed Oct 15 09:24: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 9862D28C287; Wed, 15 Oct 2008 09:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 FY9CFDR9xurL; Wed, 15 Oct 2008 09:24:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8FE0528C277; Wed, 15 Oct 2008 09:24:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kq8z8-000CbU-C0 for namedroppers-data@psg.com; Wed, 15 Oct 2008 16: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 1Kq8z1-000CaR-8I for namedroppers@ops.ietf.org; Wed, 15 Oct 2008 16:12:25 +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 m9FGCKYK031714 for ; Wed, 15 Oct 2008 12:12:20 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200810151612.m9FGCKYK031714@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 15 Oct 2008 12:12:07 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: [dnsext] DNS profile effort Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_429330244==.ALT" X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --=====================_429330244==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear colleagues, As discussed previously the chairs were to make a decision by the end of September on the fate of DNS Profile document. Due to lack of progress on that document we regret there is no other option but to cancel the effort. Olafur and Andrew --=====================_429330244==.ALT Content-Type: text/html; charset="us-ascii"
Dear colleagues,

As discussed previously the chairs were to make a decision by the
end of September on the fate of DNS Profile document.

Due to lack of progress on that document we regret there is no other
option but to cancel the effort.

        Olafur and Andrew --=====================_429330244==.ALT-- -- to unsubscribe send a message to namedroppers-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 Oct 17 05:41: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 B4DA63A6897; Fri, 17 Oct 2008 05:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.665 X-Spam-Level: X-Spam-Status: No, score=-0.665 tagged_above=-999 required=5 tests=[AWL=-0.170, 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 nv6ai64LBPmn; Fri, 17 Oct 2008 05:41:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5EC253A67EE; Fri, 17 Oct 2008 05:41:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KqoVe-000MNC-Mn for namedroppers-data@psg.com; Fri, 17 Oct 2008 12:32:50 +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 1KqoVX-000MLy-1m for namedroppers@ops.ietf.org; Fri, 17 Oct 2008 12:32:46 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m9HCWe88054170 for ; Fri, 17 Oct 2008 08:32: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 m9HCWeiX054169 for namedroppers@ops.ietf.org; Fri, 17 Oct 2008 08:32:40 -0400 (EDT) (envelope-from namedroppers) Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KqBpy-000Bgo-HJ for namedroppers@ops.ietf.org; Wed, 15 Oct 2008 19:15:23 +0000 Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id m9FJF8YZ010609 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 15 Oct 2008 15:15:09 -0400 Date: Wed, 15 Oct 2008 15:15:07 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: George Barwood cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-barwood-dnsext-fr-resolver-mitigations-03 In-Reply-To: Message-ID: 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: [ Note: Post was moderated. ] On Sun, 12 Oct 2008, George Barwood wrote: > I have revised my draft at > > http://www.ietf.org/internet-drafts/draft-barwood-dnsext-fr-resolver-mitigations-03.txt Did the WG decide to take on this draft? My understanding is that 'dnsext' in the name indicates a working group draft as opposed to an individual submission, but the WG page does not list this draft. I must have missed the discussion of whether the WG should take on this work. I am against having the WG take on this draft. Recommendation: Anyone interested in avoiding cache poisoning should use port randomization or TCP, or a combination of both. I suggest that a common deployment scenario consists of a group of site-wide recursors serving stub resolvers. If the stub resolvers are handled with UDP port randomization, and the recursors use TCP, poisoning is limited to MITM attacks. Only the site recursors need to be altered, and this alteration is completely within the current DNS specifications. The stub resolvers (which often do not cache responses) are speedilly serviced by UDP as before. The recursors (which usually do cache responses) get a lot of benefit from the overhead of TCP. Comments on the draft: There is no such thing as a "Kaminsky Attack". The attack to which the draft refers was previously well known, as has been previously reported with complete citations to previous analysis on this list, and on other lists. DNS spoofing and cache poisoning was previously well-known to be trivial, and accomplished in a fraction of a second on many popular name servers; The attack is STILL trivial, and Kaminsky didn't discover anything that made that attack easier. Kaminsky didn't discover ANYTHING novel, nor ANYTHING that bears attachment of a new name. Rather, system administrators unfamiliar with DNS vulnerabilities may have been surprised to learn how easy it was to spoof DNS, but this fact is not new. Continued use of the name "Kaminsky Attack" to describe a previously known attack is a kind of contributory plagarism, since Kaminsky cannot make claim to discovering the attack. The draft asserts that by "repeating the query, additional entropy is obtained". This assertion is false. Repeating the query either lowers the entropy since it just doubles the number of valid outstanding query ids that the attacker. If these QIDs are unique and not reused, there are now only 32k pairs of QIDs (n * n-1; 65536 * 65535), which is less entropy than would be found by ordinary port randomization, but doubling the load on DNS. I have also reported that an attacker can arrange to repeat the same query in an attempt to exploit a birthday problem. Having the nameserver do this on its own initiative just makes the attacker's job that much easier. I am quite uncomfortable with the loose use of the term 'entropy' as a justification that these tests make spoofing any harder. I am especially dubious of the notion that one can inspect DNS payload data to somehow get more 'entropy'. It should also noted that nameservers may reply from a different IP address than the one the query was sent to. This is fairly common on multi-homed computers. One cannot add a check that the IP address is the same. The draft also notes some 'in-essential' information may be lost. There is no 'in-essential' information in DNS, at least, no information that a caching recursor can determine to be 'in-essential'. Any record that exists in DNS must be considered to be meaningful to the site that placed that record. The draft also suggests randomly changing case of the query. DNS is not case sensitive. Randomizing the case of the query and then checking that the case remains the same in the response is a violation of DNS protocol. Whether popular servers currently change case or not has no bearing on whether other servers/implementers can assume this will or will not happen. In 3.4, prepending a random nonce and assuming a "referral is probable" is a violation of protocol. The server that receives a query can send, at its own discretion, a referral or perform recursion. Assuming what the remote server might do when it has a choice is a violation of DNS protoocol. I also note that TCP suffers none of these particular poisoning problems, and the 3way handshake is generally faster than the multi-packet "convergence" contemplated in this draft. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-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 Oct 17 08:26: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 528D83A6A16; Fri, 17 Oct 2008 08:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.525 X-Spam-Level: X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 d-xJ8OZwITeV; Fri, 17 Oct 2008 08:26:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7F2C33A697F; Fri, 17 Oct 2008 08:26:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kqr8e-000EwE-A0 for namedroppers-data@psg.com; Fri, 17 Oct 2008 15:21:16 +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 1Kqr8X-000EuV-E4 for namedroppers@ops.ietf.org; Fri, 17 Oct 2008 15:21:12 +0000 Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 634216CB3E0; Fri, 17 Oct 2008 08:21:10 -0700 (PDT) Date: Fri, 17 Oct 2008 08:21:10 -0700 From: Eric Rescorla To: Dean Anderson Cc: George Barwood , namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-barwood-dnsext-fr-resolver-mitigations-03 In-Reply-To: References: 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: <20081017152110.634216CB3E0@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Wed, 15 Oct 2008 15:15:07 -0400 (EDT), Dean Anderson wrote: > > [ Note: Post was moderated. ] > > > On Sun, 12 Oct 2008, George Barwood wrote: > > > I have revised my draft at > > > > http://www.ietf.org/internet-drafts/draft-barwood-dnsext-fr-resolver-mitigations-03.txt > > Did the WG decide to take on this draft? My understanding is that > 'dnsext' in the name indicates a working group draft as opposed to an > individual submission, but the WG page does not list this draft. Your understanding is wrong. That's not what it means. In fact, it's quite conventional for individuals to use draft---* for drafts they hope the WG will eventually take on. -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 Fri Oct 17 11:16: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 4B4233A6AF0; Fri, 17 Oct 2008 11:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.825 X-Spam-Level: X-Spam-Status: No, score=-0.825 tagged_above=-999 required=5 tests=[AWL=-0.331, 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 NviHwlODivMI; Fri, 17 Oct 2008 11:16:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 207773A6A2A; Fri, 17 Oct 2008 11:16:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KqtiH-0006t1-GX for namedroppers-data@psg.com; Fri, 17 Oct 2008 18:06: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 1Kqti5-0006rQ-VR for namedroppers@ops.ietf.org; Fri, 17 Oct 2008 18:06:09 +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 m9HI5v53057353 for ; Fri, 17 Oct 2008 14:05:57 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200810171805.m9HI5v53057353@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 17 Oct 2008 14:05:55 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Re: [dnsext] Firewall support for large DNS names (>255) and packets (>512)? In-Reply-To: <48F42CE9.7040204@chrysler.com> References: <200810102322.m9ANMOcM028982@drugs.dv.isc.org> <20081011215903.A3A136BE02F@kilo.rtfm.com> <48F42CE9.7040204@chrysler.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_608930926==.ALT" X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --=====================_608930926==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 07:42 14/10/2008, Kevin Darcy wrote: >Matthew Dempsky wrote: >>On Sat, Oct 11, 2008 at 2:59 PM, Eric Rescorla >> wrote: >> >>>Is the suggestion that DNSCurve should be made an RFC? If so, it >>>seems to me that a clear prerequisite to that discussion would be >>>the existence of DNSCurve I-D. >>> >> >>Yes. I've been working on a DNSCurve Internet-Draft since it was >>brought up on Thursday, and I hope to have a publicly available draft >>soon. >> >> >>>Barring that, why exactly are we having a discussion about the >>>practicality of a specific design decision in DNSCurve? >>> >> >>I initially brought it up because I wanted to know if anyone knew of >>*operational* issues with these limitations. I was well aware that >>the RFCs limited names to 255 bytes. Did Bill Manning, Kevin Darcy, >>or anyone else think I just coincidentally picked this number to ask >>about? >> >No, I didn't think it was a "coincidence", but at the same time, I >didn't know if you were aware how ancient, well-defined and >well-established that particular limitation is. There are two DNS name lengths that implementations need to respect, the 63 byte label length and the 255 byte total length. With the exception of "not-so smart" proposed uses of bit-labels[1] there has not been much evidence that the 255 byte name length is a problem. Most label names are short (<20 characters) and depth of the DNS tree is limited to <10 labels. On the other hand, issues have been raised with the 63 byte label length, in IDN contexts and in NSEC3 context. In IDN the problem is mostly theoretical (and/or political) as the currently used punycode encoder is highly effective. As for DNS protocol elements there are a number of them out there that do not follow the rules for DNS names because they think they know all the rules. For example number of implementations drop DNS packets if the name on first RRset uncompressed! http://psg.com/lists/namedroppers/namedroppers.2006/msg00582.html Based on this I would not make any assumptions if the 255 byte total length is enforced/honored, without doing serious testing. >Is there any reason why the research into the operational impact of >changing the name-size limitation can't be conducted in _parallel_ >with the discussions over the merits of the DNSCurve draft itself? >Drafts almost always have multiple revisions anyway, whatever >operational information that comes to light in this regard can be >incorporated -- to the extent it needs to be -- into a later >revision of the draft... > Exactly, but there is no need to jump to action until we know if there is a problem. Problem == There is a demonstrated need in real life example, either an overflow occurs or we are real close to the overflow Remember: changing the DNS infrastructure takes REAL REAL REAL LONG LONG LONG time, think decades not years. Historical note: [1] Bit labels taught us two important lessons: 1. Adding new label types is almost impossible as the whole infrastructure needs to be changed before the type is useful. Authoritative high level servers MUST know about the new label type or they will return FORMERR for the query. 2. Changing the semantics of DNS is a difficult process that has unexpected side effects all over the place. Bit labels were invented to address perceived need in the IPv6 reverse tree, I was one of the people working on proposals that eventually lead to the bit labels proposal. IMHO there was a fundamental mistake in that whole process: "People wanted to be able to delegate address blocks on any bit boundary". The discussion that Bill Manning referred to about bit labels name being broken up into so many DNS labels that the "ip6.arpa." or "ipv6.int." post-fixes did not fit, was resolved by assuming that the IANA block would be at least 6 bits long, preferably 12 bits long OR in the bottom 64 bits people would have fewer than 64 delegations. Of course the whole discussion was silly because who wants to issue 100+ queries to resolve a name or operate lots of zones that have only have 1 or 2 delegations. Olafur --=====================_608930926==.ALT Content-Type: text/html; charset="us-ascii" <chair-hat= off>
<dns-historian=on>

At 07:42 14/10/2008, Kevin Darcy wrote:
Matthew Dempsky wrote:
On Sat, Oct 11, 2008 at 2:59 PM, Eric Rescorla <ekr@networkresonance.com> wrote:
 
Is the suggestion that DNSCurve should be made an RFC?  If so, it
seems to me that a clear prerequisite to that discussion would be
the existence of DNSCurve I-D.
   

Yes.  I've been working on a DNSCurve Internet-Draft since it was
brought up on Thursday, and I hope to have a publicly available draft
soon.

 
Barring that, why exactly are we having a discussion about the
practicality of a specific design decision in DNSCurve?
   

I initially brought it up because I wanted to know if anyone knew of
*operational* issues with these limitations.  I was well aware that
the RFCs limited names to 255 bytes.  Did Bill Manning, Kevin Darcy,
or anyone else think I just coincidentally picked this number to ask
about?
 
No, I didn't think it was a "coincidence", but at the same time, I didn't know if you were aware how ancient, well-defined and well-established that particular limitation is.

There are two DNS name lengths that implementations need to respect,
the 63 byte label length and the 255 byte total length.
With the exception of "not-so smart" proposed uses of bit-labels[1] there
has not been much evidence that the 255 byte name length is a problem.
Most label names are short (<20 characters) and depth of the DNS tree
is limited to <10 labels.

On the other hand, issues have been raised with the 63 byte
label length, in IDN contexts and in NSEC3 context. In IDN the problem
is mostly theoretical (and/or political) as the currently used punycode
encoder is highly effective.

As for DNS protocol elements there are a number of them out there that do
not follow the rules for DNS names because they think they know all the
rules. For example number of implementations drop DNS packets if the
name on first RRset uncompressed! 
http://psg.com/lists/namedroppers/namedroppers.2006/msg00582.html

Based on this I would not make any assumptions if the 255 byte total length
is enforced/honored, without doing serious testing.

Is there any reason why the research into the operational impact of changing the name-size limitation can't be conducted in _parallel_ with the discussions over the merits of the DNSCurve draft itself? Drafts almost always have multiple revisions anyway, whatever operational information that comes to light in this regard can be incorporated -- to the extent it needs to be -- into a later revision of the draft...


Exactly, but there is no need to jump to action until we know if there
is a problem.
Problem == There is a demonstrated need in real life example, either
        an overflow occurs or we are real close to the overflow
           
Remember: changing the DNS infrastructure takes
REAL REAL REAL LONG LONG LONG time, think decades not years.

Historical note:
[1] Bit labels taught us two important lessons:
        1. Adding new label types is almost impossible as the whole
         infrastructure needs to be changed before the type is useful.
         Authoritative high level servers MUST know about the new label
        type or they will return FORMERR for the query. 
        2. Changing the semantics of DNS is a difficult process that
        has unexpected side effects all over the place.

Bit labels were invented to address perceived need in the IPv6 reverse tree,
I was one of the people working on proposals that eventually lead to the
bit labels proposal. IMHO there was a fundamental mistake in that
whole process:
"People wanted to be able to delegate address blocks on any bit boundary".

The discussion that Bill Manning referred to about bit labels name being
broken up into so many DNS labels that the "ip6.arpa." or "ipv6.int."
post-fixes did not fit, was resolved by assuming that the IANA block
would be at least 6 bits long, preferably 12 bits long OR
in the bottom 64 bits people would have fewer than 64 delegations.
Of course the whole discussion was silly because who wants to issue
100+ queries to resolve a name or operate lots of zones that have
only have 1 or 2 delegations.

         Olafur  --=====================_608930926==.ALT-- -- to unsubscribe send a message to namedroppers-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 Oct 17 13:29: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 25C3028C0F1; Fri, 17 Oct 2008 13:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.078 X-Spam-Level: X-Spam-Status: No, score=0.078 tagged_above=-999 required=5 tests=[AWL=-1.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 lnJ-8TBDo+gm; Fri, 17 Oct 2008 13:29:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 681103A6B07; Fri, 17 Oct 2008 13:29:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KqvsM-000KLr-Hb for namedroppers-data@psg.com; Fri, 17 Oct 2008 20:24:46 +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 1KqvsG-000KKs-Lh for namedroppers@ops.ietf.org; Fri, 17 Oct 2008 20:24:43 +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 m9HKOaMV058562 for ; Fri, 17 Oct 2008 16:24:37 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200810172024.m9HKOaMV058562@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 17 Oct 2008 16:24:33 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: [dnsext] Re: Time-line for forgery resilience phase #2 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_617249337==.ALT" X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --=====================_617249337==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Dear colleagues, Thank you for taking the suggestions below to heart and following the plan. At this point we have following drafts submitted: = http://tools.ietf.org/id/draft-barwood-dnsext-fr-resolver-mitigations-04.tx= t http://tools.ietf.org/id/draft-reid-dnsext-aleatoric-00.txt http://tools.ietf.org/id/draft-weaver-dnsext-fr-comprehensive-00.txt = http://tools.ietf.org/id/draft-wijngaards-dnsext-resolver-side-mitigation-0= 0.txt http://tools.ietf.org/html/draft-hubert-ulevitch-edns-ping-00 http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00 If we forgot any please reply to this message with the link for the draft. The forum is now open for discussion. We propose that you start a new thread for each subject rather than just= reply to this message, in the Subject line put FR: Topic As far as we can tell the ideas contained in the drafts can be summarized= into following rough categories: Packet acceptance Data admission Data integrity checks Attack detection Please use these words in your messages to facilitate clearer understanding. Feel free to propose new categories. In Minneapolis the WG is scheduled to meet on Tuesday afternoon. The chairs have asked for a small meeting room on Monday (during one of the first 2 sessions) and on Tuesday morning for a "design" team to meet. If you want to be invited to these meetings send us an e-mail, we want to get a broad balance of expertise and experience in that room. The "design" team will present the recommendations (if any) at the Working Group meeting. Olafur and Andrew At 12:22 04/09/2008, =D3lafur Gu=F0mundsson /DNSEXT wrote: >The WG has had 2 months to learn about the issues and kick ideas around. >At this point the discussion has reach the point of diminishing returns. >The discussion needs to become more focused! > >The chairs propose following plan to make progress: >0. Discussion on namedroppers on ideas without drafts comes to an end. > If you need to ask a clarifying question, please put the tag [CLARIFY]= in > your Subject: line. > >1. By September 30'th everyone that has ideas they want to share > should have an ID published. > suggested names for drafts: draft--dnsext-fr--xx.txt > >2. During October the WG will discuss the ideas and recommendations from= the > drafts. Editors are encouraged to update their drafts frequently= during > this window based on the discussions. > >3. During November the WG will select from the ideas on what to recommend= as > the extended Forgery Resilience approach. > The chairs plan to have a special session early in the week at the IETF > meeting for interested parties to hash out what makes sense. > Recommendations from that session will be proposed to the WG at > the official WG meeting. > >4. If the WG does not reach a rough consensus by late November the chairs > may form a design team to come up with a recommendation. > >5. An official WG document(s) will be submitted no later than early > December. > (we will need editors for this document(s)) > >6. By late January we will have WGLC on the document(s). > The document(s) will be advanced to the IESG by March 1'st. > >Based on this plan, please stop all Forgery=20 >Resilience (FR) discussion right now. >If you are not writing down your FR ideas in a draft, >please review and comment on the following WG last calls: > >http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01190.html >http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01430.html > > Olafur and Andrew --=====================_617249337==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear colleagues,

Thank you for taking the suggestions below to heart and following the plan.

At this point we have following drafts submitted:
  http://tools.ietf.org/id/draft-barwood-dnsext-fr-resolver-mitigations-04.txt=
  http://tools.ietf.org/id/draft-reid-dnsext-aleatoric-00.txt
   http://tools.ietf.org/id/draft-weaver-dnsext-fr-comprehensive-00.txt
  http://tools.ietf.org/id/draft-wijngaards-dnsext-resolver-side-mitigation-00= .txt
  http://tools.ietf.org/html/draft-hubert-ulevitch-edns-ping-00
  http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

If we forgot any please reply to this message with the link for the draft.

The forum is now open for discussion.
We propose that you start a new thread for each subject rather than just reply
to this message, in the Subject line put
        FR: Topic

As far as we can tell the ideas contained in the drafts can be summarized into
following rough categories:
        Packet acceptance
        Data admission
        Data integrity checks
        Attack detection

Please use these words in your messages to facilitate clearer understanding.
Feel free to propose new categories.

In Minneapolis the WG is scheduled to meet on Tuesday afternoon.
The chairs have asked for a small meeting room on Monday (during one
of the first 2 sessions) and on Tuesday morning for a "design" team to meet.
If you want to be invited to these meetings send us an e-mail, we want to
get a broad balance of expertise and experience in that room.
The "design" team will present the recommendations (if any) at the
Working Group meeting.

        Olafur and Andrew

At 12:22 04/09/2008, =D3lafur Gu=F0mundsson /DNSEXT wrote:


The WG has had 2 months to le= arn about the issues and kick ideas around.
At this point the discussion has reach the point of diminishing returns.
The discussion needs to become more focused!

The chairs propose following plan to make progress:
0. Discussion on namedroppers on ideas without drafts comes to an end.
   If you need to ask a clarifying question, please put the tag [CLARIFY] in
   your Subject: line.

1. By September 30'th  everyone that has ideas they want to share
   should have an ID published.
   suggested names for drafts: draft-<editor>-dnsext-fr-<name>-xx.txt

2. During October the WG will discuss the ideas and recommendations from the
   drafts.  Editors are encouraged to update their drafts frequently during
   this window based on the discussions.

3. During November the WG will select from the ideas on what to recommend as
   the extended Forgery Resilience approach.
   The chairs plan to have a special session early in the week at the IETF
   meeting for interested parties to hash out what makes sense.
   Recommendations from that session will be proposed to the WG at
   the official WG meeting.

4. If the WG does not reach a rough consensus by late November the chairs
   may form a design team to come up with a recommendation.

5. An official WG document(s) will be submitted no later than early
   December.
   (we will need editors for this document(s))

6. By late January we will have WGLC on the document(s).
   The document(s) will be advanced to the IESG by March 1'st.

Based on this plan, please stop all Forgery Resilience (FR) discussion right now.
If you are not writing down your FR ideas in a draft,
please review and comment on the following WG last calls:

http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01190.html
http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01430.html

        Olafur and Andrew
--=====================_617249337==.ALT-- -- to unsubscribe send a message to namedroppers-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 Oct 20 02:49: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 12E913A69D6; Mon, 20 Oct 2008 02:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.338 X-Spam-Level: X-Spam-Status: No, score=-5.338 tagged_above=-999 required=5 tests=[AWL=-0.940, 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 kl4j15m-38YC; Mon, 20 Oct 2008 02:49:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EF86D3A69B5; Mon, 20 Oct 2008 02:49:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KrrGd-0006ak-Ji for namedroppers-data@psg.com; Mon, 20 Oct 2008 09:41:39 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KrrGG-0006Z6-Dj for namedroppers@ops.ietf.org; Mon, 20 Oct 2008 09:41:21 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 27ED41C011C; Mon, 20 Oct 2008 11:41:13 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 2369A1C011A; Mon, 20 Oct 2008 11:41:13 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 17BB87B0057; Mon, 20 Oct 2008 11:41:13 +0200 (CEST) Date: Mon, 20 Oct 2008 11:41:13 +0200 From: Stephane Bortzmeyer To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= /DNSEXT chair Cc: namedroppers@ops.ietf.org Subject: [dnsext] Re: Time-line for forgery resilience phase #2 Message-ID: <20081020094113.GA1978@nic.fr> References: <200810172024.m9HKOaMV058562@stora.ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200810172024.m9HKOaMV058562@stora.ogud.com> X-Operating-System: Debian GNU/Linux lenny/sid X-Kernel: Linux 2.6.26-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 Fri, Oct 17, 2008 at 04:24:33PM -0400, Ólafur Guðmundsson /DNSEXT chair wrote a message of 238 lines which said: > At this point we have following drafts submitted: http://tools.ietf.org/id/draft-ietf-dnsext-forgery-resilience-07.txt -- to unsubscribe send a message to namedroppers-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 Oct 21 07:11: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 1D0E128C11A; Tue, 21 Oct 2008 07:11: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 s6FZnt9kXWBm; Tue, 21 Oct 2008 07:11:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A89B53A6A7C; Tue, 21 Oct 2008 07:11:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsHq3-000F63-3a for namedroppers-data@psg.com; Tue, 21 Oct 2008 14:03:59 +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 1KsHpp-000F4m-FJ for namedroppers@ops.ietf.org; Tue, 21 Oct 2008 14:03: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 m9LE3hNv057651 for ; Tue, 21 Oct 2008 10:03:43 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m9LE3h1l057650 for namedroppers@ops.ietf.org; Tue, 21 Oct 2008 10:03:43 -0400 (EDT) (envelope-from namedroppers) Received: from [208.87.234.190] (helo=cluster-h.mailcontrol.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KrIjw-000DP9-GG for namedroppers@ops.ietf.org; Sat, 18 Oct 2008 20:49:38 +0000 Received: from emsv.co.uk ([84.234.24.63]) by rly07h.srv.mailcontrol.com (MailControl) with SMTP id m9IKnQZx028119 for ; Sat, 18 Oct 2008 21:49:26 +0100 From: "George Barwood" To: Message-ID: Subject: [dnsext] FR: comments re draft-weaver-dnsext-fr-comprehensive-00.txt Date: Sat, 18 Oct 2008 21:49:11 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 MIME-Version: 1.0 Organization: Education and Media Services Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original" Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 X-Scanned-By: MailControl A-08-50-15 (www.mailcontrol.com) on 10.72.0.117 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. ] My comments on http://tools.ietf.org/id/draft-weaver-dnsext-fr-comprehensive-00.txt >From section 6: The algorithm is simple: ... and all cache entries set or dependent on the first result should be voided That seems to me to be actually quite complex, since the dependencies need to be tracked ( so any use of a NS record to fetch other records etc. must also be tracked ). The state-holding requirements, although nontrivial, are also reasonable. Consider a recursive resolver (or a cluster node in a clustered resolver implementation) that generates 10,000 outstanding external queries per second. If the timeout is 1 second, and the state-holding required involves 1 KB of data, the additional memory requirements would only be 10 MB of data for such a resolver. Even with a longer timeout or a more active resolver, the state-holding requirements should be reasonable. Was the number of ports that need to be left open considered? Could that be a problem? >From section 8: When a DNS resolver starts, and when a resolver notices that its IP address has changed.. The NAT device could change without the resolver IP address changing. For example the resolver might be using an intermediate computer as a gateway, or the behavior of a NAT device might change without notice, for example due switching to a backup device, or any number of possibilties that cannot be predicted. So my feeling is that the complexity of attempting this is not justified. I suggest that duplication is simple and cheap, and will not cause problems for authorities ( which can probably easily cope with an order of magnitude increase in traffic ). The possible exception being the root and top level domains, where a random prepended nonce can be used to encode almost unlimited entropy, and authorities behind NAT devices that may impose very low limits on incoming connections, where using the same source port for repetition may avoid problems ( needs research ? ) If 40b of entropy are available on the request and the resolver is not under a significant attack, duplication is not necessary. Thus duplication should be viewed as a fallback position for resolvers which are behind a NAT or other entropy stripping device, accessing authoritative servers which don't respond to 0x20 (per Dagon et. al's proposal [0x20], or is known to be under an active blind attack. The initial priming query is a high-value target, where repetition is in my view advisable ( and 0x20 is nil ). Especially if the attacker can predict the time when the root will be refreshed, by being able to see the TTL. Similarly the refresh of top level domains. Public resolvers might choose to refresh early, or to conceal the exact TTL in some way ( I don't think this is discussed in any of the current drafts ). However, it appears reasonable to return one of the values as the answer to the transaction, as blind transaction attacks are less powerful than blind cache attacks (Section 4). I'm not sure I have properly followed your logic here, but simple non-Kaminsky attacks need to be considered. If say only 20 to 25 bits of entropy are available, and the TTL is 20 seconds, a random attack on a large number of IP addresses could succeed too easily I think. At least I'm uneasy about this. For the NS record and associated A records, the separate global and local scope is approximated by validating the NS RRSet and all elements within it using subsequent separate fetches. With non-deterministic authorities, the seperate fetch might not agree. If there were just 2 IP addresses for the name servers, you might end up with a single address, and a loss of resilience. On uses for additional data : I think you might have missed out the common usage where authorities return the NS and glue with responses to keep the TTL high. With regard to performance, I think it's important to decide whether extra complexity ( which increases the risk of problems, bugs and security holes ) is wise. It may not be worth having more complexity simply to save a few packets that probably won't cause any problems. >From an engineering perspective, systems are best designed with reliable layers that can be depended on. Repetition (and 0x20,nonce) can be implemented in a well-isolated layer where the problem of spoofing is addressed without complicating the overall design of the resolver in other areas. It also doesn't disturb the logic of how the resolver interacts with servers ( except in the non-deterministic case ). Hence I argue for straightforward repetition ( which is necesary in any case IMO ) to achieve acceptable security rather than complex optimization schemes ( that in any case may use more packets in some cases ). Simple solutions, provided they work, are to be preferred, IMO. I also think building in some margin of safety is sensible, which is why I suggest 50 bits rather than 40. The history of DNS suggests that we may yet be missing something important, so provided the cost is not a major problem ( and I suggest that it isn't ), it's best to err on the safe side, even though of course that gives no guarantee against our own fallability. It may be that I am missing something here, and that operators are very sensitive to the number of packets required, but according to my rough reasoning this should not be the case. The DNS server load for an organisation ( other than at the root and TLD operators ), should be completely insignificant compared to the processing of higher level applications. Maybe someone with more operational experience could cast more light on this question Kind regards, and apologies if I have laboured the point, repetition is possibly infectious. George -- to unsubscribe send a message to namedroppers-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 Oct 22 03:13: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 788523A6B67; Wed, 22 Oct 2008 03:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.66 X-Spam-Level: **** X-Spam-Status: No, score=4.66 tagged_above=-999 required=5 tests=[AWL=-1.859, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001, TRACKER_ID=2.003] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39rEjM8cPCfi; Wed, 22 Oct 2008 03:13:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 976BE3A6A0B; Wed, 22 Oct 2008 03:13:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsadD-000Obm-DU for namedroppers-data@psg.com; Wed, 22 Oct 2008 10:07:59 +0000 Received: from [195.188.213.6] (helo=smtp-out3.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ksad3-000Oau-EW for namedroppers@ops.ietf.org; Wed, 22 Oct 2008 10:07:56 +0000 Received: from [172.23.170.147] (helo=anti-virus03-10) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1Ksad1-0001P2-Oz for namedroppers@ops.ietf.org; Wed, 22 Oct 2008 11:07:47 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with esmtpa (Exim 4.52) id 1Ksad1-0005nk-Au for namedroppers@ops.ietf.org; Wed, 22 Oct 2008 11:07:47 +0100 Message-ID: <05938DB8C4884FA693B84BF19F426168@localhost> From: "George Barwood" To: Subject: [dnsext] FR: An argument against 0x20 and mitigation by standard labels Date: Wed, 22 Oct 2008 11:07:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: A possible argument against 0x20 is that administrators, in order to lessen the load on their authoritative name servers from resolvers that implement 0x20 and repetition, may start using long labels. This could lead to increased memory requirement for caches. Therefore a few standard labels could be defined, that SHOULD be used for adding 0x20 entropy. Caches can then arrange to store these labels only once. My suggestion would be the labels ABCDEFGHIJKLMNOPQRSTUVWXYZ and ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ giving 26 and 52 bits of entropy respectively. These are language neutral, and can easily be checked for correctness during manual editing. A typical zone file would then be $ORIGIN example.com. @ 86400 IN SOA ( ns1 hostmaster 2008102001 ; serial number 1500 ; refresh 600 ; retry 1209600 ; expire 3600 ; Name Error TTL ) 86400 NS NS1 86400 NS NS2 86400 MX 10 MX1 86400 MX 20 MX2 NS1 86400 A 1.2.3.4 NS2 86400 A 4.3.2.1 MX1 86400 A 1.2.3.4 MX2 86400 A 4.3.2.1 WWW 86400 CNAME www.ABCDEFGHIJKLMNOPQRSTUVWXYZ www.ABCDEFGHIJKLMNOPQRSTUVWXYZ 120 A 1.2.3.4 -- to unsubscribe send a message to namedroppers-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 Oct 22 04:02: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 5FF7728C139; Wed, 22 Oct 2008 04:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=-0.156, 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 ptOnUEg-Klzr; Wed, 22 Oct 2008 04:02:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 153D23A697A; Wed, 22 Oct 2008 04:02:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsbQe-0003Fh-GX for namedroppers-data@psg.com; Wed, 22 Oct 2008 10:59:04 +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 1KsbQR-0003EZ-2y for namedroppers@ops.ietf.org; Wed, 22 Oct 2008 10:58:58 +0000 Received: from jelte (vhe-520087.sshn.net [195.169.221.157]) by sol.nlnetlabs.nl (Postfix) with ESMTP id A440F130D40; Wed, 22 Oct 2008 12:58:49 +0200 (CEST) Received: from [192.168.8.11] (dragon [192.168.8.11]) by jelte (Postfix) with ESMTP id E4C2CCFA08; Wed, 22 Oct 2008 12:59:05 +0200 (CEST) Message-ID: <48FF0775.3070401@NLnetLabs.nl> Date: Wed, 22 Oct 2008 12:59:01 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: George Barwood Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] FR: An argument against 0x20 and mitigation by standard labels References: <05938DB8C4884FA693B84BF19F426168@localhost> In-Reply-To: <05938DB8C4884FA693B84BF19F426168@localhost> 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 George Barwood wrote: > A possible argument against 0x20 is that administrators, in order to > lessen the load on their authoritative name servers from resolvers that > implement 0x20 and repetition, may start using long labels. > > This could lead to increased memory requirement for caches. > > Therefore a few standard labels could be defined, that SHOULD be used > for adding 0x20 entropy. > > Caches can then arrange to store these labels only once. > > My suggestion would be the labels > > ABCDEFGHIJKLMNOPQRSTUVWXYZ > > and > > ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ > > giving 26 and 52 bits of entropy respectively. These are language > neutral, and can easily be checked for correctness during manual editing. > > WWW 86400 CNAME www.ABCDEFGHIJKLMNOPQRSTUVWXYZ > www.ABCDEFGHIJKLMNOPQRSTUVWXYZ 120 A 1.2.3.4 > 2 questions come to mind, but I am probably misunderstanding the goal here; 1. Aren't you still 'short-named' at the cname record here? I.E. what would such a setup actually accomplish? 2. Wouldn't this encourage the exact behaviour that you're trying to protect against? (more people using longer names, even if it is limited to 26 or 52 bytes per address) Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI/wd14nZCKsdOncURAiUCAKC9pyIjsuTcyiXW3iyWAeeDJZ23CQCeIp2T AkEiBbzE/ihgLcUG7xB+7p8= =+Rje -----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 Oct 22 08:45: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 D51E63A69B2; Wed, 22 Oct 2008 08:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.957 X-Spam-Level: X-Spam-Status: No, score=-4.957 tagged_above=-999 required=5 tests=[AWL=0.091, 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 5Boa7QRGUCdj; Wed, 22 Oct 2008 08:45:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DC7263A682E; Wed, 22 Oct 2008 08:45:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsfmZ-0000Zj-3y for namedroppers-data@psg.com; Wed, 22 Oct 2008 15:37:59 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ksfm3-0000XL-70 for namedroppers@ops.ietf.org; Wed, 22 Oct 2008 15:37:39 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9MFWE8S011620; Wed, 22 Oct 2008 08:32:19 -0700 (PDT) From: Nicholas Weaver To: "George Barwood" In-Reply-To: <05938DB8C4884FA693B84BF19F426168@localhost> Subject: Re: [dnsext] FR: An argument against 0x20 and mitigation by standard labels X-Priority: 3 References: <05938DB8C4884FA693B84BF19F426168@localhost> Message-Id: <5838342A-EF9E-4527-A8BF-181DCBBA6061@icsi.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 22 Oct 2008 08:32:13 -0700 Cc: Nicholas Weaver , X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Oct 22, 2008, at 3:07 AM, George Barwood wrote: > A possible argument against 0x20 is that administrators, in order to > lessen the load on their authoritative name servers from resolvers > that implement 0x20 and repetition, may start using long labels. > > This could lead to increased memory requirement for caches. I don't think this is a concern: Lets take a resolver that has 1 Million! cache entries. At an extra 10B a label (for extra 0x20-padding on names?), this would be a whopping 10MB of memory. Suppose the same resolver has 100M active cache entries. Thats still just 1 GB. Or about $30. So who cares about the memory usage of slightly longer names? -- to unsubscribe send a message to namedroppers-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 Oct 22 14:22: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 309113A67D8; Wed, 22 Oct 2008 14:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[AWL=-0.155, 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 BE1jdbPW-xf3; Wed, 22 Oct 2008 14:22:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 071DB3A67D4; Wed, 22 Oct 2008 14:22:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ksl4K-00021F-FY for namedroppers-data@psg.com; Wed, 22 Oct 2008 21:16:40 +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 1Ksl49-00020Q-4j for namedroppers@ops.ietf.org; Wed, 22 Oct 2008 21:16:34 +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 m9MLKT6u023661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Oct 2008 14:20:33 -0700 Date: Wed, 22 Oct 2008 17:16:21 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Results of WGLC: draft-ietf-dnsext-dnssec-rsasha256-05 Message-ID: <20081022211620.GA1896@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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, 22 Oct 2008 14:20:34 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, The working group last call for draft-ietf-dnsext-dnssec-rsasha256-05 completed. There was adequate review by the Working Group to satisfy our convention that at least five people need to review a document, and express support, in order that the document be sent to the IESG. Some actions are required before the document can proceed. I express my apologies to the Working Group and to the ever-patient draft editor for the delay in getting this report back to the Working Group since the Last Call ended. The actions are these: 1. The reference to [SCHNEIER-1996] will be removed. 2. The key size reference to RFC 4641 will be removed. 3. A WG participant raised a concern about a sentence in §4.1. The editor will change the sentence as follows: Apart from the restrictions specified in section 2, this document will not specify what size of keys to use. That is an operational issue and depends largely on the environment and intended use. 4. The reference to RFC 3447 will be changed to an Informational reference. 5. A large number of nits will be addressed. 6. There is an ambiguity in the algorithm in §3. The editor proposes to alter the section, rewording it this way: The FF octet MUST be repeated the exact number of times so that the total length of the concatenated term in parentheses equals the length of the modulus of the signer's public key ("n"). If you are among those who noted this ambiguity, please review that proposed change and respond if you object: we will take silence on this matter to indicate agreement with the proposal. 7. On the basis of the discussion during WGLC, and considerations of the effects of the change, the Chairs have directed the editor to remove the requirement that implementations must also support NSEC3. This means restoring the algorithm aliases; the result will be approximately the request to IANA we see in (e.g.) the -02 draft, §5. While we appreciate the advantages of tidiness and of promoting the implementation of NSEC3, we have concluded that the cost is too great, because it prevents those implementations not supporting NSEC3 from supporting SHA-2 as well. The editor has agreed to make all these changes, and post a -06 for final consideration. One week after -06 becomes available, unless anyone objects to specific changes that were made in response to the WGLC (or, of course, comes up with a complete showstopper that has never been raised), we'll send the document to the IESG. Thanks for your continued work in reviewing documents of the Working Group. 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 Wed Oct 22 17:59: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 1FCEF3A6BBC; Wed, 22 Oct 2008 17:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=-2.081, 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 pL3Y5aZlVh-i; Wed, 22 Oct 2008 17:59:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 331353A6BB4; Wed, 22 Oct 2008 17:59:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsoTF-000GYV-PY for namedroppers-data@psg.com; Thu, 23 Oct 2008 00:54:37 +0000 Received: from [76.96.30.40] (helo=QMTA04.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsoTA-000GXr-Hr for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 00:54:34 +0000 Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id VmRc1a00C0x6nqcA40uW8F; Thu, 23 Oct 2008 00:54:30 +0000 Received: from MIKES-LAPTOM.comcast.net ([68.48.0.197]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id W0uS1a0024F1VyU8Y0uS0H; Thu, 23 Oct 2008 00:54:29 +0000 X-Authority-Analysis: v=1.0 c=1 a=gjHhN06smIIA:10 a=liyGigqBEMQA:10 a=McwNBNstDIUcqLktPVgA:9 a=nktWbNfwLx1ZNsnA5vcA:7 a=hPH6aSig4KUiX0jexnUQSZaqG7AA:4 a=pQ5v7ofoLL0A:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 22 Oct 2008 20:54:26 -0400 To: namedroppers@ops.ietf.org From: Michael StJohns Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME In-Reply-To: References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <48F33C34.3010901@nlnetlabs.nl> <48F35170.30900@links.org> <4B27E2458EBA97669B259355@Ximines.local> <48F3B11B.8090202@links.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: After thinking about this topic for a while, I'm still bothered by the inconsistency of treatment here. But I think I have a possible mechanism - at least for DNAME. DNAME is the pretty much the equivalent of a delegation - only sideways. Why not treat it like any other delegation? In other words, in addition to the records currently permitted at a DNAME node, add DS to the list. This would require slightly overloading the meaning of DS, but in a way that doesn't break the model too much. If a DNAME node does not have at least one corresponding DS record (proven by NSEC/NSEC3), the validation rules are exactly the same as if you'd not included a DS for a subordinate delegation. E.g. no DNSSEC is expected in the target zone. Since one of either DNAMEs or NS records can be present at a node (I think that's correct), the interpretation of the DS record is dependent on which of these two is present. If the type is DNAME, the DS record points to a DNSKEY record at the target name and the chain has to continue from there. This gets away from the problem where a resolver has one trust anchor, but doesn't have a trust anchor for the target zone at the cost of requiring some administration of the DS at the DNAME. Continuing the logic from above, if you get a unsecure DNAME delegation (i.e. DNAME without DS), you *stop* doing DNSSEC validation. It doesn't matter if you have trust anchors for any further targets - the validation answer is UNSECURE. This is required for consistency - different resolvers have different sets of trust anchors. It's not all that coherent to get BOGUS from one, UNSECURE from another and UNKNOWN from a third if you can avoid it. Chaining security back to the original trust anchor and evaluating security in terms of data that chains back ONLY to that trust anchor seems to be the most consistent approach. In any event, I think this is at least somewhat backwards compatible. Let the mud slinging begin... :-) Mike -- to unsubscribe send a message to namedroppers-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 Oct 22 20:49: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 564423A68E4; Wed, 22 Oct 2008 20:49:19 -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 UUugn-2PBWsH; Wed, 22 Oct 2008 20:49:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 35E093A68AC; Wed, 22 Oct 2008 20:49:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ksr6o-0002tY-Ii for namedroppers-data@psg.com; Thu, 23 Oct 2008 03:43:38 +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 1Ksr6i-0002sr-8H for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 03:43:35 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id m9N3hO08055012; Thu, 23 Oct 2008 14:43:24 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200810230343.m9N3hO08055012@drugs.dv.isc.org> To: Michael StJohns Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME In-reply-to: Your message of "Wed, 22 Oct 2008 20:54:26 EDT." Date: Thu, 23 Oct 2008 14:43:24 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , Michael StJohns writes: > > After thinking about this topic for a while, I'm still bothered by the incons > istency of treatment here. > > But I think I have a possible mechanism - at least for DNAME. > > DNAME is the pretty much the equivalent of a delegation - only sideways. W > hy not treat it like any other delegation? In other words, in addition to th > e records currently permitted at a DNAME node, add DS to the list. This woul > d require slightly overloading the meaning of DS, but in a way that doesn't b > reak the model too much. > > If a DNAME node does not have at least one corresponding DS record (proven by > NSEC/NSEC3), the validation rules are exactly the same as if you'd not inclu > ded a DS for a subordinate delegation. E.g. no DNSSEC is expected in the targ > et zone. > > Since one of either DNAMEs or NS records can be present at a node (I think th > at's correct), the interpretation of the DS record is dependent on which of t > hese two is present. If the type is DNAME, the DS record points to a DNSKEY > record at the target name and the chain has to continue from there. So I create a DNAME pointing into a zone I don't own and add a DS pointing to a forged DNSKEY. This DNSKEY is then marked as trusted and I now have control of a zone I don't own. > This gets away from the problem where a resolver has one trust anchor, but do > esn't have a trust anchor for the target zone at the cost of requiring some a > dministration of the DS at the DNAME. > > Continuing the logic from above, if you get a unsecure DNAME delegation (i.e. > DNAME without DS), you *stop* doing DNSSEC validation. It doesn't matter if > you have trust anchors for any further targets - the validation answer is UN > SECURE. This is required for consistency - different resolvers have differen > t sets of trust anchors. It's not all that coherent to get BOGUS from one, U > NSECURE from another and UNKNOWN from a third if you can avoid it. Chaining > security back to the original trust anchor and evaluating security in terms o > f data that chains back ONLY to that trust anchor seems to be the most consis > tent approach. There are only three possible outputs from a validating resolver. The *all* of the answer and authority sections are SECURE (ad=1). All of the answer and authority sections passed validation (got SECURE or INSECURE) and some part was INSECURE (ad=0). Validation failed for some part and you get SERVFAIL. There is no UNKNOWN output. Records without a trust anchor are INSECURE. > In any event, I think this is at least somewhat backwards compatible. > > Let the mud slinging begin... :-) > > Mike > > > -- > to 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 Oct 22 21:29: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 388C63A68B7; Wed, 22 Oct 2008 21:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=-1.387, 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 BOr8WLuUenfc; Wed, 22 Oct 2008 21:29:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E4C373A68B6; Wed, 22 Oct 2008 21:29:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsrmF-0005nC-3I for namedroppers-data@psg.com; Thu, 23 Oct 2008 04:26:27 +0000 Received: from [76.96.62.40] (helo=QMTA04.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ksrm8-0005ml-D0 for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 04:26:24 +0000 Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA04.westchester.pa.mail.comcast.net with comcast id W1Kf1a00316LCl0544SKLk; Thu, 23 Oct 2008 04:26:19 +0000 Received: from MIKES-LAPTOM.comcast.net ([68.48.0.197]) by OMTA06.westchester.pa.mail.comcast.net with comcast id W4SJ1a0074F1VyU3S4SJUb; Thu, 23 Oct 2008 04:26:19 +0000 X-Authority-Analysis: v=1.0 c=1 a=gjHhN06smIIA:10 a=liyGigqBEMQA:10 a=48vgC7mUAAAA:8 a=baFlL40mBfQlDDAHE04A:9 a=j2MjpjilqZLvDgOxAz0A:7 a=WWI94LsjD2ZjNnIXPjfrjrpUJIEA:4 a=PKgchsl1YdkA:10 a=iw4bf7yTzGQA:10 a=h9s5Ru71U4oA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 23 Oct 2008 00:26:18 -0400 To: Mark Andrews From: Michael StJohns Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: namedroppers@ops.ietf.org In-Reply-To: <200810230343.m9N3hO08055012@drugs.dv.isc.org> References: <200810230343.m9N3hO08055012@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: At 11:43 PM 10/22/2008, Mark Andrews wrote: >In message , Michael StJohns writes: >> >> After thinking about this topic for a while, I'm still bothered by the incons >> istency of treatment here. >> >> But I think I have a possible mechanism - at least for DNAME. >> >> DNAME is the pretty much the equivalent of a delegation - only sideways. W >> hy not treat it like any other delegation? In other words, in addition to th >> e records currently permitted at a DNAME node, add DS to the list. This woul >> d require slightly overloading the meaning of DS, but in a way that doesn't b >> reak the model too much. >> >> If a DNAME node does not have at least one corresponding DS record (proven by >> NSEC/NSEC3), the validation rules are exactly the same as if you'd not inclu >> ded a DS for a subordinate delegation. E.g. no DNSSEC is expected in the targ >> et zone. >> >> Since one of either DNAMEs or NS records can be present at a node (I think th >> at's correct), the interpretation of the DS record is dependent on which of t >> hese two is present. If the type is DNAME, the DS record points to a DNSKEY >> record at the target name and the chain has to continue from there. > > So I create a DNAME pointing into a zone I don't own and > add a DS pointing to a forged DNSKEY. This DNSKEY is then > marked as trusted and I now have control of a zone I don't > own. I think you're confusing how you might implement this with what I actually said. When doing this, you have to do the analysis first for the non-cached approach. Where you do all the validations and lookups from the beginning. THEN think about how you cache the data to keep from polluting trust states. For caching, you only mark the apex DNSKEY (and its subordinate data) of the target zone as trusted ONLY for queries that are referred in via the off-tree DNAME and DS. If you come at it any other way you don't trust the data unless you have a superior trust anchor. (Yup I know - more cruft, but relative to DNSSEC probably not a great portion of the cruft). Let's say the recursive validating resolver doesn't have a superior trust anchor for the target - a direct query for the target gets the data with an output state of unknown/unsecure. An indirect query via the DNAME - assuming the target is signed and the DS chain validates - has the possibility of getting data with an output state of secure - or for that matter bogus (in which case no data or partial data is returned). If you do have a configured trust anchor for the target zone and that validation doesn't match the DS referral from the DNAME - well - that's probably one of the BOGUS cases. If you don't have a configured trust anchor for the target zone, umm... then the owner of the DNAME can steer you pretty much wherever he wants - even a zone that's somewhere that doesn't have a trust anchor so how is this worse? You are correct that if you implement this so the resolver takes the indirect trust and caches it as absolute trust then the owner of any DNAME under any trust anchor can pollute the trust cache on that resover. So don't implement it this way.... >> This gets away from the problem where a resolver has one trust anchor, but do >> esn't have a trust anchor for the target zone at the cost of requiring some a >> dministration of the DS at the DNAME. >> >> Continuing the logic from above, if you get a unsecure DNAME delegation (i.e. >> DNAME without DS), you *stop* doing DNSSEC validation. It doesn't matter if >> you have trust anchors for any further targets - the validation answer is UN >> SECURE. This is required for consistency - different resolvers have differen >> t sets of trust anchors. It's not all that coherent to get BOGUS from one, U >> NSECURE from another and UNKNOWN from a third if you can avoid it. Chaining >> security back to the original trust anchor and evaluating security in terms o >> f data that chains back ONLY to that trust anchor seems to be the most consis >> tent approach. > > There are only three possible outputs from a validating resolver. > > The *all* of the answer and authority sections are SECURE (ad=1). > > All of the answer and authority sections passed validation (got > SECURE or INSECURE) and some part was INSECURE (ad=0). > > Validation failed for some part and you get SERVFAIL. > > There is no UNKNOWN output. Records without a trust anchor are > INSECURE. There's a difference between the output from a validator and the output from a validating resolver - but I digress... We're just going to have to agree to disagree. I can distinguish between data where I have no information about its trust state (it might be signed, but I have NO trust anchor so I have no way of determining whether it is secure unsecure or bogus) and data where I have information about its trust state (because I have a trust anchor and I was able to run a validator and return one of secure, unsecure or bogus on the provided data). That difference may or may not be important to an end-application validator - but I'm not willing to exclude it from consideration at this point. So mentally from now on just substitute UNSECURE wherever I say UNKNOWN and I'll consider the protest given proforma.... :-) > >> In any event, I think this is at least somewhat backwards compatible. >> >> Let the mud slinging begin... :-) >> >> Mike >> >> >> -- >> to 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 Thu Oct 23 00:40: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 9110F3A6B54; Thu, 23 Oct 2008 00:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.126 X-Spam-Level: X-Spam-Status: No, score=-102.126 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_UNSUB22=0.948, 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 WdH+FNvvoPwL; Thu, 23 Oct 2008 00:40:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 77DF23A684F; Thu, 23 Oct 2008 00:40:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ksuf6-000Kym-AE for namedroppers-data@psg.com; Thu, 23 Oct 2008 07:31:16 +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 1Ksues-000KwN-GZ for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 07:31:08 +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.3/8.14.3) with ESMTP id m9N7Uc2w030695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 09:30:39 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4900281E.50307@nlnetlabs.nl> Date: Thu, 23 Oct 2008 09:30:38 +0200 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Michael StJohns CC: Mark Andrews , namedroppers@ops.ietf.org Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME References: <200810230343.m9N3hO08055012@drugs.dv.isc.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 23 Oct 2008 09:30:40 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael, You can propose some new mechanism here, but do not overload the DS semantics more. Get a new type code, like DLV did. That said, lets sling some mud :-) Michael StJohns wrote: > At 11:43 PM 10/22/2008, Mark Andrews wrote: >>> DNAME is the pretty much the equivalent of a delegation - only sideways. W >>> hy not treat it like any other delegation? In other words, in addition to th >>> e records currently permitted at a DNAME node, add DS to the list. This woul >>> d require slightly overloading the meaning of DS, but in a way that doesn't b >>> reak the model too much. >>> So you want the owner of the DNAME to indicate if he is referring to a secured zone or not (using a hash of a key). And the validator can then check if the destination is really secure. This needs only one bit: target of redirection is supposed to be secure yes/no. The chain of trust runs parralel to the delegation hierarchy, and I think sideways chains of trust need not enter the picture here. Not for your DNAME concerns. Although the above is what I think you want. I think the current DNAME situation is fine. The resolver can see if the target of a DNAME redirection is secure or not based on trust anchors, and is going to set the security result of the entire DNAME-chain to the lowest security encountered anyway. >>> This gets away from the problem where a resolver has one trust anchor, but do >>> esn't have a trust anchor for the target zone at the cost of requiring some a >>> dministration of the DS at the DNAME. Yeeks how to keep that DS up to date. Better one bit: target secure, it does not suffer from key rollover. >>> Continuing the logic from above, if you get a unsecure DNAME delegation (i.e. >>> DNAME without DS), you *stop* doing DNSSEC validation. It doesn't matter if >>> you have trust anchors for any further targets - the validation answer is UN >>> SECURE. This is required for consistency - different resolvers have differen >>> t sets of trust anchors. It's not all that coherent to get BOGUS from one, U >>> NSECURE from another and UNKNOWN from a third if you can avoid it. Chaining >>> security back to the original trust anchor and evaluating security in terms o >>> f data that chains back ONLY to that trust anchor seems to be the most consis >>> tent approach. >> There are only three possible outputs from a validating resolver. >> >> The *all* of the answer and authority sections are SECURE (ad=1). >> >> All of the answer and authority sections passed validation (got >> SECURE or INSECURE) and some part was INSECURE (ad=0). >> >> Validation failed for some part and you get SERVFAIL. >> >> There is no UNKNOWN output. Records without a trust anchor are >> INSECURE. I agree with Mark here. > We're just going to have to agree to disagree. I can distinguish between data where I have no information about its trust state (it might be signed, but I have NO trust anchor so I have no way of determining whether it is secure unsecure or bogus) and data where I have information about its trust state (because I have a trust anchor and I was able to run a validator and return one of secure, unsecure or bogus on the provided data). That difference may or may not be important to an end-application validator - but I'm not willing to exclude it from consideration at this point. So mentally from now on just substitute UNSECURE wherever I say UNKNOWN and I'll consider the protest given proforma.... :-) No. You see when a validator encounters a securely-insecure delegation, I mean a proof that a DS is absent. Then it knows that the remainder is not signed with a chain of trust from the trust anchor that it has been following. However, the result is simply insecure, and not somehow magically more secure that a result obtained without a trust anchor at all. What is the extra security afforded by a securely insecure delegation? The result is as prone to modification as a result obtained for a domain without trust anchor. Of course, the two domain set ups have a different operational configuration. So although you can give them different names (which can be useful for other things, such as operator debugging), they have the same level of security. >>> Let the mud slinging begin... :-) Cheers, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkAKB4ACgkQkDLqNwOhpPin2gCgtHuA1I2S/+Gok9TQ3BNnN7Pw Z+MAn2YAD/HLWriLwP0y2+q55FScRfW8 =nwDQ -----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 Thu Oct 23 02:49: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 A27C93A6959; Thu, 23 Oct 2008 02:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 rDRk9YvoJnrI; Thu, 23 Oct 2008 02:49:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B39AB3A6C45; Thu, 23 Oct 2008 02:49:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KswlO-00075a-Qf for namedroppers-data@psg.com; Thu, 23 Oct 2008 09:45:54 +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 1KswlK-000753-2u for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 09:45:52 +0000 Received: from [172.16.2.71] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m9N9ji2u078376; Thu, 23 Oct 2008 05:45:45 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <48F33C34.3010901@nlnetlabs.nl> <48F35170.30900@links.org> <4B27E2458EBA97669B259355@Ximines.local> <48F3B11B.8090202@links.org> Date: Thu, 23 Oct 2008 11:27:53 +0200 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: ed.lewis@neustar.biz 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: At 20:54 -0400 10/22/08, Michael StJohns wrote: >After thinking about this topic for a while, I'm still bothered by the >inconsistency of treatment here. What inconsistency? >But I think I have a possible mechanism - at least for DNAME. > >DNAME is the pretty much the equivalent of a delegation - only sideways. >Why not treat it like any other delegation? In other words, in addition to >the records currently permitted at a DNAME node, add DS to the list. >This would require slightly overloading the meaning of DS, but in a way >that doesn't break the model too much. This makes as much sense as "matrix management." DNAME isn't a delegation, it's a query restart. What if the DNAME says there is a DS for the target but following the tree down to the target has no DNAME? >This gets away from the problem where a resolver has one trust anchor, but >doesn't have a trust anchor for the target zone at the cost of requiring >some administration of the DS at the DNAME. This is not a problem. If the target of the DNAME is not DNSSEC protected, it doesn't matter to the DNS. The application maybe, but what can it do? If the target administrator has not signed the zone, then the application simply cannot validate the answer via DNSSEC. >another and UNKNOWN from a third if you can avoid it. Chaining security back >to the original trust anchor and evaluating security in terms of data that >chains back ONLY to that trust anchor seems to be the most >consistent approach. I think you are expecting too much from DNSSEC. Thinking about this scenario, if your application really needed security like this, why would there be the situation of secure DNAME insecure DNAME secure? Although this flip-flop may happen, will it happen where it matters? Is it realistic? Or are we whacking with a sledgehammer at a shadow? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Thu Oct 23 02:50: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 628B13A6C45; Thu, 23 Oct 2008 02:50:07 -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 HhGRagfvuRJ0; Thu, 23 Oct 2008 02:50:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EED1F3A6C05; Thu, 23 Oct 2008 02:50:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kswi1-0006o0-TD for namedroppers-data@psg.com; Thu, 23 Oct 2008 09:42:25 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kswhv-0006nQ-GR for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 09:42:22 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:To:Subject:MIME-Version:X-Mailer: Message-ID:From:Date:X-MIMETrack:Content-Type: Content-Transfer-Encoding; b=tkHPvFmmgKw/OsETW84eDXWz0DVLs5lKEMkA0ofN7pB/y8HU+QjjXAFH TLvwk8Nx+ZdMWHnL03nRPpVHFLecHSY51qE0IWxnsqefJLnZczHVkjo96 1GmlAJgFRmPH5ho; 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=1224754939; x=1256290939; 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:=20Source=20Po rt=20and=20QID=20selection=20for=20re-transmits?|Date:=20 Thu,=2023=20Oct=202008=2010:42:16=20+0100|Message-ID:=20< OFC76E0B00.F35C649D-ON802574EB.00341AB2-802574EB.00354F1B @nominet.org.uk>|To:=20namedroppers@ops.ietf.org |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable; bh=0SnlHykK0h9n0D7dq+q8MeOsNmGHJU+ovIt5T6BlYaM=; b=FuS9INhK9RtqLMsENjDytUNlUQhOQzN9PFtUEQtGf2pE7ApdExihfd8/ 4lXE1aDBo664bZFCHxqR8xscQmGdDGwPJZx+iPQ1vPf6sMcxRzTnC1mZi Za9fAXLUTqsvVTj; X-IronPort-AV: E=Sophos;i="4.33,469,1220223600"; d="scan'208";a="8366164" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 23 Oct 2008 10:42:17 +0100 To: namedroppers@ops.ietf.org Subject: [dnsext] Source Port and QID selection for re-transmits? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V85_M2_08202008 August 20, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 23 Oct 2008 10:42:16 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 23/10/2008 10:42:16 AM, Serialize complete at 23/10/2008 10:42:16 AM Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On researching a draft I'm writing I've been unable to find any guidance=20 on whether the QID and Source Port of a re-transmit should be the same as=20 for the original request. Post Kaminsky, my initial thought was that each re-transmission of a=20 request should pick a new QID and a new Source Port. However if an earlier attempt at the same request is still left=20 outstanding, such that a response to any of the retries would still be=20 accepted, this apparently creates a potential birthday attack situation=20 (as per =A75 of the Forgery Resilience draft). This could also contribute = to QID/SPort pool exhaustion. The FR draft itself is silent on this question. What are the WG's thoughts? Ray --=20 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 Oct 23 04:04: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 CC3FF28C1BC; Thu, 23 Oct 2008 04:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.119, 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 I1AYz8rP7oRU; Thu, 23 Oct 2008 04:04:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E98B328C1B2; Thu, 23 Oct 2008 04:04:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsxuJ-000DWC-Se for namedroppers-data@psg.com; Thu, 23 Oct 2008 10:59:11 +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 1KsxuC-000DUj-IP for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 10:59:07 +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.3/8.14.3) with ESMTP id m9NAwwrN070880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 12:58:59 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <490058F2.5020508@nlnetlabs.nl> Date: Thu, 23 Oct 2008 12:58:58 +0200 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Ray.Bellis@nominet.org.uk CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Source Port and QID selection for re-transmits? References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 23 Oct 2008 12:58:59 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ray.Bellis@nominet.org.uk wrote: > On researching a draft I'm writing I've been unable to find any guidance > on whether the QID and Source Port of a re-transmit should be the same as > for the original request. > What are the WG's thoughts? Leave to implementation. Lengthening the time the packet is accepted is one choice. Choosing new ID, port (and no longer accepting the old one) is another choice. You could caution against birthday attacks, but please do not prescribe implementation. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkAWPIACgkQkDLqNwOhpPgiEQCfdPrn5iPx1osvAKE7DsTnYxA3 6J4AoK/YPt6a4x7W/1/s36rL9sLHbtdt =Ax8n -----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 Thu Oct 23 04:05: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 D14D328C1A8; Thu, 23 Oct 2008 04:05:47 -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 1LbegT8PF6YN; Thu, 23 Oct 2008 04:05:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DFDB228C199; Thu, 23 Oct 2008 04:05:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ksxv6-000DbI-Mq for namedroppers-data@psg.com; Thu, 23 Oct 2008 11:00:00 +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 1Ksxuu-000DZO-6P for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 10:59:55 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 8498133C1F; Thu, 23 Oct 2008 12:01:11 +0100 (BST) Message-ID: <49005921.2090108@links.org> Date: Thu, 23 Oct 2008 11:59:45 +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: Michael StJohns CC: namedroppers@ops.ietf.org Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <48F33C34.3010901@nlnetlabs.nl> <48F35170.30900@links.org> <4B27E2458EBA97669B259355@Ximines.local> <48F3B11B.8090202@links.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Michael StJohns wrote: > After thinking about this topic for a while, I'm still bothered by > the inconsistency of treatment here. > > But I think I have a possible mechanism - at least for DNAME. > > DNAME is the pretty much the equivalent of a delegation - only > sideways. Why not treat it like any other delegation? In other > words, in addition to the records currently permitted at a DNAME > node, add DS to the list. This would require slightly overloading > the meaning of DS, but in a way that doesn't break the model too > much. > > If a DNAME node does not have at least one corresponding DS record > (proven by NSEC/NSEC3), the validation rules are exactly the same as > if you'd not included a DS for a subordinate delegation. E.g. no > DNSSEC is expected in the target zone. > > Since one of either DNAMEs or NS records can be present at a node (I > think that's correct), the interpretation of the DS record is > dependent on which of these two is present. If the type is DNAME, > the DS record points to a DNSKEY record at the target name and the > chain has to continue from there. > > This gets away from the problem where a resolver has one trust > anchor, but doesn't have a trust anchor for the target zone at the > cost of requiring some administration of the DS at the DNAME. > > Continuing the logic from above, if you get a unsecure DNAME > delegation (i.e. DNAME without DS), you *stop* doing DNSSEC > validation. It doesn't matter if you have trust anchors for any > further targets - the validation answer is UNSECURE. This is > required for consistency - different resolvers have different sets of > trust anchors. It's not all that coherent to get BOGUS from one, > UNSECURE from another and UNKNOWN from a third if you can avoid it. > Chaining security back to the original trust anchor and evaluating > security in terms of data that chains back ONLY to that trust anchor > seems to be the most consistent approach. > > In any event, I think this is at least somewhat backwards compatible. > > > Let the mud slinging begin... :-) I don't understand the rationale behind all this complication. If I chose to point a DNAME at an unsecured domain, then that was my choice, and I should live with it. If I don't want the domain to be unsecured, then I should either not delegate to it, or ensure it is secured by non-protocol means (e.g. by owning the domain myself, by contract, by sufficient purchase of beer for the domain owner, etc.) -- 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 Oct 23 06:40: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 5E1BA3A6889; Thu, 23 Oct 2008 06:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.959 X-Spam-Level: X-Spam-Status: No, score=-4.959 tagged_above=-999 required=5 tests=[AWL=0.089, 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 bWb80G21m7KI; Thu, 23 Oct 2008 06:39:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6E2CF3A6820; Thu, 23 Oct 2008 06:39:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kt0Kp-0002bm-2b for namedroppers-data@psg.com; Thu, 23 Oct 2008 13:34:43 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kt0Ke-0002ao-Il for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 13:34:36 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m9NDYLJG018238; Thu, 23 Oct 2008 06:34:21 -0700 (PDT) Cc: Nicholas Weaver , Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Wouter Wijngaards In-Reply-To: <490058F2.5020508@nlnetlabs.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [dnsext] Source Port and QID selection for re-transmits? Date: Thu, 23 Oct 2008 06:34:22 -0700 References: <490058F2.5020508@nlnetlabs.nl> X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Oct 23, 2008, at 3:58 AM, Wouter Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ray.Bellis@nominet.org.uk wrote: >> On researching a draft I'm writing I've been unable to find any >> guidance >> on whether the QID and Source Port of a re-transmit should be the >> same as >> for the original request. >> What are the WG's thoughts? > > Leave to implementation. Lengthening the time the packet is > accepted is > one choice. Choosing new ID, port (and no longer accepting the old > one) > is another choice. You could caution against birthday attacks, but > please do not prescribe implementation. I don't think it matters much: Case 1: Retry uses the same entropy. Case 2: Retry uses a new entropy set. For BOTH cases, there is an additional window of time outstanding where a spoofed packet could be received. There is a trivially slight attacker advantage on case 1, as the attacker can continue to send from a randomly selected subset of the entropy space instead of starting over, but if you have 32b+ of entropy, this advantage is going to be trivially small, and if you have only 16b of entropy, you are sunk anyway. -- to unsubscribe send a message to namedroppers-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 Oct 23 09:31: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 A251B3A6405; Thu, 23 Oct 2008 09:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[AWL=-1.040, 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 OLr5P0Cv6Pq7; Thu, 23 Oct 2008 09:31:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 53A103A685C; Thu, 23 Oct 2008 09:31:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kt301-000LBZ-QW for namedroppers-data@psg.com; Thu, 23 Oct 2008 16:25:25 +0000 Received: from [76.96.30.40] (helo=QMTA04.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kt2zn-000L9Z-6V for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 16:25:20 +0000 Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id WEhQ1a0040S2fkCA4GR99v; Thu, 23 Oct 2008 16:25:09 +0000 Received: from MIKES-LAPTOM.comcast.net ([68.48.0.197]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id WGR51a00U4F1VyU8VGR63k; Thu, 23 Oct 2008 16:25:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=gjHhN06smIIA:10 a=liyGigqBEMQA:10 a=hqaSkvWfAAAA:8 a=OzSqGtDSAAAA:8 a=tLdN9z_5qzAnzNSLCsAA:9 a=YnxxknQPltqC-fd1IK4A:7 a=pSuRVmeAMV5tSVlzk4JmigoBYOAA:4 a=h9s5Ru71U4oA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 23 Oct 2008 12:25:06 -0400 To: Ben Laurie From: Michael StJohns Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: namedroppers@ops.ietf.org In-Reply-To: <49005921.2090108@links.org> References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <48F33C34.3010901@nlnetlabs.nl> <48F35170.30900@links.org> <4B27E2458EBA97669B259355@Ximines.local> <48F3B11B.8090202@links.org> <49005921.2090108@links.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: At 06:59 AM 10/23/2008, Ben Laurie wrote: >Michael StJohns wrote: > >I don't understand the rationale behind all this complication. > >If I chose to point a DNAME at an unsecured domain, then that was my >choice, and I should live with it. If I don't want the domain to be >unsecured, then I should either not delegate to it, or ensure it is >secured by non-protocol means (e.g. by owning the domain myself, by >contract, by sufficient purchase of beer for the domain owner, etc.) Hi Ben - One of the problem we get with DNS is that there are two views of the data (at least) - the publisher's, and the resolver's views. DNSSEC makes this more complicated by the presence or absence of certain trust anchors. As publisher, I have a signed domain, and as publisher, I publish a DNAME also pointing at a signed domain. I've done my due diligence as you suggest - I even own the target zone. As resolver, I get a trust anchor for the first domain (more probably for a parent of the domain), but I don't have any a priori information that the target domain is also signed (or even that I had a redirect to that zone), so I don't know to get a trust anchor for it. There's no way of encoding in DNS/DNSSEC the publishers security intentions with respect to the complete DNAME chain. This leads to the problem where the publisher thought it was delegating into a signed zone, but the resolver thought the zone was unknown (no superior trust anchor). The resolver has no way of telling that the publisher really thought this zone was signed and that the resolver should return a BOGUS answer if the target zone wasn't. Answering Ed's question about inconsistency here: In a resolution without indirect records (e.g. DNAME, CNAME, MX, etc), the resolvers expectation about the security state of the answer are originally set by the presence or absence of a trust anchor and, assuming the trust anchor is present, that expectation changes only upon proof that it should (e.g. signed delegation into unsigned zone). With DNAME, once the resolver starts doing lookups in the target zone, it restarts its expectation of the state of the answer based on what it knows about trust anchors for the target. There is no chain of proof possible from the DNAME zone to the target zone in this model. My suggestions are an attempt to provide a chain of proof from the original trust anchor (provided by the DNAME publisher or its parent) through to the final answer. If that chain of proof validates, the resolver can say something useful about the entire answer chain and the final answer and I think that's the only case in which this is true. The case where the resolver just happens to have trust anchors for the DNAME zone and all of the target zones says useful things about each individual zone lookup, but not about the compound answer (I can elaborate here about DNAME publisher expectations and target zone publisher actions if necessary). >-- >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 Oct 23 09:42: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 567D63A6A0A; Thu, 23 Oct 2008 09:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.269 X-Spam-Level: X-Spam-Status: No, score=-1.269 tagged_above=-999 required=5 tests=[AWL=-0.832, 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 5HkKJZ0ZCLs2; Thu, 23 Oct 2008 09:42:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 284053A6930; Thu, 23 Oct 2008 09:42:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kt3CK-000MoD-67 for namedroppers-data@psg.com; Thu, 23 Oct 2008 16:38:08 +0000 Received: from [76.96.30.32] (helo=QMTA03.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kt3Bw-000Mkh-Sh for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 16:37:49 +0000 Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id WA8V1a0020cQ2SLA3GdjQb; Thu, 23 Oct 2008 16:37:43 +0000 Received: from MIKES-LAPTOM.comcast.net ([68.48.0.197]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id WGdg1a00S4F1VyU8WGdhsU; Thu, 23 Oct 2008 16:37:43 +0000 X-Authority-Analysis: v=1.0 c=1 a=gjHhN06smIIA:10 a=liyGigqBEMQA:10 a=48vgC7mUAAAA:8 a=MVm5Yr9nSXuRcVtt6UQA:9 a=rb5PnB5H7wEtQ_lT8FAA:7 a=WY4JyX0Wo6thwLUmAoeD6VpBtQ8A:4 a=8peU3wBK19oA:10 a=9k6G2--EmesA:10 a=r9vth0PIv-oA:10 a=rn3Q8Ux-5rcA:10 a=e1i35A98MB8A:10 a=78M5ERyKqZAA:10 a=g-J4WiLAdV0A:10 a=h9s5Ru71U4oA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 23 Oct 2008 12:37:41 -0400 To: Edward Lewis ,namedroppers@ops.ietf.org From: Michael StJohns Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: ed.lewis@neustar.biz In-Reply-To: References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <48F33C34.3010901@nlnetlabs.nl> <48F35170.30900@links.org> <4B27E2458EBA97669B259355@Ximines.local> <48F3B11B.8090202@links.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: At 05:27 AM 10/23/2008, Edward Lewis wrote: >At 20:54 -0400 10/22/08, Michael StJohns wrote: >>After thinking about this topic for a while, I'm still bothered by the >>inconsistency of treatment here. > >What inconsistency? See my note to Ben. >>But I think I have a possible mechanism - at least for DNAME. >> >>DNAME is the pretty much the equivalent of a delegation - only sideways. >>Why not treat it like any other delegation? In other words, in addition to >>the records currently permitted at a DNAME node, add DS to the list. >>This would require slightly overloading the meaning of DS, but in a way >>that doesn't break the model too much. > >This makes as much sense as "matrix management." DNAME isn't a delegation, it's a query restart. What if the DNAME says there is a DS for the target but following the tree down to the target has no DNAME? I'm not sure what you're getting at here. DNAMEs point off tree. So if I have foo.example.com DNAME otherexample.com foo.example.com DS foo.example.com NSEC [DNAME, DS] otherexample.com DNSKEY otherexample.com DNAME says go look at another zone. DS says here's how you bridge the trust. If you're saying, what happens if you do a DNAME to a name subordinate to the DNAME - isn't that one of those illegal cases for DNAME? >>This gets away from the problem where a resolver has one trust anchor, but >>doesn't have a trust anchor for the target zone at the cost of requiring >>some administration of the DS at the DNAME. > >This is not a problem. If the target of the DNAME is not DNSSEC protected, it doesn't matter to the DNS. This is a problem. DNAME publisher thought the target was protected, resolver didn't have trust anchors for it. >The application maybe, but what can it do? If the target administrator has not signed the zone, then the application simply cannot validate the answer via DNSSEC. > >>another and UNKNOWN from a third if you can avoid it. Chaining security back >>to the original trust anchor and evaluating security in terms of data that >>chains back ONLY to that trust anchor seems to be the most consistent approach. > >I think you are expecting too much from DNSSEC. > >Thinking about this scenario, if your application really needed security like this, why would there be the situation of secure DNAME insecure DNAME secure? Although this flip-flop may happen, will it happen where it matters? Is it realistic? Or are we whacking with a sledgehammer at a shadow? I used that one as an example to try and figure out what the output state was and got an answer from all of you that was inconsistent with the general contract. In the case I'm proposing - once you went unsecure - as provide by the DS chain through the DNAME - then you'd stay unsecure, just like you do now with signed delegations into unsigned zones. >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >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: -- to unsubscribe send a message to namedroppers-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 Oct 23 09:48: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 324083A67E4; Thu, 23 Oct 2008 09:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.459 X-Spam-Level: X-Spam-Status: No, score=-0.459 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 fnBPRB0iZTTk; Thu, 23 Oct 2008 09:48:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 41CD53A6405; Thu, 23 Oct 2008 09:48:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kt3J9-000NXk-TU for namedroppers-data@psg.com; Thu, 23 Oct 2008 16:45:11 +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 1Kt3Iz-000NW1-3c for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 16:45:08 +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 m9NGixQU082308 for ; Thu, 23 Oct 2008 12:44:59 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200810231644.m9NGixQU082308@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 23 Oct 2008 12:44:15 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: [dnsext] Fwd: Posting of IPR Disclosure Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_144770488==.ALT" X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --=====================_144770488==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed The chairs and editors of number of DNSSEC related RFC's got this notice overnight. This is being posted to the working group for information only, see https://datatracker.ietf.org/ipr/1000/ As usual, the IETF takes no position with respect to the validity of IPR claims, and you are reminded to read the relevant Intellectual Property statement in RFCs of interest to you, and evaluate the claims of the Intellectual Property holder. Olafur and Andrew >From: IETF Secretariat >Subject: Posting of IPR Disclosure >Cc: jari.arkko@piuha.net, townsley@cisco.com, ogud@ogud.com, > ajs@commandprompt.com >Date: Wed, 22 Oct 2008 15:36:49 -0700 (PDT) >X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 > >Dear Dan Massey, Matt Larson, Rob Austein, Scott Rose, Roy Arends: > >An IPR disclosure that pertains to your RFC entitled "DNS Security >Introduction >and Requirements" (RFC4033) was submitted to the IETF Secretariat on >2008-10-02 >and has been posted on the "IETF Page of Intellectual Property Rights >Disclosures" (https://datatracker.ietf.org/public/ipr_list.cgi). The title of >the IPR disclosure is "Todd S. Glassey, IP owner's Statement about IPR related >to RFC 4033, RFC 4034, RFC 4035, RFC 5155, RFC 4310, RFC 5011, RFC >4398, and IPR >claimed in Glassey GeoSpatial Keying and Evidentiary Digital >Testimony Models." > >The IETF Secretariat --=====================_144770488==.ALT Content-Type: text/html; charset="us-ascii"
The chairs and editors of number of DNSSEC related RFC's got this notice
overnight.
This is being posted to the working group for information only, see
https://datatracker.ietf.org/ipr/1000/

As usual, the IETF takes no position with respect to the validity of
IPR claims, and you are reminded to read the relevant Intellectual
Property statement in RFCs of interest to you, and evaluate the claims
of the Intellectual Property holder.

        Olafur and Andrew

From: IETF Secretariat <ietf-ipr@ietf.org>
Subject: Posting of IPR Disclosure
Cc: jari.arkko@piuha.net, townsley@cisco.com, ogud@ogud.com,
        ajs@commandprompt.com
Date: Wed, 22 Oct 2008 15:36:49 -0700 (PDT)
X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20

Dear Dan Massey, Matt Larson, Rob Austein, Scott Rose, Roy Arends:

An IPR disclosure that pertains to your RFC entitled "DNS Security Introduction
and Requirements" (RFC4033) was submitted to the IETF Secretariat on 2008-10-02
and has been posted on the "IETF Page of Intellectual Property Rights
Disclosures" ( https://datatracker.ietf.org/public/ipr_list.cgi). The title of
the IPR disclosure is "Todd S. Glassey, IP owner's Statement about IPR related
to RFC 4033, RFC 4034, RFC 4035, RFC 5155, RFC 4310, RFC 5011, RFC 4398, and IPR
claimed in Glassey GeoSpatial Keying and Evidentiary Digital Testimony Models."

The IETF Secretariat
--=====================_144770488==.ALT-- -- to unsubscribe send a message to namedroppers-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 Oct 23 09:57: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 122203A6912; Thu, 23 Oct 2008 09:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.919 X-Spam-Level: ** X-Spam-Status: No, score=2.919 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJEnmY6ZriqZ; Thu, 23 Oct 2008 09:57:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 23CA43A67EE; Thu, 23 Oct 2008 09:57:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kt3OW-000OGj-Gx for namedroppers-data@psg.com; Thu, 23 Oct 2008 16:50:44 +0000 Received: from [195.188.213.5] (helo=smtp-out2.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kt3OM-000OEK-O2 for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 16:50:38 +0000 Received: from [172.23.170.146] (helo=anti-virus03-09) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1Kt3OH-0007le-Pp; Thu, 23 Oct 2008 17:50:30 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1Kt3OC-0003cE-AX; Thu, 23 Oct 2008 17:50:24 +0100 Message-ID: From: "George Barwood" To: , References: Subject: Re: [dnsext] Source Port and QID selection for re-transmits? Date: Thu, 23 Oct 2008 17:50:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I believe the source port should be the same, due to rather low limits placed by common NAT firewalls on incoming connections - the server behind the firewall might be capable of handling millions of requests a minute, but the firewall limit might be only 100 "connections" per minute. For the QID, either possibility is ok. If a single response is expected to be sufficient, using the same QID preserves slightly more entropy ( about 1 bit ). However if multiple responses are needed, you might get two responses with the same QID, which is no good ( only one can be counted ), if the server is just slow responding to the first query. Using a new QID each time is simplest, and would be my recommendation. George ----- Original Message ----- From: To: Sent: Thursday, October 23, 2008 10:42 AM Subject: [dnsext] Source Port and QID selection for re-transmits? On researching a draft I'm writing I've been unable to find any guidance on whether the QID and Source Port of a re-transmit should be the same as for the original request. Post Kaminsky, my initial thought was that each re-transmission of a request should pick a new QID and a new Source Port. However if an earlier attempt at the same request is still left outstanding, such that a response to any of the retries would still be accepted, this apparently creates a potential birthday attack situation (as per §5 of the Forgery Resilience draft). This could also contribute to QID/SPort pool exhaustion. The FR draft itself is silent on this question. What are the WG's thoughts? 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: -- to unsubscribe send a message to namedroppers-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 Oct 23 10:20: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 064BB3A6824; Thu, 23 Oct 2008 10:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[AWL=-0.694, 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 RG49n4XGxCcU; Thu, 23 Oct 2008 10:20:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 499D03A67EE; Thu, 23 Oct 2008 10:20:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kt3oX-0001Ir-44 for namedroppers-data@psg.com; Thu, 23 Oct 2008 17:17:37 +0000 Received: from [76.96.62.17] (helo=QMTA10.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kt3oM-0001Hn-VY for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 17:17:33 +0000 Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA10.westchester.pa.mail.comcast.net with comcast id WGLx1a0030ldTLk5AHHP6L; Thu, 23 Oct 2008 17:17:23 +0000 Received: from MIKES-LAPTOM.comcast.net ([68.48.0.197]) by OMTA04.westchester.pa.mail.comcast.net with comcast id WHHN1a00b4F1VyU3QHHPdQ; Thu, 23 Oct 2008 17:17:23 +0000 X-Authority-Analysis: v=1.0 c=1 a=gjHhN06smIIA:10 a=liyGigqBEMQA:10 a=48vgC7mUAAAA:8 a=G58vr2_-s7vpSwHLCn8A:9 a=LipzKe-qSQHJijddDDsA:7 a=zIyUpY2et9tT1aUzOXx9gPcpKa8A:4 a=8peU3wBK19oA:10 a=4rq7TwIXcRUA:10 a=g-J4WiLAdV0A:10 a=h9s5Ru71U4oA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 23 Oct 2008 13:17:23 -0400 To: Wouter Wijngaards From: Michael StJohns Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: Mark Andrews ,namedroppers@ops.ietf.org In-Reply-To: <4900281E.50307@nlnetlabs.nl> References: <200810230343.m9N3hO08055012@drugs.dv.isc.org> <4900281E.50307@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: At 03:30 AM 10/23/2008, Wouter Wijngaards wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi Michael, > >You can propose some new mechanism here, but do not overload the DS >semantics more. Get a new type code, like DLV did. Fair - but the the new record will pretty much have the same syntax and semantics. >That said, lets sling some mud :-) > >Michael StJohns wrote: >> At 11:43 PM 10/22/2008, Mark Andrews wrote: >>>> DNAME is the pretty much the equivalent of a delegation - only sideways. W >>>> hy not treat it like any other delegation? In other words, in addition to th >>>> e records currently permitted at a DNAME node, add DS to the list. This woul >>>> d require slightly overloading the meaning of DS, but in a way that doesn't b >>>> reak the model too much. >>>> > >So you want the owner of the DNAME to indicate if he is referring to a >secured zone or not (using a hash of a key). And the validator can then >check if the destination is really secure. This needs only one bit: >target of redirection is supposed to be secure yes/no. I considered this - but that means that you need to ensure that all the resolvers have the second and subsequent trust anchors and that's problematic. Encoding the chain of trust as part of the DNAME referral means that I as publisher don't have to worry (much) about whether or not the resolver has my target's trust anchor. >The chain of trust runs parralel to the delegation hierarchy, and I >think sideways chains of trust need not enter the picture here. Not for >your DNAME concerns. > >Although the above is what I think you want. I think the current DNAME >situation is fine. The resolver can see if the target of a DNAME >redirection is secure or not based on trust anchors, and is going to set >the security result of the entire DNAME-chain to the lowest security >encountered anyway. Yeah, except there's no way of encoding this in a return from a validating recursive resolver to a non-DNSSEC aware stub. The one bit approach that tells the resolver to block a return unless the entire answer validates (or is securely unsecure) is slightly better, but gets into a coherence issue. >>>> This gets away from the problem where a resolver has one trust anchor, but do >>>> esn't have a trust anchor for the target zone at the cost of requiring some a >>>> dministration of the DS at the DNAME. > >Yeeks how to keep that DS up to date. Better one bit: target secure, it >does not suffer from key rollover. If I'm DNAMEing to a zone, I'm going to have to set up some protocol for dealing with changes to that zone. A variant of the trust anchor update stuff would work here. >>>> Continuing the logic from above, if you get a unsecure DNAME delegation (i.e. >>>> DNAME without DS), you *stop* doing DNSSEC validation. It doesn't matter if >>>> you have trust anchors for any further targets - the validation answer is UN >>>> SECURE. This is required for consistency - different resolvers have differen >>>> t sets of trust anchors. It's not all that coherent to get BOGUS from one, U >>>> NSECURE from another and UNKNOWN from a third if you can avoid it. Chaining >>>> security back to the original trust anchor and evaluating security in terms o >>>> f data that chains back ONLY to that trust anchor seems to be the most consis >>>> tent approach. >>> There are only three possible outputs from a validating resolver. >>> >>> The *all* of the answer and authority sections are SECURE (ad=1). >>> >>> All of the answer and authority sections passed validation (got >>> SECURE or INSECURE) and some part was INSECURE (ad=0). >>> >>> Validation failed for some part and you get SERVFAIL. >>> >>> There is no UNKNOWN output. Records without a trust anchor are >>> INSECURE. > >I agree with Mark here. > >> We're just going to have to agree to disagree. I can distinguish between data where I have no information about its trust state (it might be signed, but I have NO trust anchor so I have no way of determining whether it is secure unsecure or bogus) and data where I have information about its trust state (because I have a trust anchor and I was able to run a validator and return one of secure, unsecure or bogus on the provided data). That difference may or may not be important to an end-application validator - but I'm not willing to exclude it from consideration at this point. So mentally from now on just substitute UNSECURE wherever I say UNKNOWN and I'll consider the protest given proforma.... :-) > >No. > >You see when a validator encounters a securely-insecure delegation, I >mean a proof that a DS is absent. Then it knows that the remainder is >not signed with a chain of trust from the trust anchor that it has been >following. However, the result is simply insecure, and not somehow >magically more secure that a result obtained without a trust anchor at >all. What is the extra security afforded by a securely insecure >delegation? The result is as prone to modification as a result obtained >for a domain without trust anchor. It's a fair comment. Here's why I continue to fight this. A trust anchor provides two pieces of information: a public key, and by the mere presence of the trust anchor the initial state of a virtual "zone is signed" bit. The absence of the trust anchor does not equate to "zone is not signed" but to "resolver doesn't know whether the zone is signed" Think of it this way, the unknown state is like the X state in ASIC circuitry design. You may end up treating it as a 0 or 1 at some point, but you have to figure out a way of collapsing it to the 0 or 1 first. Resolvers basically collapse the X to a 0 - unsecure - because they don't have the ancillary information (trust anchor) to treat it as a 1. The resolver doesn't know if the zone is signed, but it has no way of proceeding unless it treats the zone as unsigned. The transition from X to 0 is not secure - there's no cryptographic proof to do the state setting. This differs from a secure transition from secure to unsecure - from 1 to 0 - by doing a signed delegation to an unsigned zone. I actually can at some point see some policy wonk requiring that resolvers under the wonk's control will not resolve names unless they are under a trust anchor. He won't care about the fact that some delegations are to unsecure zones - he's just concerned about getting DNSSEC deployed. So yes - I still think there's a difference. While I was going through this exercise of answering your email, Ben's and Ed's I came up with a pretty good example of why I think this (chaining through a DNAME) is necessary. I work for the example.com company. My local recursive resolver has been set up with example.com trust anchors. The example.com zone includes a set of records which describe the SSH fingerprints for those machines. example.com is sold to otherexample.com and a DNAME record is placed into the system to do the redirect. My local resolver still only has the trust anchor for example.com. I go to a new machine asking the "newmachine.example.com" question to retrieve the SSH fingerprint (I'm an old timer - I'm still using old scripts). I get an answer for the SSH fingerprint and for an A record - which has been cheerfully forged by a data thief. I go to that machine, update the 10 gig of ssn's, names and birthdates that I'm archiving from a machine I'm about to rebuild. That machine is somewhere in russia, china, new york, etc... and its not a company machine. Out of band, I (person, machine whatever) was told I could rely on the data returned from the resolver for security purposes. (And this is why I've told people over the years that DNSSEC should not be relied upon to validate anything other than DNS data). My machine was set up with that assumption in mind. The local resolver is doing what its supposed to do under the current DNAME interpretation. My machine is doing what it is supposed to do with the data. But I got screwed. >Of course, the two domain set ups have a different operational >configuration. So although you can give them different names (which can >be useful for other things, such as operator debugging), they have the >same level of security. > >>>> Let the mud slinging begin... :-) > >Cheers, > Wouter >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.9 (GNU/Linux) > >iEYEARECAAYFAkkAKB4ACgkQkDLqNwOhpPin2gCgtHuA1I2S/+Gok9TQ3BNnN7Pw >Z+MAn2YAD/HLWriLwP0y2+q55FScRfW8 >=nwDQ >-----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 Thu Oct 23 10:22: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 C024A3A684D; Thu, 23 Oct 2008 10:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.689 X-Spam-Level: ** X-Spam-Status: No, score=2.689 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, 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 JxMJMaoHA-+k; Thu, 23 Oct 2008 10:22:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D8C9F3A67EE; Thu, 23 Oct 2008 10:22:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kt3r9-0001Xq-V8 for namedroppers-data@psg.com; Thu, 23 Oct 2008 17:20:19 +0000 Received: from [195.188.213.5] (helo=smtp-out2.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kt3r1-0001Wp-KC for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 17:20:16 +0000 Received: from [172.23.170.140] (helo=anti-virus02-07) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1Kt3r0-0002iA-LN for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 18:20:10 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1Kt3qz-0000Jt-8s for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 18:20:09 +0100 Message-ID: <16F84B3586CB467B8B95569F7B344DA2@localhost> From: "George Barwood" To: References: <05938DB8C4884FA693B84BF19F426168@localhost> <5838342A-EF9E-4527-A8BF-181DCBBA6061@icsi.berkeley.edu> Subject: Re: [dnsext] FR: An argument against 0x20 and mitigation by standard labels Date: Thu, 23 Oct 2008 18:19:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: It's true that the memory requirements for caches are modest. But I can imagine a few examples where wasting memory might be significant: (1) Old, overloaded computers with modest amounts of memory. I have one of those on my desk. (2) Tiny devices of the future, say a computer embedded in the hologram of a credit card, where memory and power might still be at a premium. (3) A clockwork computer built from scrap. My imagination may be lacking, as well. If there is an opportunity to save resources in a protocol, at no cost, I think 2 lines in a document is a reasonable investment. There might be other human-level benefits (such strings will be readily recognised as being there for entropy), and it's good protocol design to have one preferred way to do something. George ( who remembers upgrading the RAM on his first computer from 4 kilobytes to 16 kilobytes! ) ----- Original Message ----- From: "Nicholas Weaver" To: "George Barwood" Cc: "Nicholas Weaver" ; Sent: Wednesday, October 22, 2008 4:32 PM Subject: Re: [dnsext] FR: An argument against 0x20 and mitigation by standard labels > > On Oct 22, 2008, at 3:07 AM, George Barwood wrote: > >> A possible argument against 0x20 is that administrators, in order to >> lessen the load on their authoritative name servers from resolvers that >> implement 0x20 and repetition, may start using long labels. >> >> This could lead to increased memory requirement for caches. > > I don't think this is a concern: > > Lets take a resolver that has 1 Million! cache entries. At an extra 10B > a label (for extra 0x20-padding on names?), this would be a whopping 10MB > of memory. Suppose the same resolver has 100M active cache entries. > Thats still just 1 GB. Or about $30. > > So who cares about the memory usage of slightly longer names? > > > -- > to 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 Thu Oct 23 13: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 622A73A68B5; Thu, 23 Oct 2008 13:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.204, 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 h78S2heCCemu; Thu, 23 Oct 2008 13:21:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8B9203A6AA7; Thu, 23 Oct 2008 13:21:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kt6be-000JXB-7M for namedroppers-data@psg.com; Thu, 23 Oct 2008 20:16:30 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kt6bW-000JWI-Sj for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 20:16:27 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 297713A6AAD; Thu, 23 Oct 2008 13:15:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-rsasha256-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081023201501.297713A6AAD@core3.amsl.com> Date: Thu, 23 Oct 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 : 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-06.txt Pages : 9 Date : 2008-10-23 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-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-rsasha256-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-23130344.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 Thu Oct 23 14:18: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 EE6BB3A6B17; Thu, 23 Oct 2008 14:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 SlKaj2z2pViB; Thu, 23 Oct 2008 14:18:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 192AA3A698A; Thu, 23 Oct 2008 14:18:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kt7U9-000NZq-VQ for namedroppers-data@psg.com; Thu, 23 Oct 2008 21:12:49 +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 1Kt7U2-000NZC-JO for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 21:12:46 +0000 Received: from [172.18.116.253] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m9NLCbMQ085077; Thu, 23 Oct 2008 17:12:38 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <48F2DE42.1060209@links.org> <48F33C34.3010901@nlnetlabs.nl> <48F35170.30900@links.org> <4B27E2458EBA97669B259355@Ximines.local> <48F3B11B.8090202@links.org> <49005921.2090108@links.org> Date: Thu, 23 Oct 2008 23:10:48 +0200 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: ed.lewis@neustar.biz 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: At 12:25 -0400 10/23/08, Michael StJohns wrote: >My suggestions are an attempt to provide a chain of proof from the original >trust anchor (provided by the DNAME publisher or its parent) through to the >final answer. I think that's all out of bounds for DNSSEC. DNSSEC is protecting the transfer of data within the DNS. o What if you go to a signed NAPTR record, get a replacement name that is unsigned, then a replacement string that goes to a signed SRV which leads to an unsigned A record? o What if you to to a web page that has a signed A record but are then redirected to a web page that has no signed address record? DNAME, CNAME, NAPTR, and some applications the query changes from the start to end of the whole DNS session. I'm now defining (becuase it is convenient for my side of the argument) "DNS session" to consist of any number of DNS iterations leading to the satisfaction of the application. DNSSEC protects the iteration, not the session. o What does DNS tell a user if an application, outside of the DNS, changes the name sought as a result of it's lookup process, starting from a name that was DNSSEC validated to a name that has no DNSSEC ancillary data? More or less, I don't think the problem (as I understand what Mike wants) is solvable or is commonplace enough (or even realistic) to warrant something so radical as barfing the DS record. (Heck, it's a hack Olafur invented, that was one of the three things I didn't like about it an eon ago - ask him.) Too bad I can't make it to Bethesda tonight so we could talk this over at the corner of Del Ray and Norfolk. (I.e., where there would be witnesses.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Thu Oct 23 14:28: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 57E503A6867; Thu, 23 Oct 2008 14:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[AWL=-0.394, 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 TGeafrC8onON; Thu, 23 Oct 2008 14:28:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 577933A676A; Thu, 23 Oct 2008 14:28:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kt7df-000OE4-RK for namedroppers-data@psg.com; Thu, 23 Oct 2008 21:22:39 +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 1Kt7dY-000ODP-2y for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 21:22:36 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m9NLMSRb085212 for ; Thu, 23 Oct 2008 17:22:28 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m9NLMSiI085211 for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 17:22:28 -0400 (EDT) (envelope-from namedroppers) Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KsgPK-0003sC-7r for namedroppers@ops.ietf.org; Wed, 22 Oct 2008 16:18:15 +0000 Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id m9MGGm05019332 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 22 Oct 2008 12:16:48 -0400 Date: Wed, 22 Oct 2008 12:16:47 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Nicholas Weaver cc: George Barwood , Subject: Re: [dnsext] FR: An argument against 0x20 and mitigation by standard labels In-Reply-To: <5838342A-EF9E-4527-A8BF-181DCBBA6061@icsi.berkeley.edu> Message-ID: 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: [ Note: Post was moderated. ] On Wed, 22 Oct 2008, Nicholas Weaver wrote: > > On Oct 22, 2008, at 3:07 AM, George Barwood wrote: > > > A possible argument against 0x20 is that administrators, in order to > > lessen the load on their authoritative name servers from resolvers > > that implement 0x20 and repetition, may start using long labels. > > > > This could lead to increased memory requirement for caches. > > I don't think this is a concern: > > Lets take a resolver that has 1 Million! cache entries. At an extra > 10B a label (for extra 0x20-padding on names?), this would be a > whopping 10MB of memory. Suppose the same resolver has 100M active > cache entries. Thats still just 1 GB. Or about $30. > > So who cares about the memory usage of slightly longer names? Once that 1G gets paged out, you care. But I think this 'entropy' in names business is just nonsense anyway. I am sure I won't be running it, nor advising anyone else to run it. Same for DNSinSEC, err DNSSEC. Sorry I can't give a more detailed response now, but I'm busy writing up a paper for NTIA on DNSSEC insecurity. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-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 Oct 23 15:29: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 BFB733A67EE; Thu, 23 Oct 2008 15:29:09 -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 fDPvdiIC0SbR; Thu, 23 Oct 2008 15:29:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C73F03A67AF; Thu, 23 Oct 2008 15:29:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kt8bp-0002hO-MN for namedroppers-data@psg.com; Thu, 23 Oct 2008 22:24:49 +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 1Kt8bf-0002gR-7y for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 22:24:44 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id m9NMOR2A068911; Fri, 24 Oct 2008 09:24:28 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200810232224.m9NMOR2A068911@drugs.dv.isc.org> To: Michael StJohns Cc: Ben Laurie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME In-reply-to: Your message of "Thu, 23 Oct 2008 12:25:06 EDT." Date: Fri, 24 Oct 2008 09:24:27 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , Michael StJohns writes: > At 06:59 AM 10/23/2008, Ben Laurie wrote: > >Michael StJohns wrote: > > > >I don't understand the rationale behind all this complication. > > > >If I chose to point a DNAME at an unsecured domain, then that was my > >choice, and I should live with it. If I don't want the domain to be > >unsecured, then I should either not delegate to it, or ensure it is > >secured by non-protocol means (e.g. by owning the domain myself, by > >contract, by sufficient purchase of beer for the domain owner, etc.) > > Hi Ben - > > One of the problem we get with DNS is that there are two views of the data (a > t least) - the publisher's, and the resolver's views. DNSSEC makes this more > complicated by the presence or absence of certain trust anchors. > > As publisher, I have a signed domain, and as publisher, I publish a DNAME als > o pointing at a signed domain. I've done my due diligence as you suggest - I > even own the target zone. Signing the zones and publishing DS / DLV records is due diligence. At that point you need to trust that the resolver operator will do due diligence and configure all known trust anchors or use a DLV service. Yes there will be configurations that will not return SECURE when there is theoretically enough information to return SECURE. And the simple answer is to just ensure that there is a chain of trust from the root to both zones. If you are unhappy about the lack of trust chains lobby your politicians and registry operators to get the root and infrastructure zones signed. This is not something we need to "fix" using technology. What we have today is complicated enough to manage without having to track cross zone pseudo delegations. 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 Fri Oct 24 13:02: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 062F33A67AF; Fri, 24 Oct 2008 13:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.638 X-Spam-Level: X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[AWL=-0.143, 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 fvHtfnJed5gC; Fri, 24 Oct 2008 13:02:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D8EDE3A677D; Fri, 24 Oct 2008 13:02:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KtSkB-000Ouc-Sr for namedroppers-data@psg.com; Fri, 24 Oct 2008 19:54:47 +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 1KtSjz-000OtV-DG for namedroppers@ops.ietf.org; Fri, 24 Oct 2008 19:54:43 +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 m9OJweIF004894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Oct 2008 12:58:43 -0700 Date: Fri, 24 Oct 2008 15:54:30 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Re: Results of WGLC: draft-ietf-dnsext-dnssec-rsasha256-05 Message-ID: <20081024195430.GD7013@commandprompt.com> References: <20081022211620.GA1896@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081022211620.GA1896@commandprompt.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]); Fri, 24 Oct 2008 12:58:44 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, On Wed, Oct 22, 2008 at 05:16:20PM -0400, Andrew Sullivan wrote: > The editor has agreed to make all these changes, and post a -06 for > final consideration. One week after -06 becomes available, unless > anyone objects to specific changes that were made in response to the > WGLC (or, of course, comes up with a complete showstopper that has > never been raised), we'll send the document to the IESG. I note that the -06 draft has been posted, so please check it and send any remarks you may have within the next week. Best regards, Andrew -- 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 Oct 24 14:14: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 E0E2F3A6A76; Fri, 24 Oct 2008 14:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.628 X-Spam-Level: X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[AWL=-0.133, 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 jyyfwIN10agB; Fri, 24 Oct 2008 14:14:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E861A3A6A70; Fri, 24 Oct 2008 14:14:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KtTvQ-0005Um-Sq for namedroppers-data@psg.com; Fri, 24 Oct 2008 21:10:28 +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 1KtTvA-0005TP-3G for namedroppers@ops.ietf.org; Fri, 24 Oct 2008 21:10:15 +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 m9OLEGcc010058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Oct 2008 14:14:20 -0700 Date: Fri, 24 Oct 2008 17:10:07 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Agenda items for Minneapolis, IETF-73 Message-ID: <20081024211006.GI7013@commandprompt.com> Reply-To: ajs@shinkuro.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]); Fri, 24 Oct 2008 14:14:21 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, The draft WG agenda deadline is swiftly approaching. We will have time on the agenda to deal with the additinal forgery resilience proposals, so if you have submitted something for consideration under that topic, there is no need to request time for it. If you have other items that you wish to have addressed during the meeting, please send them to me. I would appreciate receiving them by 2008-10-31, and if you send them to this address after that date there is no gurantee I will receive them (but you can use the Reply-To in the headers of this mail to reach me from now until after that date). Items that I have not received by 2008-11-03 may not be included on the agenda, because Olafur and I will be arranging the agenda on the basis of what I have by the 3d. So get your requests in soon! When requesting a slot, please give me some idea of how much time you need. Please remember, when requesting a slot, that we have 1.5 hours for this meeting. We can't promise that every request can be accommodated. Best regards, Andrew -- 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 Oct 24 14:58: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 38FF63A69C4; Fri, 24 Oct 2008 14:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.032 X-Spam-Level: X-Spam-Status: No, score=-1.032 tagged_above=-999 required=5 tests=[AWL=-0.595, 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 H5wCZQXT6LyC; Fri, 24 Oct 2008 14:58:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DE2F83A6806; Fri, 24 Oct 2008 14:58:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KtUcM-0009ZA-Jo for namedroppers-data@psg.com; Fri, 24 Oct 2008 21:54:50 +0000 Received: from [76.96.30.48] (helo=QMTA05.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KtUcE-0009Xx-Dq for namedroppers@ops.ietf.org; Fri, 24 Oct 2008 21:54:45 +0000 Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id Wjil1a00u1GXsucA5luiod; Fri, 24 Oct 2008 21:54:42 +0000 Received: from MIKES-LAPTOM.comcast.net ([68.48.0.197]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id Wlug1a0094F1VyU8TlugY2; Fri, 24 Oct 2008 21:54:41 +0000 X-Authority-Analysis: v=1.0 c=1 a=gjHhN06smIIA:10 a=liyGigqBEMQA:10 a=48vgC7mUAAAA:8 a=I3GvcKrlCDZcWeMPIyYA:9 a=xefR4WxFvj0GbfJ5Dm4A:7 a=rTK_Y30xzfOF6P7gioB5lHwLUiQA:4 a=4rq7TwIXcRUA:10 a=PKgchsl1YdkA:10 a=iw4bf7yTzGQA:10 a=h9s5Ru71U4oA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 24 Oct 2008 17:54:40 -0400 To: Mark Andrews From: Michael StJohns Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: Ben Laurie ,namedroppers@ops.ietf.org In-Reply-To: <200810232224.m9NMOR2A068911@drugs.dv.isc.org> References: <200810232224.m9NMOR2A068911@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: At 06:24 PM 10/23/2008, Mark Andrews wrote: >In message , Michael StJohns writes: >> At 06:59 AM 10/23/2008, Ben Laurie wrote: >> >Michael StJohns wrote: >> > >> >I don't understand the rationale behind all this complication. >> > >> >If I chose to point a DNAME at an unsecured domain, then that was my >> >choice, and I should live with it. If I don't want the domain to be >> >unsecured, then I should either not delegate to it, or ensure it is >> >secured by non-protocol means (e.g. by owning the domain myself, by >> >contract, by sufficient purchase of beer for the domain owner, etc.) >> >> Hi Ben - >> >> One of the problem we get with DNS is that there are two views of the data (a >> t least) - the publisher's, and the resolver's views. DNSSEC makes this more >> complicated by the presence or absence of certain trust anchors. >> >> As publisher, I have a signed domain, and as publisher, I publish a DNAME als >> o pointing at a signed domain. I've done my due diligence as you suggest - I >> even own the target zone. > > Signing the zones and publishing DS / DLV records is due > diligence. At that point you need to trust that the resolver > operator will do due diligence and configure all known trust > anchors or use a DLV service. I haven't a clue how you would expect to administer this. When was the last time you heard of someone running a zone who changed it out for a DNAME announcing this to the world? 5011 provides a mechanism to track changes in trust anchors without having to have an out of band path to those changes. Are you proposing that we create some sort of DNAME announcement protocol? Or are you suggesting something else? Let's work this further. Say .COM is signed, but .EDU isn't. Say I'm in a secure zone under .com - example.com. Say the DNAME is from subzone.example.com to otherzone.edu. Say otherzone.edu is signed. Say the resolver has a trust anchor for .COM. How the heck do I as the owner of subzone.example.com figure out which resolvers to tell about the change?? In many (most?) organizations, the guys who run the authoritative servers and update the data in the zones are not the guys who run the local resolvers, so even in the same organization the administrators may not realize they need to do something special. Certainly the DNAME documentation doesn't describe any operational considerations related to DNSSEC. > Yes there will be configurations that will not return SECURE > when there is theoretically enough information to return > SECURE. > > And the simple answer is to just ensure that there is a > chain of trust from the root to both zones. If you are > unhappy about the lack of trust chains lobby your politicians > and registry operators to get the root and infrastructure > zones signed. That may be the simple answer, but even simple answers are difficult. See above. And the fact that all nodes chain to a trust anchor is not sufficient to say that there is an unbroken chain of trust from the first trust anchor to the last answer. > This is not something we need to "fix" using technology. > What we have today is complicated enough to manage without > having to track cross zone pseudo delegations *sigh* There's complicated and there's correct. If its complicated and wrong, its still wrong. > 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: -- to unsubscribe send a message to namedroppers-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 Oct 24 15:25: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 7F03F28C15D; Fri, 24 Oct 2008 15:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 qPZaYB7JWy4l; Fri, 24 Oct 2008 15:25:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7649528C14E; Fri, 24 Oct 2008 15:25:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KtV25-000BgU-17 for namedroppers-data@psg.com; Fri, 24 Oct 2008 22:21:25 +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 1KtV1w-000Bf8-EN for namedroppers@ops.ietf.org; Fri, 24 Oct 2008 22:21:18 +0000 Received: from [172.18.116.246] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m9OMLAVV097262; Fri, 24 Oct 2008 18:21:11 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200810232224.m9NMOR2A068911@drugs.dv.isc.org> Date: Sat, 25 Oct 2008 00:21:07 +0200 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: ed.lewis@neustar.biz 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: At 17:54 -0400 10/24/08, Michael StJohns wrote: >How the heck do I as the owner of subzone.example.com figure out which >resolvers to tell about the change?? The answer is "you don't" and "DNSSEC never promised you could." Remember that the, okay, a fundamental rule of DNSSEC is that it is there to protect the resolver and not the authority of the data. You (as an admin) don't have any tools to reach out and touch your audience. Just as DNSSEC does not guarantee the answer will get through (no DoS prevention) it only guarantees that what is received can be validated (if the stars align). DNSSEC is driven from the resolver and not the authority. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 27 01:15: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 D6A9C3A6855; Mon, 27 Oct 2008 01:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.163 X-Spam-Level: ** X-Spam-Status: No, score=2.163 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 RNOeTdDh4JJA; Mon, 27 Oct 2008 01:15:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5B02F3A6922; Mon, 27 Oct 2008 01:15:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KuN8i-000LxQ-5Z for namedroppers-data@psg.com; Mon, 27 Oct 2008 08:07:52 +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 1KuN8a-000Lvo-NW for namedroppers@ops.ietf.org; Mon, 27 Oct 2008 08:07:47 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 4D9EA94B35; Mon, 27 Oct 2008 09:07:37 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 973DB93B7A; Mon, 27 Oct 2008 12:03:00 +0400 (GST) Date: Mon, 27 Oct 2008 12:03:00 +0400 From: Stephane Bortzmeyer To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Message-ID: <20081027080300.GA22504@laperouse.bortzmeyer.org> References: <48F3B11B.8090202@links.org> <49005921.2090108@links.org> 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: [Warning, most of the ideas here come from my colleeague Mohsen Souissi but he is too busy to write now.] On Thu, Oct 23, 2008 at 11:10:48PM +0200, Edward Lewis wrote a message of 46 lines which said: > o What if you go to a signed NAPTR record, get a replacement name > that is unsigned, then a replacement string that goes to a signed > SRV which leads to an unsigned A record? The reasonable thing to do, security-wise, is to decide that the validity of the "DNS session" is the validity of the *worse* iteration. If all the "DNS iterations" yield Secure and one yields Insecure, the whole session is Insecure. If some yield Secure, some Insecure, and one yields Bogus, the net result is Bogus. This will make things more difficult to debug, but, from a security point of view ("the strength of the chain is the strength of the weakest link"), it seems the only thing to do. It will be difficult to implement because a validating resolver cannot know what iterations are in the same session. You'll have to do it in the application. > o What if you to to a web page that has a signed A record but are > then redirected to a web page that has no signed address record? More complicated to handle since it is not purely DNS. Is the HTTP redirection done over TLS? :-) -- to unsubscribe send a message to namedroppers-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 Oct 27 06:17: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 8D9093A6AB6; Mon, 27 Oct 2008 06:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.919 X-Spam-Level: * X-Spam-Status: No, score=1.919 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 DIWjVwwyBk2i; Mon, 27 Oct 2008 06:17:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8B3A73A6855; Mon, 27 Oct 2008 06:17:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KuRrn-000LAt-Su for namedroppers-data@psg.com; Mon, 27 Oct 2008 13:10:43 +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 1KuRrb-000L9T-UL for namedroppers@ops.ietf.org; Mon, 27 Oct 2008 13:10:39 +0000 Received: from [192.168.1.103] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m9RDAK5q014199; Mon, 27 Oct 2008 09:10:21 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20081027080300.GA22504@laperouse.bortzmeyer.org> References: <48F3B11B.8090202@links.org> <49005921.2090108@links.org> <20081027080300.GA22504@laperouse.bortzmeyer.org> Date: Mon, 27 Oct 2008 09:10:04 -0400 To: Stephane Bortzmeyer From: Edward Lewis Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME Cc: Edward Lewis , namedroppers@ops.ietf.org 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: At 12:03 +0400 10/27/08, Stephane Bortzmeyer wrote: >[Warning, most of the ideas here come from my colleeague Mohsen >Souissi but he is too busy to write now.] He provides a good "straight man" [http://en.wikipedia.org/wiki/Comic_foil]... >The reasonable thing to do, security-wise, is to decide that the >validity of the "DNS session" is the validity of the *worse* >iteration. If all the "DNS iterations" yield Secure and one yields >Insecure, the whole session is Insecure. If some yield Secure, some >Insecure, and one yields Bogus, the net result is Bogus. That's valid - but remember that DNSSEC does not protect the DNS session, just the passing of data through the system of servers. Consider the query for "T_ANY" towards any authoritative server's apex (of any zone hosted). The return includes SOA, NS, and maybe other record sets. DNSSEC can be used to set-wise individually validate, but not report a status for the entire answer. (As in, there's just one RCODE field, no way to say "this is good, that bad, that good.) We were frustrated by that inability when writing the code way back. >More complicated to handle since it is not purely DNS. Is the HTTP >redirection done over TLS? :-) And that's also directly working into the point I was making, the security of the session is dependent on all sorts of things, in this case external to DNSSEC. DNSSEC can't (as in lacks the bit fields to) "protect" the chain from what the consuming user types into the browser and where the HTTP protocol ultimately sends the user. Yes, a bit far fetched and out of bounds for a DNS argument. I mentioned this example to show why we really can't go even "half-way" to securing a CNAME/DNAME/query re-direction/write "path" through the DNS, just the data as it is presented. You have to also trust the software correctly implements the protocol, not just sign the data. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 27 10: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 25BA63A6B6C; Mon, 27 Oct 2008 10:03:26 -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 kjfMnA0Mc6wu; Mon, 27 Oct 2008 10:03:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C9F5A3A6AC6; Mon, 27 Oct 2008 10:03:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KuVOi-000JrR-EW for namedroppers-data@psg.com; Mon, 27 Oct 2008 16:56:56 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KuVOY-000JqI-3F for namedroppers@ops.ietf.org; Mon, 27 Oct 2008 16:56:49 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:To:Subject:MIME-Version:X-Mailer: Message-ID:From:Date:X-MIMETrack:Content-Type; b=fqg7WTdhXsOUW5JwBlUv2HQPhBdqecKdF3rFQXq1chNmSHShxBOny3ha CUJ3awPGyf7vQiQtcS41jTHOof5GbDZV0xsbna540naSEo9vsPTKfbR/j lWBCjqcDdERbAGo; 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=1225126606; x=1256662606; 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:=20draft-belli s-dnsext-dnsproxy-00|Date:=20Mon,=2027=20Oct=202008=2016: 56:46=20+0000|Message-ID:=20|To:=20named roppers@ops.ietf.org|MIME-Version:=201.0; bh=T9zBZwaHgoh4yaHpHYeyyrelzdKDoWIYEhxYM2stLpI=; b=MdLWsmX13bnDVyGzsVO3c5xCU6FiE2QVYpvk1XuG9ONyzG+1T/1oJidJ uhFH5zUBvE7sNhUuGHYJvO5T9I6vAWsDxPu65EnPf/VWPQPeub1dI71B7 IA/oXgmsKkIIFOh; X-IronPort-AV: E=Sophos;i="4.33,493,1220223600"; d="scan'208";a="6544668" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 27 Oct 2008 16:56:44 +0000 To: namedroppers@ops.ietf.org Subject: [dnsext] draft-bellis-dnsext-dnsproxy-00 MIME-Version: 1.0 X-Mailer: Lotus Notes Build V85_M2_08202008 August 20, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Mon, 27 Oct 2008 16:56:46 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 27/10/2008 04:56:44 PM, Serialize complete at 27/10/2008 04:56:44 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I've just submitted: http://tools.ietf.org/html/draft-bellis-dnsext-dnsproxy-00 "This document provides guidelines for the implementation of DNS proxies, as found in broadband routers and other similar network devices." The draft is based on the various incompatibilities found whilst working on SAC035 earlier this year. 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 Mon Oct 27 11:09: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 18A743A6BC3; Mon, 27 Oct 2008 11:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.712 X-Spam-Level: X-Spam-Status: No, score=0.712 tagged_above=-999 required=5 tests=[AWL=1.207, 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 hG1NZ5AdIMDK; Mon, 27 Oct 2008 11:09:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 30A2A3A6B33; Mon, 27 Oct 2008 11:09:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KuWR5-0001Dp-HJ for namedroppers-data@psg.com; Mon, 27 Oct 2008 18:03:27 +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 1KuWQx-0001Cx-8W for namedroppers@ops.ietf.org; Mon, 27 Oct 2008 18:03:23 +0000 Received: from [10.31.200.180] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m9RI3FtU017265; Mon, 27 Oct 2008 14:03:15 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20081024211006.GI7013@commandprompt.com> References: <20081024211006.GI7013@commandprompt.com> Date: Mon, 27 Oct 2008 14:03:13 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: [dnsext] Agenda items for Minneapolis, IETF-73 Cc: ed.lewis@neustar.biz 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: I've been debating on requesting a slot for AXFR clarify. But right now it's not likely to be asked for. There was a lot of conversation over AXFR Clarify last meeting but in my one lame attempt at starting a follow up thread I got no where. I had planned to get back to the document when I had a stretch of time in the office, but I haven't even had time to answer Alfred's comments sent to me a few weeks or months ago. As probably a few others have experienced, the "new" DNS vulnerability (colloquially attributed to Dan Kaminsky) has kept me occupied and away from my desk since the the last IETF meeting. I don't intend to ask for a slot unless there's a sudden demand for it. OTOH, conversations about AXFR clarify can be held during the IETF week. At 17:10 -0400 10/24/08, Andrew Sullivan wrote: >Dear colleagues, > >The draft WG agenda deadline is swiftly approaching. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Oct 29 14: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 F16DD28C3F4; Wed, 29 Oct 2008 14:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.095 X-Spam-Level: X-Spam-Status: No, score=-0.095 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, 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 WKIRYXLLy3K3; Wed, 29 Oct 2008 14:20:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8C08628C15C; Wed, 29 Oct 2008 14:20:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvIL4-0007Bk-NJ for namedroppers-data@psg.com; Wed, 29 Oct 2008 21:12:26 +0000 Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvIKw-0007Ak-Qy for namedroppers@ops.ietf.org; Wed, 29 Oct 2008 21:12:22 +0000 Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.18015734; Wed, 29 Oct 2008 16:11:56 -0500 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Oct 2008 17:11:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [dnsext] RE: [DNSOP] (Off-Topic) DNSSEC Technical Testing Date: Wed, 29 Oct 2008 17:11:32 -0400 Message-ID: In-Reply-To: <45AEC6EF95942140888406588E1A660205B9E31F@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DNSOP] (Off-Topic) DNSSEC Technical Testing Thread-Index: Ackkt/vrXZ9GtSzhRd2qtxpvnx+UEAVUppqw References: <45AEC6EF95942140888406588E1A660205B9E31F@PACDCEXCMB04.cable.comcast.com> From: "Griffiths, Chris" To: , X-OriginalArrivalTime: 29 Oct 2008 21:11:54.0103 (UTC) FILETIME=[F7F74070:01C93A0A] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: We have enabled an additional DNSSEC enabled resolver on our production network which the community is free to test against. =20 The IP address is 68.87.68.170 and further information can be found at www.dnssec.comcast.net. Thanks Chris Griffiths Comcast Cable Communications, Inc. >-----Original Message----- >From: dnsop-bounces@ietf.org [mailto:dnsop-bounces@ietf.org] On Behalf >Of Livingood, Jason >Sent: Thursday, October 02, 2008 1:55 PM >To: dnsop@ietf.org; namedroppers@ops.ietf.org >Subject: [DNSOP] (Off-Topic) DNSSEC Technical Testing > >Yesterday, we attended a DNSSEC policy meeting in Washington, where we >announced that we've started a DNSSEC technical trial at Comcast. We >tend to be rather hands-on learners, so we implemented a DNSSEC-capable >resolver in our production network. Anyone on the public Internet is >welcome to point to our server and test against it. Please contact us >if you'd like error logs (should you have problems), would like keys >added, or have other questions. > >The IP is 68.87.64.154, and trial info is available at info at >http://www.dnssec.comcast.net. We plan to test Unbound, BIND, and >Nominum resolvers, and will share test results (before & after >activation/use of DNSSEC). We also plan to document what we experience >and issues we face, for the benefit of others in the community. > >Regards, >Jason > >Jason Livingood >National Engineering & Technical Operations >Comcast Cable Communications >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop -- to unsubscribe send a message to namedroppers-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 Oct 30 07:26: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 E92023A68B8; Thu, 30 Oct 2008 07:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=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 33jDKcMO7REM; Thu, 30 Oct 2008 07:26:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1459C3A688B; Thu, 30 Oct 2008 07:26:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvYLd-0004d7-Qp for namedroppers-data@psg.com; Thu, 30 Oct 2008 14:18:05 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvYLS-0004cG-7t for namedroppers@ops.ietf.org; Thu, 30 Oct 2008 14:18:02 +0000 Received: from [172.16.33.129] (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 0FA652FE9946 for ; Thu, 30 Oct 2008 14:17:53 +0000 (UTC) Message-Id: From: Andrew Sullivan To: namedroppers@ops.ietf.org In-Reply-To: <20081024211006.GI7013@commandprompt.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [dnsext] Agenda items for Minneapolis, IETF-73 Date: Thu, 30 Oct 2008 10:17:52 -0400 References: <20081024211006.GI7013@commandprompt.com> X-Mailer: Apple Mail (2.929.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, On 24-Oct-08, at 5:10 PM, Andrew Sullivan wrote: > If you have other items that you wish to have addressed during the > meeting, please send them to me. Apart from Ed's post that he _won't_ request a slot, I have so far not heard much on this front. If you have items you want on the agenda, please ask soon. Best regards, 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 Thu Oct 30 08:51: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 A757E3A6829; Thu, 30 Oct 2008 08:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.108 X-Spam-Level: X-Spam-Status: No, score=0.108 tagged_above=-999 required=5 tests=[AWL=0.603, 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 FcwQl0dFoBjt; Thu, 30 Oct 2008 08:51:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8D6983A6878; Thu, 30 Oct 2008 08:51:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvZcX-000BI0-Nl for namedroppers-data@psg.com; Thu, 30 Oct 2008 15:39:37 +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 1KvZcL-000BGr-Fe for namedroppers@ops.ietf.org; Thu, 30 Oct 2008 15:39:31 +0000 Received: from [0.0.0.0] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m9UFdMVp057813; Thu, 30 Oct 2008 11:39:22 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20081024211006.GI7013@commandprompt.com> Date: Thu, 30 Oct 2008 11:39:18 -0400 To: Andrew Sullivan From: Edward Lewis Subject: Re: [dnsext] Agenda items for Minneapolis, IETF-73 Cc: namedroppers@ops.ietf.org 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: At 10:17 -0400 10/30/08, Andrew Sullivan wrote: >Apart from Ed's post that he _won't_ request a slot, I have so far not heard >much on this front. If you have items you want on the agenda, >please ask soon. If that's the case, then I'll request a slot equaling the length of the meeting and plan to pack my karaoke machine for the meeting. Heh-heh, if that don't stoke some agenda time requests, maybe I'll threaten to talk about glass water bottles. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Fri Oct 31 10:06: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 C63053A682F; Fri, 31 Oct 2008 10:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.25 X-Spam-Level: **** X-Spam-Status: No, score=4.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 QHMHFumvPzoG; Fri, 31 Oct 2008 10:06:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 79E393A68FA; Fri, 31 Oct 2008 10:06:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvxKB-000KBZ-EF for namedroppers-data@psg.com; Fri, 31 Oct 2008 16:58:15 +0000 Received: from [213.178.172.147] (helo=WOTAN.TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KvxJy-000K9M-UM for namedroppers@ops.ietf.org; Fri, 31 Oct 2008 16:58:08 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA067352176; Fri, 31 Oct 2008 17:56:16 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id RAA19635; Fri, 31 Oct 2008 17:56:15 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200810311656.RAA19635@TR-Sys.de> Subject: [dnsext] draft-ietf-dnsext-dnssec-rsasha256-06 nits To: jelte@NLnetLabs.nl Date: Fri, 31 Oct 2008 17:56:14 +0100 (MEZ) Cc: namedroppers@ops.ietf.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Hello again, I closely re-visited the latest revision of the DNSSEC SHA-2 draft. Indeed, technically [ and politically :-) ] now all seems to be in a rather good shape. However, I have a few small nits that might be worth addressing before publication as an RFC, perhaps during AUTH48: (1) Section 2 I suggest to replace the comma by a semicolon, because this punctuation separates two almost independent full sentences. (2) Sections 2.1 and 2.2 For consistency in style, please s/RFC5155/RFC 5155/ in the prose of the second paragraph each. Also, I suggest to remove the redundant and unpleasant repetitions of "*key* [size]" in the last paragraph each. For 2.1: vvvvv | For interoperability, as in RFC 3110 [RFC3110], the key size of RSA/ SHA-256 keys MUST NOT be less than 512 bits, and MUST NOT be more than 4096 bits. --- v | For interoperability, as in RFC 3110 [RFC3110], the size of RSA/ SHA-256 keys MUST NOT be less than 512 bits, and MUST NOT be more than 4096 bits. For 2.2: vvvvv | The key size of RSA/SHA-512 keys MUST NOT be less than 1024 bits, and MUST NOT be more than 4096 bits. --- v | The size of RSA/SHA-512 keys MUST NOT be less than 1024 bits, and MUST NOT be more than 4096 bits. (3) Section 3 (3a) For enhanced readability, I suggest to indent the two formulae one step more than the prose. (3b) For ultimate precision and unambiguity, I suggest to add the words "in octets" after "length" in the last line of the penultimate paragraph -- cryptographers are used to think and talk in bit sizes -- see the discussion about RSA keys in the draft as well! (Otherwise, the text now is o.k. there.) key. The FF octet MUST be repeated the exact number of times so that the total length of the concatenated term in parentheses equals the | length of the modulus of the signer's public key ("n"). --- ^ key. The FF octet MUST be repeated the exact number of times so that the total length of the concatenated term in parentheses equals the | length (in octets) of the modulus of the signer's public key ("n"). ^^^^^^^^^^^^^ (3c) In the last paragraph, the second sentence could be simplified, in order to enhance the readability and to emphasize that the same document is referenced for the two algorithms, without repeating the full denomination of the document. Furthermore, the double "specifications" in the same sentence is unpleasant; how about replacing the first instance by "rules" ? Incorporating both proposals, the following change would result: The "prefix" is intended to make the use of standard cryptographic libraries easier. These specifications are taken directly from the | specifications of RSASSA-PKCS1-v1_5 in PKCS #1 v2.1 section 8.2 | [RFC3447], and EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 section 9.2 | [RFC3447]. The prefixes for the different algorithms are specified below. --- The "prefix" is intended to make the use of standard cryptographic | libraries easier. These rules are taken directly from the | specifications of RSASSA-PKCS1-v1_5 in section 8.2, and the | EMSA-PKCS1-v1_5 encoding in section 9.2 of PKCS #1 v2.1 [RFC3447]. The prefixes for the different algorithms are specified below. (4) Sections 3.1 and 3.2 (4a) In the second paragraph each, the replicated "prefix" is not only unpleasant, but arguably even wrong; what is called the "algorithm designator prefix" in fact is the *entire* "algorithm identifier". I admit "designator" as a stylistic variant, but I recommend to drop the second "prefix": For 3.1: vvvvvvvv | The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as specified in PKCS #1 v2.1 [RFC3447]: --- v | The prefix is the ASN.1 BER SHA-256 algorithm designator as specified in PKCS #1 v2.1 [RFC3447]: For 3.2: vvvvvvvv | The prefix is the ASN.1 BER SHA-512 algorithm designator prefix as specified in PKCS #1 v2.1 [RFC3447]: --- v | The prefix is the ASN.1 BER SHA-512 algorithm designator as specified in PKCS #1 v2.1 [RFC3447]: (4b) For enhanced readability, I also suggest to indent the trailing lines with the hex representation one step more than the prose. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: