From owner-namedroppers@ops.ietf.org Thu Nov 01 05:57:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InWnN-0000g9-0c; Thu, 01 Nov 2007 05:57:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InWnC-0001CT-Qk; Thu, 01 Nov 2007 05:56:56 -0400 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1InWbw-00015z-Bq for namedroppers-data@psg.com; Thu, 01 Nov 2007 09:45:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.154.224.48] (helo=bert.secret-wg.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1InWbN-00012J-Gt for namedroppers@ops.ietf.org; Thu, 01 Nov 2007 09:44:54 +0000 Received: from Miffy.lan (a62-251-91-215.adsl.xs4all.nl [62.251.91.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bert.secret-wg.org (Postfix) with ESMTPSA id C90E6B831; Thu, 1 Nov 2007 10:44:35 +0100 (CET) Cc: ogud@ogud.com, namedroppers@ops.ietf.org Message-Id: <58BB7797-E78F-4A5B-92B2-09DF69ED05E6@NLnetLabs.nl> From: "Olaf M. Kolkman" To: Samuel Weiler 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 v912) Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) Date: Thu, 1 Nov 2007 10:44:36 +0100 References: X-Mailer: Apple Mail (2.912) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 > > Would the chair still like for us to select a new and better name, > now that we seem to have something that's (almost?) stable? Ohhh.. please tell me you are joking... so we (the working group) have not followed the initial plan since 06, what would be the reason to do so now, the huge experimental install base of NSEC3 code? --Olaf (namedropper) ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ -- to unsubscribe send a message to namedroppers-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 Nov 01 06:39:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InXSK-0002QL-Jw; Thu, 01 Nov 2007 06:39:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InXSJ-0002zW-At; Thu, 01 Nov 2007 06:39:20 -0400 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1InXNO-0003wA-9g for namedroppers-data@psg.com; Thu, 01 Nov 2007 10:34:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [213.154.224.48] (helo=bert.secret-wg.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1InXMr-0003uJ-8H for namedroppers@ops.ietf.org; Thu, 01 Nov 2007 10:33:57 +0000 Received: from Miffy.lan (a62-251-91-215.adsl.xs4all.nl [62.251.91.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bert.secret-wg.org (Postfix) with ESMTPSA id 4DFDAB864; Thu, 1 Nov 2007 11:33:39 +0100 (CET) Cc: Samuel Weiler , namedroppers@ops.ietf.org, Message-Id: From: "Olaf M. Kolkman" 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 v912) Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) Date: Thu, 1 Nov 2007 11:32:39 +0100 References: X-Mailer: Apple Mail (2.912) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 On 26Oct 2007, at 8:46 PM, Dean Anderson wrote: > So you didn't find anything saying that RFC3833 was to be ignored? > > In that case, I assert that RFC3833 states the policy of the IETF, and > that this draft is out of scope. > > > Making DNS records 'private' is not in the public interest. This is > just a scheme backed by registry operators to enhance sales, and does > not enhance privacy. > > I note that a registry person responded to my previous message, but > declined to include any proof that the draft's introductory purposes > were indeed true. (...) > > If one spends time on technical tasks that are > contrary to policy, the effort is wasted. And that's what I think has > happened in this case. > > > I think the technical issues can be solved. However, obtaining the > solution is a waste of time because this effort is contrary to IETF > policy and contrary to public interest. > Dear Dean, In my interpretation RFC3833 is an informational document posting the requirements to which _DNSSECbis_ was developed. I'm not sure if a debate on the correctness of my interpretation is going to be fruitful ;-). So, what follows is a bit of documented history on why and how the working group took up this work. The point I am trying to make is that the decision to take up this work was not made without appropriate discussion on the policy and the various trade-offs. When DNSSECbis was being (or about to be) last called several registries stepped up and argued that they could not deploy DNSSECbis given the ease of zone enumeration. One example of such argument is in http://www.ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00685.html . It was not the only argument, if you look at the various postings during that time you will notice that the discussion was 'involved' and covered all sides of the argument. After the WG was satisfied that the zone enumeration could be solved by (backwards compatible) extension of DNSSECbis, and that the zone enumeration could be solved independently from DNSSECbis, the document- set that we now now as rfc4033-35 was shipped was shipped. (see e.g http://www.ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00824.html) . Finally the working group was asked if they wanted to take up the work: http://www.ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01981.html After discussion in the face to face meeting (http://www.ops.ietf.org/lists/namedroppers/namedroppers.2004/msg02149.html ) the item was included in a new charter: http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00366.html . Kind regards, --Olaf Kolkman ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ -- to unsubscribe send a message to namedroppers-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 Nov 01 10:57:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InbUb-00059D-RT; Thu, 01 Nov 2007 10:57:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InbUQ-0004Rb-Kg; Thu, 01 Nov 2007 10:57:52 -0400 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1InbLZ-000LKs-RI for namedroppers-data@psg.com; Thu, 01 Nov 2007 14:48:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1InbL0-000LHk-0m for namedroppers@ops.ietf.org; Thu, 01 Nov 2007 14:48:17 +0000 Received: from mirre.nlnetlabs.nl (mirre.nlnetlabs.nl [IPv6:2001:7b8:206:1:219:d1ff:fe0b:89f4]) by open.nlnetlabs.nl (8.14.1/8.14.1) with ESMTP id lA1ElZHE060763; Thu, 1 Nov 2007 15:47:37 +0100 (CET) (envelope-from jelte@NLnetLabs.nl) Message-ID: <4729E707.1050008@NLnetLabs.nl> Date: Thu, 01 Nov 2007 15:47:35 +0100 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.6 (X11/20070910) MIME-Version: 1.0 To: Michael StJohns CC: namedroppers@ops.ietf.org Subject: Re: Fwd: Re: RSA/SHA256 References: In-Reply-To: X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 01 Nov 2007 15:47:55 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael StJohns wrote: >>> Doesn't it actually make this worse if you split them? We'd either have >>> to make it mandatory to support every combination that is possible, >>> which I think can't be done, since it still seems hard to predict the >>> future, or we'd have to require every combination that is allowed to >>> have its own specification somewhere in a published document. I don't >>> really see the difference in the location of the actual bits within the >>> algorithm field in that case. >> >> Read this again. We're currently using the same *registry* to indicate both key type and signature algorithms. >> >> Split the "key type" *registry* from the "Signature type" *registry*. >> >> The former applies to the DNSKEY record. The latter applies to the RRSIG record and never the twain shall meet. >> Ah, like that, ok, so no problem for the every-or-selected then. Still I don't really see the benefit when we go back so sending packets. Wouldn't you still need to specify it in the DNSKEY record too (if only to get it into the DS RR, so that a validator knows whether it should be able to verify it)? Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHKecH4nZCKsdOncURAvUeAKC1++u8JyI6Lpj2UWK+OF/nIL9sXQCfROET B6Z01FHkqBdEI5GdrWktuY0= =o/TR -----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 Nov 01 11:09:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InbfP-0003oL-0n; Thu, 01 Nov 2007 11:09:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InbfN-0004rM-OI; Thu, 01 Nov 2007 11:09:07 -0400 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Inbaq-000Mjm-BJ for namedroppers-data@psg.com; Thu, 01 Nov 2007 15:04:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1InbaK-000Mhe-LW for namedroppers@ops.ietf.org; Thu, 01 Nov 2007 15:04:08 +0000 Received: from mirre.nlnetlabs.nl (mirre.nlnetlabs.nl [IPv6:2001:7b8:206:1:219:d1ff:fe0b:89f4]) by open.nlnetlabs.nl (8.14.1/8.14.1) with ESMTP id lA1F3hpP062121; Thu, 1 Nov 2007 16:03:46 +0100 (CET) (envelope-from jelte@NLnetLabs.nl) Message-ID: <4729EACF.8020507@NLnetLabs.nl> Date: Thu, 01 Nov 2007 16:03:43 +0100 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.6 (X11/20070910) MIME-Version: 1.0 To: Doug Barton CC: namedroppers@ops.ietf.org Subject: Re: RSA/SHA256 References: <471FB97B.9000108@NLnetLabs.nl> <200710252358.l9PNwtUa057489@open.nlnetlabs.nl> <47213A4C.3020106@NLnetLabs.nl> In-Reply-To: X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 01 Nov 2007 16:03:46 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Doug Barton wrote: > You guys seem to think that you're making an argument FOR including > additional hashes, but in my mind you're actually making a case not to > do it. > actually, i'm trying to see whether there is a way to add algorithms without adding complexity (other than the knob for the algorithm in the signers and verifiers). Whether or not we do them now, there seems to be this thing about algorithm agility lately :) >> >> Another reason to do it once is to get it over with in terms of >> standardization; do we want to repeat this discussion for every hash >> algorithm that is not completely new? Why go through this process again >> when some organizations decide that SHA-256 isn't good enough for them >> and they require 512, when this could have been handled now? It's mostly >> the same argument, but from a protocol perspective. > > I don't see how adding a lot of hashes now makes adding a new one later > any easier. (Other than perhaps the fact that implementors will get lots > of practice writing code for new hashes.) > I wasn't talking about digest algorithms that are yet to be invented. But if it is for instance foreseen that 512 will be needed later (as well as 256), it's easier to add them both once than to go through the I-D and deployment process twice. In this case the hashes don't differ too much, which is why the can be grouped together. > Seriously guys, if there is an overwhelmingly good reason to add all the > intermediate hashes, please elaborate because I don't see it. "Because > we can" is NOT a good reason. > Well i could live with 'only' 256 and 512. Or even either one of those, but i can imagine the use of both. And can probably be convinced of more :) > > You have to resist the temptation to keep tinkering with this thing. If > you don't think SHA256 is strong enough to last through the early > implementation cycle while we figure out solutions to problems like > algorithm rollover, then pick ONE that will be (SHA512?, more?) and then > let's move on. > Referring to the algorithm agility thing again, i think that if we keep postponing the problem with every added algorithm (if there even *is* a problem) we'd just make it harder to find a solution. For instance, if people invent something brightly magical to use the algorithm field, one would have to work around the numbers already assigned. Not that i think that something like that is necessary, or even preferable. But that's what i'm trying to find out here. > Ok, rant over. I think I've said pretty clearly what my position is, so > I'll let others voice theirs. > They seem to be a bit apathetic about it :) Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHKerP4nZCKsdOncURAoUDAKC0kyCILJY8fGSL9kiCOnV/3CkbnwCfQEGy nVgShiV1Z3ek1YoJFwdlpxY= =NSkm -----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 Nov 01 11:57:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IncPw-0006fj-G3; Thu, 01 Nov 2007 11:57:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IncPv-000749-9U; Thu, 01 Nov 2007 11:57:12 -0400 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IncKB-0000yN-QY for namedroppers-data@psg.com; Thu, 01 Nov 2007 15:51:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,MISSING_MID, RDNS_NONE autolearn=no version=3.2.3 Received: from [63.240.77.83] (helo=sccrmhc13.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IncJx-0000x4-F2 for namedroppers@ops.ietf.org; Thu, 01 Nov 2007 15:51:08 +0000 Received: from mikespersonal.comcast.net (c-68-48-56-3.hsd1.md.comcast.net[68.48.56.3]) by comcast.net (sccrmhc13) with SMTP id <2007110115510001300amt7be>; Thu, 1 Nov 2007 15:51:00 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 01 Nov 2007 11:51:04 -0400 To: Jelte Jansen From: Michael StJohns Subject: Re: Fwd: Re: RSA/SHA256 Cc: namedroppers@ops.ietf.org In-Reply-To: <4729E707.1050008@NLnetLabs.nl> References: <4729E707.1050008@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Message-Id: X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 At 10:47 11/1/2007, Jelte Jansen wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Michael StJohns wrote: > >>>> Doesn't it actually make this worse if you split them? We'd either have >>>> to make it mandatory to support every combination that is possible, >>>> which I think can't be done, since it still seems hard to predict the >>>> future, or we'd have to require every combination that is allowed to >>>> have its own specification somewhere in a published document. I don't >>>> really see the difference in the location of the actual bits within the >>>> algorithm field in that case. >>> >>> Read this again. We're currently using the same *registry* to indicate both key type and signature algorithms. >>> >>> Split the "key type" *registry* from the "Signature type" *registry*. >>> >>> The former applies to the DNSKEY record. The latter applies to the RRSIG record and never the twain shall meet. >>> > >Ah, like that, ok, so no problem for the every-or-selected then. > >Still I don't really see the benefit when we go back so sending packets. > >Wouldn't you still need to specify it in the DNSKEY record too (if only >to get it into the DS RR, so that a validator knows whether it should be >able to verify it)? > >Jelte The DNSKEY record algorithm type field specifies a type of key - its mis-named. An RSA key can be used with any signature algorithm that's RSA based - e.g. RSA/MD5, RSA/SHA1, RSA/SHA256. If you continue to use the same registry for both DNSKEY and RRSIG algorithm fields, you run into the problem of which algorithm type to use in the DNSKEY record. For example - current implementations generally understand RSA/MD5 and RSA/SHA1. Let's say you're running (on the server side) a new implementation which also understands RSA/SHA256. You make the legal, but probably bad choice to tag all of your keys as RSA/SHA256 (and the reason you did that was that guidance suggested that RSA/SHA1 was deprecated), but for compatibility with old implementations you do a signature as RSA/SHA1 The old implementations will probably choke on this, even though its a legitimate combination because they don't understand that RSA/SHA256 in a DNSKEY really is the same key type as RSA/SHA1 or RSA/MD5. Far better if the key type just said "RSA" and left it at that. It was a bad design choice to conflate these registries in the first place. Let's fix them in this go around. -- to unsubscribe send a message to namedroppers-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 Nov 01 18:12:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IniGy-0003jc-2K; Thu, 01 Nov 2007 18:12:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IniGw-0004oD-2t; Thu, 01 Nov 2007 18:12:20 -0400 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ini8e-0001F0-62 for namedroppers-data@psg.com; Thu, 01 Nov 2007 22:03:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ini8T-0001Dh-D7 for namedroppers@ops.ietf.org; Thu, 01 Nov 2007 22:03:38 +0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id lA1M3GJt011154; Thu, 1 Nov 2007 17:03:16 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id lA1M3F4J032618; Thu, 1 Nov 2007 17:03:16 -0500 Received: from localhost ([157.185.80.253]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Nov 2007 18:03:15 -0400 Date: Thu, 1 Nov 2007 18:03:14 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@mint.samweiler.com To: Jelte Jansen cc: namedroppers@ops.ietf.org Subject: Re: RSA/SHA256 In-Reply-To: <471FB97B.9000108@NLnetLabs.nl> Message-ID: References: <471FB97B.9000108@NLnetLabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 01 Nov 2007 22:03:15.0553 (UTC) FILETIME=[00B3F510:01C81CD3] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Thu, 01 Nov 2007 17:03:16 -0500 (CDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f On Wed, 24 Oct 2007, Jelte Jansen wrote: > 1) Should this document be written? Probably. See answer to #2. > 2) Should this document specify other hash algorithms as well? In the interest of keeping the complexity to build new resolvers down somewhat, I think we should limit ourselves to only what we think we need. At any time, I would expect that to be no more than "one hash algorithm we believe is strong enough" and "one or two more, in case we're wrong". I haven't formed an opinion about exactly which ones we need right now, but if we're defining more than two, we're going down the wrong path. Do we need something stronger than SHA1? Probably. Do we need the whole SHA2 suite? No. In the absence of a clear sense of what to add beyond SHA256, let's stop at SHA256. > 3) If so, how will we handle the different algorithm/hash types? I think we should NOT split the field, and I think it's actively dangerous to split the registries, as MSJ suggests. (Visions of downgrade attacks are swimming through my head.) > 4) What should the actual status be of the new combinations? Mandatory. We know that doesn't mean they'll actually be implemented, but there's little point in doing something else. (If we don't think we need it, why specify it?) -- Sam -- to unsubscribe send a message to namedroppers-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 Nov 01 19:50:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Injnr-0005Zb-HI; Thu, 01 Nov 2007 19:50:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Injng-0007zP-BD; Thu, 01 Nov 2007 19:50:18 -0400 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1InjhC-0006pu-K4 for namedroppers-data@psg.com; Thu, 01 Nov 2007 23:43:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,MISSING_MID, RDNS_NONE autolearn=no version=3.2.3 Received: from [204.127.192.83] (helo=rwcrmhc13.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Injgd-0006oh-2F for namedroppers@ops.ietf.org; Thu, 01 Nov 2007 23:43:14 +0000 Received: from mikespersonal.comcast.net (c-68-48-56-3.hsd1.md.comcast.net[68.48.56.3]) by comcast.net (rwcrmhc13) with SMTP id <20071101234250m1300dhi4qe>; Thu, 1 Nov 2007 23:42:54 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 01 Nov 2007 19:42:53 -0400 To: Sam Weiler ,Jelte Jansen From: Michael StJohns Subject: Re: RSA/SHA256 Cc: namedroppers@ops.ietf.org In-Reply-To: References: <471FB97B.9000108@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Message-Id: X-Spam-Score: -4.0 (----) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca At 18:03 11/1/2007, Sam Weiler wrote: >On Wed, 24 Oct 2007, Jelte Jansen wrote: > >>1) Should this document be written? > >Probably. See answer to #2. > >>2) Should this document specify other hash algorithms as well? > >In the interest of keeping the complexity to build new resolvers down somewhat, I think we should limit ourselves to only what we think we need. At any time, I would expect that to be no more than "one hash algorithm we believe is strong enough" and "one or two more, in case we're wrong". I haven't formed an opinion about exactly which ones we need right now, but if we're defining more than two, we're going down the wrong path. Do we need something stronger than SHA1? Probably. Do we need the whole SHA2 suite? No. In the absence of a clear sense of what to add beyond SHA256, let's stop at SHA256. We've specified RSA as a valid key type for digital signatures. RFC3110 specifies a possible range of strengths for RSA in DNSSEC signatures from 512 to 4096 bits. NIST (and other cryptographers) have made some strong suggestions about what hashes should match up with which signature lengths - see the tables (2, 3 and 4) in the NIST 800-57 publication. That table suggests the appropriate match for RSA 2048 bit signatures is SHA224, and for 4096 - SHA384 or greater (SHA256 provides about 128 bits of strength, SHA384 provides 192 bits - RSA 4096 is somewhere between 128 and 192 bits of strength). Its not about adding SHA256 - its about adding hashes appropriate to cover the range of strengths of the signature methods that have already been approved. >>3) If so, how will we handle the different algorithm/hash types? > >I think we should NOT split the field, and I think it's actively dangerous to split the registries, as MSJ suggests. (Visions of downgrade attacks are swimming through my head.) I'm OK with not splitting the field, but your vision must be from mushrooms. So what you're saying is the CMS guys got it wrong? I find that hard to believe. Take a look at a digital certificate for example. The public key has an OID that identifies it as RSA, DSA or EC (and may provide some additional parameters such as the EC curve). The SIGNATURE has an oid that identifies it as SHA1withRSA for example. How the heck would doing this trigger this boogey man of a "downgrade attack"? Details please - and no visions. >>4) What should the actual status be of the new combinations? > >Mandatory. We know that doesn't mean they'll actually be implemented, but there's little point in doing something else. (If we don't think we need it, why specify it?) > >-- Sam > > >-- >to 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 Nov 02 02:02:33 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inpc1-0003vS-BC; Fri, 02 Nov 2007 02:02:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Inpbv-0001Mb-2K; Fri, 02 Nov 2007 02:02:28 -0400 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1InpTI-000PmH-0s for namedroppers-data@psg.com; Fri, 02 Nov 2007 05:53:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1InpT7-000Plt-0y for namedroppers@ops.ietf.org; Fri, 02 Nov 2007 05:53:26 +0000 X-IronPort-AV: E=Sophos;i="4.21,361,1188774000"; d="scan'208";a="12228698" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 02 Nov 2007 05:53:18 +0000 In-Reply-To: To: Michael StJohns Cc: Jelte Jansen , namedroppers@ops.ietf.org, Sam Weiler Subject: Re: RSA/SHA256 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: roy@nominet.org.uk Date: Thu, 1 Nov 2007 21:53:16 -0800 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 02/11/2007 05:53:17 AM, Serialize complete at 02/11/2007 05:53:17 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Michael StJohns wrote on 11/01/2007 04:42:53 PM: > At 18:03 11/1/2007, Sam Weiler wrote: > >On Wed, 24 Oct 2007, Jelte Jansen wrote: > > > >>1) Should this document be written? > > > >Probably. See answer to #2. > > > >>2) Should this document specify other hash algorithms as well? > > > >In the interest of keeping the complexity to build new resolvers down > somewhat, I think we should limit ourselves to only what we think we > need. At any time, I would expect that to be no more than "one hash > algorithm we believe is strong enough" and "one or two more, in case > we're wrong". I haven't formed an opinion about exactly which ones we > need right now, but if we're defining more than two, we're going down > the wrong path. Do we need something stronger than SHA1? Probably. > Do we need the whole SHA2 suite? No. In the absence of a clear sense > of what to add beyond SHA256, let's stop at SHA256. FWIW, I completely agree with Sam's rationale. To satisfy Mike's point below, we could, instead of SHA256, settle on SHA512. As long as we don't need to implement the whole suite. If SHA512 is available, why settle for less. > We've specified RSA as a valid key type for digital signatures. > RFC3110 specifies a possible range of strengths for RSA in DNSSEC > signatures from 512 to 4096 bits. NIST (and other cryptographers) > have made some strong suggestions about what hashes should match up > with which signature lengths - see the tables (2, 3 and 4) in the NIST > 800-57 publication. That table suggests the appropriate match for > RSA 2048 bit signatures is SHA224, and for 4096 - SHA384 or greater > (SHA256 provides about 128 bits of strength, SHA384 provides 192 bits > - RSA 4096 is somewhere between 128 and 192 bits of strength). > > Its not about adding SHA256 - its about adding hashes appropriate to > cover the range of strengths of the signature methods that have > already been approved. > > > >>3) If so, how will we handle the different algorithm/hash types? > > > >I think we should NOT split the field, and I think it's actively > dangerous to split the registries, as MSJ suggests. (Visions of > downgrade attacks are swimming through my head.) > > I'm OK with not splitting the field, but your vision must be from mushrooms. > > So what you're saying is the CMS guys got it wrong? I find that hard to believe. I haven't seen that statement. > Take a look at a digital certificate for example. The public key has > an OID that identifies it as RSA, DSA or EC (and may provide some > additional parameters such as the EC curve). The SIGNATURE has an > oid that identifies it as SHA1withRSA for example. > > How the heck would doing this trigger this boogey man of a "downgrade attack"? > > Details please - and no visions. I agree with Sam Weilers' point. I'll give you the details: 1) The digest algorithm needs to be present in the DNSKEY RR. If not, then DNSSEC will be susceptible to a downgrade attack. Consider an RRSIG with a known signature algorithm (say RSA) with an unknown digest. There is no fallback to provable unsecure, since nothing can be proven. The only path left is to label it bogus. This will cause a significant disruption of service that an upgrade to a stronger hash on the server side will be avoided. The concept of provable unsecure (or provable unknown) is not trivial, but an essential part of the architecture of DNSSEC. 2) We're now left with signalling the digest algorithm in the DNSKEY field. There are two possible ways to do this. One is to leave the algorithm field to denote the signing algorithm, i.e. no digest algorithm, and signal the digest algorithm in the public key field. We now have an 8 bits field for the signature algorithm, for which we only have 4 algorithms (DH,DSA,RSA,ECC), and a somewhat odd digest field within the public key field. That doesn't look like a clean design either. The other option is to split the 8 bits signature field in two. Whatever ratio we choose, we now have significantly less space to expand on. Complexity doesn't get easier either, since any combination must be possible, since every allocated digest algorithm needs to work with every allocated signature algorithm. We would also need a new structure for the DS record. That leaves us with the current status quo. That is not a bad option. I would argue it is fairly optimal use of the signature field space. At least it is the lesser of all the alternative evils I mentioned above. > >>4) What should the actual status be of the new combinations? > > > >Mandatory. We know that doesn't mean they'll actually be > implemented, but there's little point in doing something else. (If we > don't think we need it, why specify it?) Agreed. Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Nov 02 03:34:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inr2Z-0007vS-45; Fri, 02 Nov 2007 03:34:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Inr2S-0003iE-Uj; Fri, 02 Nov 2007 03:34:03 -0400 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Inqtl-0004F5-0S for namedroppers-data@psg.com; Fri, 02 Nov 2007 07:24:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Inqta-0004ES-Bd for namedroppers@ops.ietf.org; Fri, 02 Nov 2007 07:24:51 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 840BC11430 for ; Fri, 2 Nov 2007 07:24:45 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: 10 years ago in dnssec (was Re: RSA/SHA256 ) In-Reply-To: Your message of "Thu, 01 Nov 2007 21:53:16 PST." References: X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Date: Fri, 02 Nov 2007 07:24:45 +0000 Message-ID: <1332.1193988285@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 --=-=-= i saw this... > > >>2) Should this document specify other hash algorithms as well? > > > > > >In the interest of keeping the complexity to build new resolvers down > > somewhat, I think we should limit ourselves to only what we think we > > need. At any time, I would expect that to be no more than "one hash > > algorithm we believe is strong enough" and "one or two more, in case > > we're wrong". ... > > ... we could, instead of SHA256, settle on SHA512. As long as we don't > need to implement the whole suite. If SHA512 is available, why settle for > less. ...which reminded me of this: --=-=-= Content-Type: message/rfc822 Content-Disposition: attachment; filename=676 Return-Path: owner-dns-security Delivery-Date: Wed Oct 8 22:21:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA01374 for dns-security-outgoing; Wed, 8 Oct 1997 22:17:37 -0400 (EDT) Message-Id: <199710090225.TAA19658@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "Paul Rarey" , gnu@toad.com cc: "Donald E. Eastlake 3rd" , "Carl Malamud [IMS]" , dns-security@tis.com Subject: Re: Secure DNS Implementation in BIND In-reply-to: <34393C57.4A49D688@Clorox.com> Date: Wed, 08 Oct 1997 19:25:52 -0700 From: John Gilmore Sender: owner-dns-security@ex.tis.com Precedence: bulk > What happens at the end of three years? The RSA patent expires, and you don't need to negotiate with RSA to build a DNS implementation that uses RSA. Until then, RSA has committed to offer perpetual DNSsafe licenses to anyone who wants to implement DNS Security. If you base your DNSSEC work on BIND, you are covered by ISC's license; if you have an independent implementation, you can get your own license from RSA. John --=-=-=-- -- to unsubscribe send a message to namedroppers-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 Nov 02 13:27:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io0IX-00054R-6B; Fri, 02 Nov 2007 13:27:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Io0II-0006KN-4Z; Fri, 02 Nov 2007 13:27:04 -0400 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Io09Q-000JBt-Gd for namedroppers-data@psg.com; Fri, 02 Nov 2007 17:17:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, MISSING_MID,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.62.24] (helo=QMTA02.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Io09C-000JAK-Iw for namedroppers@ops.ietf.org; Fri, 02 Nov 2007 17:17:37 +0000 Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA02.westchester.pa.mail.comcast.net with smtp id 7t2u1Y0090cZkys0000n00; Fri, 02 Nov 2007 17:17:26 +0000 Received: from mikespersonal.comcast.net ([68.48.56.3]) by OMTA10.westchester.pa.mail.comcast.net with comcast id 7tHR1Y00804A3tg0000000; Fri, 02 Nov 2007 17:17:27 +0000 X-Authority-Analysis: v=1.0 c=1 a=gHtpOJo5BpDOoojSzDkA:9 a=Qz5iqEaN67tLmBdb-rQA:7 a=0JaqgUmH2b80M5fJgHYfM5jxZCwA:4 a=h9s5Ru71U4oA:10 a=ZJM67umtWTMTIF2GmJAA:9 a=D7r0rHHPUF0-1O0DE6EA:7 a=wbppX4QSz-sXXKFbp2O-7482qoUA:4 a=37WNUvjkh6kA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 02 Nov 2007 13:15:19 -0400 To: roy@nominet.org.uk From: Michael StJohns Subject: Re: RSA/SHA256 Cc: Jelte Jansen ,namedroppers@ops.ietf.org, Sam Weiler In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_139206515==.ALT" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: efb5d987e2484f3d9a304cc31a003441 --=====================_139206515==.ALT Content-Type: text/plain; charset="us-ascii" At 01:53 11/2/2007, roy@nominet.org.uk wrote: >Michael StJohns wrote on 11/01/2007 04:42:53 PM: > >> At 18:03 11/1/2007, Sam Weiler wrote: >> >On Wed, 24 Oct 2007, Jelte Jansen wrote: >> > >> >>1) Should this document be written? >> > >> >Probably. See answer to #2. >> > >> >>2) Should this document specify other hash algorithms as well? >> > >> >In the interest of keeping the complexity to build new resolvers down >> somewhat, I think we should limit ourselves to only what we think we >> need. At any time, I would expect that to be no more than "one hash >> algorithm we believe is strong enough" and "one or two more, in case >> we're wrong". I haven't formed an opinion about exactly which ones we >> need right now, but if we're defining more than two, we're going down >> the wrong path. Do we need something stronger than SHA1? Probably. >> Do we need the whole SHA2 suite? No. In the absence of a clear sense >> of what to add beyond SHA256, let's stop at SHA256. > >FWIW, I completely agree with Sam's rationale. To satisfy Mike's point >below, we could, instead of SHA256, settle on SHA512. As long as we don't >need to implement the whole suite. If SHA512 is available, why settle for >less. Except that there's a real continuing cost for doing it this way. SHA512 *is* more expensive to calculate than SHA256 - not a lot, but some. That's a cost that carries forward on every signing and every verification. Implementing the whole suite is a cost that happens once, is not all that much more expensive for 4 algorithms as for one, and is spread over all the systems that run that version of the code. [NB: SHA224 and 256 have approximately the same costs per hash as do SHA384 and SHA512] The complexity argument doesn't hold water - it's a lookup table that selects three elements - the hash, the signature mechanism and for some (for all of the RSA signatures) the padding. Implementation wise, the calling sequence for each element is mostly identical within those elements (e.g. same signature calls, same hash calls, same padding calls). >> We've specified RSA as a valid key type for digital signatures. >> RFC3110 specifies a possible range of strengths for RSA in DNSSEC >> signatures from 512 to 4096 bits. NIST (and other cryptographers) >> have made some strong suggestions about what hashes should match up >> with which signature lengths - see the tables (2, 3 and 4) in the NIST >> 800-57 publication. That table suggests the appropriate match for >> RSA 2048 bit signatures is SHA224, and for 4096 - SHA384 or greater >> (SHA256 provides about 128 bits of strength, SHA384 provides 192 bits >> - RSA 4096 is somewhere between 128 and 192 bits of strength). >> >> Its not about adding SHA256 - its about adding hashes appropriate to >> cover the range of strengths of the signature methods that have >> already been approved. >> >> >> >>3) If so, how will we handle the different algorithm/hash types? >> > >> >I think we should NOT split the field, and I think it's actively >> dangerous to split the registries, as MSJ suggests. (Visions of >> downgrade attacks are swimming through my head.) >> >> I'm OK with not splitting the field, but your vision must be from >mushrooms. >> >> So what you're saying is the CMS guys got it wrong? I find that hard to >believe. > >I haven't seen that statement. CMS - Cryptographic Message Syntax - all of the PKIX guys. Not a statement per se, but a method of doing cryptographic operations. The key type is distinct from all of the possible signature types it can be used to form. E.g. an RSA key (OID 1.2.840.113549.1.1.1) used in the SubjectPublicKeyInfo field of a certificate is different than the signature algorithm type SHA1withRSA (OID 1.2.840.113549.1.1.5) used to identify the signature over the certificate. RFC3280. >> Take a look at a digital certificate for example. The public key has >> an OID that identifies it as RSA, DSA or EC (and may provide some >> additional parameters such as the EC curve). The SIGNATURE has an >> oid that identifies it as SHA1withRSA for example. >> >> How the heck would doing this trigger this boogey man of a "downgrade >attack"? >> >> Details please - and no visions. > >I agree with Sam Weilers' point. I'll give you the details: Roy - I'm not sure what the following is trying to prove. As I read it, what you've said is that if the signature algorithm field value in the RRSIG record is unknown, then you can't validate the RRSIG. Is that correct? If so, I agree with you. If I get a value in this field that means "RSA/MIKESHASHALG256" and no one understands it, the RRSIG can't be validated. The deployment of ANY new value for the algorithm field of the RRSIG will have this same characteristic for some resolvers that didn't get the word. >1) The digest algorithm needs to be present in the DNSKEY RR. If not, then >DNSSEC will be susceptible to a downgrade attack. Consider an RRSIG with a >known signature algorithm (say RSA) with an unknown digest. There is no >fallback to provable unsecure, since nothing can be proven. The only path >left is to label it bogus. This will cause a significant disruption of >service that an upgrade to a stronger hash on the server side will be >avoided. The concept of provable unsecure (or provable unknown) is not >trivial, but an essential part of the architecture of DNSSEC. And this following statement doesn't follow from the previous. The mis-named algorithm field signals the key type of the DNSKEY. Or are you saying that a DNSKEY labeled RSA/MD5 can't be used in a RSA/SHA1 signature? [Sigh - OK - I went back to the source documents and found the source of my and your problem. In RFC4035 - section 5.3.1 there's this paragraph which says exactly that: The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST match the owner name, algorithm, and key tag for some DNSKEY RR in the zone's apex DNSKEY RRset. ] This wasn't in the original DNSSEC (2535) and shouldn't have included "algorithm" in this version - at least in this manner. It should have read "The DNSKEY RR algorithm field must contain a key type which is compatible with the RRSIG RR's signature algorithm as indicated in the Algorithm field" or something similar. I'm not sure what to say here. I believe the indicated paragraph is incorrect, but its what's standardized. OTOH, it only affects resolvers, and could be worked around in resolvers that understand the new signature algorithms at the time they're implemented and that's basically what I've proposed. If you and Sam are saying that if you don't label the key type with the hash algorithm (current model where sig and key type are the same), then the zone owner can use a weaker hash in the signature than intended and that's a downgrade attack? I'm saying that the choice of security strengths to use in the zone is the zone operator and if he chooses to use a weak hash with a stronger length key - that's his business. Especially since we don't specify the matching of hash to key length in the first place. If anyone were still using MD5, you'd have them have to have duplicate DNSKEY records (except for the alg field) to transition into SHA1 land. (Or at least ANOTHER DNSKEY of the same or longer length). Aren't the zones large enough already? Do you want to do this for SHA1 to SHA224 or SHA256 as well? I'd rather use the existing keys and just transition to the new signature algorithms. I'm still not sure where the downgrade attack comment comes from. Given that its your only security argument so far - could you try to clarify it for me please? So I'm still puzzled about downgrade attacks, but no longer puzzled about the opposition to splitting the registry. >2) We're now left with signalling the digest algorithm in the DNSKEY >field. There are two possible ways to do this. One is to leave the >algorithm field to denote the signing algorithm, i.e. no digest algorithm, >and signal the digest algorithm in the public key field. We now have an 8 >bits field for the signature algorithm, for which we only have 4 >algorithms (DH,DSA,RSA,ECC), and a somewhat odd digest field within the >public key field. That doesn't look like a clean design either. The other >option is to split the 8 bits signature field in two. Whatever ratio we >choose, we now have significantly less space to expand on. Complexity >doesn't get easier either, since any combination must be possible, since >every allocated digest algorithm needs to work with every allocated >signature algorithm. We would also need a new structure for the DS record. > >That leaves us with the current status quo. That is not a bad option. I >would argue it is fairly optimal use of the signature field space. At >least it is the lesser of all the alternative evils I mentioned above. > >> >>4) What should the actual status be of the new combinations? >> > >> >Mandatory. We know that doesn't mean they'll actually be >> implemented, but there's little point in doing something else. (If we >> don't think we need it, why specify it?) > >Agreed. > >Regards, > >Roy --=====================_139206515==.ALT Content-Type: text/html; charset="us-ascii" At 01:53 11/2/2007, roy@nominet.org.uk wrote:
Michael StJohns wrote on 11/01/2007 04:42:53 PM:

> At 18:03 11/1/2007, Sam Weiler wrote:
> >On Wed, 24 Oct 2007, Jelte Jansen wrote:
> >
> >>1) Should this document be written?
> >
> >Probably.  See answer to #2.
> >
> >>2) Should this document specify other hash algorithms as well?
> >
> >In the interest of keeping the complexity to build new resolvers down
> somewhat, I think we should limit ourselves to only what we think we
> need.  At any time, I would expect that to be no more than "one hash
> algorithm we believe is strong enough" and "one or two more, in case
> we're wrong".  I haven't formed an opinion about exactly which ones we
> need right now, but if we're defining more than two, we're going down
> the wrong path.  Do we need something stronger than SHA1?  Probably.
> Do we need the whole SHA2 suite?  No.  In the absence of a clear sense
> of what to add beyond SHA256, let's stop at SHA256.

FWIW, I completely agree with Sam's rationale. To satisfy Mike's point
below, we could, instead of SHA256, settle on SHA512. As long as we don't
need to implement the whole suite. If SHA512 is available, why settle for
less.

Except that there's a real continuing cost for doing it this way.  SHA512 *is* more expensive to calculate than SHA256 - not a lot, but some.  That's a cost that carries forward on every signing and every verification.  Implementing the whole suite is a cost that happens once, is not all that much more expensive for 4 algorithms as for one, and is spread over all the systems that run that version of the code.  [NB: SHA224 and 256 have approximately the same costs per hash as do SHA384 and SHA512]

The complexity argument doesn't hold water - it's a lookup table that selects three elements - the hash, the signature mechanism and for some (for all of the RSA signatures) the padding.  Implementation wise, the calling sequence for each element is mostly identical within those elements (e.g. same signature calls, same hash calls, same padding calls).

> We've specified RSA as a valid key type for digital signatures.
> RFC3110 specifies a possible range of strengths for RSA in DNSSEC
> signatures from 512 to 4096 bits.  NIST (and other cryptographers)
> have made some strong suggestions about what hashes should match up
> with which signature lengths - see the tables (2, 3 and 4) in the NIST
> 800-57 publication.    That table suggests the appropriate match for
> RSA 2048 bit signatures is SHA224, and for 4096 - SHA384 or greater
> (SHA256 provides about 128 bits of strength, SHA384 provides 192 bits
> - RSA 4096 is somewhere between 128 and 192 bits of strength).
>
> Its not about adding SHA256 - its about adding hashes appropriate to
> cover the range of strengths of the signature methods that have
> already been approved.
>
>
> >>3) If so, how will we handle the different algorithm/hash types?
> >
> >I think we should NOT split the field, and I think it's actively
> dangerous to split the registries, as MSJ suggests.  (Visions of
> downgrade attacks are swimming through my head.)
>
> I'm OK with not splitting the field, but your vision must be from
mushrooms.
>
> So what you're saying is the CMS guys got it wrong? I find that hard to
believe.

I haven't seen that statement.

CMS - Cryptographic Message Syntax - all of the PKIX guys.  Not a statement per se, but a method of doing cryptographic operations.  The key type is distinct from all of the possible signature types it can be used to form.  E.g. an RSA key (OID 1.2.840.113549.1.1.1) used in the SubjectPublicKeyInfo field of a certificate is different than the signature algorithm type SHA1withRSA (OID 1.2.840.113549.1.1.5) used to identify the signature over the certificate.

RFC3280.


> Take a look at a digital certificate for example.  The public key has
> an OID that identifies it as RSA, DSA or EC (and may provide some
> additional parameters such as the EC curve).   The SIGNATURE has an
> oid that identifies it as SHA1withRSA for example.
>
> How the heck would doing this trigger this boogey man of a "downgrade
attack"?
>
> Details please - and no visions.

I agree with Sam Weilers' point. I'll give you the details:

Roy - I'm not sure what the following is trying to prove.  As I read it, what you've said is that if the signature algorithm field value in  the RRSIG record is unknown, then you can't validate the RRSIG.  Is that correct?  If so, I agree with you.   If I get a value in this field that means "RSA/MIKESHASHALG256" and no one understands it, the RRSIG can't be validated.  The deployment of ANY new value for the algorithm field of the RRSIG will have this same characteristic for some resolvers that didn't get the word.

1) The digest algorithm needs to be present in the DNSKEY RR. If not, then
DNSSEC will be susceptible to a downgrade attack. Consider an RRSIG with a
known signature algorithm (say RSA) with an unknown digest. There is no
fallback to provable unsecure, since nothing can be proven. The only path
left is to label it bogus. This will cause a significant disruption of
service that an upgrade to a stronger hash on the server side will be
avoided. The concept of provable unsecure (or provable unknown) is not
trivial, but an essential part of the architecture of DNSSEC.

And this following statement doesn't follow from the previous.  The mis-named algorithm field signals the key type of the DNSKEY.  Or are you saying that a DNSKEY labeled RSA/MD5 can't be used in a RSA/SHA1 signature?

[Sigh - OK - I went back to the source documents and found the source of my and your problem.  In RFC4035 - section 5.3.1 there's this paragraph which says exactly that:


The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
      match the owner name, algorithm, and key
tag for some DNSKEY RR in
      the zone's apex DNSKEY RRset.
]

This wasn't in the original DNSSEC (2535) and shouldn't have included "algorithm" in this version - at least in this manner. It should have read "The DNSKEY RR algorithm field must contain a key type which is compatible with the  RRSIG RR's signature algorithm as indicated in the Algorithm field" or something similar.


I'm not sure what to say here.  I believe the indicated paragraph is incorrect, but its what's standardized.  OTOH, it only affects resolvers, and could be worked around in resolvers that understand the new signature algorithms at the time they're implemented and that's basically what I've proposed.


If you and Sam are saying that if you don't label the key type with the hash algorithm (current model where sig and key type are the same), then the zone owner can use a weaker hash in the signature than intended and that's a downgrade attack?   I'm saying that the choice of security strengths to use in the zone is the zone operator and if he chooses to use a weak hash with a stronger length key - that's his business.  Especially since we don't specify the matching of hash to key length in the first place.

If anyone were still using MD5, you'd have them have to have duplicate DNSKEY records (except for the alg field) to transition into SHA1 land.  (Or at least ANOTHER DNSKEY of the same or longer length).

Aren't the zones large enough already?  Do you want to do this for SHA1 to SHA224 or SHA256 as well?  I'd rather use the existing keys and just transition to the new signature algorithms.

I'm still not sure where the downgrade attack comment comes from.  Given that its your only security argument so far - could you try to clarify it for me please?

So I'm still puzzled about downgrade attacks, but no longer puzzled about the opposition to splitting the registry.




2) We're now left with signalling the digest algorithm in the DNSKEY
field. There are two possible ways to do this. One is to leave the
algorithm field to denote the signing algorithm, i.e. no digest algorithm,
and signal the digest algorithm in the public key field. We now have an 8
bits field for the signature algorithm, for which we only have 4
algorithms (DH,DSA,RSA,ECC), and a somewhat odd digest field within the
public key field. That doesn't look like a clean design either. The other
option is to split the 8 bits signature field in two. Whatever ratio we
choose, we now have significantly less space to expand on. Complexity
doesn't get easier either, since any combination must be possible, since
every allocated digest algorithm needs to work with every allocated
signature algorithm. We would also need a new structure for the DS record.

That leaves us with the current status quo. That is not a bad option. I
would argue it is fairly optimal use of the signature field space. At
least it is the lesser of all the alternative evils I mentioned above.

> >>4) What should the actual status be of the new combinations?
> >
> >Mandatory.  We know that doesn't mean they'll actually be
> implemented, but there's little point in doing something else.  (If we
> don't think we need it, why specify it?)

Agreed.

Regards,

Roy

--=====================_139206515==.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 Nov 02 16:49:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io3Sm-0003VY-Us; Fri, 02 Nov 2007 16:49:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Io3Sg-0006UA-OP; Fri, 02 Nov 2007 16:49:56 -0400 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Io3LU-0008iP-4k for namedroppers-data@psg.com; Fri, 02 Nov 2007 20:42:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Io3LF-0008h0-Hu for namedroppers@ops.ietf.org; Fri, 02 Nov 2007 20:42:14 +0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id lA2Kfu9Z013736; Fri, 2 Nov 2007 15:41:56 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id lA2KfvIe013726; Fri, 2 Nov 2007 15:41:57 -0500 Received: from localhost ([157.185.80.253]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Nov 2007 16:41:56 -0400 Date: Fri, 2 Nov 2007 16:41:55 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@mint.samweiler.com To: Michael StJohns cc: Jelte Jansen , namedroppers@ops.ietf.org Subject: Re: RSA/SHA256 In-Reply-To: <200711012340.lA1Ned6I017634@nutshell.tislabs.com> Message-ID: References: <471FB97B.9000108@NLnetLabs.nl> <200711012340.lA1Ned6I017634@nutshell.tislabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 02 Nov 2007 20:41:56.0754 (UTC) FILETIME=[CF200F20:01C81D90] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Fri, 02 Nov 2007 15:41:56 -0500 (CDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 First, I think I see the benefit of your proposal -- allowing the same public key (RSA or other) to be used to validate signatures generated from any of several hash algorithms without adding a new DNSKEY RR to the zone for each hash algorithm and, per the current "mandatory algorithm rules", an RRSIG for each algorithm on every RRset in the zone. That may look like a substantial benefit, bit I'm not convinced it outweighs the complexity cost of adding another crypto parameter field. > Its not about adding SHA256 - its about adding hashes appropriate to > cover the range of strengths of the signature methods that have > already been approved. No objection re: SHA256 not being the specific chosen next step, but do we really need a RANGE of stengths? Why can't we just pick one hash function at the upper end of the range and call it done? > So what you're saying is the CMS guys got it wrong? I find that hard to believe. Not at all. Context is everything. We need to look at how the certificates are being validated and the consequences of failed validation. > Take a look at a digital certificate for example. The public key > has an OID that identifies it as RSA, DSA or EC (and may provide > some additional parameters such as the EC curve). The SIGNATURE has > an oid that identifies it as SHA1withRSA for example. > > How the heck would doing this trigger this boogey man of a "downgrade attack"? > > Details please - and no visions. The devil is, indeed, in the details. In this case, it's in the details of validator behavior. It's very hard to provide details of how to break something that hasn't been fully specified. Tell you what: spec out your "split the registry" proposal to include the details of validator behavior, especially when faced when unknown/unsupported/disabled hash algorithms (in various combinations with supported and unsupported public key algorithms), and then I'll attempt to show you a downgrade attack. [Or perhaps Roy's post, which appeared after I wrote most of this note, will be sufficient.] Somewhere along the way, I suspect we'll hit the same brick wall that we've been hitting since 2002 or 2003, where we find that we have very different visions of acceptable validation results and resolver behavior. (Oops, I'm talking about visions again...) -- Sam -- to unsubscribe send a message to namedroppers-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 Nov 02 18:57:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io5SE-0005ip-9N; Fri, 02 Nov 2007 18:57:30 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Io5SD-0005Ur-2y; Fri, 02 Nov 2007 18:57:30 -0400 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Io5LF-000Hf3-8F for namedroppers-data@psg.com; Fri, 02 Nov 2007 22:50:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,MISSING_MID, RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.62.16] (helo=QMTA01.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Io5L4-000He3-C4 for namedroppers@ops.ietf.org; Fri, 02 Nov 2007 22:50:11 +0000 Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA01.westchester.pa.mail.comcast.net with smtp id 7yGi1Y00316LCl00001w00; Fri, 02 Nov 2007 22:50:02 +0000 Received: from mikespersonal.comcast.net ([68.48.56.3]) by OMTA06.westchester.pa.mail.comcast.net with comcast id 7yq21Y00104A3tg0000000; Fri, 02 Nov 2007 22:50:03 +0000 X-Authority-Analysis: v=1.0 c=1 a=DH-0s9HbNjmUNCPE194A:9 a=MTXKCbLua2umvBmUa-70t32jofcA:4 a=YMxiO07kagMA:10 a=h9s5Ru71U4oA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 02 Nov 2007 18:50:06 -0400 To: Sam Weiler From: Michael StJohns Subject: Re: RSA/SHA256 Cc: Jelte Jansen ,namedroppers@ops.ietf.org In-Reply-To: References: <471FB97B.9000108@NLnetLabs.nl> <200711012340.lA1Ned6I017634@nutshell.tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Message-Id: X-Spam-Score: -4.0 (----) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 At 16:41 11/2/2007, Sam Weiler wrote: >>How the heck would doing this trigger this boogey man of a "downgrade attack"? >> >>Details please - and no visions. > >The devil is, indeed, in the details. In this case, it's in the details of validator behavior. It's very hard to provide details of how to break something that hasn't been fully specified. Tell you what: spec out your "split the registry" proposal to include the details of validator behavior, especially when faced when unknown/unsupported/disabled hash algorithms (in various combinations with supported and unsupported public key algorithms), and then I'll attempt to show you a downgrade attack. [Or perhaps Roy's post, which appeared after I wrote most of this note, will be sufficient.] How about I just ask you to do a downgrade attack using currently defined algorithms? E.g. RSA/MD5 and RSA/SHA1 Resolver understands RSA/MD5 but not RSA/SHA1. (Yeah, I know - the latter one is mandatory). If the DNSKEY is RSA/SHA1, the RRSIG is RSA/SHA1 - resolver can't validate it because it doesn't understand the signature algorithm - it doesn't even need to look at the DNSKEY to figure this out. If the DNSKEY is RSA/SHA1, the RRSIG is RSA/MD5 - 4035 compliant resolver can't validate it because the DNSKEY and RRSIG algorithm IDs don't agree, even though the resolver actually has all the information it needs to validate. If the DNSKEY is RSA (new approach), the RRSIG is RSA/MD5 - resolver that understands that the algorithm value in the DNSKEY is actually a key type can validate it. So the question is - what's the downgrade attack here? To go further, without adding any more hashes, let's say the resolver understands both RSA/MD5 and RSA/SHA1. If the resolver behavior is programmed to say that for any DNSKEY, we ignore the hash component of the algorithm field - e.g. RSA/MD5 and RSA/SHA1 are equivalent values *in a DNSKEY record only* - what is the downgrade attack there? E.g. why wouldn't a resolver that understands *and by policy accepts* both hashes, accept an RRSIG with RSA/SHA1 where the DNSKEY it points to is RSA/MD5? Or vice versa? So you've got some homework - there are something like 5 cases above - hopefully at least one of them will lead you to a reasonable description of a "downgrade attack". To succeed, you need to explain why its bad for a resolver to accept a key marked RSA/SHA1 and not accept a key marked RSA/MD5 to validate a signature marked RSA/SHA1 - especially if the key material is identical - the same public key. I don't think you can do it.. but I might be wrong. >Somewhere along the way, I suspect we'll hit the same brick wall that we've been hitting since 2002 or 2003, where we find that we have very different visions of acceptable validation results and resolver behavior. (Oops, I'm talking about visions again...) -- to unsubscribe send a message to namedroppers-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 Nov 03 05:32:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoFMk-0002AG-0y; Sat, 03 Nov 2007 05:32:30 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IoFMY-0005YL-Rh; Sat, 03 Nov 2007 05:32:25 -0400 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IoFBB-000Nij-Ax for namedroppers-data@psg.com; Sat, 03 Nov 2007 09:20:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,MISSING_MID, RDNS_NONE autolearn=no version=3.2.3 Received: from [204.127.200.81] (helo=sccrmhc11.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IoFAz-000NhB-VB for namedroppers@ops.ietf.org; Sat, 03 Nov 2007 09:20:27 +0000 Received: from mikespersonal.comcast.net (c-68-48-56-3.hsd1.md.comcast.net[68.48.56.3]) by comcast.net (sccrmhc11) with SMTP id <2007110222593701100rrrjve>; Fri, 2 Nov 2007 22:59:38 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 02 Nov 2007 18:59:40 -0400 To: Sam Weiler From: Michael StJohns Subject: Re: RSA/SHA256 Cc: Jelte Jansen ,namedroppers@ops.ietf.org In-Reply-To: References: <471FB97B.9000108@NLnetLabs.nl> <200711012340.lA1Ned6I017634@nutshell.tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Message-Id: X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 At 16:41 11/2/2007, Sam Weiler wrote: >No objection re: SHA256 not being the specific chosen next step, but do we really need a RANGE of stengths? Why can't we just pick one hash function at the upper end of the range and call it done? See my discursion in the note back to Roy. Basically, there's a cost. SHA224/SHA256 cost about the same (cpu time) for the same data. SHA384/SHA512 also cost about the same as each other. However, SHA224/256 cost less than SHA384/512 over a particular data blob. There's a reason all of these are specified - they have specific strengths and they're designed to go with specific signature key lengths/strength. We could specify SHA512 for everything, but then we're imposing a higher cost on everyone (signers and resolvers) than we really need to for any given key length. The cost to implement is trivial - if done all at once. But if you want to go with the single hash approach - SHA512 is the one that covers all of the top end ranges of the allowed key lengths for RSA. -- to unsubscribe send a message to namedroppers-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 Nov 04 21:50:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ios2N-0003hU-7d; Sun, 04 Nov 2007 21:50:03 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ios2M-0000KS-Mi; Sun, 04 Nov 2007 21:50:03 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IorsL-000DET-AL for namedroppers-data@psg.com; Mon, 05 Nov 2007 02:39:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iorro-000DCi-8q for namedroppers@ops.ietf.org; Mon, 05 Nov 2007 02:39:24 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id lA52ccfE006955 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 4 Nov 2007 21:38:38 -0500 Date: Sun, 4 Nov 2007 21:38:37 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: "Olaf M. Kolkman" cc: Samuel Weiler , , Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 On Thu, 1 Nov 2007, Olaf M. Kolkman wrote: > > Dear Dean, > > > In my interpretation RFC3833 is an informational document posting the > requirements to which _DNSSECbis_ was developed. I'm not sure if a > debate on the correctness of my interpretation is going to be > fruitful ;-). So, what follows is a bit of documented history on why > and how the working group took up this work. The point I am trying to > make is that the decision to take up this work was not made without > appropriate discussion on the policy and the various trade-offs. If you mean to assert the informational status of RFC3833 as meaning it doesn't state a policy, I think that argument is unpersuasive. If you mean to assert that policy violations can't be raised in last-call, I think that argument is also unpersuasive. The IETF has no proper public interest in helping registries improperly assert 'database copyright' rights to public information by technical methods. > When DNSSECbis was being (or about to be) last called several > registries stepped up and argued that they could not deploy DNSSECbis > given the ease of zone enumeration. One example of such argument is in > http://www.ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00685.html They wrote: ======================= begin block quote However, for those of you that have asked, this is the gist of our legal advice... As compilations, zone file databases are protected under EU law by ?Database Right?. As a derivative work of the main register from which they are sourced, they are likely also to attract copyright protection in addition to or in place of database right. Both database right and copyright are negative rights in that they prohibit certain acts (primarily, copying the whole or a substantial part of the materials) but do not grant positive rights (unlike, for example, a patent, which grants a monopoly on the material involved). Database right is unique to countries which implement European Community law, but copyright is more universal. ======================= end block quote As I said, the IETF has no legitimate interest in helping registries assert these rights by technical means. Frankly, the zones are public information, and the registries do not have a right here at all. They did not "compile" this information. The registries are performing a service for which they are entitled to charge service fees. However, they do not own the DNS information collected. If the registry is decertified, it must turn over this information. That can't happen if there is a copyright asserted. This is a very serious problem that must be stopped at all levels. If these registries can't use DNSSEC because they might not be able to assert database copyright claims on public information, too bad for them. Good for the rest of us. The policy requirements are clearly stated. --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 Mon Nov 05 03:35:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoxR5-0004qW-E2; Mon, 05 Nov 2007 03:35:55 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IoxR4-0007Zi-RE; Mon, 05 Nov 2007 03:35:55 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IoxHu-0006Fd-PB for namedroppers-data@psg.com; Mon, 05 Nov 2007 08:26:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [213.154.224.48] (helo=bert.secret-wg.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IoxHL-0006DZ-Bd for namedroppers@ops.ietf.org; Mon, 05 Nov 2007 08:26:09 +0000 Received: from Grover.lan (a62-251-91-215.adsl.xs4all.nl [62.251.91.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bert.secret-wg.org (Postfix) with ESMTPSA id A1280B8A1; Mon, 5 Nov 2007 09:25:47 +0100 (CET) Cc: Samuel Weiler , , Message-Id: <0FCF022F-7A76-43C2-8EF6-E87298AF3DC4@NLnetLabs.nl> From: "Olaf M. Kolkman" 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 v912) Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) Date: Mon, 5 Nov 2007 09:25:46 +0100 References: X-Mailer: Apple Mail (2.912) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc On Nov 5, 2007, at 3:38 AM, Dean Anderson wrote: > > If you mean to assert the informational status of RFC3833 as meaning > it > doesn't state a policy, I think that argument is unpersuasive. > We seem to have to agree that we disagree. > If you mean to assert that policy violations can't be raised in > last-call, I think that argument is also unpersuasive. I am not asserting that you cannot raise such issues during last call, by all means; last call review on all aspects of technology is useful. What I tried to bring across is that we had this discussion in the working group about 3 years ago. During that discussion we saw folk arguing your view and some supporting other views. At that point in time the working group re-chartered to work on this. That should have been the time to put a firm break on the work. Today, at IETF last call, the IETF did do the technical work and implementors did invest in implementing the technology[*]. In my opinion the IETF should design technology that folk can implement given the boundaries of operational reality. It turned out that in the history of DNSSEC we did a pretty bad job by doing so because the _proper_ operational folk where not paying attention to the design space when work was done. For instance RFC2035 did, with hindsight, not understand the problems of parent-child key interactions for large registries, that lead to DNSSEC-bit. When RFC3833 was written the policy folk ---a specific sub-group of the operators species :-)--- did not pay attention. They only payed attention during last call for DNSSEC-bis (and here I refer to the threads from which I quoted a number of messages previously). It turns out that DNSSEC is a difficult technology to sell because the incentives for deployment is not well aligned with the costs of the deployment. In my honest opinion the only way to get deployment is when there will be a sufficient number of large TLDs that offer DNSSEC on their zones. To me that seems a prerequisite for the client side to invest in deployment and that seems to me a prerequisite for further development on top of DNSSEC. Without NSEC3 and its OPT-OUT feature there are significant TLDs that will not play in the DNSSEC space because their costs will be prohibitive. For instance they would have to violate their own policy. The strong point of NSEC3 is that it has been designed in such a way that it can be completely ignored. If zone operators choose not to implement/use NSEC3 they will be able to deploy DNSSEC as is. If DNS client choose not to implement NSEC3 then they will continue to see the TLDs that deploy NSEC3 as if they are not signed. In that way the technology is not forced upon folk who do not want to deploy the technology. If NSEC was being deprecated and NSEC3 were to become mandatory, and thereby _enforce_ policy, then I would be much more sympathetic to the "the DNS is public" argument. But with NSEC3 that policy discussion can proceed out of the IETF and the technology is able to deal with the tussle. Kind regards, --Olaf (no hats) [*] For full disclosure, NLnet Labs is one such implementer; Our authoritative server NSD is NSEC3 ready. NSEC3 will be a feature for the forthcoming recursive nameserver. We only started our work _after_ NSEC3 was chartered. Funded by charity and all will be available under BSD license. ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ -- to unsubscribe send a message to namedroppers-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 Nov 05 12:32:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip5oL-0006S7-3E; Mon, 05 Nov 2007 12:32:29 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip5oJ-0004An-Bb; Mon, 05 Nov 2007 12:32:29 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ip5dS-000IBF-Cm for namedroppers-data@psg.com; Mon, 05 Nov 2007 17:21:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ip5dH-000IAC-C2 for namedroppers@ops.ietf.org; Mon, 05 Nov 2007 17:21:08 +0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id lA5HKv4A020313; Mon, 5 Nov 2007 11:20:59 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id lA5HKtfj029109; Mon, 5 Nov 2007 11:20:55 -0600 Received: from localhost ([157.185.80.253]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Nov 2007 12:20:54 -0500 Date: Mon, 5 Nov 2007 12:20:53 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@mint.samweiler.com To: Michael StJohns cc: namedroppers@ops.ietf.org Subject: Re: RSA/SHA256 In-Reply-To: Message-ID: References: <471FB97B.9000108@NLnetLabs.nl> <200711012340.lA1Ned6I017634@nutshell.tislabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 05 Nov 2007 17:20:55.0033 (UTC) FILETIME=[3904BE90:01C81FD0] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Mon, 05 Nov 2007 11:20:59 -0600 (CST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Fri, 2 Nov 2007, Michael StJohns wrote: > How about I just ask you to do a downgrade attack using currently > defined algorithms? I'd rather work from a spec, even a very rough one, but I'm willing to work from the examples. Either way, it's vital to separate validation failures into the two main cases we defined in DNSSECbis: Insecure and Bogus. (Feel free to treat Indeterminate and Insecure as the same state, for the most part.) Would you flesh out the examples you gave by separating the validation failure states? From that we might be able to infer enough about the validation algorithm you intend. -- Sam -- to unsubscribe send a message to namedroppers-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 Nov 05 12:56:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip6BN-0007wq-Ln; Mon, 05 Nov 2007 12:56:17 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip6BM-00056V-FB; Mon, 05 Nov 2007 12:56:17 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ip66k-000KZJ-95 for namedroppers-data@psg.com; Mon, 05 Nov 2007 17:51:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,MISSING_MID, RDNS_NONE autolearn=no version=3.2.3 Received: from [216.148.227.155] (helo=rwcrmhc15.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ip66S-000KXr-CV for namedroppers@ops.ietf.org; Mon, 05 Nov 2007 17:51:24 +0000 Received: from mikespersonal.comcast.net (216-129-123-44.cust.layer42.net?[216.129.123.44]) by comcast.net (rwcrmhc15) with SMTP id <20071105175111m15009a280e>; Mon, 5 Nov 2007 17:51:11 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 05 Nov 2007 12:51:14 -0500 To: Sam Weiler From: Michael StJohns Subject: Re: RSA/SHA256 Cc: namedroppers@ops.ietf.org In-Reply-To: References: <471FB97B.9000108@NLnetLabs.nl> <200711012340.lA1Ned6I017634@nutshell.tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Message-Id: X-Spam-Score: -4.0 (----) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hmm... the red herring of the meta protocol.... This isn't about DNSSEC validation states, this is about cryptographic validation states of a single RRSET. While the DNSSEC validation state depends on the cryptographic validation state, they are NOT the same thing and the whole discussion about bogus/validated/unsecure/unknown is a meta-red herring. Take one RRSet of any type. Take a DNSKEY of type RSA/MD5 Sign the RRSET with that DNSKEY (the private key of course), but using RSA/SHA1 as the signature algorithm. Cryptographically, the RRSET can be validated using the DNSKEY key material (e.g. the key material is signature algorithm agnostic), but DNSSEC says this isn't kosher because the algorithm fields aren't an exact match. 4035 says the way to do this is to clone the key into another DNSKEY record and change the DNSKEY algorithm type. Why would changing the DNSKEY algorithm field from a signature algorithm to a key type and as a consequence allow one DNSKEY to be used in multiple signature algorithms allow a downgrade attack? What is this downgrade attack? At 12:20 11/5/2007, Sam Weiler wrote: >On Fri, 2 Nov 2007, Michael StJohns wrote: > >>How about I just ask you to do a downgrade attack using currently defined algorithms? > >I'd rather work from a spec, even a very rough one, but I'm willing to work from the examples. Either way, it's vital to separate validation failures into the two main cases we defined in DNSSECbis: Insecure and Bogus. (Feel free to treat Indeterminate and Insecure as the same state, for the most part.) > >Would you flesh out the examples you gave by separating the validation failure states? From that we might be able to infer enough about the validation algorithm you intend. > >-- Sam -- to unsubscribe send a message to namedroppers-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 Nov 05 17:00:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpA08-0002up-TI; Mon, 05 Nov 2007 17:00:56 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpA07-0004jP-7O; Mon, 05 Nov 2007 17:00:56 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ip9s0-000D27-Tu for namedroppers-data@psg.com; Mon, 05 Nov 2007 21:52:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ip9rR-000CzJ-Mh for namedroppers@ops.ietf.org; Mon, 05 Nov 2007 21:52:15 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id lA5LneBh008350 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 5 Nov 2007 16:49:41 -0500 Date: Mon, 5 Nov 2007 16:49:40 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: "Olaf M. Kolkman" cc: Samuel Weiler , , Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) In-Reply-To: <0FCF022F-7A76-43C2-8EF6-E87298AF3DC4@NLnetLabs.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 On Mon, 5 Nov 2007, Olaf M. Kolkman wrote: > > On Nov 5, 2007, at 3:38 AM, Dean Anderson wrote: > > > > > If you mean to assert the informational status of RFC3833 as meaning > > it doesn't state a policy, I think that argument is unpersuasive. > > We seem to have to agree that we disagree. Perhaps. But under your interpretation, the document has no meaning whatsoever. This is contrary to the rules for interpretation of documents. > > If you mean to assert that policy violations can't be raised in > > last-call, I think that argument is also unpersuasive. > > I am not asserting that you cannot raise such issues during last call, > by all means; last call review on all aspects of technology is useful. > > What I tried to bring across is that we had this discussion in the > working group about 3 years ago. During that discussion we saw folk > arguing your view and some supporting other views. At that point in > time the working group re-chartered to work on this. I reviewed these charters: Oct 6, 2003 The IESG WG Action: RECHARTER: DNS Extensions (dnsext) Jan 29, 2004 The IESG WG Action: RECHARTER: DNS Extensions (dnsext) Feb 9, 2005 The IESG WG Action: RECHARTER: DNS Extensions (dnsext) I did not find anything that would put NSEC on the agenda, nor anything that specifically reversed RFC3833, nor anything that would have asserted that the DNSEXT WG would or should assist with Database Copyright. Nor is there any obligation to assert Database Copyright, as the draft introduction claims. I appear to have been misled. > That should have been the time to put a firm break on the work. Today, > at IETF last call, the IETF did do the technical work and implementors > did invest in implementing the technology[*]. > > In my opinion the IETF should design technology that folk can > implement given the boundaries of operational reality. It turned out > that in the history of DNSSEC we did a pretty bad job by doing so > because the _proper_ operational folk where not paying attention to > the design space when work was done. I have a diffferent view of that, too. I think perhaps the improper operational folk _were_ paying attention, and that others who actually knew about crypto (eg. Dr. Bernstein) was rudely told to pound sand. --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 Mon Nov 05 18:24:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpBJ4-0005qG-Sz; Mon, 05 Nov 2007 18:24:34 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpBJ2-0008DM-4B; Mon, 05 Nov 2007 18:24:34 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpBDN-000JKP-FG for namedroppers-data@psg.com; Mon, 05 Nov 2007 23:18:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [204.152.184.167] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpBCq-000JHU-Bm for namedroppers@ops.ietf.org; Mon, 05 Nov 2007 23:18:24 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id 6D6AA11401F for ; Mon, 5 Nov 2007 23:18:07 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id DDD6EE6058 for ; Mon, 5 Nov 2007 23:18:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id lA5NG9DY068451; Tue, 6 Nov 2007 10:16:09 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200711052316.lA5NG9DY068451@drugs.dv.isc.org> To: Dean Anderson Cc: "Olaf M. Kolkman" , Samuel Weiler , namedroppers@ops.ietf.org, iesg@ietf.org From: Mark Andrews Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) In-reply-to: Your message of "Mon, 05 Nov 2007 16:49:40 CDT." Date: Tue, 06 Nov 2007 10:16:09 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 > On Mon, 5 Nov 2007, Olaf M. Kolkman wrote: > > > > > On Nov 5, 2007, at 3:38 AM, Dean Anderson wrote: > > > > > > > > If you mean to assert the informational status of RFC3833 as meaning > > > it doesn't state a policy, I think that argument is unpersuasive. > > > > We seem to have to agree that we disagree. > > Perhaps. But under your interpretation, the document has no meaning > whatsoever. This is contrary to the rules for interpretation of > documents. > > > > If you mean to assert that policy violations can't be raised in > > > last-call, I think that argument is also unpersuasive. > > > > I am not asserting that you cannot raise such issues during last call, > > by all means; last call review on all aspects of technology is useful. > > > > What I tried to bring across is that we had this discussion in the > > working group about 3 years ago. During that discussion we saw folk > > arguing your view and some supporting other views. At that point in > > time the working group re-chartered to work on this. > > I reviewed these charters: > > Oct 6, 2003 The IESG WG Action: RECHARTER: DNS Extensions (dnsext) > Jan 29, 2004 The IESG WG Action: RECHARTER: DNS Extensions (dnsext) > Feb 9, 2005 The IESG WG Action: RECHARTER: DNS Extensions (dnsext) > > I did not find anything that would put NSEC on the agenda, nor anything > that specifically reversed RFC3833, nor anything that would have > asserted that the DNSEXT WG would or should assist with Database > Copyright. Nor is there any obligation to assert Database Copyright, as > the draft introduction claims. I appear to have been misled. NSEC3 is not about "Database Copyright". It's about restoring properties that were lost with the introduction of DNSSEC. i.e. it was virtually impossible to find the names in a zone without being in a position to intercept queries from people with apriori knowledge. If registries believe that will help with their "Database Copyright" issues, well that's their belief. I never believed that NSEC signifantly changed the ability to find names as keys for whois queries. For registries there are enough other sources of apriori knowledge that their arguements were very weak. It didn't however prevent the rest of us realising that there are parts of the DNS where there isn't a lot of apriori knowledge and that people depending apon that property should still be able to sign their zones. Optin/out on the other hand will help registries as it reduces the memory required to serve a signed zone. However whether that is in the interests of public is still, very much, debatable. Being able to spoof away a delegation is not desirable and would not wish a infrastructure zone to do this. When NSEC++ work went ahead it was stated that this should be a investigation into "is it technically feasible to do this". The question about optin/out was left to be debated at a later stage as was should this become part of DNSSEC. I think there is consensus that NSEC3 is technically possible. I have seen no discussion about whether optin/out should be kept or not. I have seen no formal discussion asking the question "should NSEC3 be incorporated into the base DNSSEC". At the moment it is still a experimental extention. I, would have no problem with NSEC3 being incorporated into the base DNSSEC. I think there should be a an applicability statement that optin/out should be *not* deployed in infrastructure zones despite the obvious memory benefits. Such zones should be asserting that there is a delegation even if the contents of the delegated zone can be spoofed away. I would be happy for optin/out to be removed as it complicates the implementation for minimal benefit. Mark > > That should have been the time to put a firm break on the work. Today, > > at IETF last call, the IETF did do the technical work and implementors > > did invest in implementing the technology[*]. > > > > In my opinion the IETF should design technology that folk can > > implement given the boundaries of operational reality. It turned out > > that in the history of DNSSEC we did a pretty bad job by doing so > > because the _proper_ operational folk where not paying attention to > > the design space when work was done. > > I have a diffferent view of that, too. I think perhaps the improper > operational folk _were_ paying attention, and that others who actually > knew about crypto (eg. Dr. Bernstein) was rudely told to pound sand. > > --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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 05 18:49:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpBgp-00075g-Aw; Mon, 05 Nov 2007 18:49:07 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpBgm-00008V-V1; Mon, 05 Nov 2007 18:49:07 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpBcy-000Lt7-1W for namedroppers-data@psg.com; Mon, 05 Nov 2007 23:45:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-101.4 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_DHCP,RDNS_NONE,USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [82.93.240.211] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpBcO-000LpF-Vq for namedroppers@ops.ietf.org; Mon, 05 Nov 2007 23:44:50 +0000 Received: from outpost.ds9a.nl ([213.244.168.210] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1IpBcM-00060C-0M for namedroppers@ops.ietf.org; Tue, 06 Nov 2007 00:44:30 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id CBC4D3FBF; Tue, 6 Nov 2007 00:44:29 +0100 (CET) Date: Tue, 6 Nov 2007 00:44:29 +0100 From: bert hubert To: Mark Andrews Cc: Dean Anderson , "Olaf M. Kolkman" , Samuel Weiler , namedroppers@ops.ietf.org, iesg@ietf.org Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) Message-ID: <20071105234429.GL26874@outpost.ds9a.nl> References: <200711052316.lA5NG9DY068451@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200711052316.lA5NG9DY068451@drugs.dv.isc.org> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Tue, Nov 06, 2007 at 10:16:09AM +1100, Mark Andrews wrote: > at a later stage as was should this become part of DNSSEC. > > I think there is consensus that NSEC3 is technically possible. As a slight dissent, I'd like to state NSEC3 would be the most complex protocol element of any protocol I've ever implemented. Or ever seen, for that matter. So practically, I think it is slightly over the edge of what is technically possible - even though it might very well be sound in theory. Given the smarts of the people working on speccing it out, this is probable. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 05 19:05:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpBwZ-0000Pu-3Y; Mon, 05 Nov 2007 19:05:23 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpBwW-0000N0-Nb; Mon, 05 Nov 2007 19:05:23 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpBrq-000MzN-Nl for namedroppers-data@psg.com; Tue, 06 Nov 2007 00:00:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [216.168.239.74] (helo=peregrine.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpBra-000Mwl-8O for namedroppers@ops.ietf.org; Tue, 06 Nov 2007 00:00:20 +0000 Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id lA5NqVD2005400; Mon, 5 Nov 2007 18:52:31 -0500 Received: from dul1wnexmb02.vcorp.ad.vrsn.com ([10.170.12.135]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Nov 2007 18:58:35 -0500 Received: from dul1mcdblacka-l1.local ([10.131.29.169]) by dul1wnexmb02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Nov 2007 18:58:34 -0500 Message-ID: <472FAF08.8060209@verisign.com> Date: Mon, 05 Nov 2007 19:02:16 -0500 From: "Blacka, David" Organization: VeriSign, Inc. User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: bert hubert CC: Mark Andrews , Dean Anderson , "Olaf M. Kolkman" , Samuel Weiler , namedroppers@ops.ietf.org, iesg@ietf.org Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) References: <200711052316.lA5NG9DY068451@drugs.dv.isc.org> <20071105234429.GL26874@outpost.ds9a.nl> In-Reply-To: <20071105234429.GL26874@outpost.ds9a.nl> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030705000605020400090808" X-OriginalArrivalTime: 05 Nov 2007 23:58:34.0649 (UTC) FILETIME=[C6753890:01C82007] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c This is a cryptographically signed message in MIME format. --------------ms030705000605020400090808 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit bert hubert wrote: > On Tue, Nov 06, 2007 at 10:16:09AM +1100, Mark Andrews wrote: >> at a later stage as was should this become part of DNSSEC. >> >> I think there is consensus that NSEC3 is technically possible. > > As a slight dissent, I'd like to state NSEC3 would be the most complex > protocol element of any protocol I've ever implemented. Or ever seen, for > that matter. > > So practically, I think it is slightly over the edge of what is technically > possible - even though it might very well be sound in theory. Given the > smarts of the people working on speccing it out, this is probable. Given that at least three implementers that I know of have implemented it and had the implementations interoperate, I think that it is clear that is technically possible. -- David Blacka Sr. Engineer VeriSign Infrastructure Product Engineering --------------ms030705000605020400090808 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPojCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykg MTk5OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1 OVowga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFz cyAyIFBlcnNvbm5lbCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oG LvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4V VzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaK FGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhCAQEEBAMCAQYwDwYDVR0TBAgwBgEB /wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAqMCgGCCsGAQUF BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0 dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3DQEBBQUAA4GBAFJe tpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9juNLLt+cG+6O 51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wazfVHbSxz E2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTANBgkq hkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlT aWduIENsYXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1 OVowgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFz cyAyIEVtcGxveWVlIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANV awg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufct fGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFj CCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8E BAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVy aXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUFAAOBgQA2GP0zYNYX0wS1 2FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVwWk4oHd33wYhOG4dX Aj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb6NDbif1JwnUE A5el1JaB2CNB8DCCBBYwggN/oAMCAQICECsUEtKYtH+GOnwD9TrUy/0wDQYJKoZIhvcNAQEE BQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFz cyAyIEVtcGxveWVlIENBMB4XDTA3MDMyODAwMDAwMFoXDTA4MDMyNzIzNTk1OVowajERMA8G A1UEChMIVkVSSVNJR04xEDAOBgNVBAsTB1ZBLUVBU1QxEzARBgNVBAMTClJlY2lwaWVudHMx LjAsBgNVBAMTJWRhdmlkYiAoQmxhY2thIERhdmlkLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAOdIMJv8eXZfXcOe4nL+d6kvaSZdXCYyXn+0dp8O+C7w 6/WlLoR4I2jd8Qa2C9+G8wjfLV3BX8HqZ/TQP8TQHP16HxOc46930G+izuJJ+K80R7ANcGC3 ccU4sM4KNWGAM9vzdnnkRGrOJdt+X4JNmoTLw0lCh7SKUtHJjO/a2C6VAgMBAAGjggF4MIIB dDAJBgNVHRMEAjAAMFkGA1UdHwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNp Z24uY29tL1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNV HQ8EBAMCBaAwHgYDVR0RBBcwFYETZGF2aWRiQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGh MIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWdu J3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24w EQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkq hkiG9w0BAQQFAAOBgQBxY9XyK49IilNbH/gnV5wVylpyf5iqU+snpdgvGq1SC/ORihQmXlcT ppYJbCxgS/Q6utrKkWIFK45pwbWKzIFLt59KqdODnoJYYBFkpVi86ai43AAsJ2GQ7Snqs0Dm vzMiFEkXJXNdGV7t69LuI6xCoNTXGJQAE6hq135KCB/JxDCCBBYwggN/oAMCAQICECsUEtKY tH+GOnwD9TrUy/0wDQYJKoZIhvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3Vi amVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5 MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMB4XDTA3MDMyODAwMDAw MFoXDTA4MDMyNzIzNTk1OVowajERMA8GA1UEChMIVkVSSVNJR04xEDAOBgNVBAsTB1ZBLUVB U1QxEzARBgNVBAMTClJlY2lwaWVudHMxLjAsBgNVBAMTJWRhdmlkYiAoQmxhY2thIERhdmlk LCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOdIMJv8eXZf XcOe4nL+d6kvaSZdXCYyXn+0dp8O+C7w6/WlLoR4I2jd8Qa2C9+G8wjfLV3BX8HqZ/TQP8TQ HP16HxOc46930G+izuJJ+K80R7ANcGC3ccU4sM4KNWGAM9vzdnnkRGrOJdt+X4JNmoTLw0lC h7SKUtHJjO/a2C6VAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1UdHwRSMFAwTqBMoEqG SGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBs b3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETZGF2aWRiQHZl cmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxp YWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQG CCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQBxY9XyK49IilNbH/gnV5wV ylpyf5iqU+snpdgvGq1SC/ORihQmXlcTppYJbCxgS/Q6utrKkWIFK45pwbWKzIFLt59KqdOD noJYYBFkpVi86ai43AAsJ2GQ7Snqs0DmvzMiFEkXJXNdGV7t69LuI6xCoNTXGJQAE6hq135K CB/JxDGCA8kwggPFAgEBMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UE AxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQKxQS0pi0f4Y6fAP1OtTL/TAJBgUr DgMCGgUAoIICXTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NzExMDYwMDAyMTZaMCMGCSqGSIb3DQEJBDEWBBQYNS7TWELrD7iFmWx3uG4OkC9e8DBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJ MEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNp Z24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3ll ZSBDQQIQKxQS0pi0f4Y6fAP1OtTL/TCB1AYLKoZIhvcNAQkQAgsxgcSggcEwgawxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVl IENBAhArFBLSmLR/hjp8A/U61Mv9MA0GCSqGSIb3DQEBAQUABIGAiubHYs3PJvkL87hujBqN UMKnPIMke8fx7q0EXAuiWKbG7LiFZZ2CVdTww5m5kPxMuMnW92OYE6yAk6mAhDPvekoE89QL fx8ZGb+RH5Y4Swd4CBovCW1SfKBqq1H+R0bXJu2PJVwMQjkkhZNm/juwVqYD9B6WwOas+wJa 7HX6BrMAAAAAAAA= --------------ms030705000605020400090808-- -- to unsubscribe send a message to namedroppers-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 Nov 05 19:59:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpCmY-0008MX-RB; Mon, 05 Nov 2007 19:59:06 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpCmW-0001CU-6r; Mon, 05 Nov 2007 19:59:06 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpCg2-00041z-9F for namedroppers-data@psg.com; Tue, 06 Nov 2007 00:52:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpCfV-00040I-1B for namedroppers@ops.ietf.org; Tue, 06 Nov 2007 00:52:05 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id lA60os6h008487 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 5 Nov 2007 19:51:10 -0500 Date: Mon, 5 Nov 2007 19:50:54 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Mark Andrews cc: "Olaf M. Kolkman" , Samuel Weiler , , Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) In-Reply-To: <200711052316.lA5NG9DY068451@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b On Tue, 6 Nov 2007, Mark Andrews wrote: > NSEC3 is not about "Database Copyright". It's about restoring > properties that were lost with the introduction of DNSSEC. It is indeed about database copyright. As Olaf wrote: > When DNSSECbis was being (or about to be) last called several > registries stepped up and argued that they could not deploy DNSSECbis > given the ease of zone enumeration. One example of such argument is in > http://www.ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00685.html In that messages, they wrote: ======================= begin block quote However, for those of you that have asked, this is the gist of our legal advice... As compilations, zone file databases are protected under EU law by ?Database Right?. As a derivative work of the main register from which they are sourced, they are likely also to attract copyright protection in addition to or in place of database right. Both database right and copyright are negative rights in that they prohibit certain acts (primarily, copying the whole or a substantial part of the materials) but do not grant positive rights (unlike, for example, a patent, which grants a monopoly on the material involved). Database right is unique to countries which implement European Community law, but copyright is more universal. ======================= end block quote So the problem and premise is database copyright. As the draft-12 states in Section 1: An enumerated zone can be used, for example, as a source of probable e-mail addresses for spam, or as a key for multiple WHOIS queries to reveal registrant data which many registries may have legal obligations to protect. Many registries therefore prohibit copying of their zone data; however, the use of NSEC RRs renders these policies unenforceable. There are no _obligations_ to protect this data. The data is public. This is just about Registries trying to use database copyright to assert ownership over public information, and their effort to obtain technical methods to enforce their dubious legal assertions. Their interests are contrary to the interests of the internet community, and in particular the ISOC, in preserving public access to public information. The ISOC has a duty to the public trust to preserve public access to this information. On Tue, 6 Nov 2007, Mark Andrews wrote: > I think there is consensus that NSEC3 is technically possible. On Mon, 5 Nov 2007, Blacka, David wrote: > Given that at least three implementers that I know of have implemented > it and had the implementations interoperate, I think that it is clear > that is technically possible. I don't know about 3 implementers, but I agree that I _expect_ it should be possible to fix the technical problems identified. However, those problems are not fixed in this draft (12). Draft -12 still has serious technical problems. --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 Mon Nov 05 21:07:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpDql-0006fm-A9; Mon, 05 Nov 2007 21:07:31 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpDqh-00037U-Id; Mon, 05 Nov 2007 21:07:31 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpDjY-0008e0-4a for namedroppers-data@psg.com; Tue, 06 Nov 2007 02:00:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [204.152.184.167] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpDix-0008ZO-WB for namedroppers@ops.ietf.org; Tue, 06 Nov 2007 01:59:45 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id E694C11401C for ; Tue, 6 Nov 2007 01:59:22 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id A8DF2E6058 for ; Tue, 6 Nov 2007 01:59:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id lA61wwxc000584; Tue, 6 Nov 2007 12:58:58 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200711060158.lA61wwxc000584@drugs.dv.isc.org> To: Dean Anderson Cc: "Olaf M. Kolkman" , Samuel Weiler , namedroppers@ops.ietf.org, iesg@ietf.org Reply-to: namedroppers@ops.ietf.org, iesg@ietf.org Mail-followup-to: namedroppers@ops.ietf.org, iesg@ietf.org From: Mark Andrews Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) In-reply-to: Your message of "Mon, 05 Nov 2007 19:50:54 CDT." Date: Tue, 06 Nov 2007 12:58:58 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be > On Tue, 6 Nov 2007, Mark Andrews wrote: > > NSEC3 is not about "Database Copyright". It's about restoring > > properties that were lost with the introduction of DNSSEC. > > It is indeed about database copyright. As Olaf wrote: > > When DNSSECbis was being (or about to be) last called several > > registries stepped up and argued that they could not deploy DNSSECbis > > given the ease of zone enumeration. One example of such argument is in > > http://www.ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00685.html There were also arguements about the lost properties. If memory serves me Dan made such a arguement. Guess which one persuaded me to not complain about doing NSEC3. Olaf cannot know which arguement(s) caused people to make the decisions they did unless he went and asked them or they volunteered the information. He can only know what the result was. I know, I completely, dismissed the whois arguement for NSEC3. The need to do something stood on its own merits even after dismissing those arguements. > So the problem and premise is database copyright. > > As the draft-12 states in Section 1: > > An enumerated zone can be used, for example, as a source of probable > e-mail addresses for spam, or as a key for multiple WHOIS queries to > reveal registrant data which many registries may have legal > obligations to protect. Many registries therefore prohibit copying > of their zone data; however, the use of NSEC RRs renders these > policies unenforceable. So what. It's one of many rationals for NSEC3. IT IS NOT THE ONLY ONE. > There are no _obligations_ to protect this data. The data is public. > This is just about Registries trying to use database copyright to assert > ownership over public information, and their effort to obtain technical > methods to enforce their dubious legal assertions. Their interests are > contrary to the interests of the internet community, and in particular > the ISOC, in preserving public access to public information. The ISOC > has a duty to the public trust to preserve public access to this > information. > > > > > On Tue, 6 Nov 2007, Mark Andrews wrote: > > I think there is consensus that NSEC3 is technically possible. > > On Mon, 5 Nov 2007, Blacka, David wrote: > > > Given that at least three implementers that I know of have implemented > > it and had the implementations interoperate, I think that it is clear > > that is technically possible. > > I don't know about 3 implementers, but I agree that I _expect_ it should > be possible to fix the technical problems identified. However, those > problems are not fixed in this draft (12). Draft -12 still has serious > technical problems. Please point out the technical problems. Arguements about rational or procedual issues arn't productive and will cause any technical problems to be missed. Mark > --Dean > > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 05 23:42:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpGGf-0004GK-MS; Mon, 05 Nov 2007 23:42:25 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpGGc-0006XT-Sh; Mon, 05 Nov 2007 23:42:25 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpGAK-000JCE-93 for namedroppers-data@psg.com; Tue, 06 Nov 2007 04:35:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpG9l-000J9y-Fr for namedroppers@ops.ietf.org; Tue, 06 Nov 2007 04:35:34 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id lA64YsKS008702 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 5 Nov 2007 23:34:54 -0500 Date: Mon, 5 Nov 2007 23:34:53 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: namedroppers@ops.ietf.org, cc: "Olaf M. Kolkman" , Samuel Weiler Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) In-Reply-To: <200711060158.lA61wwxc000584@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 On Tue, 6 Nov 2007, Mark Andrews wrote: > There were also arguements about the lost properties. If > memory serves me Dan made such a arguement. Guess which > one persuaded me to not complain about doing NSEC3. The "lost properties" weren't lost, because they didn't exist previously. You have to have something before you can lose it. As RFC3833 states, those properties aren't suitable goals for DNSSEC. The "lost properties" arguments are just a weak attempts to couch the database copyright issue in more obscure, more palatable, technical terms. But it is easy to see through those efforts. > > I don't know about 3 implementers, but I agree that I _expect_ it should > > be possible to fix the technical problems identified. However, those > > problems are not fixed in this draft (12). Draft -12 still has serious > > technical problems. > > Please point out the technical problems. Arguements about > rational or procedual issues arn't productive and will > cause any technical problems to be missed. This has already been done by others. The problem, as I understand it, is that the present draft steers into a corner with SHA-1 hash, and the hash cannot be replaced securely. This technical problem is probably hard (like rekeying), but should be surmountable. But it is not worth the effort since we know now the effects of this technology contradict IETF policy and public interest. But I do think that arguments about policy and procedural issues are relevant to the last call, as Olaf noted in agreement. I think this draft cannot pass now for technical reasons and cannot ever pass for policy reasons. --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 Nov 06 02:06:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpIVj-0004BH-7v; Tue, 06 Nov 2007 02:06:07 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpIVf-0001L6-KC; Tue, 06 Nov 2007 02:06:07 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpINr-0001PO-4W for namedroppers-data@psg.com; Tue, 06 Nov 2007 06:57:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-101.4 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_DHCP,RDNS_NONE,USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [82.93.240.211] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpINI-0001My-0u for namedroppers@ops.ietf.org; Tue, 06 Nov 2007 06:57:41 +0000 Received: from outpost.ds9a.nl ([213.244.168.210] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1IpINC-0002mj-Ow for namedroppers@ops.ietf.org; Tue, 06 Nov 2007 07:57:18 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 599E2402C; Tue, 6 Nov 2007 07:57:18 +0100 (CET) Date: Tue, 6 Nov 2007 07:57:18 +0100 From: bert hubert To: "Blacka, David" Cc: Mark Andrews , Dean Anderson , "Olaf M. Kolkman" , Samuel Weiler , namedroppers@ops.ietf.org, iesg@ietf.org Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) Message-ID: <20071106065718.GA25177@outpost.ds9a.nl> References: <200711052316.lA5NG9DY068451@drugs.dv.isc.org> <20071105234429.GL26874@outpost.ds9a.nl> <472FAF08.8060209@verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <472FAF08.8060209@verisign.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On Mon, Nov 05, 2007 at 07:02:16PM -0500, Blacka, David wrote: > > So practically, I think it is slightly over the edge of what is technically > > possible - even though it might very well be sound in theory. Given the > > smarts of the people working on speccing it out, this is probable. > > Given that at least three implementers that I know of have implemented > it and had the implementations interoperate, I think that it is clear > that is technically possible. Yes - but already we find that more needs to be done, hence the current discussions on NSECPARAM, NSEC++ etc. That an implementation can claim to support X does not mean X is actually technically possible or likely to be done well. Perhaps I'm raising the bar here, but we're holding out for good implementations. And given the length and complication of NSEC3/++/PARAM, that might in practice be very hard. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 06 03:16:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpJbr-0007KH-Et; Tue, 06 Nov 2007 03:16:31 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpJbo-0002gr-Us; Tue, 06 Nov 2007 03:16:31 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpJWJ-0005y0-Jy for namedroppers-data@psg.com; Tue, 06 Nov 2007 08:10:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [213.154.224.48] (helo=bert.secret-wg.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpJVk-0005u2-32 for namedroppers@ops.ietf.org; Tue, 06 Nov 2007 08:10:29 +0000 Received: from Miffy.lan (a62-251-91-215.adsl.xs4all.nl [62.251.91.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bert.secret-wg.org (Postfix) with ESMTPSA id 23ED2B899; Tue, 6 Nov 2007 09:10:10 +0100 (CET) Cc: Samuel Weiler , , Message-Id: <8C283598-0EE4-4903-B156-BB5C353778BF@NLnetLabs.nl> From: "Olaf M. Kolkman" 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 v912) Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) Date: Tue, 6 Nov 2007 09:10:08 +0100 References: X-Mailer: Apple Mail (2.912) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 On 5Nov 2007, at 10:49 PM, Dean Anderson wrote: > > I reviewed these charters: > > Oct 6, 2003 The IESG WG Action: RECHARTER: DNS Extensions (dnsext) > Jan 29, 2004 The IESG WG Action: RECHARTER: DNS Extensions (dnsext) > Feb 9, 2005 The IESG WG Action: RECHARTER: DNS Extensions (dnsext) > > I did not find anything that would put NSEC on the agenda, nor > anything > that specifically reversed RFC3833, nor anything that would have > asserted that the DNSEXT WG would or should assist with Database > Copyright. Nor is there any obligation to assert Database Copyright, > as > the draft introduction claims. I appear to have been misled. In the charter the work item as been phrased as: o Identify (a) method(s) to prevent the possibility of trivial zone enumeration. The Working group approached this in two ways, one documented in RFC4470/4471, which requires on-line keys and on-the fly calculations of signatures, the other being NSEC3, allowing for off-line calculation of the data needed for authenticated denial of existence. --Olaf -Olaf --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ -- to unsubscribe send a message to namedroppers-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 Nov 06 03:22:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpJhD-0004UQ-QK; Tue, 06 Nov 2007 03:22:03 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpJhA-0002w5-DL; Tue, 06 Nov 2007 03:22:03 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpJcg-0006Sb-QU for namedroppers-data@psg.com; Tue, 06 Nov 2007 08:17:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [213.154.224.48] (helo=bert.secret-wg.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpJc7-0006PY-M2 for namedroppers@ops.ietf.org; Tue, 06 Nov 2007 08:17:05 +0000 Received: from Miffy.lan (a62-251-91-215.adsl.xs4all.nl [62.251.91.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bert.secret-wg.org (Postfix) with ESMTPSA id DA813B8A5; Tue, 6 Nov 2007 09:16:45 +0100 (CET) Cc: "Blacka, David" , Mark Andrews , Dean Anderson , Samuel Weiler , namedroppers@ops.ietf.org, iesg@ietf.org Message-Id: <39C3CCD5-F560-4BB0-A5A6-2A502CF3192A@NLnetLabs.nl> From: "Olaf M. Kolkman" To: bert hubert In-Reply-To: <20071106065718.GA25177@outpost.ds9a.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) Date: Tue, 6 Nov 2007 09:16:44 +0100 References: <200711052316.lA5NG9DY068451@drugs.dv.isc.org> <20071105234429.GL26874@outpost.ds9a.nl> <472FAF08.8060209@verisign.com> <20071106065718.GA25177@outpost.ds9a.nl> X-Mailer: Apple Mail (2.912) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 On 6Nov 2007, at 7:57 AM, bert hubert wrote: > On Mon, Nov 05, 2007 at 07:02:16PM -0500, Blacka, David wrote: >>> So practically, I think it is slightly over the edge of what is >>> technically >>> possible - even though it might very well be sound in theory. >>> Given the >>> smarts of the people working on speccing it out, this is probable. >> >> Given that at least three implementers that I know of have >> implemented >> it and had the implementations interoperate, I think that it is clear >> that is technically possible. > > Yes - but already we find that more needs to be done, hence the > current > discussions on NSECPARAM, NSEC++ etc. Well NSECPARAM is part of the specification. The only thing that needs to be documented better, based on IESG feedback, is the algorithm agility. That is not a major tweak in the algorithm but a description of an operational practice. > That an implementation can claim to > support X does not mean X is actually technically possible or likely > to be > done well. That is why we have a staged standards track and allow for time to mature. And also 'rough consensus and running code'; in contrast to other protocols developed in DNSEXT, there is running code, by multiple implementors. And at least rough consensus in the WG. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ -- to unsubscribe send a message to namedroppers-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 Nov 06 05:29:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpLgX-0002WL-7K; Tue, 06 Nov 2007 05:29:29 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpLgT-0006ST-JP; Tue, 06 Nov 2007 05:29:29 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpLWK-000FN2-Qq for namedroppers-data@psg.com; Tue, 06 Nov 2007 10:18:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [204.152.184.167] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpLVT-000FKD-IV for namedroppers@ops.ietf.org; Tue, 06 Nov 2007 10:18:23 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id 8ED6C11401E for ; Tue, 6 Nov 2007 10:18:02 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id 847E5E6058 for ; Tue, 6 Nov 2007 10:18:02 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id lA6AHrN4064781; Tue, 6 Nov 2007 21:17:55 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200711061017.lA6AHrN4064781@drugs.dv.isc.org> To: namedroppers@ops.ietf.org, iesg@ietf.org From: Mark Andrews Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) In-reply-to: Your message of "Mon, 05 Nov 2007 23:34:53 CDT." Date: Tue, 06 Nov 2007 21:17:53 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 > > On Tue, 6 Nov 2007, Mark Andrews wrote: > > > There were also arguements about the lost properties. If > > memory serves me Dan made such a arguement. Guess which > > one persuaded me to not complain about doing NSEC3. > > The "lost properties" weren't lost, because they didn't exist > previously. You have to have something before you can lose it. As > RFC3833 states, those properties aren't suitable goals for DNSSEC. The > "lost properties" arguments are just a weak attempts to couch the > database copyright issue in more obscure, more palatable, technical > terms. But it is easy to see through those efforts. Where does NSEC3 fail to meet the requrements of RFC3833? The fact that it provides *more* doesn't preclude it from being accepted into DNSSEC. NSEC3 meets the requirements of RFC3822 2.6. Authenticated Denial of Domain Names. It can prove the existance / non existance of a name. NSEC allows enumeration which is not a requirement. NSEC3 denies enumentation which, again, is not a requirement. > > > I don't know about 3 implementers, but I agree that I _expect_ it should > > > be possible to fix the technical problems identified. However, those > > > problems are not fixed in this draft (12). Draft -12 still has serious > > > technical problems. > > > > Please point out the technical problems. Arguements about > > rational or procedual issues arn't productive and will > > cause any technical problems to be missed. > > This has already been done by others. The problem, as I understand it, > is that the present draft steers into a corner with SHA-1 hash, and the > hash cannot be replaced securely. This technical problem is probably > hard (like rekeying), but should be surmountable. But it is not worth > the effort since we know now the effects of this technology contradict > IETF policy and public interest. > > But I do think that arguments about policy and procedural issues are > relevant to the last call, as Olaf noted in agreement. > > I think this draft cannot pass now for technical reasons and cannot ever > pass for policy reasons. > > --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: -- 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 Nov 06 10:33:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpQR6-0003Ou-EI; Tue, 06 Nov 2007 10:33:52 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpQR2-0007Cw-JS; Tue, 06 Nov 2007 10:33:52 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpQJ1-000CiI-IU for namedroppers-data@psg.com; Tue, 06 Nov 2007 15:25:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.168.239.75] (helo=osprey.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpQIq-000CgW-KD for namedroppers@ops.ietf.org; Tue, 06 Nov 2007 15:25:26 +0000 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id lA6FIu61002611; Tue, 6 Nov 2007 10:18:56 -0500 Received: from dul1wnexmb02.vcorp.ad.vrsn.com ([10.170.12.135]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 15:24:38 +0000 Received: from dul1mcdblacka-l1.local ([10.131.29.169]) by dul1wnexmb02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 10:24:38 -0500 Message-ID: <47308830.6010402@verisign.com> Date: Tue, 06 Nov 2007 10:28:48 -0500 From: "Blacka, David" Organization: VeriSign, Inc. User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Michael StJohns CC: Sam Weiler , namedroppers@ops.ietf.org Subject: Re: RSA/SHA256 References: <471FB97B.9000108@NLnetLabs.nl> <200711012340.lA1Ned6I017634@nutshell.tislabs.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030401040300020904000103" X-OriginalArrivalTime: 06 Nov 2007 15:24:38.0487 (UTC) FILETIME=[25160E70:01C82089] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 This is a cryptographically signed message in MIME format. --------------ms030401040300020904000103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Michael StJohns wrote: > Why would changing the DNSKEY algorithm field from a signature > algorithm to a key type and as a consequence allow one DNSKEY to be > used in multiple signature algorithms allow a downgrade attack? > What is this downgrade attack? So the particular downgrade attack here is the ability for an attacker to downgrade a zone from SECURE to INSECURE by replacing RRSIGs. The executive summary here is that by separating the DNSKEY algorithm from the RRSIG algorithm, you break the chain of trust. On the surface, separating the registries creates situations that look analogous to the use of private algorithms today. However, there is an important difference. Let's go over how a validator follows a chain of trust across a zone boundary. 1) The validator sees a DS RRset. It validates that RRset using a key that it trusts. So far, this is very standard and normal. 2) If, by looking at this DS RRset the validator determines that it doesn't recognize any of the DNSKEY algorithms present, it can stop right there and declare the zone INSECURE. Still, pretty normal. 3) However, looking at the DNSKEY algorithm in the DS records can be ambiguous. The current example of this is when private algorithms are in use. However, if we adopt your separate registries proposal, it will always be true. If the case is ambiguous, the validator delays the decision. 4) The zone's DNSKEY RRset is fetched and a DS record is matched to a DNSKEY. At this point, the validator trusts the matching DNSKEY. In the private algorithm case, at this point the validator can determine what the algorithm actually is and, if it is unrecognized, declare the zone INSECURE. In your case, however, it can't. It only knows that the DNSKEY is "RSA" (e.g.) and not that the zone is signed with a hash the validator supports. At this point, in the current standard, the validator knows definitively (and securely) whether the zone is able to be validated. In your proposal, it does not. Under your proposal, the next step would have to be for the validator to find the signature by the (now trusted) DNSKEY and check the signature algorithm. Unfortunately, if that RRSIG uses an algorithm that the validator doesn't understand, it can't tell if the RRSIG is valid or not. That is, it is unable to determine securely whether or not it should treat the zone as INSECURE or not. So, that leads to the downgrade attack. The attacker simply replaces the DNSKEY RRset RRSIGs with ones of his own devising that use some unknown algorithm number, thus causing the zone to be downgraded. The key to this is that currently, DNSSEC *relies* on the fact that a validator can tell if it can validate something by simply looking at the DNSKEY. If it can't, the the DS -> DNSKEY traversal doesn't work. -- David Blacka Sr. Engineer VeriSign Infrastructure Product Engineering --------------ms030401040300020904000103 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPojCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykg MTk5OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1 OVowga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFz cyAyIFBlcnNvbm5lbCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oG LvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4V VzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaK FGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhCAQEEBAMCAQYwDwYDVR0TBAgwBgEB /wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAqMCgGCCsGAQUF BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0 dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3DQEBBQUAA4GBAFJe tpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9juNLLt+cG+6O 51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wazfVHbSxz E2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTANBgkq hkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlT aWduIENsYXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1 OVowgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFz cyAyIEVtcGxveWVlIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANV awg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufct fGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFj CCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8E BAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVy aXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUFAAOBgQA2GP0zYNYX0wS1 2FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVwWk4oHd33wYhOG4dX Aj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb6NDbif1JwnUE A5el1JaB2CNB8DCCBBYwggN/oAMCAQICECsUEtKYtH+GOnwD9TrUy/0wDQYJKoZIhvcNAQEE BQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFz cyAyIEVtcGxveWVlIENBMB4XDTA3MDMyODAwMDAwMFoXDTA4MDMyNzIzNTk1OVowajERMA8G A1UEChMIVkVSSVNJR04xEDAOBgNVBAsTB1ZBLUVBU1QxEzARBgNVBAMTClJlY2lwaWVudHMx LjAsBgNVBAMTJWRhdmlkYiAoQmxhY2thIERhdmlkLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAOdIMJv8eXZfXcOe4nL+d6kvaSZdXCYyXn+0dp8O+C7w 6/WlLoR4I2jd8Qa2C9+G8wjfLV3BX8HqZ/TQP8TQHP16HxOc46930G+izuJJ+K80R7ANcGC3 ccU4sM4KNWGAM9vzdnnkRGrOJdt+X4JNmoTLw0lCh7SKUtHJjO/a2C6VAgMBAAGjggF4MIIB dDAJBgNVHRMEAjAAMFkGA1UdHwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNp Z24uY29tL1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNV HQ8EBAMCBaAwHgYDVR0RBBcwFYETZGF2aWRiQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGh MIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWdu J3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24w EQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkq hkiG9w0BAQQFAAOBgQBxY9XyK49IilNbH/gnV5wVylpyf5iqU+snpdgvGq1SC/ORihQmXlcT ppYJbCxgS/Q6utrKkWIFK45pwbWKzIFLt59KqdODnoJYYBFkpVi86ai43AAsJ2GQ7Snqs0Dm vzMiFEkXJXNdGV7t69LuI6xCoNTXGJQAE6hq135KCB/JxDCCBBYwggN/oAMCAQICECsUEtKY tH+GOnwD9TrUy/0wDQYJKoZIhvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3Vi amVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5 MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMB4XDTA3MDMyODAwMDAw MFoXDTA4MDMyNzIzNTk1OVowajERMA8GA1UEChMIVkVSSVNJR04xEDAOBgNVBAsTB1ZBLUVB U1QxEzARBgNVBAMTClJlY2lwaWVudHMxLjAsBgNVBAMTJWRhdmlkYiAoQmxhY2thIERhdmlk LCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOdIMJv8eXZf XcOe4nL+d6kvaSZdXCYyXn+0dp8O+C7w6/WlLoR4I2jd8Qa2C9+G8wjfLV3BX8HqZ/TQP8TQ HP16HxOc46930G+izuJJ+K80R7ANcGC3ccU4sM4KNWGAM9vzdnnkRGrOJdt+X4JNmoTLw0lC h7SKUtHJjO/a2C6VAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1UdHwRSMFAwTqBMoEqG SGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBs b3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETZGF2aWRiQHZl cmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxp YWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQG CCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQBxY9XyK49IilNbH/gnV5wV ylpyf5iqU+snpdgvGq1SC/ORihQmXlcTppYJbCxgS/Q6utrKkWIFK45pwbWKzIFLt59KqdOD noJYYBFkpVi86ai43AAsJ2GQ7Snqs0DmvzMiFEkXJXNdGV7t69LuI6xCoNTXGJQAE6hq135K CB/JxDGCA8kwggPFAgEBMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UE AxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQKxQS0pi0f4Y6fAP1OtTL/TAJBgUr DgMCGgUAoIICXTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NzExMDYxNTI4NDhaMCMGCSqGSIb3DQEJBDEWBBSkwmX2R8SZ6VSTMZD24CHVXS+rpDBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJ MEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNp Z24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3ll ZSBDQQIQKxQS0pi0f4Y6fAP1OtTL/TCB1AYLKoZIhvcNAQkQAgsxgcSggcEwgawxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVl IENBAhArFBLSmLR/hjp8A/U61Mv9MA0GCSqGSIb3DQEBAQUABIGAqaaVdOIX+gRpAXYa/AZj FRkKKUQUFkIOEYmK9u8JgsRFPiur1FjcU9uAiQdTPivCkE63VJk8tZFozfXAZwVGADyO5t2N mQ8D/oeJfvWcpcCGQmO3mN4LorLtsZmHU9dkRSvQedONsQp4J2CjR7RBNPXnstK3Z7PJjOn/ a9NQxjoAAAAAAAA= --------------ms030401040300020904000103-- -- to unsubscribe send a message to namedroppers-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 Nov 06 23:33:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpcbP-0001Hh-A4; Tue, 06 Nov 2007 23:33:19 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpcbI-0007T9-LB; Tue, 06 Nov 2007 23:33:19 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpcSF-000DUQ-K6 for namedroppers-data@psg.com; Wed, 07 Nov 2007 04:23:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,MISSING_MID, RDNS_NONE autolearn=no version=3.2.3 Received: from [209.18.121.242] (helo=mailrelay.wirelesslogixgroup.com) by psg.com with esmtps (SSLv3:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpcS4-000DTd-8O for namedroppers@ops.ietf.org; Wed, 07 Nov 2007 04:23:46 +0000 Received: from mikespersonal.comcast.net ([64.221.254.66]) by mailrelay.wirelesslogixgroup.com (V-Link Solutions Inc. Mail Relay Server) with SMTP (SSL) id MPE82838; Tue, 06 Nov 2007 23:23:38 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 06 Nov 2007 23:23:41 -0500 To: "Blacka, David" From: Michael StJohns Subject: Re: RSA/SHA256 Cc: Sam Weiler ,namedroppers@ops.ietf.org In-Reply-To: <47308830.6010402@verisign.com> References: <471FB97B.9000108@NLnetLabs.nl> <200711012340.lA1Ned6I017634@nutshell.tislabs.com> <47308830.6010402@verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Message-Id: X-Spam-Score: -4.0 (----) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Hi David - thanks for this note - its detailed enough that I now understand the concerns. I think the certificate equivalent is that your using the algorithm field of the DNSKEY record sort of like the inner signature algorithm field. At 10:28 11/6/2007, Blacka, David wrote: >Michael StJohns wrote: > >> Why would changing the DNSKEY algorithm field from a signature >> algorithm to a key type and as a consequence allow one DNSKEY to be >> used in multiple signature algorithms allow a downgrade attack? > >> What is this downgrade attack? > >So the particular downgrade attack here is the ability for an attacker >to downgrade a zone from SECURE to INSECURE by replacing RRSIGs. > >The executive summary here is that by separating the DNSKEY algorithm >from the RRSIG algorithm, you break the chain of trust. > >On the surface, separating the registries creates situations that look >analogous to the use of private algorithms today. However, there is an >important difference. Let's go over how a validator follows a chain of >trust across a zone boundary. > >1) The validator sees a DS RRset. It validates that RRset using a key >that it trusts. So far, this is very standard and normal. Right. >2) If, by looking at this DS RRset the validator determines that it >doesn't recognize any of the DNSKEY algorithms present, it can stop >right there and declare the zone INSECURE. Still, pretty normal. Right. See my next comment. I was suggesting changing the meaning of the field in the DNSKEY record. Although 4034 conflates the DS algorithm field with the DNSKEY record field, I don't think that's necessarily required. >3) However, looking at the DNSKEY algorithm in the DS records can be >ambiguous. The current example of this is when private algorithms are >in use. However, if we adopt your separate registries proposal, it will >always be true. If the case is ambiguous, the validator delays the >decision. Actually, why can't the DS record continue to use the signature algorithm as the value of the field? As far is I can tell, you're using the fact of the listing of the set of signature algorithms at the parent (in the DS records) as the indication of the required signature algorithms for the child zone. >4) The zone's DNSKEY RRset is fetched and a DS record is matched to a >DNSKEY. At this point, the validator trusts the matching DNSKEY. In >the private algorithm case, at this point the validator can determine >what the algorithm actually is and, if it is unrecognized, declare the >zone INSECURE. In your case, however, it can't. It only knows that the > DNSKEY is "RSA" (e.g.) and not that the zone is signed with a hash the >validator supports. Currently, you declare the zone insecure after checking the parent set of algorithms in the DS records doesn't contain a known signature algorithm - correct? If the DS does contain a known algorithm, the child zone (and its contents) is bogus if the apex DNSKEY record isn't signed with one of those known algorithms? And this carries forward to all of the records within the zone. So its not actually the presence of the signature algorithm in the apex DNSKEY RRSET that's the problem, but the listing of the algorithm in the parent DS delegation set? And currently, that has to match up with the child DNSKEY rrset. >At this point, in the current standard, the validator knows definitively >(and securely) whether the zone is able to be validated. In your >proposal, it does not. Maybe - see above. I think this works going forward. The DS record lists the signature algorithms - each pointing to a key that can form the algorithm. Deletion of the RRSIG containing that signature algorithm is prevented by the signed indication at the parent. It probably can't be retrofitted to fold in the current RSA/MD5, RSA/SHA1 - old resolvers will barf on the DS/DNSKEY mismatch - but certainly can for resolvers that understand the new algorithms. >Under your proposal, the next step would have to be for the validator to >find the signature by the (now trusted) DNSKEY and check the signature >algorithm. Unfortunately, if that RRSIG uses an algorithm that the >validator doesn't understand, it can't tell if the RRSIG is valid or >not. That is, it is unable to determine securely whether or not it >should treat the zone as INSECURE or not. > >So, that leads to the downgrade attack. The attacker simply replaces >the DNSKEY RRset RRSIGs with ones of his own devising that use some >unknown algorithm number, thus causing the zone to be downgraded. >The key to this is that currently, DNSSEC *relies* on the fact that a >validator can tell if it can validate something by simply looking at the >DNSKEY. If it can't, the the DS -> DNSKEY traversal doesn't work. Yup. But not the only way to accomplish this required signature algorithm signalling. DNSKEYs tend to be fairly large blobs of data - I'd really like not to have to repeat the blob to support multiple signature types. Later, Mike >-- >David Blacka >Sr. Engineer VeriSign Infrastructure Product Engineering > -- to unsubscribe send a message to namedroppers-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 Nov 07 17:15:22 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IptBC-0001Ie-KJ; Wed, 07 Nov 2007 17:15:22 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IptB9-0004ry-Cg; Wed, 07 Nov 2007 17:15:22 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ipt11-0001vH-ME for namedroppers-data@psg.com; Wed, 07 Nov 2007 22:04:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ipt0S-0001su-Pd for namedroppers@ops.ietf.org; Wed, 07 Nov 2007 22:04:34 +0000 Received: from sr22.av8.net (sr22.av8.net [198.3.136.5]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id lA7M3k7l013731 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 7 Nov 2007 17:03:47 -0500 Date: Wed, 7 Nov 2007 17:03:46 -0500 (EST) From: Dean Anderson X-X-Sender: dean@sr22.av8.net To: Mark Andrews cc: namedroppers@ops.ietf.org, Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) In-Reply-To: <200711061017.lA6AHrN4064781@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 On Tue, 6 Nov 2007, Mark Andrews wrote: > > Where does NSEC3 fail to meet the requrements of RFC3833? RFC 3833 Section 1: - While some participants in the meeting were interested in protecting against disclosure of DNS data to unauthorized parties, the design team made an explicit decision that "DNS data is `public'", and ruled all threats of data disclosure explicitly out of scope for DNSSEC. I cited this previously, in some more detail. > The fact that it provides *more* doesn't preclude it from > being accepted into DNSSEC. Actually, I think it does in this case because the "more" part violates the policy and interests of the internet community and promotes the technical implementation of a database copyright on public information. > NSEC3 meets the requirements of RFC3822 2.6. Authenticated > Denial of Domain Names. Authenticated NXDOMAIN already meets this requirement. NSEC/NSEC3 appears to be an end-run around RFC3833 Section 1. --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 Nov 07 17:31:51 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IptR9-0005d1-35; Wed, 07 Nov 2007 17:31:51 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IptR7-0005Ig-Ip; Wed, 07 Nov 2007 17:31:51 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IptKr-0003QE-Sv for namedroppers-data@psg.com; Wed, 07 Nov 2007 22:25:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [204.152.184.167] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IptK9-0003L8-Aj for namedroppers@ops.ietf.org; Wed, 07 Nov 2007 22:25:04 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id 51C4611401F for ; Wed, 7 Nov 2007 22:24:36 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id 6C779E6056 for ; Wed, 7 Nov 2007 22:24:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id lA7MOOMG036302; Thu, 8 Nov 2007 09:24:24 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200711072224.lA7MOOMG036302@drugs.dv.isc.org> To: Dean Anderson Cc: namedroppers@ops.ietf.org, iesg@ietf.org From: Mark Andrews Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) In-reply-to: Your message of "Wed, 07 Nov 2007 17:03:46 CDT." Date: Thu, 08 Nov 2007 09:24:24 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 > On Tue, 6 Nov 2007, Mark Andrews wrote: > > > > Where does NSEC3 fail to meet the requrements of RFC3833? > > RFC 3833 Section 1: > > - While some participants in the meeting were interested in > protecting against disclosure of DNS data to unauthorized parties, > the design team made an explicit decision that "DNS data is > `public'", and ruled all threats of data disclosure explicitly out > of scope for DNSSEC. This is a "don't allow the data to be encrypted" clause. The data is still sent in the plain. > I cited this previously, in some more detail. > > > The fact that it provides *more* doesn't preclude it from > > being accepted into DNSSEC. > > Actually, I think it does in this case because the "more" part violates > the policy and interests of the internet community and promotes the > technical implementation of a database copyright on public information. > > > NSEC3 meets the requirements of RFC3822 2.6. Authenticated > > Denial of Domain Names. > > Authenticated NXDOMAIN already meets this requirement. > > NSEC/NSEC3 appears to be an end-run around RFC3833 Section 1. > --Dean > > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 > > -- 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 Nov 09 10:30:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqVoE-0007gG-84; Fri, 09 Nov 2007 10:30:14 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqVoA-0001EI-L4; Fri, 09 Nov 2007 10:30:14 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IqVav-0004vB-8S for namedroppers-data@psg.com; Fri, 09 Nov 2007 15:16:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-100.8 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM, RDNS_NONE,USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IqVaL-0004n1-Pf for namedroppers@ops.ietf.org; Fri, 09 Nov 2007 15:16:11 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id lA9FEY9r086588 for ; Fri, 9 Nov 2007 10:14:34 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id lA9FEXvi086587 for namedroppers@ops.ietf.org; Fri, 9 Nov 2007 10:14:33 -0500 (EST) (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.68 (FreeBSD)) (envelope-from ) id 1IqLbS-000KEz-PO for namedroppers@ops.ietf.org; Fri, 09 Nov 2007 04:36:40 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id lA94a6S4015771 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 8 Nov 2007 23:36:06 -0500 Date: Thu, 8 Nov 2007 23:36:05 -0500 (EST) From: Dean Anderson To: Mark Andrews cc: namedroppers@ops.ietf.org, Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) In-Reply-To: <200711072224.lA7MOOMG036302@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 [ 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, 8 Nov 2007, Mark Andrews wrote: > > RFC 3833 Section 1: > > > > - While some participants in the meeting were interested in > > protecting against disclosure of DNS data to unauthorized parties, > > the design team made an explicit decision that "DNS data is > > `public'", and ruled all threats of data disclosure explicitly out > > of scope for DNSSEC. > > This is a "don't allow the data to be encrypted" clause. > The data is still sent in the plain. The RFC3833 text above is plain. There are three elements: 1) Protecting against disclosure of DNS data was discussed. 2) Explicit decision: "DNS data is `public'" 3) Threats of data disclosure explicitly out of scope. NSEC3 is meant to protect against disclosure of DNS data (a topic discussed). The NSEC3 draft was designed with the purpose of altering the public nature of DNS data in order to enforce an improper database copyright, contrary to the explicit decision cited. And NSEC3 addresses a problem (data disclosure) that is explicitly out of scope for DNSSEC. --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 Nov 09 11:59:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqXD1-0007Ti-Oc; Fri, 09 Nov 2007 11:59:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqXCz-0005Aw-1n; Fri, 09 Nov 2007 11:59:55 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IqX6P-00098y-9G for namedroppers-data@psg.com; Fri, 09 Nov 2007 16:53:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [213.154.224.48] (helo=bert.secret-wg.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IqX5q-00094v-5g for namedroppers@ops.ietf.org; Fri, 09 Nov 2007 16:52:47 +0000 Received: from dhcp-93.nlnetlabs.nl (dhcp-93.nlnetlabs.nl [213.154.224.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bert.secret-wg.org (Postfix) with ESMTPSA id 3C97DB831; Fri, 9 Nov 2007 17:24:23 +0100 (CET) Cc: Mark Andrews , namedroppers@ops.ietf.org, Message-Id: <4502E4BC-B3A6-4DCD-80B4-C3E75E88627A@NLnetLabs.nl> From: "Olaf M. Kolkman" 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 v912) Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) Date: Fri, 9 Nov 2007 17:24:22 +0100 References: X-Mailer: Apple Mail (2.912) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Hello Dean, you wrote: > The RFC3833 text above is plain. There are three elements: > > 1) Protecting against disclosure of DNS data was discussed. > > 2) Explicit decision: "DNS data is `public'" > > 3) Threats of data disclosure explicitly out of scope. I would agree that the above is indeed the gist of RFC3833. > NSEC3 is meant to protect against disclosure of DNS data (a topic > discussed). The NSEC3 draft was designed with the purpose of altering > the public nature of DNS data in order to enforce an improper database > copyright, contrary to the explicit decision cited. And NSEC3 > addresses > a problem (data disclosure) that is explicitly out of scope for > DNSSEC. After DNSSEC bis was developed on the basis of the requirement in RFC3833, folk found out that deploying DNSSEC would violate policies _already_ implemented to enforce registry policies. The technique used to enforce those policy was blocking of AXFR queries (e.g. through TSIG authentication). Deployment of DNSSEC would allow a NSEC walk and thereby full enumeration of the DNS zone. The result: those registries would _never_ deploy DNSSEC. Another way to look at this is that DNSSECbis answers leak more information about the zone than is required for answering the query. NSEC3 is the mechanism to minimize that information leakage. It would probably be possible to define some argument that asserts that NSEC3 does not violate RFC3833 but that would be a polemic exercise. As I tried to argue before, the working group went through a long and careful discussion, including a recharter, to determine this item in scope enough to extend DNSSECbis. So technically one could say that the introduction of the NSEC3 document updates RFC 3883. But all technicalities aside, with NSEC3 available we may see a few big registries deploy DNSSEC and that may get us on the upwards part of the deployment curve. And although I (personally) support the notion that data in the DNS is public and blocking AXFR for policy reasons is silly, I realize and accept that there are folk and institutions with a different opinion on this. Enjoy your weekend, --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ -- to unsubscribe send a message to namedroppers-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 Nov 09 12:29:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqXfR-0005O9-6o; Fri, 09 Nov 2007 12:29:17 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqXfN-0006eb-Sx; Fri, 09 Nov 2007 12:29:17 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IqXa6-000AfH-7G for namedroppers-data@psg.com; Fri, 09 Nov 2007 17:23:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IqXZv-000Abt-IV for namedroppers@ops.ietf.org; Fri, 09 Nov 2007 17:23:40 +0000 Received: from [64.235.108.48] (helo=[192.168.182.28]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IqWtR-0006pF-CP; Fri, 09 Nov 2007 16:39:41 +0000 Cc: Mark Andrews , namedroppers@ops.ietf.org, iesg@ietf.org Message-Id: From: Joe Abley 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 v912) Subject: Re: [DNSOP] Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) Date: Fri, 9 Nov 2007 11:39:38 -0500 References: X-Mailer: Apple Mail (2.912) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On 8-Nov-2007, at 23:36, Dean Anderson wrote: > NSEC3 is meant to protect against disclosure of DNS data (a topic > discussed). I don't think so. NSEC3 is intended to prevent enumeration of the resource records in a zone by a remote third party. That's not the same thing. For example, even if a zone contained NSEC3 records, it's still perfectly possible for DNS data to be disclosed to parties who are not the originator of a client query (e.g. through traffic intercept, query logs on intermediate caches, etc.) Joe -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Nov 10 16:54:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqyHN-0004wI-TA; Sat, 10 Nov 2007 16:54:13 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqyHK-0006I2-E1; Sat, 10 Nov 2007 16:54:13 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iqy8o-000OKd-95 for namedroppers-data@psg.com; Sat, 10 Nov 2007 21:45:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [80.67.170.53] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iqy8d-000OJW-JJ for namedroppers@ops.ietf.org; Sat, 10 Nov 2007 21:45:16 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 0C75F240822; Sat, 10 Nov 2007 21:44:58 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 618B815909E; Sat, 10 Nov 2007 19:42:33 -0200 (BRST) Date: Sat, 10 Nov 2007 19:42:33 -0200 From: Stephane Bortzmeyer To: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <20071110214233.GB8260@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a After review, this document seems to me be in a good shape and it would be a good idea to foresee a WG Last Call for it. The issues I still have (yes, I will record them on the Wiki) * a reference (normative?) to RFC 4086 would be a very good idea, with a link from section 9 "Implementations SHOULD use good random source to select a Query ID" * -01 says "TBD: Do we need to talk about stub resolvers? Does this draft apply to them?" I believe that the answer is yes. A typical stub resolver cannot receive unexpected answers (it typically does not listen for ever on the network) but it still can be fooled when listening for a reply. In addition, a typical stub resolver should listen only to the answers coming from the nameservers listed in its configuration (/etc/resolv.conf on Unix) but I'm not sure they all do and, anyway, it is not sufficient, the other countermeasures mentioned in section 9 all apply. [Soap box: I regret there is no list of changes from previous versions. It seems most of them are precisions in the Countermeasures 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 Nov 10 19:55:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ir16e-000593-Is; Sat, 10 Nov 2007 19:55:20 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ir16b-0001hK-Cz; Sat, 10 Nov 2007 19:55:20 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ir10D-0009oU-6E for namedroppers-data@psg.com; Sun, 11 Nov 2007 00:48:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ir0zu-0009mQ-IP for namedroppers@ops.ietf.org; Sun, 11 Nov 2007 00:48:35 +0000 Received: (qmail 14967 invoked by uid 399); 11 Nov 2007 00:48:21 -0000 Received: from localhost (HELO slave.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 11 Nov 2007 00:48:21 -0000 X-Originating-IP: 127.0.0.1 Date: Sat, 10 Nov 2007 16:48:19 -0800 (PST) From: Doug Barton To: Dean Anderson cc: namedroppers@ops.ietf.org, iesg@ietf.org Subject: Re: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) In-Reply-To: Message-ID: References: User-Agent: Alpine 0.99999 (BSF 796 2007-11-08) X-OpenPGP-Key-ID: 0xD5B2F0FB X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 On Thu, 8 Nov 2007, Dean Anderson wrote: > The RFC3833 text above is plain. There are three elements: You seem to be making the claim that once text is enshrined in an RFC that it is holy writ, and can never be changed or improved. As far as I know, that's not how the IETF works. > NSEC3 is meant to protect against disclosure of DNS data NSEC3 is meant to prevent unauthorized users from gaining access to information that it is currently possible to restrict them from obtaining. Said more simply, it's designed to prevent DNSSEC from removing an ability that zone managers have (and many depend on) currently. It is in no way designed to prevent anyone from directly querying for a given label and receiving an answer for that label (even if the "answer" is that it doesn't exist). > The NSEC3 draft was designed with the purpose of altering the public > nature of DNS data in order to enforce an improper database copyright, Once again, NSEC3 is designed to make sure that DNSSEC does NOT alter the nature of DNS data as it exists currently, and as a rather substantial percentage of the currently deployed base expects it to continue to exist. It's pretty clear Dean that you have a very strong opinion about whether or not any zone manager should be able to restrict access to any information in their zone (up to and including zone transfer), however your view is far from being unanimous (or one could potentially even say far from being well supported). FWIW, I will repeat the same statement I've been making for roughly 12 years now. Prevention of zone enumeration is a hard and fast requirement to have DNSSEC deployed at any reasonable definition of "widely." To the extent that NSEC3 supports that goal, I'm in support of it. Doug -- If you're never wrong, you're not trying hard enough -- to unsubscribe send a message to namedroppers-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 Nov 12 03:09:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrUMj-0006OJ-5P; Mon, 12 Nov 2007 03:09:53 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrUMg-0007Zw-3l; Mon, 12 Nov 2007 03:09:53 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrUDL-0004V4-6d for namedroppers-data@psg.com; Mon, 12 Nov 2007 08:00:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.154.224.48] (helo=bert.secret-wg.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrUCe-0004Q1-F0 for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 07:59:54 +0000 Received: from Miffy.lan (a62-251-91-215.adsl.xs4all.nl [62.251.91.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bert.secret-wg.org (Postfix) with ESMTPSA id 6A22EB870; Mon, 12 Nov 2007 08:59:26 +0100 (CET) Cc: namedroppers@ops.ietf.org Message-Id: <36A81163-EE76-425E-AE5A-62F0AF38E77F@NLnetLabs.nl> From: "Olaf M. Kolkman" To: Stephane Bortzmeyer In-Reply-To: <20071110214233.GB8260@laperouse.bortzmeyer.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Date: Mon, 12 Nov 2007 08:59:27 +0100 References: <20071110214233.GB8260@laperouse.bortzmeyer.org> X-Mailer: Apple Mail (2.912) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On 10Nov 2007, at 10:42 PM, Stephane Bortzmeyer wrote: > [Soap box: I regret there is no list of changes from previous > versions. It seems most of them are precisions in the Countermeasures > section] See: http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/ found via http://tools.ietf.org/wg/dnsext/ --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ -- to unsubscribe send a message to namedroppers-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 Nov 12 04:48:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrVuU-0005mi-IA; Mon, 12 Nov 2007 04:48:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrVuP-00031Q-17; Mon, 12 Nov 2007 04:48:50 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrVpK-000FVG-7g for namedroppers-data@psg.com; Mon, 12 Nov 2007 09:43:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrVp1-000FTZ-3i for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 09:43:21 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1IrVoy-0005hb-Bs; Mon, 12 Nov 2007 10:43:08 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.68) (envelope-from ) id 1IrVow-0002xW-E5; Mon, 12 Nov 2007 10:43:06 +0100 From: Florian Weimer To: Stephane Bortzmeyer Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt References: <20071110214233.GB8260@laperouse.bortzmeyer.org> Date: Mon, 12 Nov 2007 10:43:06 +0100 In-Reply-To: <20071110214233.GB8260@laperouse.bortzmeyer.org> (Stephane Bortzmeyer's message of "Sat, 10 Nov 2007 19:42:33 -0200") Message-ID: <87sl3biytx.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 * Stephane Bortzmeyer: > After review, this document seems to me be in a good shape and it > would be a good idea to foresee a WG Last Call for it. > > The issues I still have (yes, I will record them on the Wiki) > > * a reference (normative?) to RFC 4086 would be a very good idea, with > a link from section 9 "Implementations SHOULD use good random source > to select a Query ID" There is no industry consensus that this is a good idea. -- to unsubscribe send a message to namedroppers-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 Nov 12 05:00:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrW5o-0000ue-LK; Mon, 12 Nov 2007 05:00:32 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrW5m-0003SD-EA; Mon, 12 Nov 2007 05:00:32 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrW1S-000GjO-Nq for namedroppers-data@psg.com; Mon, 12 Nov 2007 09:56:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [80.67.170.53] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrW0t-000GeQ-32 for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 09:55:46 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 57261240827; Mon, 12 Nov 2007 09:55:13 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 5F6941590AA; Mon, 12 Nov 2007 07:46:23 -0200 (BRST) Date: Mon, 12 Nov 2007 07:46:23 -0200 From: Stephane Bortzmeyer To: "Olaf M. Kolkman" Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <20071112094623.GA13772@laperouse.bortzmeyer.org> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <36A81163-EE76-425E-AE5A-62F0AF38E77F@NLnetLabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36A81163-EE76-425E-AE5A-62F0AF38E77F@NLnetLabs.nl> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Mon, Nov 12, 2007 at 08:59:27AM +0100, Olaf M. Kolkman wrote a message of 24 lines which said: > http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/ Yes, and there is GNU diff, too. But a hand-written "Changes" section allows to have a simpler and more synthetic view of the changes, without spurious diffs (such as the change in the boilerplate that the tool above noticed). -- to unsubscribe send a message to namedroppers-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 Nov 12 05:18:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrWMj-0006cW-FG; Mon, 12 Nov 2007 05:18:01 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrWMf-0003zX-A2; Mon, 12 Nov 2007 05:18:01 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrWHc-000IAN-Nf for namedroppers-data@psg.com; Mon, 12 Nov 2007 10:12:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [80.67.170.53] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrWHR-000I9Z-E7 for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 10:12:38 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id A7693240824; Mon, 12 Nov 2007 10:12:22 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 325E11590AA; Mon, 12 Nov 2007 08:05:05 -0200 (BRST) Date: Mon, 12 Nov 2007 08:05:06 -0200 From: Stephane Bortzmeyer To: Florian Weimer Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <20071112100506.GA15120@laperouse.bortzmeyer.org> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87sl3biytx.fsf@mid.deneb.enyo.de> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Mon, Nov 12, 2007 at 10:43:06AM +0100, Florian Weimer wrote a message of 12 lines which said: > > * a reference (normative?) to RFC 4086 would be a very good idea, with > > a link from section 9 "Implementations SHOULD use good random source > > to select a Query ID" > > There is no industry consensus that this is a good idea. What is not a good idea? "Implementations SHOULD use good random source to select a Query ID" or "The draft should add a reference to RFC 4086"? -- to unsubscribe send a message to namedroppers-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 Nov 12 05:19:51 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrWOV-0000q5-PQ; Mon, 12 Nov 2007 05:19:51 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrWOT-00043X-8B; Mon, 12 Nov 2007 05:19:51 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrWIT-000IEs-Hq for namedroppers-data@psg.com; Mon, 12 Nov 2007 10:13:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_DHCP,RDNS_NONE autolearn=no version=3.2.3 Received: from [82.93.240.211] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrWHu-000ICk-Ox for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 10:13:20 +0000 Received: from outpost.ds9a.nl ([213.244.168.210] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1IrWHp-0005cm-M3 for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 11:12:57 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 7227740CE; Mon, 12 Nov 2007 11:12:57 +0100 (CET) Date: Mon, 12 Nov 2007 11:12:57 +0100 From: bert hubert To: Florian Weimer Cc: Stephane Bortzmeyer , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <20071112101257.GC4718@outpost.ds9a.nl> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87sl3biytx.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Mon, Nov 12, 2007 at 10:43:06AM +0100, Florian Weimer wrote: > > The issues I still have (yes, I will record them on the Wiki) > > > > * a reference (normative?) to RFC 4086 would be a very good idea, with > > a link from section 9 "Implementations SHOULD use good random source > > to select a Query ID" > > There is no industry consensus that this is a good idea. Can you elaborate? Because it seems to me that having a good source of random for things we like to be unpredictable is very much an industry consensus. Thanks. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 12 05:36:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrWeZ-0006Dj-2J; Mon, 12 Nov 2007 05:36:27 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrWeV-0004Z2-JQ; Mon, 12 Nov 2007 05:36:26 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrWYd-000JaX-IV for namedroppers-data@psg.com; Mon, 12 Nov 2007 10:30:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrWYS-000JZx-Oh for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 10:30:14 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1IrWYQ-0000tv-EP; Mon, 12 Nov 2007 11:30:06 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.68) (envelope-from ) id 1IrWYO-0003A0-JP; Mon, 12 Nov 2007 11:30:04 +0100 From: Florian Weimer To: Stephane Bortzmeyer Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> Date: Mon, 12 Nov 2007 11:30:04 +0100 In-Reply-To: <20071112100506.GA15120@laperouse.bortzmeyer.org> (Stephane Bortzmeyer's message of "Mon, 12 Nov 2007 08:05:06 -0200") Message-ID: <87y7d3hi37.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 * Stephane Bortzmeyer: > On Mon, Nov 12, 2007 at 10:43:06AM +0100, > Florian Weimer wrote > a message of 12 lines which said: > >> > * a reference (normative?) to RFC 4086 would be a very good idea, with >> > a link from section 9 "Implementations SHOULD use good random source >> > to select a Query ID" >> >> There is no industry consensus that this is a good idea. > > What is not a good idea? "Implementations SHOULD use good random > source to select a Query ID" or "The draft should add a reference to > RFC 4086"? The former. It has been argued that non-repeating query IDs are more important than good randomness. I tried very hard to understand this, but I still don't get 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 Mon Nov 12 05:55:47 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrWxH-0004vz-Dq; Mon, 12 Nov 2007 05:55:47 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrWxE-0005I2-SR; Mon, 12 Nov 2007 05:55:47 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrWrs-000LHK-FR for namedroppers-data@psg.com; Mon, 12 Nov 2007 10:50:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.154.224.48] (helo=bert.secret-wg.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrWrJ-000LBw-AL for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 10:49:54 +0000 Received: from dhcp-07.nlnetlabs.nl (dhcp-07.nlnetlabs.nl [213.154.224.70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bert.secret-wg.org (Postfix) with ESMTPSA id 09936B896; Mon, 12 Nov 2007 11:49:31 +0100 (CET) Cc: Stephane Bortzmeyer , namedroppers@ops.ietf.org Message-Id: From: "Olaf M. Kolkman" To: Florian Weimer In-Reply-To: <87y7d3hi37.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Date: Mon, 12 Nov 2007 11:49:15 +0100 References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> X-Mailer: Apple Mail (2.912) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 On 12Nov 2007, at 11:30 AM, Florian Weimer wrote: > * Stephane Bortzmeyer: > >> On Mon, Nov 12, 2007 at 10:43:06AM +0100, >> Florian Weimer wrote >> a message of 12 lines which said: >> >>>> * a reference (normative?) to RFC 4086 would be a very good idea, >>>> with >>>> a link from section 9 "Implementations SHOULD use good random >>>> source >>>> to select a Query ID" >>> >>> There is no industry consensus that this is a good idea. >> >> What is not a good idea? "Implementations SHOULD use good random >> source to select a Query ID" or "The draft should add a reference to >> RFC 4086"? > > The former. It has been argued that non-repeating query IDs are more > important than good randomness. I tried very hard to understand this, > but I still don't get it. Does a sentence like this help clarify: "The (sequence of) Query IDs SHOULD be unpredictable" possibly with the addition off: "e.g. by using a good source of randomness to generate them". Or is your question more fundamental? --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ -- to unsubscribe send a message to namedroppers-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 Nov 12 09:19:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ira8Y-0005w6-JT; Mon, 12 Nov 2007 09:19:38 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ira8U-0005zQ-Ve; Mon, 12 Nov 2007 09:19:38 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ira0j-000EfI-Vi for namedroppers-data@psg.com; Mon, 12 Nov 2007 14:11:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ira0V-000Ed7-Bt for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 14:11:28 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1Ira0P-0003cn-0V; Mon, 12 Nov 2007 15:11:13 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.68) (envelope-from ) id 1Ira0M-0004Ax-5G; Mon, 12 Nov 2007 15:11:10 +0100 From: Florian Weimer To: "Olaf M. Kolkman" Cc: Stephane Bortzmeyer , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> Date: Mon, 12 Nov 2007 15:11:10 +0100 In-Reply-To: (Olaf M. Kolkman's message of "Mon, 12 Nov 2007 11:49:15 +0100") Message-ID: <87k5ond05d.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a * Olaf M. Kolkman: >> The former. It has been argued that non-repeating query IDs are more >> important than good randomness. I tried very hard to understand this, >> but I still don't get it. > > Does a sentence like this help clarify: > > "The (sequence of) Query IDs SHOULD be unpredictable" > possibly with the addition off: > "e.g. by using a good source of randomness to generate them". I think this is worse because you should reuse query IDs in some cases (to avoid the birthday paradox when you still accept previous in-flight queries). > Or is your question more fundamental? Oh, let me put this differently: An implementation does not follow anything close to RFC 4086. We should figure out why they do this. Maybe there's a compelling reason, and in that case, the reason really should be mentioned in the draft. -- to unsubscribe send a message to namedroppers-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 Nov 12 10:04:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IraqL-0007Re-2n; Mon, 12 Nov 2007 10:04:53 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IraqI-0007JH-Om; Mon, 12 Nov 2007 10:04:53 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Irajm-000Kvy-2H for namedroppers-data@psg.com; Mon, 12 Nov 2007 14:58:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Irajb-000Ksd-DQ for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 14:58:00 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6EA4E1142E for ; Mon, 12 Nov 2007 14:57:51 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt In-Reply-To: Your message of "Mon, 12 Nov 2007 10:43:06 +0100." <87sl3biytx.fsf@mid.deneb.enyo.de> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 12 Nov 2007 14:57:51 +0000 Message-ID: <27988.1194879471@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 > > * a reference (normative?) to RFC 4086 would be a very good idea, with > > a link from section 9 "Implementations SHOULD use good random source > > to select a Query ID" > > There is no industry consensus that this is a good idea. agreed. there's no consensus that even a ~31 bit pseudo random combination of source port and query ID is good enough to have confidence that any given answer was really received from a purported server. there is also no consensus on the meaning of "good" in the context of "good random source". some say arc4random is fine, others say it's too weak. you could say something like "Implementations SHOULD NOT use query-ID schemes for which a proof of concept has demonstrated trivial predictability and easy cache pollution. NOTE WELL that the definition of 'trivial' changes every year, and that nothing short of Secure DNS can provide confidence in answers." -- to unsubscribe send a message to namedroppers-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 Nov 12 10:54:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irbbz-0005ub-26; Mon, 12 Nov 2007 10:54:07 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irbbw-0000LV-S7; Mon, 12 Nov 2007 10:54:07 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrbUO-000PUx-QB for namedroppers-data@psg.com; Mon, 12 Nov 2007 15:46:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_DHCP,RDNS_NONE autolearn=no version=3.2.3 Received: from [82.93.240.211] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrbTp-000PQn-Nl for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 15:45:59 +0000 Received: from outpost.ds9a.nl ([213.244.168.210] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1IrbTk-0000Ox-03; Mon, 12 Nov 2007 16:45:36 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 90E5E40AB; Mon, 12 Nov 2007 16:45:35 +0100 (CET) Date: Mon, 12 Nov 2007 16:45:35 +0100 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <20071112154535.GC31775@outpost.ds9a.nl> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <27988.1194879471@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27988.1194879471@sa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c On Mon, Nov 12, 2007 at 02:57:51PM +0000, Paul Vixie wrote: > > > a link from section 9 "Implementations SHOULD use good random source > > > to select a Query ID" > > > > There is no industry consensus that this is a good idea. > > agreed. there's no consensus that even a ~31 bit pseudo random combination > of source port and query ID is good enough to have confidence that any given > answer was really received from a purported server. That is correct. The intent of this draft is not to generate the end-all of DNS security - that might well be DNSSEC, or as you call it 'Secure DNS'. The intent of this draft is to raise the security bar for the interim period until DNS gets real cryptography. The draft states as much: The current internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to make 'spoofing' a recursing nameserver many orders of magnitude harder. Even a cryptographically secured DNS benefits from having the ability to discard bogus answers quickly, as this potentially saves large amounts of computation. > you could say something like "Implementations SHOULD NOT use query-ID schemes > for which a proof of concept has demonstrated trivial predictability and easy > cache pollution. NOTE WELL that the definition of 'trivial' changes every > year, and that nothing short of Secure DNS can provide confidence in answers." Should an implementation chose to use a random generation scheme that turns out to be predictable, it should be obliged to shift to one that is not. So the definition of 'trivial' or any other qualifying modifier should not be a problem. The upshot of it all is that the chosen query-ID (and source port) SHOULD NOT be easily predictable. And I'm sure there is "industry consensus" that having an easily predictable query-ID is not a good thing. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 12 11:34:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrcEl-000330-Iq; Mon, 12 Nov 2007 11:34:11 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrcEg-0002xO-D7; Mon, 12 Nov 2007 11:34:11 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Irc9f-0003sp-T1 for namedroppers-data@psg.com; Mon, 12 Nov 2007 16:28:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [131.111.8.134] (helo=ppsw-4.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Irc91-0003oa-Ma for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 16:28:38 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:45625) by ppsw-4.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.154]:25) with esmtpa (EXTERNAL:fanf2) id 1Irc8u-0004Gk-E5 (Exim 4.63) (return-path ); Mon, 12 Nov 2007 16:28:08 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Irc8u-0002av-B4 (Exim 4.67) (return-path ); Mon, 12 Nov 2007 16:28:08 +0000 Date: Mon, 12 Nov 2007 16:28:08 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Florian Weimer cc: Stephane Bortzmeyer , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt In-Reply-To: <87y7d3hi37.fsf@mid.deneb.enyo.de> Message-ID: References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Mon, 12 Nov 2007, Florian Weimer wrote: > * Stephane Bortzmeyer: > > > > What is not a good idea? "Implementations SHOULD use good random > > source to select a Query ID" or "The draft should add a reference to > > RFC 4086"? > > The former. It has been argued that non-repeating query IDs are more > important than good randomness. I tried very hard to understand this, > but I still don't get it. You can't just naively pick a query ID at random from the whole 16 bit space because you'll have ID clashes. You need a scheme that does not re-use recent IDs too quickly, but this does not mean that you don't need good randomness. Tony. -- f.a.n.finch http://dotat.at/ SOLE: VARIABLE BECOMING NORTHWESTERLY 3 OR 4, OCCASIONALLY 5. SLIGHT OR MODERATE. MAINLY FAIR. GOOD. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 12 11:43:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrcNq-00010G-5I; Mon, 12 Nov 2007 11:43:34 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrcNl-0003Kc-On; Mon, 12 Nov 2007 11:43:34 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrcIh-0004pa-Rw for namedroppers-data@psg.com; Mon, 12 Nov 2007 16:38:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrcIX-0004oY-58 for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 16:38:10 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1IrcI8-0002zM-MX; Mon, 12 Nov 2007 17:37:41 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.68) (envelope-from ) id 1IrcGt-0004vw-Bu; Mon, 12 Nov 2007 17:36:23 +0100 From: Florian Weimer To: Tony Finch Cc: Stephane Bortzmeyer , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> Date: Mon, 12 Nov 2007 17:36:23 +0100 In-Reply-To: (Tony Finch's message of "Mon, 12 Nov 2007 16:28:08 +0000") Message-ID: <87k5ona0ag.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 * Tony Finch: > On Mon, 12 Nov 2007, Florian Weimer wrote: >> * Stephane Bortzmeyer: >> > >> > What is not a good idea? "Implementations SHOULD use good random >> > source to select a Query ID" or "The draft should add a reference to >> > RFC 4086"? >> >> The former. It has been argued that non-repeating query IDs are more >> important than good randomness. I tried very hard to understand this, >> but I still don't get it. > > You can't just naively pick a query ID at random from the whole 16 bit > space because you'll have ID clashes. Why are ID clashes a problem? Do real-world authoritative servers misbehave when confronted with them? This should really be mentioned in the draft. -- to unsubscribe send a message to namedroppers-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 Nov 12 12:22:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irczx-0002iZ-Qp; Mon, 12 Nov 2007 12:22:57 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irczv-0004wT-Jk; Mon, 12 Nov 2007 12:22:57 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ircsv-0008qO-NV for namedroppers-data@psg.com; Mon, 12 Nov 2007 17:15:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [204.152.184.167] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrcsR-0008mn-0g for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 17:15:26 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id EF87611401F; Mon, 12 Nov 2007 17:15:09 +0000 (UTC) (envelope-from Shane_Kerr@isc.org) Received: from [192.168.1.18] (hurix.ams-ix.net [193.194.136.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id B2731E6056; Mon, 12 Nov 2007 17:15:09 +0000 (UTC) (envelope-from shane@isc.org) Message-ID: <47388A1B.4030604@isc.org> Date: Mon, 12 Nov 2007 18:15:07 +0100 From: Shane Kerr Reply-To: shane_kerr@isc.org Organization: ISC User-Agent: Thunderbird 2.0.0.6 (X11/20070806) MIME-Version: 1.0 To: Florian Weimer CC: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> <87k5ona0ag.fsf@mid.deneb.enyo.de> In-Reply-To: <87k5ona0ag.fsf@mid.deneb.enyo.de> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florian Weimer wrote: > * Tony Finch: > >> On Mon, 12 Nov 2007, Florian Weimer wrote: >>> * Stephane Bortzmeyer: >>>> What is not a good idea? "Implementations SHOULD use good random >>>> source to select a Query ID" or "The draft should add a reference to >>>> RFC 4086"? >>> The former. It has been argued that non-repeating query IDs are more >>> important than good randomness. I tried very hard to understand this, >>> but I still don't get it. >> You can't just naively pick a query ID at random from the whole 16 bit >> space because you'll have ID clashes. > > Why are ID clashes a problem? Do real-world authoritative servers > misbehave when confronted with them? Well, it's a resolver that picks the query ID, but this is a good question. The only time you have an actual clash is when you have a duplicate ID+source IP+source port+destination IP+destination port for a UDP query, because then the resolver has no way to disambiguate the replies it gets. Certainly some implementations may have problems with duplicate query IDs, but that's out of scope for an RFC, IMHO. - -- Shane -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHOIoXMsfZxBO4kbQRAq+jAJ4y4C3h9Yxjhftdtv7dlUDNypTtmACeI2qw NZxccHl/WUSWJ/tnS0dfaJE= =K5Hn -----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 Nov 12 12:35:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrdCB-0001RB-EZ; Mon, 12 Nov 2007 12:35:35 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrdC9-0005Xf-62; Mon, 12 Nov 2007 12:35:35 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ird7C-000AaG-CI for namedroppers-data@psg.com; Mon, 12 Nov 2007 17:30:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ird6e-000ASv-H3 for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 17:30:08 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id D1F1D11434; Mon, 12 Nov 2007 17:29:51 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: bert hubert cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt In-Reply-To: Your message of "Mon, 12 Nov 2007 16:45:35 +0100." <20071112154535.GC31775@outpost.ds9a.nl> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <27988.1194879471@sa.vix.com> <20071112154535.GC31775@outpost.ds9a.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 12 Nov 2007 17:29:51 +0000 Message-ID: <86081.1194888591@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 > And I'm sure there is "industry consensus" that having an easily predictable > query-ID is not a good thing. so far, so good. do we have a winner on the above wording? -- to unsubscribe send a message to namedroppers-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 Nov 12 12:38:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrdF9-0007yR-OW; Mon, 12 Nov 2007 12:38:39 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrdF5-0005el-Kn; Mon, 12 Nov 2007 12:38:39 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrdAe-000B11-Mz for namedroppers-data@psg.com; Mon, 12 Nov 2007 17:34:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrdAT-000AxR-QD for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 17:33:55 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1IrdAP-0004tz-Qw; Mon, 12 Nov 2007 18:33:46 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.68) (envelope-from ) id 1IrdAK-0005OR-0T; Mon, 12 Nov 2007 18:33:40 +0100 From: Florian Weimer To: shane_kerr@isc.org Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> <87k5ona0ag.fsf@mid.deneb.enyo.de> <47388A1B.4030604@isc.org> Date: Mon, 12 Nov 2007 18:33:39 +0100 In-Reply-To: <47388A1B.4030604@isc.org> (Shane Kerr's message of "Mon, 12 Nov 2007 18:15:07 +0100") Message-ID: <87fxzb8j2k.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 * Shane Kerr: >> Why are ID clashes a problem? Do real-world authoritative servers >> misbehave when confronted with them? > > Well, it's a resolver that picks the query ID, but this is a good > question. Yes, and it has to choose them in a way that doesn't trigger bugs in authoritative servers (or upstream resolvers, if there's a hierarchy). > The only time you have an actual clash is when you have a duplicate ID+source > IP+source port+destination IP+destination port for a UDP query, because then the > resolver has no way to disambiguate the replies it gets. In a typical setup, this will just look like a duplicate packet. And thanks to certain load balancers, you already need to deal with this situation on the resolver side. Parallel UDP and TCP queries with the same ID could be a different matter. > Certainly some implementations may have problems with duplicate query IDs, but > that's out of scope for an RFC, IMHO. Does that mean ID collision avoidance is just based on a hunch? I don't want to sound disparaging--I just hope that we can get rid of the additional complexity such a requirement implies. I agree that if collision avoidance isn't a must, the RFC can be silent on this issue. -- to unsubscribe send a message to namedroppers-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 Nov 12 12:47:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrdNQ-0000bp-1l; Mon, 12 Nov 2007 12:47:12 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrdNO-00061d-0U; Mon, 12 Nov 2007 12:47:12 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrdJG-000C5s-PO for namedroppers-data@psg.com; Mon, 12 Nov 2007 17:42:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [131.111.8.138] (helo=ppsw-8.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrdIh-000C3J-KW for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 17:42:37 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:46342) by ppsw-8.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1IrdIe-0003dy-QR (Exim 4.67) (return-path ); Mon, 12 Nov 2007 17:42:16 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1IrdIe-0000ga-5w (Exim 4.67) (return-path ); Mon, 12 Nov 2007 17:42:16 +0000 Date: Mon, 12 Nov 2007 17:42:16 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Florian Weimer cc: Stephane Bortzmeyer , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt In-Reply-To: <87k5ona0ag.fsf@mid.deneb.enyo.de> Message-ID: References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> <87k5ona0ag.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 On Mon, 12 Nov 2007, Florian Weimer wrote: > > Why are ID clashes a problem? I'd expect them to cause in the most benign case delays because of retries. Or a server might be mistakenly marked as broken, or the client might get confused and return bogus data. It depends on how the client disambiguates replies to queries and how paranoid it is. Tony. -- f.a.n.finch http://dotat.at/ BISCAY: NORTHERLY 3 OR 4, OCCASIONALLY 5 LATER IN NORTH. SLIGHT OR MODERATE. SHOWERS. GOOD. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 12 13:00:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrdaM-0003Vw-Sx; Mon, 12 Nov 2007 13:00:34 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrdaK-0006Wz-AD; Mon, 12 Nov 2007 13:00:34 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrdVl-000DfR-0L for namedroppers-data@psg.com; Mon, 12 Nov 2007 17:55:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrdVa-000Ddf-CE for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 17:55:43 +0000 Received: from andrew-vpn.int.libertyrms.com ([10.1.7.6] helo=trilby.local) by mail.libertyrms.com with esmtp (Exim 4.22) id 1IrdVT-0001h8-8T for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 12:55:31 -0500 Received: by trilby.local (Postfix, from userid 1019) id D52CD3AB8EA; Mon, 12 Nov 2007 12:57:17 -0500 (EST) Date: Mon, 12 Nov 2007 12:57:17 -0500 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <20071112175717.GH7741@afilias.info> Reply-To: Andrew Sullivan References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> <87k5ona0ag.fsf@mid.deneb.enyo.de> <47388A1B.4030604@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47388A1B.4030604@isc.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Mon, Nov 12, 2007 at 06:15:07PM +0100, Shane Kerr wrote: > > Certainly some implementations may have problems with duplicate query IDs, but > that's out of scope for an RFC, IMHO. It's not out of scope for consideration in this discussion, though, is it? It seems it'd be relevant to whether a good source of randomness is what should be recommended. If some implementation has problems with duplicate query IDs, then they'll be able to argue that randomness is the wrong target, I think. A -- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 jabber: ajsaf@jabber.org +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-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 Nov 12 13:03:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irddd-00033s-IV; Mon, 12 Nov 2007 13:03:57 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrddZ-0006kZ-Ry; Mon, 12 Nov 2007 13:03:57 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrdWY-000Dlk-3Q for namedroppers-data@psg.com; Mon, 12 Nov 2007 17:56:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [131.111.8.132] (helo=ppsw-2.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrdVz-000Dix-DO for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 17:56:20 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:48627) by ppsw-2.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.152]:25) with esmtpa (EXTERNAL:fanf2) id 1IrdVv-0000df-7k (Exim 4.63) (return-path ); Mon, 12 Nov 2007 17:55:59 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1IrdVv-0003G0-CF (Exim 4.67) (return-path ); Mon, 12 Nov 2007 17:55:59 +0000 Date: Mon, 12 Nov 2007 17:55:59 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Shane Kerr cc: Florian Weimer , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt In-Reply-To: <47388A1B.4030604@isc.org> Message-ID: References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> <87k5ona0ag.fsf@mid.deneb.enyo.de> <47388A1B.4030604@isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Mon, 12 Nov 2007, Shane Kerr wrote: > > The only time you have an actual clash is when you have a duplicate > ID+source IP+source port+destination IP+destination port for a UDP > query, because then the resolver has no way to disambiguate the replies > it gets. This situation is common for stub resolvers, and for cacheing resolvers that are doing a lot of lookups against the same zone. Any high-volume DNS client *will* encounter problems with naive random query IDs. Tony. -- f.a.n.finch http://dotat.at/ WEST FORTIES CROMARTY FORTH TYNE WEST DOGGER: WESTERLY VEERING NORTHERLY 4 OR 5, INCREASING 5 TO 7, PERHAPS GALE 8 LATER IN TYNE AND WEST DOGGER. MODERATE OR ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 12 13:16:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrdpY-0008Q4-4o; Mon, 12 Nov 2007 13:16:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrdpV-0007Cf-7a; Mon, 12 Nov 2007 13:16:16 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrdjN-000FLf-Up for namedroppers-data@psg.com; Mon, 12 Nov 2007 18:09:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_DHCP,RDNS_NONE autolearn=no version=3.2.3 Received: from [82.93.240.211] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Irdip-000FIy-2T for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 18:09:36 +0000 Received: from outpost.ds9a.nl ([213.244.168.210] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1Irdim-0001o7-Iy for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 19:09:16 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 2432B4052; Mon, 12 Nov 2007 19:09:16 +0100 (CET) Date: Mon, 12 Nov 2007 19:09:15 +0100 From: bert hubert To: Shane Kerr Cc: Florian Weimer , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <20071112180915.GA12879@outpost.ds9a.nl> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> <87k5ona0ag.fsf@mid.deneb.enyo.de> <47388A1B.4030604@isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47388A1B.4030604@isc.org> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Mon, Nov 12, 2007 at 06:15:07PM +0100, Shane Kerr wrote: > The only time you have an actual clash is when you have a duplicate ID+source > IP+source port+destination IP+destination port for a UDP query, because then the > resolver has no way to disambiguate the replies it gets. Even more - "source ip, source port, destination ip, destination port, id, qname, qtype" - these all have to match. Authoritative servers do not look at the id of questions they get, except to copy them to the answer. So duplicate query-IDs are only a problem for the resolver emitting them, which will then have trouble disambiguating replies - iow, it is buggy. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 12 13:30:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ire36-0007ZL-S1; Mon, 12 Nov 2007 13:30:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ire33-0007gG-D2; Mon, 12 Nov 2007 13:30:16 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrdxU-000H4N-QS for namedroppers-data@psg.com; Mon, 12 Nov 2007 18:24:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [131.111.8.132] (helo=ppsw-2.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Irdww-000Gz2-0t for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 18:24:11 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:53769) by ppsw-2.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.152]:25) with esmtpa (EXTERNAL:fanf2) id 1Irdwp-0002Bu-7y (Exim 4.63) for namedroppers@ops.ietf.org (return-path ); Mon, 12 Nov 2007 18:23:47 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Irdwp-0008GU-Ei (Exim 4.67) for namedroppers@ops.ietf.org (return-path ); Mon, 12 Nov 2007 18:23:47 +0000 Date: Mon, 12 Nov 2007 18:23:47 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt In-Reply-To: <20071112175717.GH7741@afilias.info> Message-ID: References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> <87k5ona0ag.fsf@mid.deneb.enyo.de> <47388A1B.4030604@isc.org> <20071112175717.GH7741@afilias.info> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 You should read the following slides for a discussion of how to use good randomness for packet IDs without causing interop problems. The protocols are TCP and IP, but similar considerations apply to DNS. http://www.bsdcan.org/2006/papers/ImprovingTCPIP.pdf Note that bad randomness will cause the same kinds of interop problems as good randomness, so there's no harm recommending good randomness. Tony. -- f.a.n.finch http://dotat.at/ MALIN HEBRIDES: SOUTHERLY IN EAST AT FIRST, OTHERWISE NORTHWESTERLY 5 TO 7, OCCASIONALLY GALE 8 IN HEBRIDES. ROUGH OR VERY ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 12 14:46:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrfEf-0004AD-2d; Mon, 12 Nov 2007 14:46:17 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrfEc-0001yV-Nt; Mon, 12 Nov 2007 14:46:17 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Irf7I-000Pnv-Sz for namedroppers-data@psg.com; Mon, 12 Nov 2007 19:38:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Irf78-000Pn2-3u for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 19:38:35 +0000 Received: from [192.168.100.17] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id AA59BC2DB5; Mon, 12 Nov 2007 19:38:27 +0000 (GMT) Date: Mon, 12 Nov 2007 19:38:15 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Tony Finch , Florian Weimer cc: Stephane Bortzmeyer , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: In-Reply-To: References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a --On 12 November 2007 16:28:08 +0000 Tony Finch wrote: > You can't just naively pick a query ID at random from the whole 16 bit > space because you'll have ID clashes. You need a scheme that does not > re-use recent IDs too quickly, but this does not mean that you don't > need good randomness. I think not. Picking ID's in ascending numerical order (skipping clashes) would satisfy that, but obviously be less useful than a random scheme (which also skipped clashes). I am assuming here that there is some set of IDs for which are dangerous. I think the problem here is people are trying to describe the mechanism for allocating ID's etc. rather than what it is desirable to achieve. EG: "ID's SHOULD be assigned in a manner that the ability of a third party with access wire data to guess ID's on subsequent queries is minimised; this could, for instance, be achieved by introducing a pseudo-random component into the mechanism used to select the ID". 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 Nov 12 17:12:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrhVg-0005XQ-1M; Mon, 12 Nov 2007 17:12:00 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrhVc-0007z8-Ej; Mon, 12 Nov 2007 17:12:00 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrhOM-000CrV-7e for namedroppers-data@psg.com; Mon, 12 Nov 2007 22:04:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_DHCP,RDNS_NONE autolearn=no version=3.2.3 Received: from [82.93.240.211] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrhNm-000CoB-Tr for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 22:04:08 +0000 Received: from outpost.ds9a.nl ([213.244.168.210] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1IrhNg-0004Nd-Ij; Mon, 12 Nov 2007 23:03:44 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 68DEA40B2; Mon, 12 Nov 2007 23:03:44 +0100 (CET) Date: Mon, 12 Nov 2007 23:03:44 +0100 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <20071112220343.GA19255@outpost.ds9a.nl> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <27988.1194879471@sa.vix.com> <20071112154535.GC31775@outpost.ds9a.nl> <86081.1194888591@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86081.1194888591@sa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 On Mon, Nov 12, 2007 at 05:29:51PM +0000, Paul Vixie wrote: > > And I'm sure there is "industry consensus" that having an easily predictable > > query-ID is not a good thing. > > so far, so good. do we have a winner on the above wording? From my end, we do. In rfc-ese: Implementations MUST NOT use Query-IDs that can easily be predicted or Implementations MUST use Query-IDs that are not easily predicted I'd personally prefer something along the lines of Implementations MUST use Query-IDs that are hard to predict Regards, Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 12 17:50:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iri70-0001K7-JH; Mon, 12 Nov 2007 17:50:34 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iri6y-0001Do-8d; Mon, 12 Nov 2007 17:50:34 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iri27-000H1V-MR for namedroppers-data@psg.com; Mon, 12 Nov 2007 22:45:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [80.67.170.53] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iri1w-000Gz4-T6 for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 22:45:26 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 15294240828; Mon, 12 Nov 2007 22:45:07 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id CE5F6941EC; Mon, 12 Nov 2007 20:35:43 -0200 (BRST) Date: Mon, 12 Nov 2007 20:35:43 -0200 From: Stephane Bortzmeyer To: bert hubert Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <20071112223543.GA12580@laperouse.bortzmeyer.org> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <27988.1194879471@sa.vix.com> <20071112154535.GC31775@outpost.ds9a.nl> <86081.1194888591@sa.vix.com> <20071112220343.GA19255@outpost.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071112220343.GA19255@outpost.ds9a.nl> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Mon, Nov 12, 2007 at 11:03:44PM +0100, bert hubert wrote a message of 34 lines which said: > Implementations MUST use Query-IDs that are hard to predict More detailed, with the help of Alex Bligh: Implementations MUST use Query-IDs that are hard to predict for a third party with access to wire data. This could, for instance, be achieved by introducing a random [RFC 4086] or pseudo-random component into the mechanism used to select the ID -- Read on /., about MS-Windows error messages: Your system must meet the requirements to be able to run the Windows Random Number Generator on Vista. Otherwise, you will need to use Windows Number Generator Basic. The only number WNGB can generate is 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 Mon Nov 12 18:24:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrieA-0008Dg-Qy; Mon, 12 Nov 2007 18:24:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irie6-0002Il-Mz; Mon, 12 Nov 2007 18:24:50 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IriYj-000Jwl-2t for namedroppers-data@psg.com; Mon, 12 Nov 2007 23:19:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [204.152.184.167] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IriYC-000Jt2-6h for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 23:18:56 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id 2DB95114060 for ; Mon, 12 Nov 2007 23:18:39 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id 4AB52E6056 for ; Mon, 12 Nov 2007 23:18:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id lACNIAGO003165; Tue, 13 Nov 2007 10:18:11 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200711122318.lACNIAGO003165@drugs.dv.isc.org> To: Tony Finch Cc: Shane Kerr , Florian Weimer , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt In-reply-to: Your message of "Mon, 12 Nov 2007 17:55:59 -0000." Date: Tue, 13 Nov 2007 10:18:10 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f > On Mon, 12 Nov 2007, Shane Kerr wrote: > > > > The only time you have an actual clash is when you have a duplicate > > ID+source IP+source port+destination IP+destination port for a UDP > > query, because then the resolver has no way to disambiguate the replies > > it gets. > > This situation is common for stub resolvers, and for cacheing resolvers > that are doing a lot of lookups against the same zone. Any high-volume > DNS client *will* encounter problems with naive random query IDs. It also doesn't help when the OS re-assigns the same port number over and over and over until there happens to be a collision which just causes it to move onto the next port and repeat the process. > Tony. > -- > f.a.n.finch http://dotat.at/ > WEST FORTIES CROMARTY FORTH TYNE WEST DOGGER: WESTERLY VEERING NORTHERLY 4 OR > 5, INCREASING 5 TO 7, PERHAPS GALE 8 LATER IN TYNE AND WEST DOGGER. MODERATE > OR ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 12 18:33:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrimC-0001iR-3K; Mon, 12 Nov 2007 18:33:08 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irim9-0002Y2-33; Mon, 12 Nov 2007 18:33:08 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Irih7-000Kf4-4U for namedroppers-data@psg.com; Mon, 12 Nov 2007 23:27:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [204.152.184.167] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Irige-000Kds-CP for namedroppers@ops.ietf.org; Mon, 12 Nov 2007 23:27:38 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id 5A178114052 for ; Mon, 12 Nov 2007 23:27:23 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id 8994CE6067 for ; Mon, 12 Nov 2007 23:27:23 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id lACNQvCQ003229; Tue, 13 Nov 2007 10:26:58 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200711122326.lACNQvCQ003229@drugs.dv.isc.org> To: bert hubert Cc: Shane Kerr , Florian Weimer , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt In-reply-to: Your message of "Mon, 12 Nov 2007 19:09:15 BST." <20071112180915.GA12879@outpost.ds9a.nl> Date: Tue, 13 Nov 2007 10:26:57 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 > On Mon, Nov 12, 2007 at 06:15:07PM +0100, Shane Kerr wrote: > > > The only time you have an actual clash is when you have a duplicate ID+sour > ce > > IP+source port+destination IP+destination port for a UDP query, because the > n the > > resolver has no way to disambiguate the replies it gets. > > Even more - "source ip, source port, destination ip, destination port, id, > qname, qtype" - these all have to match. But not in the error reply space. The client has to handle just getting back the 12 octet DNS header for NOTIMP, FORMERR, SERVFAIL etc. Good answers (includes NXDOMAIN) to queries contain the qname and qtype. It also has to handle delayed error replies, duplicate error replies (possibly due to duplicate queries), etc. > Authoritative servers do not look at the id of questions they get, except to > copy them to the answer. Recursive servers do duplicate query suppression. Remember there are often chains of recursive servers. > So duplicate query-IDs are only a problem for the resolver emitting them, > which will then have trouble disambiguating replies - iow, it is buggy. > > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 12 20:59:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irl3x-0001il-6p; Mon, 12 Nov 2007 20:59:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irl3r-0006ki-8g; Mon, 12 Nov 2007 20:59:37 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Irkws-0008Cu-Ue for namedroppers-data@psg.com; Tue, 13 Nov 2007 01:52:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Irkwi-0008CG-5t for namedroppers@ops.ietf.org; Tue, 13 Nov 2007 01:52:13 +0000 Received: from Puki.ogud.com (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id lAD1pwc7018934; Mon, 12 Nov 2007 20:51:58 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <200711130151.lAD1pwc7018934@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 12 Nov 2007 20:51:12 -0500 To: Stephane Bortzmeyer , bert hubert From: Olafur Gudmundsson Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Cc: namedroppers@ops.ietf.org In-Reply-To: <20071112223543.GA12580@laperouse.bortzmeyer.org> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <27988.1194879471@sa.vix.com> <20071112154535.GC31775@outpost.ds9a.nl> <86081.1194888591@sa.vix.com> <20071112220343.GA19255@outpost.ds9a.nl> <20071112223543.GA12580@laperouse.bortzmeyer.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a At 17:35 12/11/2007, Stephane Bortzmeyer wrote: >On Mon, Nov 12, 2007 at 11:03:44PM +0100, > bert hubert wrote > a message of 34 lines which said: > > > Implementations MUST use Query-IDs that are hard to predict > >More detailed, with the help of Alex Bligh: > >Implementations MUST use Query-IDs that are hard to predict for a >third party with access to wire data. This could, for instance, be >achieved by introducing a random [RFC 4086] or pseudo-random component >into the mechanism used to select the ID when third party has access to query stream (i.e. wire access) all bets are off as it sees the query and can forge a single answer. The issue we are trying to address is: can a third party somehow observe few sequential queries and from that information predict future query id's and ports. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 13 04:05:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irrhx-0002K6-9p; Tue, 13 Nov 2007 04:05:21 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irrhv-0001ga-2z; Tue, 13 Nov 2007 04:05:21 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrraL-000IW5-SN for namedroppers-data@psg.com; Tue, 13 Nov 2007 08:57:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrrZq-000IUE-7k for namedroppers@ops.ietf.org; Tue, 13 Nov 2007 08:57:14 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) by open.nlnetlabs.nl (8.14.1/8.14.1) with ESMTP id lAD8unjD072959; Tue, 13 Nov 2007 09:56:49 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <473966D1.4070803@nlnetlabs.nl> Date: Tue, 13 Nov 2007 09:56:49 +0100 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: Tony Finch CC: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> <87k5ona0ag.fsf@mid.deneb.enyo.de> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Tue, 13 Nov 2007 09:56:52 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony Finch wrote: > On Mon, 12 Nov 2007, Florian Weimer wrote: >> Why are ID clashes a problem? > > I'd expect them to cause in the most benign case delays because of > retries. Or a server might be mistakenly marked as broken, or the client > might get confused and return bogus data. It depends on how the client > disambiguates replies to queries and how paranoid it is. A quick calculation says that a busy resolver, talking to a forwarder/cache, with 1000 queries per second, each query takes 500 msec to be answered, that uses a plain random 16bit ID (no extra ports), has 85% chance of having a duplicate ID outstanding, and thus being unable to disambiguate the reply. That is pretty high, I think the draft can say something about avoiding these ID clashes. Best regards, Wouter PS. formula used, p = 1-exp(-n*n*H/2), with n=500, H=65536. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHOWbRkDLqNwOhpPgRAij/AKCza9IdLGdqVxppySQf0Dgs1j0XNACeKROj Eim/a3PHTnw2WXf7LDMrWn8= =qxye -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 13 04:44:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrsKA-0003BD-8W; Tue, 13 Nov 2007 04:44:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrsK6-0002yO-Kp; Tue, 13 Nov 2007 04:44:50 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrsFo-000MBA-Dj for namedroppers-data@psg.com; Tue, 13 Nov 2007 09:40:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrsFc-000MAO-DT for namedroppers@ops.ietf.org; Tue, 13 Nov 2007 09:40:14 +0000 Received: from [192.168.100.17] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id D2BD2C2DB2; Tue, 13 Nov 2007 09:40:04 +0000 (GMT) Date: Tue, 13 Nov 2007 09:39:50 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Olafur Gudmundsson , Stephane Bortzmeyer , bert hubert cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <9DA7DD82F603E908F9D0443C@Ximenes.local> In-Reply-To: <200711130151.lAD1pwc7018934@ogud.com> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <27988.1194879471@sa.vix.com> <20071112154535.GC31775@outpost.ds9a.nl> <86081.1194888591@sa.vix.com> <20071112220343.GA19255@outpost.ds9a.nl> <20071112223543.GA12580@laperouse.bortzmeyer.org> <200711130151.lAD1pwc7018934@ogud.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Olafur, > when third party has access to query stream (i.e. wire access) all > bets are off as it sees the query and can forge a single answer. > > The issue we are trying to address is: can a third party somehow > observe few sequential queries and from that information > predict future query id's and ports. (re your first para) of course, if they have access to *all* wire data. Equally, IDs being hard to predict where a third party has access to *no* wire data is not a sufficiently strong solution (obviously). I think you might, however, be missing the point. The point is not to pretend that the originator of the query will thereby gain security if a third party DOES have access to all wire data, just that if IDs are hard to predict if a third party DID have access to *all* wire data, then this is (I think) SUFFICIENT that it is hard (enough) to forge replies etc. when the third party doesn't have access to *all* wire data (we presume they might have access to some, e.g. some queries the third party answers itself). The reason I picked this threshold was if you imagine the situation where a third party engineers a situation where the resolver concerned makes all queries to a server in the control of a third party (e.g. by making a user visit an html page with a sequence of links in to addresses located within a domain controlled by him) and then a single query of the server whose address he wants to fake (e.g. a short delay then http://www.mybank.example.com/ or whatever), then in practice the attacker has had access (or hopes he has had access) to all (recent) wire data and we are hoping he can't then guess the next ID - i.e. we are hoping the ID is hard to guess when the third party has had access to 'all wire data'. You could write "access to all wire data except the putative query to be made" but clearly the attacker won't have access to something which has not yet happened, hence my failure to exclude that case specifically. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 13 04:50:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrsPx-0003Tr-NM; Tue, 13 Nov 2007 04:50:49 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrsPu-00039J-DC; Tue, 13 Nov 2007 04:50:49 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrsM3-000Mmc-30 for namedroppers-data@psg.com; Tue, 13 Nov 2007 09:46:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [83.246.72.252] (helo=gurgel.gson.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrsLs-000Mm2-6b for namedroppers@ops.ietf.org; Tue, 13 Nov 2007 09:46:41 +0000 Received: from guava.gson.org (a91-152-94-125.elisa-laajakaista.fi [91.152.94.125]) by gurgel.gson.org (Postfix) with ESMTP id 5790F405F; Tue, 13 Nov 2007 09:47:07 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id 01AD4762AC; Tue, 13 Nov 2007 11:46:21 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18233.29293.966899.990157@guava.gson.org> Date: Tue, 13 Nov 2007 11:46:21 +0200 To: Florian Weimer Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt In-Reply-To: <87fxzb8j2k.fsf@mid.deneb.enyo.de> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> <87k5ona0ag.fsf@mid.deneb.enyo.de> <47388A1B.4030604@isc.org> <87fxzb8j2k.fsf@mid.deneb.enyo.de> X-Mailer: VM 7.19 under Emacs 21.4.1 From: gson@araneus.fi (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Florian Weimer wrote re query IDs: > Yes, and it has to choose them in a way that doesn't trigger bugs in > authoritative servers (or upstream resolvers, if there's a hierarchy). Do you know of any such bugs? The users of the two recursive DNS server implementations I have worked on certainly haven't reported any problems caused by such bugs. What both of those implementations actually do is to choose the query ID randomly among the set of query IDs not already in use by outstanding queries. This exclusion of already outstanding IDs is done purely to aid in uniquely identifying the response, not to work around any known external bug. -- Andreas Gustafsson, gson@araneus.fi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 13 04:55:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrsU6-0006mB-Od; Tue, 13 Nov 2007 04:55:06 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrsU3-0003H9-5W; Tue, 13 Nov 2007 04:55:06 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrsQF-000NCa-VT for namedroppers-data@psg.com; Tue, 13 Nov 2007 09:51:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrsQ5-000NBx-87 for namedroppers@ops.ietf.org; Tue, 13 Nov 2007 09:51:02 +0000 Received: from [192.168.100.17] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 76EF7C2DB2; Tue, 13 Nov 2007 09:50:53 +0000 (GMT) Date: Tue, 13 Nov 2007 09:50:37 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Wouter Wijngaards , Tony Finch cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <498B60125701B610547919C1@Ximenes.local> In-Reply-To: <473966D1.4070803@nlnetlabs.nl> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> <87k5ona0ag.fsf@mid.deneb.enyo.de> <473966D1.4070803@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: DNSEXT discussion X-Spam-Score: -3.7 (---) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 --On 13 November 2007 09:56:49 +0100 Wouter Wijngaards wrote: > A quick calculation says that a busy resolver, talking to a > forwarder/cache, with 1000 queries per second, each query takes 500 msec > to be answered, that uses a plain random 16bit ID (no extra ports), has > 85% chance of having a duplicate ID outstanding, and thus being unable > to disambiguate the reply. That is pretty high, I think the draft can > say something about avoiding these ID clashes. > > Best regards, > Wouter > PS. formula used, p = 1-exp(-n*n*H/2), with n=500, H=65536. 1-exp(-n*n/2H) I think you mean. I'm not sure that's right though because it won't use a random ID, it will use a random ID that is not already outstanding. In which case the server simply has 500 IDs outstanding (on average) at any one time out of a maximum possible ID space of 2^16, which means if the attacker sends in one packet, he'd have a chance of 0.7% of picking one outstanding. Send in tens of thousands of packets a second (for instance one with every ID) and you are guaranteed a match. But you'd also have to match not only the ID, but also the QNAME etc. If one uses random ports as well, one needs to send in millions of pps which is (slightly) harder today. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 13 05:55:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrtQs-0003dH-ST; Tue, 13 Nov 2007 05:55:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrtQq-0005DP-GD; Tue, 13 Nov 2007 05:55:50 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrtK1-0002Wf-Sw for namedroppers-data@psg.com; Tue, 13 Nov 2007 10:48:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [204.152.184.167] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrtJX-0002Ub-82 for namedroppers@ops.ietf.org; Tue, 13 Nov 2007 10:48:30 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id 2EC9E114049; Tue, 13 Nov 2007 10:48:12 +0000 (UTC) (envelope-from Shane_Kerr@isc.org) Received: from [199.6.1.234] (unknown [199.6.1.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id ADF2BE6056; Tue, 13 Nov 2007 10:48:11 +0000 (UTC) (envelope-from shane@isc.org) Message-ID: <473980E9.2080808@isc.org> Date: Tue, 13 Nov 2007 11:48:09 +0100 From: Shane Kerr Reply-To: shane_kerr@isc.org Organization: ISC User-Agent: Thunderbird 2.0.0.6 (X11/20070806) MIME-Version: 1.0 To: Alex Bligh CC: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <27988.1194879471@sa.vix.com> <20071112154535.GC31775@outpost.ds9a.nl> <86081.1194888591@sa.vix.com> <20071112220343.GA19255@outpost.ds9a.nl> <20071112223543.GA12580@laperouse.bortzmeyer.org> <200711130151.lAD1pwc7018934@ogud.com> <9DA7DD82F603E908F9D0443C@Ximenes.local> In-Reply-To: <9DA7DD82F603E908F9D0443C@Ximenes.local> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alex, Alex Bligh wrote: > > The reason I picked this threshold was if you imagine the situation > where a third party engineers a situation where the resolver concerned > makes all queries to a server in the control of a third party I think this rationale makes sense. One thing I often find missing from RFCs is exactly this sort explanation. Maybe including it would be useful? - -- Shane -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHOYDmMsfZxBO4kbQRAsoRAJ0WGcP0/oa/QUDTnuUbAPgo0NNpIwCgyhF4 XUFtJp1CH0CcS2lKmY4rM8Y= =wL4P -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 13 07:33:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iruxe-0007Ly-Cf; Tue, 13 Nov 2007 07:33:46 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iruxb-0008BE-17; Tue, 13 Nov 2007 07:33:46 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Irur4-000Cxn-PZ for namedroppers-data@psg.com; Tue, 13 Nov 2007 12:26:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IruqZ-000CtT-Md for namedroppers@ops.ietf.org; Tue, 13 Nov 2007 12:26:43 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) by open.nlnetlabs.nl (8.14.1/8.14.1) with ESMTP id lADCQ9XS055398; Tue, 13 Nov 2007 13:26:09 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <473997E1.9090008@nlnetlabs.nl> Date: Tue, 13 Nov 2007 13:26:09 +0100 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: Alex Bligh CC: Tony Finch , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> <87k5ona0ag.fsf@mid.deneb.enyo.de> <473966D1.4070803@nlnetlabs.nl> <498B60125701B610547919C1@Ximenes.local> In-Reply-To: <498B60125701B610547919C1@Ximenes.local> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Tue, 13 Nov 2007 13:26:10 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -3.7 (---) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alex Bligh wrote: > 1-exp(-n*n/2H) I think you mean. I'm not sure that's right though because Yes that formula. > it won't use a random ID, it will use a random ID that is not already > outstanding. In which case the server simply has 500 IDs outstanding Well text, suggesting to use a random ID that is not already outstanding, could be added to the draft to clear up that true 'random only' is not such a good idea. That is what I meant. Otherwise, I agree with your analysis. > (on average) at any one time out of a maximum possible ID space of 2^16, > which means if the attacker sends in one packet, he'd have a chance > of 0.7% of picking one outstanding. Send in tens of thousands of > packets a second (for instance one with every ID) and you are guaranteed > a match. But you'd also have to match not only the ID, but also the > QNAME etc. If one uses random ports as well, one needs to send in > millions of pps which is (slightly) harder today. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHOZfhkDLqNwOhpPgRAqYsAKCtfvBvI7AGqkZqrtcdM6EyhMk8PgCfW2fV tQuvHZljDipd+v0OYgI58OM= =sNSy -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 13 09:51:42 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irx78-000335-P3; Tue, 13 Nov 2007 09:51:42 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irx75-0004b3-Ki; Tue, 13 Nov 2007 09:51:42 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Irwzc-0004KZ-3P for namedroppers-data@psg.com; Tue, 13 Nov 2007 14:43:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrwzO-0004Hx-RE for namedroppers@ops.ietf.org; Tue, 13 Nov 2007 14:43:50 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0D9B111426 for ; Tue, 13 Nov 2007 14:43:42 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt In-Reply-To: Your message of "Tue, 13 Nov 2007 09:56:49 +0100." <473966D1.4070803@nlnetlabs.nl> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> <87k5ona0ag.fsf@mid.deneb.enyo.de> <473966D1.4070803@nlnetlabs.nl> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 13 Nov 2007 14:43:42 +0000 Message-ID: <2803.1194965022@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a > A quick calculation says that a busy resolver, talking to a > forwarder/cache, with 1000 queries per second, each query takes 500 msec > to be answered, that uses a plain random 16bit ID (no extra ports), has > 85% chance of having a duplicate ID outstanding, and thus being unable > to disambiguate the reply. That is pretty high, I think the draft can > say something about avoiding these ID clashes. i don't think the draft ought to mention avoiding id clashes. as marka said, some recursive servers do duplicate-suppression, that is, they won't launch another upstream query if they're already working on one that had the same , and no, is not a factor in that calculation, and yes, rfc1034/1035 permits this. also, i have in recent years developed (outside of the BIND framework) a recursive nameserver which, when selecting a for an upstream query, avoids any that are in use for existing upstream queries. so the 85% figure shown above may be affecting the performance of my DNS initiator, since if i get a collision i have to keep trying, but 0% of my upstream 's duplicate those already in flight. ever. this thread appears to have ratholed. bert proposed language. are we there yet? -- to unsubscribe send a message to namedroppers-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 Nov 13 10:24:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irxd4-0006Xk-J0; Tue, 13 Nov 2007 10:24:42 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irxd0-0006zU-8n; Tue, 13 Nov 2007 10:24:42 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrxV6-0008oc-FP for namedroppers-data@psg.com; Tue, 13 Nov 2007 15:16:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.154.224.48] (helo=bert.secret-wg.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrxUU-0008mC-36 for namedroppers@ops.ietf.org; Tue, 13 Nov 2007 15:16:11 +0000 Received: from dhcp-07.nlnetlabs.nl (dhcp-07.nlnetlabs.nl [213.154.224.70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bert.secret-wg.org (Postfix) with ESMTPSA id 5BA0FB824; Tue, 13 Nov 2007 16:15:48 +0100 (CET) Cc: namedroppers@ops.ietf.org Message-Id: <46E117A5-8E74-49BE-974E-0403FF2EA212@NLnetLabs.nl> From: "Olaf M. Kolkman" To: Paul Vixie In-Reply-To: <2803.1194965022@sa.vix.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3--236100680" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Date: Tue, 13 Nov 2007 16:15:47 +0100 References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> <87k5ona0ag.fsf@mid.deneb.enyo.de> <473966D1.4070803@nlnetlabs.nl> <2803.1194965022@sa.vix.com> X-Pgp-Agent: GPGMail d50 (Leopard) X-Mailer: Apple Mail (2.912) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-3--236100680 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 13Nov 2007, at 3:43 PM, Paul Vixie wrote: > > this thread appears to have ratholed. bert proposed language. are we > there yet? You mean: "Implementations MUST NOT use Query-IDs that can easily be predicted" Speaking for myself: I found the discussion helpful to understand the issue in depth. Now I am comfortable with the above sentence. And for what its worth, the recursive nameserver of which development I am sideways involved in follows the behavior you describes too :-) --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-3--236100680 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: This message is locally signed. iD8DBQFHOb+jtN/ca3YJIocRAmZXAJ9oHdBtHKYsMJRN+vYz9HGcMlPR2ACfUVT1 aMckubOZCF1+LjV5K9zCozg= =bOcP -----END PGP SIGNATURE----- --Apple-Mail-3--236100680-- -- to unsubscribe send a message to namedroppers-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 Nov 13 11:09:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryKU-0005P2-Q6; Tue, 13 Nov 2007 11:09:34 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IryKS-0000Rj-Bd; Tue, 13 Nov 2007 11:09:34 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IryED-000EMJ-Vw for namedroppers-data@psg.com; Tue, 13 Nov 2007 16:03:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IryE3-000EKv-Dx for namedroppers@ops.ietf.org; Tue, 13 Nov 2007 16:03:00 +0000 Received: from mac-andrew.int.libertyrms.com ([10.1.3.198]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1IryE2-0002Nl-Qu for namedroppers@ops.ietf.org; Tue, 13 Nov 2007 11:02:54 -0500 Received: by trilby.local (Postfix, from userid 1019) id 951833AC036; Tue, 13 Nov 2007 11:04:45 -0500 (EST) Date: Tue, 13 Nov 2007 11:04:45 -0500 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <20071113160444.GC8030@afilias.info> Reply-To: Andrew Sullivan References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Mon, Nov 12, 2007 at 07:38:15PM +0000, Alex Bligh wrote: > "ID's SHOULD be assigned in a manner that the ability of a third party > with access wire data to guess ID's on subsequent queries is minimised; > this could, for instance, be achieved by introducing a pseudo-random > component into the mechanism used to select the ID". I like this version. It specifys narrowly the condition one is trying to avoid, and gives a clue about why one wants to avoid it. It provides an example of how to avoid it, but does not prescribe one. A -- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 jabber: ajsaf@jabber.org +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-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 Nov 13 11:31:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iryfd-0003UI-Q1; Tue, 13 Nov 2007 11:31:25 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iryfb-0002kQ-Gi; Tue, 13 Nov 2007 11:31:25 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrybB-000H6Z-1d for namedroppers-data@psg.com; Tue, 13 Nov 2007 16:26:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iryb0-000H5f-C5 for namedroppers@ops.ietf.org; Tue, 13 Nov 2007 16:26:43 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id EABE51142E; Tue, 13 Nov 2007 16:26:37 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Andrew Sullivan cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt In-Reply-To: Your message of "Tue, 13 Nov 2007 11:04:45 EST." <20071113160444.GC8030@afilias.info> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> <20071113160444.GC8030@afilias.info> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 13 Nov 2007 16:26:37 +0000 Message-ID: <28130.1194971197@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c > > "ID's SHOULD be assigned in a manner that the ability of a third party > > with access wire data to guess ID's on subsequent queries is minimised; > > this could, for instance, be achieved by introducing a pseudo-random > > component into the mechanism used to select the ID". > > I like this version. It specifys narrowly the condition one is trying > to avoid, and gives a clue about why one wants to avoid it. It > provides an example of how to avoid it, but does not prescribe one. i don't like this version, it overspecifies. i like bert's version. -- to unsubscribe send a message to namedroppers-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 Nov 14 05:12:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFEJ-0007gV-Uv; Wed, 14 Nov 2007 05:12:19 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsFEG-0003zV-Au; Wed, 14 Nov 2007 05:12:19 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IsF5G-000I65-85 for namedroppers-data@psg.com; Wed, 14 Nov 2007 10:02:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IsF4x-000I2T-MC for namedroppers@ops.ietf.org; Wed, 14 Nov 2007 10:02:52 +0000 Received: from [192.168.100.17] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id F003CC2DA3; Wed, 14 Nov 2007 10:02:36 +0000 (GMT) Date: Wed, 14 Nov 2007 10:02:21 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Andrew Sullivan , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <881F01A041B6208D6EBBA886@Ximenes.local> In-Reply-To: <20071113160444.GC8030@afilias.info> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <20071112100506.GA15120@laperouse.bortzmeyer.org> <87y7d3hi37.fsf@mid.deneb.enyo.de> <20071113160444.GC8030@afilias.info> 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: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 --On 13 November 2007 11:04:45 -0500 Andrew Sullivan wrote: > "ID's SHOULD be assigned in a manner that the ability of a third party > with access wire data to guess ID's on subsequent queries is minimised; > this could, for instance, be achieved by introducing a pseudo-random > component into the mechanism used to select the ID". It has been pointed out to me off list that there is an ambiguity, viz "how much wire data". What I meant was that the it should be difficult to guess if the malefactor has seen ALL the wire data (bar the packet being assembled which obviously hasn't yet been set). Being hard to guess if they have only seen a little is not sufficient (for the reasons I outlined before). We could thus change this to "with access to all previous wire data". Remember we are not trying to guard against the threat of someone with the wire data of the query packet to be sent (that would require DNSSEC), we are trying to specify how hard the query ID should be to guess (I have no strong feelings on this; I think it risks fuelling Paul's overspecification criticism but does make things easier). I wrote: > The reason I picked this threshold was if you imagine the situation > where a third party engineers a situation where the resolver concerned > makes all queries to a server in the control of a third party (e.g. > by making a user visit an html page with a sequence of links in > to addresses located within a domain controlled by him) and then > a single query of the server whose address he wants to fake (e.g. > a short delay then http://www.mybank.example.com/ or whatever), > then in practice the attacker has had access (or hopes he has had > access) to all (recent) wire data and we are hoping he can't > then guess the next ID - i.e. we are hoping the ID is hard to guess > when the third party has had access to 'all wire data'. It has been suggested this scenario only represents a snapshot of queries. The implicit criticism is "why not then require only that the ID is hard to guess for a malefactor with access to a recent snapshot of queries". The answer is "because it's hard to define a recent snapshot with any precision and requiring that the it is hard to guess if they've seen all previous data is sufficient (if more than is necessary)". Paul argues that this overspecifies things. I agree there is a highish hurdle here. But given we are talking about "minimising ability of a third party" within a "SHOULD" recommendation, I am not too concerned by that. Would "ID's SHOULD be assigned in a manner that attempts to minimise the ability of a third party with access to all previous wire data to guess ID subsequent queries" be better? Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 15 10:11:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsgNY-0007ea-Lq; Thu, 15 Nov 2007 10:11:40 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsgNU-000862-Fo; Thu, 15 Nov 2007 10:11:40 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IsgDr-000Hyf-Nv for namedroppers-data@psg.com; Thu, 15 Nov 2007 15:01:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [80.67.170.53] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IsgDL-000Hvq-0e for namedroppers@ops.ietf.org; Thu, 15 Nov 2007 15:01:23 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 186D1240826; Thu, 15 Nov 2007 15:00:52 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id DECDB1590BB; Thu, 15 Nov 2007 13:00:30 -0200 (BRST) Date: Thu, 15 Nov 2007 13:00:30 -0200 From: Stephane Bortzmeyer To: namedroppers@ops.ietf.org Subject: Microsoft: Vulnerability in DNS Could Allow Spoofing Message-ID: <20071115150030.GC8350@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Relevant for the discussion about draft-ietf-dnsext-forgery-resilience. See also http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-3898 Microsoft Security Bulletin MS07-062 - Affected Software: - Microsoft Windows 2000 Server Service Pack 4 - Windows Server 2003 Service Pack 1 - Windows Server 2003 Service Pack 2 - Windows Server 2003 x64 Edition - Windows Server 2003 x64 Edition Service Pack 2 - Windows Server 2003 with SP1 for Itanium-based Systems - Windows Server 2003 with SP2 for Itanium-based Systems - Impact: Spoofing - Version Number: 1.0 - - From Microsoft Security Bulletin MS07-062: Vulnerability Details DNS Spoofing Attack Vulnerability CVE-2007-3898 A spoofing vulnerability exists in Windows DNS Servers. The vulnerability could allow non-privileged users to send malicious responses to DNS requests, thereby spoofing or redirecting Internet traffic from legitimate locations. Mitigating Factors for DNS Spoofing Attack Vulnerability CVE-2007-3898 Mitigation refers to a setting, common configuration, or general best-practice, existing in a default state, that could reduce the severity of exploitation of a vulnerability. Microsoft has not identified any mitigations for this vulnerability. Top of sectionTop of section Workarounds for DNS Spoofing Attack Vulnerability CVE-2007-3898 Workaround refers to a setting or configuration change that does not correct the underlying vulnerability but would help block known attack vectors before you apply the update. Microsoft has not identified any workarounds for this vulnerability. FAQ for DNS Spoofing Attack Vulnerability CVE-2007-3898 What is the scope of the vulnerability? A spoofing vulnerability exists in Windows DNS Severs. An attacker who successfully exploited this vulnerability could impersonate a legitimate address. What causes the vulnerability? The Windows DNS Server service doesnt provide enough entropy in its random choice of transaction values when it sends out queries to upstream DNS servers. What might an attacker use the vulnerability to do? An attacker who successfully exploited this vulnerability could gain information about the DNS servers transaction IDs, and use that information to send malicious responses to DNS requests, thus redirecting Internet traffic from legitimate locations to an address of the attackers choice. How could an attacker exploit the vulnerability? An attacker who successfully exploited this vulnerability could respond to a DNS query with false or misleading information, thereby redirecting Internet traffic from legitimate locations. Could the vulnerability be exploited over the Internet? Yes, an attacker could exploit this vulnerability over the Internet by sending specific responses to an Internet-facing DNS server that is performing recursive lookups. What systems are primarily at risk from the vulnerability? This vulnerability applies to Windows DNS servers that perform recursive lookups. -- to unsubscribe send a message to namedroppers-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 Nov 15 12:22:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsiPn-0000Mg-Tx; Thu, 15 Nov 2007 12:22:08 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsiPk-00071f-O7; Thu, 15 Nov 2007 12:22:07 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IsiJt-0002Kz-Ss for namedroppers-data@psg.com; Thu, 15 Nov 2007 17:16:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-201.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.3 Received: from [156.154.24.139] (helo=ns4.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IsiJ1-0002Fj-0b for namedroppers@ops.ietf.org; Thu, 15 Nov 2007 17:15:26 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 2A4362AC6B; Thu, 15 Nov 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IsiIv-0001xu-U3; Thu, 15 Nov 2007 12:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2672bis-dname-06.txt Message-Id: Date: Thu, 15 Nov 2007 12:15:01 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Update to DNAME Redirection in the DNS Author(s) : S. Rose, W. Wijngaards Filename : draft-ietf-dnsext-rfc2672bis-dname-06.txt Pages : 16 Date : 2007-11-15 The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is an update to the original specification in RFC 2672. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2672bis-dname-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-15110734.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2672bis-dname-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-15110734.I-D@ietf.org> --OtherAccess-- --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 Nov 15 13:36:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isja2-0001aB-AX; Thu, 15 Nov 2007 13:36:46 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsjZx-0001lF-R6; Thu, 15 Nov 2007 13:36:46 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IsjTK-0009S8-I3 for namedroppers-data@psg.com; Thu, 15 Nov 2007 18:29:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IsjSd-0009NZ-Kd for namedroppers@ops.ietf.org; Thu, 15 Nov 2007 18:29:31 +0000 Received: from postmark.nist.gov (emailha2.nist.gov [129.6.16.198]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id lAFIT2br010214 for ; Thu, 15 Nov 2007 13:29:02 -0500 Received: from 619893L ([129.6.220.160]) by postmark.nist.gov (8.13.1/8.13.1) with SMTP id lAFITK31020946 for ; Thu, 15 Nov 2007 13:29:22 -0500 From: "Scott Rose" To: Subject: RE: I-D ACTION:draft-ietf-dnsext-rfc2672bis-dname-06.txt Date: Thu, 15 Nov 2007 13:28:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Importance: Normal In-Reply-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Major changes (from -05): 1. addressed comments from Ed Lewis: http://ops.ietf.org/lists/namedroppers/namedroppers.2007/msg00531.html 2. Removed NSEC3 discussion (NSEC3 draft has the same text that was in -05) 3. Changed the TTL of synthesized CNAME RRs from 0 to the TTL of the corresponding DNAME RR (as per Mark Andrews and Ed Lewis' comments). Wouter and I think that this draft is pretty much done at this point. I'd like to ask the WG (and chair) to start the working group last call and get this draft progressed. Scott > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DNS Extensions Working Group of the IETF. > > Title : Update to DNAME Redirection in the DNS > Author(s) : S. Rose, W. Wijngaards > Filename : draft-ietf-dnsext-rfc2672bis-dname-06.txt > Pages : 16 > Date : 2007-11-15 > > The DNAME record provides redirection for a sub-tree of the domain > name tree in the DNS system. That is, all names that end with a > particular suffix are redirected to another part of the DNS. This is > an update to the original specification in RFC 2672. > > -- to unsubscribe send a message to namedroppers-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 Nov 17 05:25:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItKs1-0007UJ-DX; Sat, 17 Nov 2007 05:25:49 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItKrx-0007cZ-UP; Sat, 17 Nov 2007 05:25:49 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItKke-000G3E-AP for namedroppers-data@psg.com; Sat, 17 Nov 2007 10:18:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [80.67.170.53] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItKkT-000G2A-In for namedroppers@ops.ietf.org; Sat, 17 Nov 2007 10:18:06 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 0BF9C240823; Sat, 17 Nov 2007 10:17:03 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 1EF6D1590AC; Fri, 16 Nov 2007 12:55:13 -0200 (BRST) Date: Fri, 16 Nov 2007 12:55:14 -0200 From: Stephane Bortzmeyer To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <20071116145514.GB18431@laperouse.bortzmeyer.org> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <27988.1194879471@sa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27988.1194879471@sa.vix.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Mon, Nov 12, 2007 at 02:57:51PM +0000, Paul Vixie wrote a message of 24 lines which said: > there's no consensus that even a ~31 bit pseudo random combination > of source port and query ID is good enough to have confidence that > any given answer was really received from a purported server. As mentioned by Bert, we do not try to achieve the same result as DNSSEC. We try to raise the bar for the attacker. A sort of Better-Than-Nothing security. > there is also no consensus on the meaning of "good" in the context > of "good random source". some say arc4random is fine, others say > it's too weak. Hence the idea to delegate the whole point to RFC 4086, which is already written. -- to unsubscribe send a message to namedroppers-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 Nov 17 05:25:54 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItKs6-0007Yw-Cm; Sat, 17 Nov 2007 05:25:54 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItKs4-0007cq-0u; Sat, 17 Nov 2007 05:25:54 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItKkL-000G1l-V7 for namedroppers-data@psg.com; Sat, 17 Nov 2007 10:17:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_06_12,RDNS_NONE autolearn=no version=3.2.3 Received: from [80.67.170.53] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItKk6-000G0R-SM for namedroppers@ops.ietf.org; Sat, 17 Nov 2007 10:17:48 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id E1BEB240837; Sat, 17 Nov 2007 10:17:21 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 025A71590AC; Fri, 16 Nov 2007 19:55:13 -0200 (BRST) Date: Fri, 16 Nov 2007 19:55:13 -0200 From: Stephane Bortzmeyer To: Jim Reid Cc: namedroppers@ops.ietf.org Subject: Re: I-D Action:draft-reid-dnsext-zs-00.txt Message-ID: <20071116215513.GA6441@laperouse.bortzmeyer.org> References: 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 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -2.1 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 On Mon, Nov 12, 2007 at 08:20:01AM -0500, Internet-Drafts@ietf.org wrote a message of 88 lines which said: > Title : The Zone Status (ZS) DNS Resource Record > Author(s) : J. Reid > Filename : draft-reid-dnsext-zs-00.txt I'm not really convinced of the usefulness of this RR. It is non structured (so it cannot be automatically parsed) and the only thing it gives that TXT does not provide is the ability to query only ZS records, which does not seem a lot. (In the wild, TXT records seem to be used a lot for this purpose, sometimes with a full CVS $Id$ in a TXT value.) If someone wants to work on this topic, I would suggest a more structured RR. Things like the date of the last update should really be a parsable type. But I'm not sure it is worth working on that instead of, for instance, IRIS for things like "publishing real-time contact data for [ENUM] zone owners" or the various presence protocols (RFC 3856, or RFC 3921) for things like "the zone owner is asleep, so don't bother trying voice-based communication". The end user considerations section seems to be quite broken, as far as i18n is concerned. Speaking of "unusual character sets" is inappropriate, specially when the examples given are Chinese and Arabic scripts, hardly "unusual". If such records would be used for messages to the end-user, as suggested in section 3, a real i18n would be necessary, with language-tagging of the messages. -- to unsubscribe send a message to namedroppers-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 Nov 17 05:26:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItKsS-00081u-42; Sat, 17 Nov 2007 05:26:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItKsQ-0007dK-VY; Sat, 17 Nov 2007 05:26:16 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItKk6-000G0V-HF for namedroppers-data@psg.com; Sat, 17 Nov 2007 10:17:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24,RDNS_NONE autolearn=no version=3.2.3 Received: from [80.67.170.53] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItKjv-000FzT-TF for namedroppers@ops.ietf.org; Sat, 17 Nov 2007 10:17:33 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 502ED24082E; Sat, 17 Nov 2007 10:17:12 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 8BBBB1590AC; Fri, 16 Nov 2007 13:00:43 -0200 (BRST) Date: Fri, 16 Nov 2007 13:00:43 -0200 From: Stephane Bortzmeyer To: Shane Kerr Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <20071116150042.GA25176@laperouse.bortzmeyer.org> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <27988.1194879471@sa.vix.com> <20071112154535.GC31775@outpost.ds9a.nl> <86081.1194888591@sa.vix.com> <20071112220343.GA19255@outpost.ds9a.nl> <20071112223543.GA12580@laperouse.bortzmeyer.org> <200711130151.lAD1pwc7018934@ogud.com> <9DA7DD82F603E908F9D0443C@Ximenes.local> <473980E9.2080808@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <473980E9.2080808@isc.org> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -2.2 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 On Tue, Nov 13, 2007 at 11:48:09AM +0100, Shane Kerr wrote a message of 29 lines which said: > I think this rationale makes sense. One thing I often find missing > from RFCs is exactly this sort explanation. +1 As long as the rationale is clearly separated from the normative text (rationales and case studies tend to rot and to be not longer relevant after a while). > Maybe including it would be useful? What do you think of my proposed text? -- to unsubscribe send a message to namedroppers-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 Nov 17 05:28:36 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItKui-0001mx-BN; Sat, 17 Nov 2007 05:28:36 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItKud-0007hy-IJ; Sat, 17 Nov 2007 05:28:36 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItKjv-000Fze-RI for namedroppers-data@psg.com; Sat, 17 Nov 2007 10:17:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24,RDNS_NONE autolearn=no version=3.2.3 Received: from [80.67.170.53] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItKjk-000Fxf-OE for namedroppers@ops.ietf.org; Sat, 17 Nov 2007 10:17:22 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 16A6E240822; Sat, 17 Nov 2007 10:17:03 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id E1B9B1590AC; Fri, 16 Nov 2007 12:52:37 -0200 (BRST) Date: Fri, 16 Nov 2007 12:52:37 -0200 From: Stephane Bortzmeyer To: bert hubert Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <20071116145237.GA18431@laperouse.bortzmeyer.org> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <27988.1194879471@sa.vix.com> <20071112154535.GC31775@outpost.ds9a.nl> <86081.1194888591@sa.vix.com> <20071112220343.GA19255@outpost.ds9a.nl> <20071112223543.GA12580@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071112223543.GA12580@laperouse.bortzmeyer.org> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -2.2 (--) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 On Mon, Nov 12, 2007 at 08:35:43PM -0200, Stephane Bortzmeyer wrote a message of 25 lines which said: > More detailed, with the help of Alex Bligh: New version that I propose, with a clearer separation between the norm and the rationale (they could even be placed in different sections). I believe this captures the discussion in the WG and that nothing was forgotten. Rule: Implementations MUST use Query-IDs that are hard to predict for a third party, even if this third party has access to previous wire data. Advice for implementors: "Hard to predict" Query-IDs could, for instance, be achieved by introducing a random [RFC 4086] or pseudo-random component into the mechanism used to select the ID. Be warned that Query-IDs of outstanding requests should not be reused so a purely random solution is dangerous. For instance, a recursive server can have another recursive server upstream and some recursive servers do duplicate-suppression, that is, they won't launch another upstream query if they're already working on one that had the same ( is not a factor in that calculation). Rationale: Predictable Query-IDs are dangerous because they allow the bad guys to easily spoof responses. Purely random Query-IDs may lead to problems for the resolver which emits them, because there will be a high risk of duplicate IDs. Sorting out duplicated IDs in responses is easy if the response contains the and but more complicated for errors like SERVFAIL. So, a possible solution is to choose randomly from the pool of IDs not currently used by a pending query. Even without the ability to snoop on the wire, a third party can still have access to wire data, for instance, where the resolver concerned makes all queries to a server in the control of a third party (e.g. by making a user visit an HTML page with a sequence of links in to addresses located within a domain controlled by him) and then a single query of the server whose address he wants to fake (e.g. a short delay then http://www.mybank.example.com/). Then in practice the attacker has had access (or hopes he has had access) to all (recent) wire data and we are hoping he can't then guess the next ID - i.e. we are hoping the ID is hard to guess when the third party has had access to 'all former wire 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 Sat Nov 17 07:02:54 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItMNy-0002Su-3P; Sat, 17 Nov 2007 07:02:54 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItMNv-00025P-O2; Sat, 17 Nov 2007 07:02:54 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItMHj-000NgH-9y for namedroppers-data@psg.com; Sat, 17 Nov 2007 11:56:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItMHY-000NfX-K3 for namedroppers@ops.ietf.org; Sat, 17 Nov 2007 11:56:21 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 443B1D6C18; Sat, 17 Nov 2007 11:56:13 +0000 (GMT) Date: Sat, 17 Nov 2007 11:56:10 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Stephane Bortzmeyer , bert hubert cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: In-Reply-To: <20071116145237.GA18431@laperouse.bortzmeyer.org> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <27988.1194879471@sa.vix.com> <20071112154535.GC31775@outpost.ds9a.nl> <86081.1194888591@sa.vix.com> <20071112220343.GA19255@outpost.ds9a.nl> <20071112223543.GA12580@laperouse.bortzmeyer.org> <20071116145237.GA18431@laperouse.bortzmeyer.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: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 --On 16 November 2007 12:52:37 -0200 Stephane Bortzmeyer wrote: > On Mon, Nov 12, 2007 at 08:35:43PM -0200, > Stephane Bortzmeyer wrote > a message of 25 lines which said: > >> More detailed, with the help of Alex Bligh: > > New version that I propose, This works for me. I am presuming the "Rationale" section is not for the RFC but for the list, or we might change "bad guys" to "attacker" etc. [ I Had drafted a response saying it may be that duplicating query IDs where the rest of the query n-tuple is different is desirable on high volume query originators, with some stats to indicate when it might be necessary, and rephrased in terms of the necessity of disambiguating responses rather than merely saying "dangerous". However, given the difficulties with SERVFAIL etc., I concluded that if you stick all this in, you are left more with the definition of a problem for an implementers rather than implementation advice. On the basis these extra words were thus unhelpful, I suggest sticking with what you wrote ] 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 Sat Nov 17 08:07:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItNO8-00010u-BM; Sat, 17 Nov 2007 08:07:09 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItNO4-0004p3-K0; Sat, 17 Nov 2007 08:07:08 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItNIC-0002dZ-8X for namedroppers-data@psg.com; Sat, 17 Nov 2007 13:01:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_DHCP,RDNS_NONE autolearn=no version=3.2.3 Received: from [82.93.240.211] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItNHd-0002Zo-8Y for namedroppers@ops.ietf.org; Sat, 17 Nov 2007 13:00:42 +0000 Received: from outpost.ds9a.nl ([213.244.168.210] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1ItNHa-0000jT-9n for namedroppers@ops.ietf.org; Sat, 17 Nov 2007 14:00:22 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id E5AFE4082; Sat, 17 Nov 2007 14:00:21 +0100 (CET) Date: Sat, 17 Nov 2007 14:00:21 +0100 From: bert hubert To: Stephane Bortzmeyer Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <20071117130021.GC31179@outpost.ds9a.nl> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <27988.1194879471@sa.vix.com> <20071112154535.GC31775@outpost.ds9a.nl> <86081.1194888591@sa.vix.com> <20071112220343.GA19255@outpost.ds9a.nl> <20071112223543.GA12580@laperouse.bortzmeyer.org> <20071116145237.GA18431@laperouse.bortzmeyer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071116145237.GA18431@laperouse.bortzmeyer.org> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Fri, Nov 16, 2007 at 12:52:37PM -0200, Stephane Bortzmeyer wrote: > New version that I propose, with a clearer separation between the norm > and the rationale (they could even be placed in different sections). I > believe this captures the discussion in the WG and that nothing was > forgotten. > > > Rule: > > Implementations MUST use Query-IDs that are hard to predict for a > third party, even if this third party has access to previous wire > data. I like it a lot. > Advice for implementors: > > "Hard to predict" Query-IDs could, for instance, be achieved by > introducing a random [RFC 4086] or pseudo-random component into the This could be put in chapter 10, 'rationale' perhaps. Thanks! -- 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 Sat Nov 17 08:12:24 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItNTE-0004D4-Du; Sat, 17 Nov 2007 08:12:24 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItNTB-0004zR-9r; Sat, 17 Nov 2007 08:12:24 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItNOX-00035T-TS for namedroppers-data@psg.com; Sat, 17 Nov 2007 13:07:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [80.67.170.53] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItNON-00033C-5H for namedroppers@ops.ietf.org; Sat, 17 Nov 2007 13:07:28 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 524BC240826; Sat, 17 Nov 2007 13:07:07 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 294171590AC; Sat, 17 Nov 2007 11:01:05 -0200 (BRST) Date: Sat, 17 Nov 2007 14:01:06 +0100 From: Stephane Bortzmeyer To: Alex Bligh Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <20071117130106.GA19823@laperouse.bortzmeyer.org> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <27988.1194879471@sa.vix.com> <20071112154535.GC31775@outpost.ds9a.nl> <86081.1194888591@sa.vix.com> <20071112220343.GA19255@outpost.ds9a.nl> <20071112223543.GA12580@laperouse.bortzmeyer.org> <20071116145237.GA18431@laperouse.bortzmeyer.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 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Sat, Nov 17, 2007 at 11:56:10AM +0000, Alex Bligh wrote a message of 28 lines which said: > I am presuming the "Rationale" section is not for the RFC but for > the list, IMHO, no, it should go into the RFC. I'm one of the people who think that RFCs lack rationales and explanations. Of course, the rationale must be clearly separated from the normative rules. > or we might change "bad guys" to "attacker" etc. OK -- to unsubscribe send a message to namedroppers-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 Nov 17 18:56:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItXWh-0003SJ-G1; Sat, 17 Nov 2007 18:56:39 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItXWd-0000mj-1D; Sat, 17 Nov 2007 18:56:39 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItXMI-0002Le-PC for namedroppers-data@psg.com; Sat, 17 Nov 2007 23:45:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItXM8-0002KS-2o for namedroppers@ops.ietf.org; Sat, 17 Nov 2007 23:45:49 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1ItXM1-0003x2-IQ; Sun, 18 Nov 2007 00:45:38 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.68) (envelope-from ) id 1ItXLy-0005AO-NR; Sun, 18 Nov 2007 00:45:34 +0100 From: Florian Weimer To: Stephane Bortzmeyer Cc: bert hubert , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <27988.1194879471@sa.vix.com> <20071112154535.GC31775@outpost.ds9a.nl> <86081.1194888591@sa.vix.com> <20071112220343.GA19255@outpost.ds9a.nl> <20071112223543.GA12580@laperouse.bortzmeyer.org> <20071116145237.GA18431@laperouse.bortzmeyer.org> Date: Sun, 18 Nov 2007 00:45:34 +0100 In-Reply-To: <20071116145237.GA18431@laperouse.bortzmeyer.org> (Stephane Bortzmeyer's message of "Fri, 16 Nov 2007 12:52:37 -0200") Message-ID: <87wssg8mht.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 * Stephane Bortzmeyer: > "Hard to predict" Query-IDs could, for instance, be achieved by > introducing a random [RFC 4086] or pseudo-random component into the Nit: RFC 4086 covers pseudo-randomness as well. Not very extensively, but it's there. > Purely random Query-IDs may lead to problems for the resolver which > emits them, because there will be a high risk of duplicate > IDs. Sorting out duplicated IDs in responses is easy if the response > contains the and but more complicated for errors like > SERVFAIL. Ah! Finally a reason for non-repeating IDs. Thanks. -- to unsubscribe send a message to namedroppers-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 Nov 18 08:51:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItkYO-00080C-1O; Sun, 18 Nov 2007 08:51:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItkYL-0003yx-JN; Sun, 18 Nov 2007 08:51:16 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItkPt-000BAc-CC for namedroppers-data@psg.com; Sun, 18 Nov 2007 13:42:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [80.67.170.53] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItkPf-000B8T-Bu for namedroppers@ops.ietf.org; Sun, 18 Nov 2007 13:42:23 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id A3CE8240822; Sun, 18 Nov 2007 13:42:00 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 77A4B1590AC; Sun, 18 Nov 2007 14:29:48 +0100 (CET) Date: Sun, 18 Nov 2007 14:29:48 +0100 From: Stephane Bortzmeyer To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <20071118132948.GA13052@laperouse.bortzmeyer.org> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071110214233.GB8260@laperouse.bortzmeyer.org> X-Transport: UUCP rules X-Operating-System: Ubuntu 7.10 (gutsy) User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Sat, Nov 10, 2007 at 07:42:33PM -0200, Stephane Bortzmeyer wrote a message of 30 lines which said: > * -01 says "TBD: Do we need to talk about stub resolvers? Does this > draft apply to them?" I believe that the answer is yes. A typical stub > resolver cannot receive unexpected answers (it typically does not > listen for ever on the network) but it still can be fooled when > listening for a reply. In addition, a typical stub resolver should > listen only to the answers coming from the nameservers listed in its > configuration (/etc/resolv.conf on Unix) but I'm not sure they all > do and, anyway, it is not sufficient, the other countermeasures > mentioned in section 9 all apply. And about this issue? Everybody agrees? -- to unsubscribe send a message to namedroppers-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 Nov 18 09:26:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itl67-0006CT-UK; Sun, 18 Nov 2007 09:26:07 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itl65-00056B-D1; Sun, 18 Nov 2007 09:26:07 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Itl1u-000EWW-1M for namedroppers-data@psg.com; Sun, 18 Nov 2007 14:21:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_DHCP,RDNS_NONE autolearn=no version=3.2.3 Received: from [82.93.240.211] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Itl1C-000ESQ-7Z for namedroppers@ops.ietf.org; Sun, 18 Nov 2007 14:21:27 +0000 Received: from outpost.ds9a.nl ([213.244.168.210] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1Itl16-0000nY-VX for namedroppers@ops.ietf.org; Sun, 18 Nov 2007 15:20:57 +0100 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 949DD4040; Sun, 18 Nov 2007 15:20:56 +0100 (CET) Date: Sun, 18 Nov 2007 15:20:56 +0100 From: bert hubert To: Stephane Bortzmeyer Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <20071118142056.GC23565@outpost.ds9a.nl> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <20071118132948.GA13052@laperouse.bortzmeyer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071118132948.GA13052@laperouse.bortzmeyer.org> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Sun, Nov 18, 2007 at 02:29:48PM +0100, Stephane Bortzmeyer wrote: > > * -01 says "TBD: Do we need to talk about stub resolvers? Does this > > draft apply to them?" I believe that the answer is yes. A typical stub > > resolver cannot receive unexpected answers (it typically does not > > listen for ever on the network) but it still can be fooled when > > listening for a reply. In addition, a typical stub resolver should > > listen only to the answers coming from the nameservers listed in its > > configuration (/etc/resolv.conf on Unix) but I'm not sure they all > > do and, anyway, it is not sufficient, the other countermeasures > > mentioned in section 9 all apply. > > And about this issue? Everybody agrees? I agree, at least. -- 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 Nov 18 10:05:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itli4-0000BY-C9; Sun, 18 Nov 2007 10:05:20 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itli1-00062R-Vn; Sun, 18 Nov 2007 10:05:20 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Itlcg-000HhK-0f for namedroppers-data@psg.com; Sun, 18 Nov 2007 14:59:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItlcV-000Hgk-94 for namedroppers@ops.ietf.org; Sun, 18 Nov 2007 14:59:40 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id BFF86C2DAB; Sun, 18 Nov 2007 14:59:30 +0000 (GMT) Date: Sun, 18 Nov 2007 14:59:26 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Stephane Bortzmeyer , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt Message-ID: <969DEC34FF6CE0A738B95CAA@Ximines.local> In-Reply-To: <20071118132948.GA13052@laperouse.bortzmeyer.org> References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <20071118132948.GA13052@laperouse.bortzmeyer.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: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 --On 18 November 2007 14:29:48 +0100 Stephane Bortzmeyer wrote: >> * -01 says "TBD: Do we need to talk about stub resolvers? Does this >> draft apply to them?" I believe that the answer is yes. A typical stub >> resolver cannot receive unexpected answers (it typically does not >> listen for ever on the network) but it still can be fooled when >> listening for a reply. In addition, a typical stub resolver should >> listen only to the answers coming from the nameservers listed in its >> configuration (/etc/resolv.conf on Unix) but I'm not sure they all >> do and, anyway, it is not sufficient, the other countermeasures >> mentioned in section 9 all apply. > > And about this issue? Everybody agrees? Yes, though I am not sure the "In addition" bit adds anything. Either it means it should only listen to answers with the IP source address of those nameservers (which I am pretty sure is taken care of in the normal rules for any query originating host unless I am missing something), or it means they should somehow be able to determine whether the answers /actually/ come from those nameservers and are thus not spoofed (which is not possible). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Nov 18 15:38:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itque-00042u-H7; Sun, 18 Nov 2007 15:38:40 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itqub-0007F5-5a; Sun, 18 Nov 2007 15:38:40 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Itqo1-000JVL-Pt for namedroppers-data@psg.com; Sun, 18 Nov 2007 20:31:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [204.152.184.138] (helo=mail2.ntp.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Itqnr-000JUd-7e for namedroppers@ops.ietf.org; Sun, 18 Nov 2007 20:31:44 +0000 Received: from 65-86-158-146.client.dsl.net (65-86-158-146.client.dsl.net [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 EE537398AE; Sun, 18 Nov 2007 20:31:37 +0000 (UTC) (envelope-from mayer@gis.net) Received: from host178.209-113-182.oem.net ([209.113.182.178] helo=[172.16.2.49]) by 65-86-158-146.client.dsl.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Itqnd-0005UH-Uu; Sun, 18 Nov 2007 15:31:26 -0500 Message-ID: <4740A060.6010501@gis.net> Date: Sun, 18 Nov 2007 15:28:16 -0500 From: Danny Mayer Reply-To: mayer@gis.net User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Stephane Bortzmeyer Cc: bert hubert , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <27988.1194879471@sa.vix.com> <20071112154535.GC31775@outpost.ds9a.nl> <86081.1194888591@sa.vix.com> <20071112220343.GA19255@outpost.ds9a.nl> <20071112223543.GA12580@laperouse.bortzmeyer.org> In-Reply-To: <20071112223543.GA12580@laperouse.bortzmeyer.org> X-Enigmail-Version: 0.95.5 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@gis.net Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Stephane Bortzmeyer wrote: > On Mon, Nov 12, 2007 at 11:03:44PM +0100, > bert hubert wrote > a message of 34 lines which said: > >> Implementations MUST use Query-IDs that are hard to predict > > More detailed, with the help of Alex Bligh: > > Implementations MUST use Query-IDs that are hard to predict for a > third party with access to wire data. This could, for instance, be > achieved by introducing a random [RFC 4086] or pseudo-random component > into the mechanism used to select the ID > > -- > Read on /., about MS-Windows error messages: > > Your system must meet the requirements to be able to run the Windows > Random Number Generator on Vista. Otherwise, you will need to use > Windows Number Generator Basic. The only number WNGB can generate is > 4. You can use CryptGenRandom() on Windows if you want a good random number generator. However, none of this has anything to do with the question on Query-IDs and is at a level of detail that the implementor would be dealing with. 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 Sun Nov 18 23:18:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ity5N-0008QA-0W; Sun, 18 Nov 2007 23:18:13 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ity5K-00055i-Ig; Sun, 18 Nov 2007 23:18:12 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItxyG-0007Tl-Tb for namedroppers-data@psg.com; Mon, 19 Nov 2007 04:10:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-202.0 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.3 Received: from [156.154.16.158] (helo=ns0.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItxxT-0007P8-5s for namedroppers@ops.ietf.org; Mon, 19 Nov 2007 04:10:33 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 47DED328F6; Mon, 19 Nov 2007 04:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItxxS-0001IJ-6b; Sun, 18 Nov 2007 23:10:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-dnsext-dnssec-bis-updates-06.txt Message-Id: Date: Sun, 18 Nov 2007 23:10:02 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Clarifications and Implementation Notes for DNSSECbis Author(s) : S. Weiler, R. Austein Filename : draft-ietf-dnsext-dnssec-bis-updates-06.txt Pages : 11 Date : 2007-11-18 This document is a collection of minor technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as an interim repository of DNSSECbis errata. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-bis-updates-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-18230958.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-bis-updates-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-18230958.I-D\@ietf.org> --OtherAccess-- --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 Sun Nov 18 23:25:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItyC2-0004pp-E1; Sun, 18 Nov 2007 23:25:06 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItyBx-0005DE-BZ; Sun, 18 Nov 2007 23:25:06 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ity8m-0008CR-Um for namedroppers-data@psg.com; Mon, 19 Nov 2007 04:21:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ity8c-0008Bj-B5 for namedroppers@ops.ietf.org; Mon, 19 Nov 2007 04:21:39 +0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id lAJ4Kicf005332; Sun, 18 Nov 2007 22:20:44 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id lAJ4Ki5K027862; Sun, 18 Nov 2007 22:20:44 -0600 Received: from localhost ([157.185.80.253]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Nov 2007 23:20:43 -0500 Date: Sun, 18 Nov 2007 23:20:42 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@mint.samweiler.com To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair cc: IETF DNSEXT WG Subject: Re: Proposed resolution of Re: RFC4034 6.2 item 3 In-Reply-To: <200703151530.l2FFURuL025883@ogud.com> Message-ID: References: <200703132328.l2DNSNeX089585@drugs.dv.isc.org> <200703151530.l2FFURuL025883@ogud.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-913773773-1195441173=:7351" Content-ID: X-OriginalArrivalTime: 19 Nov 2007 04:20:43.0779 (UTC) FILETIME=[8D1EBD30:01C82A63] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Sun, 18 Nov 2007 22:20:44 -0600 (CST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-913773773-1195441173=:7351 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Thu, 15 Mar 2007, Ólafur Guðmundsson /DNSEXT co-chair wrote: > Proposed change: > RFC3597 trumps RFC403x > > NSEC and RRSIG should be removed from the list of types > to apply DNSSEC canonical down casing name rules to domain > names in RDATA. ... > WG Actions: > DNSSEC-bis-updates will reflect this change as soon a possible Done. Section 4.4 (Errors in Canonical Form Type Code List) has been moved up to Section 2 and expanded to cover NSEC and RRSIG. -- Sam --8323328-913773773-1195441173=:7351-- -- to unsubscribe send a message to namedroppers-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 Nov 18 23:25:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItyCS-0004s9-7t; Sun, 18 Nov 2007 23:25:32 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItyCO-0005Db-Lm; Sun, 18 Nov 2007 23:25:32 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ity8K-0008B6-Oc for namedroppers-data@psg.com; Mon, 19 Nov 2007 04:21:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ity7l-00087u-82 for namedroppers@ops.ietf.org; Mon, 19 Nov 2007 04:21:00 +0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id lAJ4KZFP005324; Sun, 18 Nov 2007 22:20:35 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id lAJ4KZIV027859; Sun, 18 Nov 2007 22:20:35 -0600 Received: from localhost ([157.185.80.253]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Nov 2007 23:20:34 -0500 Date: Sun, 18 Nov 2007 23:20:34 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@mint.samweiler.com To: Scott Rose cc: IETF DNSEXT WG , Michael StJohns Subject: Re: comments on draft-ietf-dnsext-dnssec-bis-updates-05 In-Reply-To: <45F03C9B.3050308@nist.gov> Message-ID: References: <45F03C9B.3050308@nist.gov> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 19 Nov 2007 04:20:35.0029 (UTC) FILETIME=[87E79850:01C82A63] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Sun, 18 Nov 2007 22:20:35 -0600 (CST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 On Thu, 8 Mar 2007, Scott Rose wrote: > I just (quickly) read over the -05 version of the DNSSEC-bis-updates draft. > I noticed 2 typos and 1 issue that may have been resolved, but I can't > remember. [typos snipped] Thank you for catching these. The newest version of the draft fixes both typos. > Also, I remember on thing from MSJ's DNSSEC-SO draft: In section 2.3.2.2, > third bullet item (in regards to recursive caching servers): > > The resolver side MUST also set the CD bit when sending queries > when the CD bit is set in the initiating query. [Note: The > current behavior for a PNE recursive resolver may be in error.] > > Has this been covered in a thread? I don't remember. In my mind, it may be > necessary if there is some upstream cache in the middle. The caching > resolver still has the option (local policy) to perform validation after > sending the response back to the originator for determining the cache status > (BAD or not). I don't remember a thread on this, but I think RFC4035 already says this (implicitly) in the third paragraph of section 3.2.2: http://tools.ietf.org/html/rfc4035#section-3.2.2 Am I misunderstanding this? Do we need to clarify it further? (I'm CC'ing MSJ in case he might have some wisdom to offer.) -- Sam (dnssec-bis-updates co-editor) -- to unsubscribe send a message to namedroppers-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 Nov 18 23:25:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItyCd-0004yL-DH; Sun, 18 Nov 2007 23:25:43 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItyCY-0005Dm-Us; Sun, 18 Nov 2007 23:25:43 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ity8V-0008BV-Jx for namedroppers-data@psg.com; Mon, 19 Nov 2007 04:21:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ity8C-00089f-TZ for namedroppers@ops.ietf.org; Mon, 19 Nov 2007 04:21:14 +0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id lAJ4L5x8005343; Sun, 18 Nov 2007 22:21:05 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id lAJ4L5Af027867; Sun, 18 Nov 2007 22:21:05 -0600 Received: from localhost ([157.185.80.253]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Nov 2007 23:21:05 -0500 Date: Sun, 18 Nov 2007 23:21:04 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@mint.samweiler.com To: Roy Arends cc: namedroppers@ops.ietf.org Subject: Re: additions to dnssec-bis-updates-04.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 19 Nov 2007 04:21:05.0154 (UTC) FILETIME=[99DC4E20:01C82A63] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Sun, 18 Nov 2007 22:21:05 -0600 (CST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 On Mon, 5 Mar 2007, Roy Arends wrote: > According to the rules in 5.2, the validator needs to check for the > absence of DS and SOA in this NSEC record. This check passes. Obviously, > the validator needs to check for presence of the NS bit, but the section > does not mention that. Added, using Roy's text. I still don't fully understand the wildcard no data issue (below). I'll repeast my request for more discussion and/or suggested text. -- Sam >>> (4) expanding wildcards/wildcard no data response >>> >>> Both response types need a proof that the wildcard is at the closest >>> encloser. The closest encloser can be determined by comparing QNAME to >>> both ownername and nxtdname of the NSEC and take the nearest common >>> ancestor. Every NSEC in a response MUST have the same closest encloser >>> (this is fact, not a requirement). i.e. validator must check this way > that >>> there is no closer wildcard match. >> >> I'm vaguely remembering some discussion of why we didn't need anything >> more and why 4035's text was, in fact, sufficient. Since I don't >> fully recall the details, I'd like someone else to confirm this before >> we add it, and preferably to write the text on it. Can we have some >> more discussion on this item? > > Here is an example: > > zone: > > example.com NSEC *.example.com > *.example.com A 192.0.2.1 > bar.example.com NSEC *.bar.example.com > *.bar.example.com A 192.0.2.2 > alfa.bar.example.com NSEC gamma.bar.example.com > > Query: > > foo.bar.example.com A > > Spoofed response: > > foo.bar.example.com A 192.0.2.1 > foo.bar.example.com RRSIG (labelcnt=2) > alfa.bar.example.com NSEC gamma.bar.example.com > > Real response: > > foo.bar.example.com A 192.0.2.2 > foo.bar.example.com RRSIG (labelcnt=3) > alfa.bar.example.com NSEC gamma.bar.example.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 19 00:00:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itykl-0004WK-EC; Mon, 19 Nov 2007 00:00:59 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itykh-00062A-SO; Mon, 19 Nov 2007 00:00:59 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Itygv-000B26-CH for namedroppers-data@psg.com; Mon, 19 Nov 2007 04:57:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,MISSING_MID, RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.62.96] (helo=QMTA09.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItygL-000B0e-Nw for namedroppers@ops.ietf.org; Mon, 19 Nov 2007 04:56:45 +0000 Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA09.westchester.pa.mail.comcast.net with comcast id EU6A1Y00317dt5G0502L00; Mon, 19 Nov 2007 04:56:24 +0000 Received: from mikespersonal.comcast.net ([68.48.56.3]) by OMTA13.westchester.pa.mail.comcast.net with comcast id EUwP1Y00L04A3tg0300000; Mon, 19 Nov 2007 04:56:24 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=qzeQvZY3Kj7OW70J-cEA:9 a=Awm9HoYwjJ9md5W6GkQA:7 a=Wc6YT4va40Z5oc3KXpe8CMsONPkA:4 a=qO67t3yunzcA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 18 Nov 2007 23:56:29 -0500 To: Sam Weiler ,Scott Rose From: Michael StJohns Subject: Re: comments on draft-ietf-dnsext-dnssec-bis-updates-05 Cc: IETF DNSEXT WG In-Reply-To: References: <45F03C9B.3050308@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Message-Id: X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 4035 doesn't say what I think you think it says... It says that the Nameserver side passes the bit to the resolver side so that the resolver side will return the records it has without checking. It doesn't say that the resolver side should set the bit in its upstream queries - I can't read this section in a way that would constitute an implicit indication this bit should be set. As written, if the next upstream resolver is also a validating resolver, it will filter out "bad" data even if the CD bit is set, so the client will never see the raw data. E.g. client -> intermediate resolver (local cache) -> intermediate resolver (provider cache or forced proxy) -> zone server If the local cache resolver doesn't set the bit, the provider cache resolver won't return the raw stuff. Suggest actually stating this explicitly along the lines of: "The resolver side of a security-aware recursive resolver MUST set the CD bit on its upstream queries." I wrote the above as an all the time thing - i'm pretty sure a security aware recursive server should ALWAYS be getting the raw stuff without filtering. Otherwise the cache could be incorrect if the first query to a record is without the CD bit and the signature stuff is wrong. Mike At 23:20 11/18/2007, Sam Weiler wrote: >On Thu, 8 Mar 2007, Scott Rose wrote: > >>I just (quickly) read over the -05 version of the DNSSEC-bis-updates draft. I noticed 2 typos and 1 issue that may have been resolved, but I can't remember. [typos snipped] > >Thank you for catching these. The newest version of the draft fixes both typos. > >>Also, I remember on thing from MSJ's DNSSEC-SO draft: In section 2.3.2.2, third bullet item (in regards to recursive caching servers): >> >> The resolver side MUST also set the CD bit when sending queries >> when the CD bit is set in the initiating query. [Note: The >> current behavior for a PNE recursive resolver may be in error.] >> >>Has this been covered in a thread? I don't remember. In my mind, it may be necessary if there is some upstream cache in the middle. The caching resolver still has the option (local policy) to perform validation after sending the response back to the originator for determining the cache status (BAD or not). > >I don't remember a thread on this, but I think RFC4035 already says this (implicitly) in the third paragraph of section 3.2.2: http://tools.ietf.org/html/rfc4035#section-3.2.2 > >Am I misunderstanding this? Do we need to clarify it further? (I'm CC'ing MSJ in case he might have some wisdom to offer.) > >-- Sam (dnssec-bis-updates co-editor) -- to unsubscribe send a message to namedroppers-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 Nov 19 06:00:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4N0-0003Fr-C9; Mon, 19 Nov 2007 06:00:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu4Mw-0001Ra-RY; Mon, 19 Nov 2007 06:00:50 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iu4Fd-0009tq-7I for namedroppers-data@psg.com; Mon, 19 Nov 2007 10:53:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [204.152.184.167] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iu4F7-0009sY-TF for namedroppers@ops.ietf.org; Mon, 19 Nov 2007 10:52:57 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id 8D9CB11401E; Mon, 19 Nov 2007 10:52:40 +0000 (UTC) (envelope-from Shane_Kerr@isc.org) Received: from [199.6.1.234] (unknown [199.6.1.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 51B03E6056; Mon, 19 Nov 2007 10:52:40 +0000 (UTC) (envelope-from shane@isc.org) Message-ID: <47416AF6.3070201@isc.org> Date: Mon, 19 Nov 2007 11:52:38 +0100 From: Shane Kerr Reply-To: shane_kerr@isc.org Organization: ISC User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: Stephane Bortzmeyer CC: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-forgery-resilience-01.txt References: <20071110214233.GB8260@laperouse.bortzmeyer.org> <87sl3biytx.fsf@mid.deneb.enyo.de> <27988.1194879471@sa.vix.com> <20071112154535.GC31775@outpost.ds9a.nl> <86081.1194888591@sa.vix.com> <20071112220343.GA19255@outpost.ds9a.nl> <20071112223543.GA12580@laperouse.bortzmeyer.org> <20071116145237.GA18431@laperouse.bortzmeyer.org> In-Reply-To: <20071116145237.GA18431@laperouse.bortzmeyer.org> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephane Bortzmeyer wrote: > On Mon, Nov 12, 2007 at 08:35:43PM -0200, > Stephane Bortzmeyer wrote > a message of 25 lines which said: > >> More detailed, with the help of Alex Bligh: > > New version that I propose, with a clearer separation between the norm > and the rationale (they could even be placed in different sections). I > believe this captures the discussion in the WG and that nothing was > forgotten. Nice. I like it. - -- Shane -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHQWrzMsfZxBO4kbQRAvz0AJ9ZWhJ48W1zTSAAZxBvD6LeaAE2SQCfSX7Y EcEa3XEnwbl7LBk0hRa/xrU= =yUu8 -----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 Nov 19 10:58:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu912-00051t-OE; Mon, 19 Nov 2007 10:58:28 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu910-0003kl-GY; Mon, 19 Nov 2007 10:58:28 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iu8rl-0009Nr-Ko for namedroppers-data@psg.com; Mon, 19 Nov 2007 15:48:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-202.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.3 Received: from [156.154.16.158] (helo=ns0.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iu8rB-0009KN-SR for namedroppers@ops.ietf.org; Mon, 19 Nov 2007 15:48:37 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id CD8943289E; Mon, 19 Nov 2007 15:48:11 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu8r5-0003A8-Ni; Mon, 19 Nov 2007 10:48:11 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP Reply-To: ietf@ietf.org Cc: Message-Id: Date: Mon, 19 Nov 2007 10:48:11 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Domain Name System (DNS) IANA Considerations ' as a BCP 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 2007-12-03. 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-2929bis-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13373&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 Mon Nov 19 16:28:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuEAY-0008UZ-F5; Mon, 19 Nov 2007 16:28:38 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuEAT-0004x9-WC; Mon, 19 Nov 2007 16:28:38 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IuE2e-000Bdo-IC for namedroppers-data@psg.com; Mon, 19 Nov 2007 21:20:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IuE2T-000Bce-S2 for namedroppers@ops.ietf.org; Mon, 19 Nov 2007 21:20:23 +0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id lAJLJq2A029054; Mon, 19 Nov 2007 15:19:53 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id lAJLJqYl004149; Mon, 19 Nov 2007 15:19:52 -0600 Received: from localhost ([157.185.80.253]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Nov 2007 16:19:52 -0500 Date: Mon, 19 Nov 2007 16:19:51 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@mint.samweiler.com To: "Olaf M. Kolkman" cc: IETF DNSEXT WG , Jakob Schlyter , Mark Andrews , Mats Dufberg , Peter Koch Subject: Re: [dnssec-deployment] some observations about .SE's DNSSEC In-Reply-To: <58D077C8-6863-46E3-B723-834D52F2965D@NLnetLabs.nl> Message-ID: References: Your message of "Thu, 27 Sep 2007 08:27:46 +0200." <4AB9B2D0-3FCE-40F1-AF2F-D861E64618A2@rfc.se> <58D077C8-6863-46E3-B723-834D52F2965D@NLnetLabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 19 Nov 2007 21:19:52.0187 (UTC) FILETIME=[EC6954B0:01C82AF1] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Mon, 19 Nov 2007 15:19:53 -0600 (CST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Thu, 27 Sep 2007, Olaf M. Kolkman wrote: > The suggestion is that the AD bit is used in the query to signal the > readiness to deal with AD bits in the answer. I support this. (I would say "set AD in the answer only if either the AD or DO bits are set in the query".) As for where to publish it: unlike most of dnssec-bis-updates, which has basically been limited to clarifying underspecifications and lesser matters, this looks like a real change. On the other hand, it's small enough that I don't see the benefit of rolling a new document. I'd like to see a little more discussion (and implementation?), but, unless discussion leads in some other direction, I'll plan to add this to the next revision of dnssec-bis-updates. -- Sam -- to unsubscribe send a message to namedroppers-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 Nov 19 21:59:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuJKP-0002XQ-LU; Mon, 19 Nov 2007 21:59:09 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuJKM-0004gh-8q; Mon, 19 Nov 2007 21:59:09 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IuJ88-000CHC-2o for namedroppers-data@psg.com; Tue, 20 Nov 2007 02:46:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,MISSING_MID, RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.30.32] (helo=QMTA03.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IuJ7Y-000CEU-S0 for namedroppers@ops.ietf.org; Tue, 20 Nov 2007 02:46:10 +0000 Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id EqK41Y0080vp7WL0A03G00; Tue, 20 Nov 2007 02:45:55 +0000 Received: from mikespersonal.comcast.net ([68.48.56.3]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id Eqls1Y00J04A3tg0800000; Tue, 20 Nov 2007 02:45:55 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=Ca-uF_-hn6_NjX3YcI4A:9 a=fyFUYhadnfOHWEgaml0A:7 a=HDZoiyURujEQP3O86QvnZod3O38A:4 a=K6OZBpTtl3cA:10 a=Y6qChIQXU1wA:10 a=7OmpBygbiDMA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Nov 2007 21:45:54 -0500 To: Sam Weiler ,Scott Rose From: Michael StJohns Subject: Re: comments on draft-ietf-dnsext-dnssec-bis-updates-05 Cc: IETF DNSEXT WG In-Reply-To: References: <45F03C9B.3050308@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion Message-Id: X-Spam-Score: -4.0 (----) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 OK - thinking about it, I think its even more complex than this. I think the CD bit gets set in only those upstream queries where the resolver has a configured trust anchor superior to the query. (.e.g .COM for queries to sub1.example.com) Let's say your local validating resolver has a trust anchor for "example.com" but not ".com" Let's say the next upstream resolver has a trust anchor for .com. If the local resolver sets the CD bit on queries in foo.com the client could get data in foo.com even if the data were invalid at the upstream resolver even though the upstream resolver should have protected the local resolver. The next question is how does this interoperate with DLV? The DLV covered zone (e.g. a dlv server for .com) isn't trust anchor for .com, but contains a set of trust anchors within .com. If your local resolver has a set of DLV covered zones ... do you wait to figure out how to set the CD bit until after you query for DLV resolution? My head hurts. Any thoughts? At 23:56 11/18/2007, Michael StJohns wrote: >4035 doesn't say what I think you think it says... > >It says that the Nameserver side passes the bit to the resolver side so that the resolver side will return the records it has without checking. It doesn't say that the resolver side should set the bit in its upstream queries - I can't read this section in a way that would constitute an implicit indication this bit should be set. > > As written, if the next upstream resolver is also a validating resolver, it will filter out "bad" data even if the CD bit is set, so the client will never see the raw data. > >E.g. > >client -> intermediate resolver (local cache) -> intermediate resolver (provider cache or forced proxy) -> zone server > >If the local cache resolver doesn't set the bit, the provider cache resolver won't return the raw stuff. > >Suggest actually stating this explicitly along the lines of: > >"The resolver side of a security-aware recursive resolver MUST set the CD bit on its upstream queries." > >I wrote the above as an all the time thing - i'm pretty sure a security aware recursive server should ALWAYS be getting the raw stuff without filtering. Otherwise the cache could be incorrect if the first query to a record is without the CD bit and the signature stuff is wrong. > >Mike > > > >At 23:20 11/18/2007, Sam Weiler wrote: >>On Thu, 8 Mar 2007, Scott Rose wrote: >> >>>I just (quickly) read over the -05 version of the DNSSEC-bis-updates draft. I noticed 2 typos and 1 issue that may have been resolved, but I can't remember. [typos snipped] >> >>Thank you for catching these. The newest version of the draft fixes both typos. >> >>>Also, I remember on thing from MSJ's DNSSEC-SO draft: In section 2.3.2.2, third bullet item (in regards to recursive caching servers): >>> >>> The resolver side MUST also set the CD bit when sending queries >>> when the CD bit is set in the initiating query. [Note: The >>> current behavior for a PNE recursive resolver may be in error.] >>> >>>Has this been covered in a thread? I don't remember. In my mind, it may be necessary if there is some upstream cache in the middle. The caching resolver still has the option (local policy) to perform validation after sending the response back to the originator for determining the cache status (BAD or not). >> >>I don't remember a thread on this, but I think RFC4035 already says this (implicitly) in the third paragraph of section 3.2.2: http://tools.ietf.org/html/rfc4035#section-3.2.2 >> >>Am I misunderstanding this? Do we need to clarify it further? (I'm CC'ing MSJ in case he might have some wisdom to offer.) >> >>-- Sam (dnssec-bis-updates co-editor) > > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 20 20:30:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuePy-0003Mm-Ab; Tue, 20 Nov 2007 20:30:18 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuePt-0002x2-V4; Tue, 20 Nov 2007 20:30:18 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IueFc-000I7x-J2 for namedroppers-data@psg.com; Wed, 21 Nov 2007 01:19:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM, RDNS_NONE autolearn=no version=3.2.3 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IueFQ-000I7H-G2 for namedroppers@ops.ietf.org; Wed, 21 Nov 2007 01:19:30 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id lAL1JIJn010474 for ; Tue, 20 Nov 2007 20:19:18 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id lAL1JIbJ010473 for namedroppers@ops.ietf.org; Tue, 20 Nov 2007 20:19:18 -0500 (EST) (envelope-from namedroppers) Received: from [195.54.244.3] (helo=telnic.org) by psg.com with esmtps (SSLv3:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Itpx7-000EZj-OR for namedroppers@ops.ietf.org; Sun, 18 Nov 2007 19:37:15 +0000 Received: from [195.54.233.69] (account jim [195.54.233.69] verified) by telnic.org (CommuniGate Pro SMTP 5.0.9) with ESMTPSA id 376260; Sun, 18 Nov 2007 19:37:06 +0000 In-Reply-To: <20071116215513.GA6441@laperouse.bortzmeyer.org> References: <20071116215513.GA6441@laperouse.bortzmeyer.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <97E67A3C-95FC-4E48-B30A-F7BB543E445E@telnic.org> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: I-D Action:draft-reid-dnsext-zs-00.txt Date: Sun, 18 Nov 2007 19:37:01 +0000 To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.752.2) X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 [ 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 Nov 16, 2007, at 21:55, Stephane Bortzmeyer wrote: > I'm not really convinced of the usefulness of this RR. It is non > structured (so it cannot be automatically parsed) and the only thing > it gives that TXT does not provide is the ability to query only ZS > records, which does not seem a lot. (In the wild, TXT records seem to > be used a lot for this purpose, sometimes with a full CVS $Id$ in a > TXT value.) The whole point of this proposed RRType is that it's unstructured. Its RDATA is meant to be read by a human being, not a computer. In fact the reason for proposing this RRType is that providing zone status info can't readily be done with a TXT record because these are already used for all sorts of things, like $Id$ strings or SPF cruft. As the draft explains. > If someone wants to work on this topic, I would suggest a more > structured RR. Things like the date of the last update should really > be a parsable type. IMO it would make more sense to have a discrete RRtype that held a timestamp for the zone's last update (or whatever). > But I'm not sure it is worth working on that instead of, for instance, > IRIS for things like "publishing real-time contact data for [ENUM] > zone owners" or the various presence protocols (RFC 3856, or RFC 3921) > for things like "the zone owner is asleep, so don't bother trying > voice-based communication". This is a very, very bad idea. First off, it assumes that all zones are supported by a registry that runs IRIS. This is just not true: where's the IRIS server for some delegation of example.com? Second, it assumes that every registry has an IRIS service that can take updates for every zone (from zillions of different zone owners?) several times a day whenever the zone's presence/status info changes. Which seems highly unlikely. It would be much simpler for everyone if this was done through the DNS using an RRtype that was specifically defined for disclosing human-readable zone status and/or presence info. Finally, it's not possible to update an IRIS server and some zone file in an atomic transaction. So the zone data can't be guaranteed to be in sync with what some IRIS status message might say. > The end user considerations section seems to be quite broken, as far > as i18n is concerned. Speaking of "unusual character sets" is > inappropriate, specially when the examples given are Chinese and > Arabic scripts, hardly "unusual". If such records would be used for > messages to the end-user, as suggested in section 3, a real i18n would > be necessary, with language-tagging of the messages. You're being mischeivous. :-) It's quite wrong to imply that I'm saying these scripts are unusual: everyone knows they're not. The objective of this section of the draft is to advise prospective publishers of ZS records to consider the audience that will be reading these records and the devices they might have. In other words, "Don't put an Arabic (say) string in the RDATA unless you're sure that the majority of people looking his up can read Arabic and have devices which can render these characters/scripts appropriately.". If you feel the language in the draft does not properly reflect that common sense principle, please contribute text that does. -- to unsubscribe send a message to namedroppers-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 Nov 24 06:58:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivtey-0006aF-5R; Sat, 24 Nov 2007 06:58:56 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivteu-0007m0-Q4; Sat, 24 Nov 2007 06:58:56 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IvtWu-00095K-CB for namedroppers-data@psg.com; Sat, 24 Nov 2007 11:50:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-201.1 required=5.0 tests=AWL,BAYES_00,FH_HAS_XAIMC, RDNS_NONE,USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.3 Received: from [202.99.23.227] (helo=people.com.cn) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IvtWK-0008xI-00 for namedroppers@ops.ietf.org; Sat, 24 Nov 2007 11:50:20 +0000 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm4474838c7; Sat, 24 Nov 2007 20:02:57 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1384741f453; Tue, 20 Nov 2007 00:10:53 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Tue, 20 Nov 2007 00:10:53 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu8rf-0007s7-HH; Mon, 19 Nov 2007 10:48:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu8rc-0007oZ-2q for ietf-announce@ietf.org; Mon, 19 Nov 2007 10:48:44 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu8rZ-0002tU-Rm for ietf-announce@ietf.org; Mon, 19 Nov 2007 10:48:44 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id CD8943289E; Mon, 19 Nov 2007 15:48:11 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu8r5-0003A8-Ni; Mon, 19 Nov 2007 10:48:11 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 19 Nov 2007 10:48:11 -0500 X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: namedroppers@ops.ietf.org Subject: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Reply-To: ietf@ietf.org List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -1.3 (-) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Domain Name System (DNS) IANA Considerations ' as a BCP 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 2007-12-03. 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-2929bis-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13373&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- to unsubscribe send a message to namedroppers-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 Nov 28 05:17:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxJz4-0005uM-E4; Wed, 28 Nov 2007 05:17:34 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxJz2-00047Y-T3; Wed, 28 Nov 2007 05:17:34 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxJqJ-000C5O-KN for namedroppers-data@psg.com; Wed, 28 Nov 2007 10:08:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxJq8-000C4q-RA for namedroppers@ops.ietf.org; Wed, 28 Nov 2007 10:08:26 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id C09AE1C0124; Wed, 28 Nov 2007 11:08:19 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id BBA721C0111; Wed, 28 Nov 2007 11:08:19 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id B8E9D58ECCD; Wed, 28 Nov 2007 11:08:19 +0100 (CET) Date: Wed, 28 Nov 2007 11:08:19 +0100 From: Stephane Bortzmeyer To: ietf@ietf.org Cc: namedroppers@ops.ietf.org Subject: Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP Message-ID: <20071128100819.GA21382@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-5-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa On Mon, Nov 19, 2007 at 10:48:11AM -0500, The IESG wrote a message of 24 lines which said: > The IESG has received a request from the DNS Extensions WG (dnsext) to > consider the following document: > > - 'Domain Name System (DNS) IANA Considerations ' > as a BCP I approve the goal (the main change is to simplify the registration of new DNS Resource Record codes, from "IETF consensus" to the new "DNS RRTYPE Allocation Policy" in section 3.1.1 of the I-D). I've read the document and I've found only one typo (3.1.1: "a Meta-Type who processing is optional", I believe it should be "whose processing"). But I find that the Expert Review process in section 3.1.1 may be described too lightly. I base my opinion on experience with the ietf-languages process (RFC 4646) which uses a similar expert review. There have been some problems such as deadlocking (the expert thought his previous comments were to be addressed, while the requester thought he had to wait the expert) or uncertainty about delays (does a new form, sent to address some comments, reset the period?). draft-ietf-ltru-4646bis-09 (section 3.5) specifically addresses these points, which seem to be ignored in draft-ietf-dnsext-2929bis-06.txt: * modifications made to the request during the course of the registration process (they extend the period, but do not reset it), * clear indication of the outcome of the process (acceptance, rejection, extension). Some requests on ietf-languages saw the period pass and no decision taken, * appeals to the IESG May be such wording should appear in draft-ietf-dnsext-2929bis? -- to unsubscribe send a message to namedroppers-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 Nov 28 07:12:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxLmF-0005uy-5q; Wed, 28 Nov 2007 07:12:27 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxLmE-0002zd-EU; Wed, 28 Nov 2007 07:12:27 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxLgN-000IP1-DM for namedroppers-data@psg.com; Wed, 28 Nov 2007 12:06:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [85.17.178.134] (helo=stipula.dds.nl) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxLfs-000IN1-95 for namedroppers@ops.ietf.org; Wed, 28 Nov 2007 12:06:07 +0000 Received: from localhost (localhost [127.0.0.1]) by stipula.dds.nl (Postfix) with ESMTP id 1003F564104; Wed, 28 Nov 2007 13:05:46 +0100 (CET) Received: from stipula.dds.nl ([127.0.0.1]) by localhost (stipula.dds.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16015-07-2; Wed, 28 Nov 2007 13:05:42 +0100 (CET) Received: from [192.168.254.1] (82-170-145-155-static.dsl.ip.tiscali.nl [82.170.145.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by stipula.dds.nl (Postfix) with ESMTP id 846375641DE; Wed, 28 Nov 2007 13:05:33 +0100 (CET) Message-ID: <474D5989.7000405@nlnetlabs.nl> Date: Wed, 28 Nov 2007 13:05:29 +0100 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Namedroppers CC: Sam Weiler Subject: dnssec-updates text, include SOA in negative answers X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.90.1/4914/Mon Nov 26 08:22:46 2007 on stipula.dds.nl X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, While writing a validator, I encountered the following issue. I would like to propose adding some small text to the dnssec-updates document to clean this up. [proposed text] Include SOA in negative answers. Servers that serve DNSSEC signed zones SHOULD include SOA records in the authority section for negative answers (name error, no data). This enables clients to distinguish referrals from negative answers when the query did not set the RD bit, and validate accordingly. For example, a client makes a query without RD bit to its upstream caching server, and receives a reply from that cache with empty answer section, NS record present, no SOA record, no DS record in the authority section and maybe NSEC or NSEC3 records present in the authority section, and possibly A records in the additional section. The presence of the SOA record signals nodata instead of a referral. Trying to determine the message status by attempting to use (any present) NSEC records is error prone. The reason for the NSEC proof to fail may be a security failure, and using that to determine message status conflates security and message content. [/proposed text] You can leave out the 'For example' paragraph if you want, Sam; the issue may be clear from the first. I believe that current servers that serve DNSSEC all include SOA records in the authority section; and therefore implementation is already widespread. Simply trying to clean up the DNSSEC protocol by saying that leaving out SOA records is not a good idea. (rfc 4034 and 4035 are silent about including SOA records in negative answers, although the examples show SOA records in the authority section). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHTVmJkDLqNwOhpPgRAj0vAJ4w3IBv1gH6TkCFMoJoyvmNiGBNxACdEzx6 pRNrXTO1ICBiqU6EyU6gkak= =N4+Q -----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 Nov 28 08:57:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNPc-00083T-Pl; Wed, 28 Nov 2007 08:57:12 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxNPb-0003Qe-7D; Wed, 28 Nov 2007 08:57:12 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxNIP-000Oei-HA for namedroppers-data@psg.com; Wed, 28 Nov 2007 13:49:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxNI8-000OdZ-N6 for namedroppers@ops.ietf.org; Wed, 28 Nov 2007 13:49:39 +0000 Received: from [192.168.1.101] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id lASDnAs4076093; Wed, 28 Nov 2007 08:49:11 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <474D5989.7000405@nlnetlabs.nl> References: <474D5989.7000405@nlnetlabs.nl> Date: Wed, 28 Nov 2007 08:49:06 -0500 To: "W.C.A. Wijngaards" From: Edward Lewis Subject: Re: dnssec-updates text, include SOA in negative answers Cc: Namedroppers , Sam Weiler Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 At 1:05 PM +0100 11/28/07, W.C.A. Wijngaards wrote: >Include SOA in negative answers. > >Servers that serve DNSSEC signed zones SHOULD include SOA records in the >authority section for negative answers (name error, no data). This >enables clients to distinguish referrals from negative answers when the >query did not set the RD bit, and validate accordingly. Is that necessary? If the negative answer is coming from an authoritative server, the AA bit will be on for a negative answer and off for a referral. OTOH, the AA bit is not covered by a DNSSEC [rfc 4034etal] protection. But I am less certain about this in responses from cache (in which the AA bit is never set). (Ergo, I think the "for example" is needed to remind folks that this is a cache issue.) >For example, a client makes a query without RD bit to its upstream >caching server, and receives a reply from that cache with empty answer >section, NS record present, no SOA record, no DS record in the authority >section and maybe NSEC or NSEC3 records present in the authority >section, and possibly A records in the additional section. The presence >of the SOA record signals nodata instead of a referral. Trying to >determine the message status by attempting to use (any present) NSEC >records is error prone. The reason for the NSEC proof to fail may be a >security failure, and using that to determine message status conflates >security and message content. Why would there be NS records in the authority section of a negative answer? (It's been a while for me, I am trying to recall negative answers in the DNSSEC era.) If the NSEC records don't validate, what use is the response anyway? I mean, if their is a security failure, why then use the response to see if this is a referral or a negative answer? I'm also trying to figure out the normal use case of asking a cache a non-RD bit query. I do it only for debugging, so see why a SERVFAIL was returned. I can't really imagine any other reason to ask a cache in a non-RD manner. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. -- to unsubscribe send a message to namedroppers-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 Nov 28 09:56:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxOKd-00043i-8F; Wed, 28 Nov 2007 09:56:07 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxOKc-0003Z8-MC; Wed, 28 Nov 2007 09:56:07 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxOEt-0003bV-IA for namedroppers-data@psg.com; Wed, 28 Nov 2007 14:50:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [85.17.178.134] (helo=stipula.dds.nl) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxOEL-0003WT-Hv for namedroppers@ops.ietf.org; Wed, 28 Nov 2007 14:49:56 +0000 Received: from localhost (localhost [127.0.0.1]) by stipula.dds.nl (Postfix) with ESMTP id 0DC585642A9; Wed, 28 Nov 2007 15:49:36 +0100 (CET) Received: from stipula.dds.nl ([127.0.0.1]) by localhost (stipula.dds.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02081-03; Wed, 28 Nov 2007 15:49:32 +0100 (CET) Received: from [192.168.254.1] (82-170-145-155-static.dsl.ip.tiscali.nl [82.170.145.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by stipula.dds.nl (Postfix) with ESMTP id 39F965641F8; Wed, 28 Nov 2007 15:49:27 +0100 (CET) Message-ID: <474D7FF6.5030005@nlnetlabs.nl> Date: Wed, 28 Nov 2007 15:49:26 +0100 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Edward Lewis CC: Namedroppers , Sam Weiler Subject: Re: dnssec-updates text, include SOA in negative answers References: <474D5989.7000405@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.90.1/4914/Mon Nov 26 08:22:46 2007 on stipula.dds.nl X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Edward Lewis wrote: > Is that necessary? > > If the negative answer is coming from an authoritative server, the AA > bit will be on for a negative answer and off for a referral. OTOH, the > AA bit is not covered by a DNSSEC [rfc 4034etal] protection. > > But I am less certain about this in responses from cache (in which the > AA bit is never set). > > (Ergo, I think the "for example" is needed to remind folks that this is > a cache issue.) OK. > Why would there be NS records in the authority section of a negative > answer? (It's been a while for me, I am trying to recall negative > answers in the DNSSEC era.) Rfc2308 shows a collection of negative answers, and NS records can be present and absent in the authority section of negative answers. Basically, NS record for the zone you query (with or without SOA record), or NS record for the zone after a CNAME and nxdomain. > If the NSEC records don't validate, what use is the response anyway? I > mean, if their is a security failure, why then use the response to see > if this is a referral or a negative answer? For RRSIG validation yes, but other NSEC checks depend on what you are trying to prove; wildcards, type missing, domain name error, DS types, child-vs-parent-side NSEC, and so on. These checks failing are not security failures in themselves, but become security failures depending on what you are trying to prove. > I'm also trying to figure out the normal use case of asking a cache a > non-RD bit query. I do it only for debugging, so see why a SERVFAIL was > returned. I can't really imagine any other reason to ask a cache in a > non-RD manner. I don't know, but I want to validate it :-) You can have a resolver send its non-RD queries to a validating-cache, to make sure it is not led astray by bogus data? Now, I'm only trying to answer you, not saying this is likely to be useful. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHTX/2kDLqNwOhpPgRAo36AKCnuqUQ9mvV+nf8P4dFXeI91y8kLQCglFkD DZ/WFm9hek4WZptjzUvh9Bw= =okeC -----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 Nov 28 10:38:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxOzi-0005fb-AC; Wed, 28 Nov 2007 10:38:34 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxOzh-0005hS-65; Wed, 28 Nov 2007 10:38:34 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxOv1-0007bi-Ed for namedroppers-data@psg.com; Wed, 28 Nov 2007 15:33:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxOuj-0007ae-Vv for namedroppers@ops.ietf.org; Wed, 28 Nov 2007 15:33:37 +0000 Received: from [10.31.32.161] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id lASFXAPG076724; Wed, 28 Nov 2007 10:33:10 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <474D7FF6.5030005@nlnetlabs.nl> References: <474D5989.7000405@nlnetlabs.nl> <474D7FF6.5030005@nlnetlabs.nl> Date: Wed, 28 Nov 2007 10:28:50 -0500 To: Namedroppers From: Edward Lewis Subject: Re: dnssec-updates text, include SOA in negative answers Cc: Edward Lewis Content-Type: multipart/alternative; boundary="============_-1015858504==_ma============" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 --============_-1015858504==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 3:49 PM +0100 11/28/07, W.C.A. Wijngaards wrote: >Rfc2308 shows a collection of negative answers, and NS records can be >present and absent in the authority section of negative answers. >Basically, NS record for the zone you query (with or without SOA >record), or NS record for the zone after a CNAME and nxdomain. The problem with RFC 2308 is that it doesn't document the header bits. There's one example of a negative answer with NS records in the authority section and no SOA accompanying them. That's for an NXDOMAIN only, and as section 2.2. starts: "NODATA is indicated by an answer with the RCODE set to NOERROR and no relevant answers in the answer section. The authority section will contain an SOA record, or there will be no NS records there." So we are back to NXDOMAIN situation. An NXDOMAIN can come from a cached answer (no AA). There are four examples given. Type 1 has SOA and NS, Type 2 has none of that. There is this quote in 2.1.1: "Some resolvers treat a TYPE 1 NXDOMAIN response as a referral. To alleviate this problem it is recommended that servers that are authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN responses, that is the authority section contains a SOA record and no NS records. If a non- authoritative server sends a type 1 NXDOMAIN response to one of these old resolvers, the result will be an unnecessary query to an authoritative server." Type 3 has an empty Authority section. Type 4 looks just like the NOERROR referral. What is said there? Hmmmm. In this case I don't find explanatory text. But I would conclude that an NXDOMAIN is not a referral - the message is saying "your destination does not exist, but here are some NS records." You'd be foolish to take these NS records as a referral "on the road to nowhere." (Let me say my motivation is to resist the recommendation to add anything to the response, so I am looking hard to see if the addition of the SOA is a necessary evil.) It would seem to me that instead of adding the SOA to the NS records there, we follow the Type 1 - Type 2 recommendation text and urge folks to just not include the NS set for the same reason cited there and in your problem statement. So - would you consider instead a recommendation to not include NS records in a negative answer (as opposed to adding the SOA)? > >> If the NSEC records don't validate, what use is the response anyway? I >> mean, if their is a security failure, why then use the response to see >> if this is a referral or a negative answer? > >For RRSIG validation yes, but other NSEC checks depend on what you are >trying to prove; wildcards, type missing, domain name error, DS types, >child-vs-parent-side NSEC, and so on. These checks failing are not >security failures in themselves, but become security failures depending >on what you are trying to prove. I don't agree - if the signature fails, the record (set) is garbage if you care about security. Well, I mean, if you get an NSEC* with a bad sig it is useless. If you get one with a good sig but then the bit map doesn't make sense, then I'd still guess it is garbage, spindulated (I made that word up) in some botched zone update/cache issue or maybe a calculated to confuse attack. (Maybe I am missing the point here.) >I don't know, but I want to validate it :-) > >You can have a resolver send its non-RD queries to a validating-cache, >to make sure it is not led astray by bogus data? Now, I'm only trying to >answer you, not saying this is likely to be useful. I see your paranoia medication isn't working. ;) DNSSEC doesn't guarantee that the data is correct, just that it came cleanly. So there will be many times you validate the wrong IP address. All DNSSEC does is make it possible to place blame on the poor zone admin who will probably be busy preparing a resume, in the old days, he would have been pointing a finger to the host admin. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. --============_-1015858504==_ma============ Content-Type: text/html; charset="us-ascii" Re: dnssec-updates text, include SOA in negative answers
At 3:49 PM +0100 11/28/07, W.C.A. Wijngaards wrote:

>Rfc2308 shows a collection of negative answers, and NS records can be
>present and absent in the authority section of negative answers.
>Basically, NS record for the zone you query (with or without SOA
>record), or NS record for the zone after a CNAME and nxdomain.
The problem with RFC 2308 is that it doesn't document the header bits.

There's one example of a negative answer with NS records in the authority section and no SOA accompanying them.  That's for an NXDOMAIN only, and as section 2.2. starts:

"NODATA is indicated by an answer with the RCODE set to NOERROR and no
relevant answers in the answer section.  The authority section will
contain an SOA record, or there will be no NS records there."

So we are back to NXDOMAIN situation.  An NXDOMAIN can come from a cached answer (no AA).  There are four examples given.  Type 1 has SOA and NS, Type 2 has none of that.  There is this quote in 2.1.1:

"Some resolvers treat a TYPE 1 NXDOMAIN response as a referral.  To
alleviate this problem it is recommended that servers that are
authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN
responses, that is the authority section contains a SOA record and no
NS records.  If a non- authoritative server sends a type 1 NXDOMAIN
response to one of these old resolvers, the result will be an
unnecessary query to an authoritative server."

Type 3 has an empty Authority section.

Type 4 looks just like the NOERROR referral.  What is said there?  Hmmmm.  In this case I don't find explanatory text.  But I would conclude that an NXDOMAIN is not a referral - the message is saying "your destination does not exist, but here are some NS records."  You'd be foolish to take these NS records as a referral "on the road to nowhere."

(Let me say my motivation is to resist the recommendation to add anything to the response, so I am looking hard to see if the addition of the SOA is a necessary evil.)

It would seem to me that instead of adding the SOA to the NS records there, we follow the Type 1 - Type 2 recommendation text and urge folks to just not include the NS set for the same reason cited there and in your problem statement.

So - would you consider instead a recommendation to not include NS records in a negative answer (as opposed to adding the SOA)?

>
>> If the NSEC records don't validate, what use is the response anyway? I
>> mean, if their is a security failure, why then use the response to see
>> if this is a referral or a negative answer?
>
>For RRSIG validation yes, but other NSEC checks depend on what you are
>trying to prove; wildcards, type missing, domain name error, DS types,
>child-vs-parent-side NSEC, and so on. These checks failing are not
>security failures in themselves, but become security failures depending
>on what you are trying to prove.

I don't agree - if the signature fails, the record (set) is garbage if you care about security.  Well, I mean, if you get an NSEC* with a bad sig it is useless.  If you get one with a good sig but then the bit map doesn't make sense, then I'd still guess it is garbage, spindulated (I made that word up) in some botched zone update/cache issue or maybe a calculated to confuse attack.

(Maybe I am missing the point here.)

>I don't know, but I want to validate it :-)
>
>You can have a resolver send its non-RD queries to a validating-cache,
>to make sure it is not led astray by bogus data? Now, I'm only trying to
>answer you, not saying this is likely to be useful.

I see your paranoia medication isn't working. ;)

DNSSEC doesn't guarantee that the data is correct, just that it came cleanly.  So there will be many times you validate the wrong IP address.  All DNSSEC does is make it possible to place blame on the poor zone admin who will probably be busy preparing a resume, in the old days, he would have been pointing a finger to the host admin. ;)

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.
--============_-1015858504==_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 Wed Nov 28 11:16:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxPa7-0006it-1U; Wed, 28 Nov 2007 11:16:11 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxPa6-00071D-Ez; Wed, 28 Nov 2007 11:16:11 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxPU2-000A2r-Q9 for namedroppers-data@psg.com; Wed, 28 Nov 2007 16:09:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [85.17.178.135] (helo=spalding.dds.nl) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxPTX-000A17-Ft for namedroppers@ops.ietf.org; Wed, 28 Nov 2007 16:09:39 +0000 Received: from localhost (localhost [127.0.0.1]) by spalding.dds.nl (Postfix) with ESMTP id 9FC251F80CD; Wed, 28 Nov 2007 17:09:21 +0100 (CET) Received: from spalding.dds.nl ([127.0.0.1]) by localhost (spalding.dds.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16671-01; Wed, 28 Nov 2007 17:09:18 +0100 (CET) Received: from [192.168.254.1] (82-170-145-155-static.dsl.ip.tiscali.nl [82.170.145.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by spalding.dds.nl (Postfix) with ESMTP id A49671F8081; Wed, 28 Nov 2007 17:09:08 +0100 (CET) Message-ID: <474D92A3.80807@nlnetlabs.nl> Date: Wed, 28 Nov 2007 17:09:07 +0100 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Edward Lewis CC: Namedroppers Subject: Re: dnssec-updates text, include SOA in negative answers References: <474D5989.7000405@nlnetlabs.nl> <474D7FF6.5030005@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.90.1/4914/Mon Nov 26 08:22:46 2007 on spalding.dds.nl X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Edward Lewis wrote: > So - would you consider instead a recommendation to not include NS > records in a negative answer (as opposed to adding the SOA)? Yes that would be fine. And I agree that less bits is better. Since that SOA record was only used to give a TTL for the negative caching, and the NSEC/NSEC3 records also have this TTL anyways; I see the opportunity to remove that SOA+signature from many more messages ;) But that digresses from the topic of this thread. > I don't agree - if the signature fails, the record (set) is garbage if > you care about security. Well, I mean, if you get an NSEC* with a bad > sig it is useless. If you get one with a good sig but then the bit map > doesn't make sense, then I'd still guess it is garbage, spindulated (I > made that word up) in some botched zone update/cache issue or maybe a > calculated to confuse attack. > > (Maybe I am missing the point here.) I agree that a bad sig makes the rrset bogus. I meant to say that part of proving certain statements with NSECs consists of checking if the proper NSECs are present, checking if the NSECs indicate the presence of particular types, and so on. The outcome of these checks, taken together with the proof question, result in a security status. The security status is not determinable without determining as well whether the message is a referral or a negative (or something else). > I see your paranoia medication isn't working. ;) > > DNSSEC doesn't guarantee that the data is correct, just that it came > cleanly. So there will be many times you validate the wrong IP > address. All DNSSEC does is make it possible to place blame on the poor > zone admin who will probably be busy preparing a resume, in the old > days, he would have been pointing a finger to the host admin. ;) :-) Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHTZKjkDLqNwOhpPgRAku4AJ9gyT2NwARLo8sknxjqp9mGF8mCzgCfbwHu smrCzaubqOrNPBvsUGV4eUM= =vouB -----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 Nov 28 12:10:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxQQr-0005QT-Qz; Wed, 28 Nov 2007 12:10:41 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxQQq-0006Tx-2b; Wed, 28 Nov 2007 12:10:41 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxQHV-000E0B-Ex for namedroppers-data@psg.com; Wed, 28 Nov 2007 17:01:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [83.246.72.252] (helo=gurgel.gson.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxQHE-000Dyu-WE for namedroppers@ops.ietf.org; Wed, 28 Nov 2007 17:00:56 +0000 Received: from guava.gson.org (a91-152-94-125.elisa-laajakaista.fi [91.152.94.125]) by gurgel.gson.org (Postfix) with ESMTP id CB5A47C92A; Wed, 28 Nov 2007 16:59:47 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id 8FD0F75F3C; Wed, 28 Nov 2007 19:00:23 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18253.40615.528242.228475@guava.gson.org> Date: Wed, 28 Nov 2007 19:00:23 +0200 To: "W.C.A. Wijngaards" Cc: Namedroppers Subject: Re: dnssec-updates text, include SOA in negative answers In-Reply-To: <474D5989.7000405@nlnetlabs.nl> References: <474D5989.7000405@nlnetlabs.nl> X-Mailer: VM 7.19 under Emacs 21.4.1 From: gson@araneus.fi (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 W.C.A. Wijngaards wrote: > [proposed text] > > Include SOA in negative answers. > > Servers that serve DNSSEC signed zones SHOULD include SOA records in the > authority section for negative answers (name error, no data). This > enables clients to distinguish referrals from negative answers when the > query did not set the RD bit, and validate accordingly. Isn't this already required by RFC2308 section 3? 3 - Negative Answers from Authoritative Servers Name servers authoritative for a zone MUST include the SOA record of the zone in the authority section of the response when reporting an NXDOMAIN or indicating that no data of the requested type exists. -- Andreas Gustafsson, gson@araneus.fi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 28 13:57:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxS6M-0007es-47; Wed, 28 Nov 2007 13:57:38 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxS6L-0002kx-Eu; Wed, 28 Nov 2007 13:57:38 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxRy9-000MnC-2B for namedroppers-data@psg.com; Wed, 28 Nov 2007 18:49:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxRxx-000MmK-PB for namedroppers@ops.ietf.org; Wed, 28 Nov 2007 18:49:03 +0000 Received: from [10.31.32.161] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id lASImXMp078150; Wed, 28 Nov 2007 13:48:34 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <474D92A3.80807@nlnetlabs.nl> References: <474D5989.7000405@nlnetlabs.nl> <474D7FF6.5030005@nlnetlabs.nl> <474D92A3.80807@nlnetlabs.nl> Date: Wed, 28 Nov 2007 13:48:32 -0500 To: "W.C.A. Wijngaards" From: Edward Lewis Subject: Re: dnssec-updates text, include SOA in negative answers Cc: Edward Lewis , Namedroppers Content-Type: multipart/alternative; boundary="============_-1015846779==_ma============" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 --============_-1015846779==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 5:09 PM +0100 11/28/07, W.C.A. Wijngaards wrote: >particular types, and so on. The outcome of these checks, taken together >with the proof question, result in a security status. The security >status is not determinable without determining as well whether the >message is a referral or a negative (or something else). Okay, I thought you meant something else. It's necessary to understand the unchecked message before knowing "what to solve for." So, it's plain to say that a message has to be unambiguous in meaning. So returning to the original suggestion to include the SOA, I think (as already stated) that would be the wrong step. We should stick with the suggestion in RFC 2308 to only send Type 2 negative responses (see the RFC for what Type 2 means) and just amplify that under DNSSEC. I would think that we should recommend that a NXDOMAIN never include NS records. That goes for caches that are not required to include the SOA as well as authoritative servers. But - perhaps it is needed to help decide the RFC 2181 trustworthiness of the data? Maybe not, if we can trust the AA bit. From RFC 2181: # Trustworthiness shall be, in order from most to least: # # + Data from a primary zone file, other than glue data, # + Data from a zone transfer, other than glue, # + The authoritative data included in the answer section of an # authoritative reply. # + Data from the authority section of an authoritative answer, # + Glue from a primary zone, or glue from a zone transfer, # + Data from the answer section of a non-authoritative answer, and # non-authoritative data from the answer section of authoritative # answers, # + Additional information from an authoritative answer, # Data from the authority section of a non-authoritative answer, # Additional information from non-authoritative answers. Then again, under DNSSEC, trustworthiness has less impact. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. --============_-1015846779==_ma============ Content-Type: text/html; charset="us-ascii" Re: dnssec-updates text, include SOA in negative answers
At 5:09 PM +0100 11/28/07, W.C.A. Wijngaards wrote:

>particular types, and so on. The outcome of these checks, taken together
>with the proof question, result in a security status. The security
>status is not determinable without determining as well whether the
>message is a referral or a negative (or something else).

Okay, I thought you meant something else.

It's necessary to understand the unchecked message before knowing "what to solve for."  So, it's plain to say that a message has to be unambiguous in meaning.

So returning to the original suggestion to include the SOA, I think (as already stated) that would be the wrong step.  We should stick with the suggestion in RFC 2308 to only send Type 2 negative responses (see the RFC for what Type 2 means) and just amplify that under DNSSEC.

I would think that we should recommend that a NXDOMAIN never include NS records.  That goes for caches that are not required to include the SOA as well as authoritative servers.  But - perhaps it is needed to help decide the RFC 2181 trustworthiness of the data?  Maybe not, if we can trust the AA bit.

From RFC 2181:

# Trustworthiness shall be, in order from most to least:
#
#     + Data from a primary zone file, other than glue data,
#     + Data from a zone transfer, other than glue,
#     + The authoritative data included in the answer section of an
#       authoritative reply.
#     + Data from the authority section of an authoritative answer,
#     + Glue from a primary zone, or glue from a zone transfer,
#     + Data from the answer section of a non-authoritative answer, and
#       non-authoritative data from the answer section of authoritative
#       answers,
#     + Additional information from an authoritative answer,
#       Data from the authority section of a non-authoritative answer,
#       Additional information from non-authoritative answers.

Then again, under DNSSEC, trustworthiness has less impact.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.
--============_-1015846779==_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 Wed Nov 28 13:59:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxS7o-0008QT-OC; Wed, 28 Nov 2007 13:59:08 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxS7o-0002pI-ET; Wed, 28 Nov 2007 13:59:08 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxRyH-000Mnv-FZ for namedroppers-data@psg.com; Wed, 28 Nov 2007 18:49:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxRy6-000Mmv-PO for namedroppers@ops.ietf.org; Wed, 28 Nov 2007 18:49:12 +0000 Received: from [10.31.32.161] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id lASImXMr078150; Wed, 28 Nov 2007 13:48:46 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <18253.40615.528242.228475@guava.gson.org> References: <474D5989.7000405@nlnetlabs.nl> <18253.40615.528242.228475@guava.gson.org> Date: Wed, 28 Nov 2007 13:42:17 -0500 To: gson@araneus.fi (Andreas Gustafsson) From: Edward Lewis Subject: Re: dnssec-updates text, include SOA in negative answers Cc: "W.C.A. Wijngaards" , Namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 At 7:00 PM +0200 11/28/07, Andreas Gustafsson wrote: >Isn't this already required by RFC2308 section 3? I don't think so. That only covers authoritative servers. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. -- to unsubscribe send a message to namedroppers-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 Nov 28 14:27:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxSYu-0007Qr-6s; Wed, 28 Nov 2007 14:27:08 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxSYt-0006cU-Nn; Wed, 28 Nov 2007 14:27:08 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxST2-000Pfp-30 for namedroppers-data@psg.com; Wed, 28 Nov 2007 19:21:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [83.246.72.252] (helo=gurgel.gson.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxSSe-000Pby-HH for namedroppers@ops.ietf.org; Wed, 28 Nov 2007 19:20:54 +0000 Received: from guava.gson.org (a91-152-94-125.elisa-laajakaista.fi [91.152.94.125]) by gurgel.gson.org (Postfix) with ESMTP id EEA2C7C906; Wed, 28 Nov 2007 19:19:43 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id 6D28D75F3B; Wed, 28 Nov 2007 21:20:38 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18253.49030.412977.99950@guava.gson.org> Date: Wed, 28 Nov 2007 21:20:38 +0200 To: Edward Lewis Cc: "W.C.A. Wijngaards" , Namedroppers Subject: Re: dnssec-updates text, include SOA in negative answers In-Reply-To: References: <474D5989.7000405@nlnetlabs.nl> <18253.40615.528242.228475@guava.gson.org> X-Mailer: VM 7.19 under Emacs 21.4.1 From: gson@araneus.fi (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Edward Lewis wrote: > >Isn't this already required by RFC2308 section 3? > > I don't think so. That only covers authoritative servers. For caching servers, there is section 6: 6 - Negative answers from the cache When a server, in answering a query, encounters a cached negative response it MUST add the cached SOA record to the authority section of the response with the TTL decremented by the amount of time it was stored in the cache. This allows the NXDOMAIN / NODATA response to time out correctly. I find it somewhat confusing that Wouter's original proposed text talks about "servers that serve DNSSEC signed zones", which I would interpret as referring to authoritative servers, and then presents an example involving a response from a caching server. But in any case, RFC2308 does seem to already cover both cases. -- Andreas Gustafsson, gson@araneus.fi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 28 14:44:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxSpX-0005rb-Kv; Wed, 28 Nov 2007 14:44:19 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxSpV-0001Ak-Ff; Wed, 28 Nov 2007 14:44:19 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxSgG-00010T-5T for namedroppers-data@psg.com; Wed, 28 Nov 2007 19:34:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxSg4-0000zU-4G for namedroppers@ops.ietf.org; Wed, 28 Nov 2007 19:34:37 +0000 Received: from [10.31.32.161] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id lASJYDge078522; Wed, 28 Nov 2007 14:34:14 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <18253.49030.412977.99950@guava.gson.org> References: <474D5989.7000405@nlnetlabs.nl> <18253.40615.528242.228475@guava.gson.org> <18253.49030.412977.99950@guava.gson.org> Date: Wed, 28 Nov 2007 14:31:16 -0500 To: gson@araneus.fi (Andreas Gustafsson) From: Edward Lewis Subject: Re: dnssec-updates text, include SOA in negative answers Cc: Edward Lewis , "W.C.A. Wijngaards" , Namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb At 9:20 PM +0200 11/28/07, Andreas Gustafsson wrote: >Edward Lewis wrote: >> >Isn't this already required by RFC2308 section 3? >> >> I don't think so. That only covers authoritative servers. > >For caching servers, there is section 6: > > 6 - Negative answers from the cache > > When a server, in answering a query, encounters a cached negative > response it MUST add the cached SOA record to the authority section > of the response with the TTL decremented by the amount of time it was > stored in the cache. This allows the NXDOMAIN / NODATA response to > time out correctly. > >I find it somewhat confusing that Wouter's original proposed text >talks about "servers that serve DNSSEC signed zones", which I would >interpret as referring to authoritative servers, and then presents an >example involving a response from a caching server. But in any case, >RFC2308 does seem to already cover both cases. >-- >Andreas Gustafsson, gson@araneus.fi Ok, but I still think we ought to reinforce the "don't include the NS set" in negative answers. Other than the legacy requirement, is there a need to have the SOA? I mean, does it contain some information that is needed? (Do we also need to prove it is the right SOA?) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. -- to unsubscribe send a message to namedroppers-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 Nov 28 17:53:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVmO-0001SX-Nx; Wed, 28 Nov 2007 17:53:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxVmN-00084U-Au; Wed, 28 Nov 2007 17:53:16 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxVeo-000F5d-5o for namedroppers-data@psg.com; Wed, 28 Nov 2007 22:45:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,RDNS_NONE autolearn=no version=3.2.3 Received: from [204.152.184.167] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxVeb-000F4K-Rb for namedroppers@ops.ietf.org; Wed, 28 Nov 2007 22:45:20 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id B502911402A for ; Wed, 28 Nov 2007 22:45:12 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id 5918BE6068 for ; Wed, 28 Nov 2007 22:45:13 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id lASIIS3J002501; Thu, 29 Nov 2007 05:18:28 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200711281818.lASIIS3J002501@drugs.dv.isc.org> To: Edward Lewis Cc: Namedroppers From: Mark Andrews Subject: Re: dnssec-updates text, include SOA in negative answers In-reply-to: Your message of "Wed, 28 Nov 2007 10:28:50 CDT." Date: Thu, 29 Nov 2007 05:18:28 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -2.6 (--) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 We need to support NXRRSET in responses to QUERY. -- 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 Nov 28 17:54:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVnB-0001in-TA; Wed, 28 Nov 2007 17:54:05 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxVnA-00086E-Mm; Wed, 28 Nov 2007 17:54:05 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxVfB-000F7y-MV for namedroppers-data@psg.com; Wed, 28 Nov 2007 22:45:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,RDNS_NONE autolearn=no version=3.2.3 Received: from [204.152.184.167] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxVem-000F5H-3w for namedroppers@ops.ietf.org; Wed, 28 Nov 2007 22:45:30 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id B142F114050 for ; Wed, 28 Nov 2007 22:45:13 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id 54CE9E606C for ; Wed, 28 Nov 2007 22:45:14 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id lASHnLVT001691; Thu, 29 Nov 2007 04:49:21 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200711281749.lASHnLVT001691@drugs.dv.isc.org> To: Edward Lewis Cc: "W.C.A. Wijngaards" , Namedroppers , Sam Weiler From: Mark Andrews Subject: Re: dnssec-updates text, include SOA in negative answers In-reply-to: Your message of "Wed, 28 Nov 2007 08:49:06 CDT." Date: Thu, 29 Nov 2007 04:49:21 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -2.6 (--) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 See RFC 2308 > At 1:05 PM +0100 11/28/07, W.C.A. Wijngaards wrote: > > >Include SOA in negative answers. > > > >Servers that serve DNSSEC signed zones SHOULD include SOA records in the > >authority section for negative answers (name error, no data). This > >enables clients to distinguish referrals from negative answers when the > >query did not set the RD bit, and validate accordingly. > > Is that necessary? > > If the negative answer is coming from an authoritative server, the AA > bit will be on for a negative answer and off for a referral. OTOH, > the AA bit is not covered by a DNSSEC [rfc 4034etal] protection. > > But I am less certain about this in responses from cache (in which > the AA bit is never set). > > (Ergo, I think the "for example" is needed to remind folks that this > is a cache issue.) > > >For example, a client makes a query without RD bit to its upstream > >caching server, and receives a reply from that cache with empty answer > >section, NS record present, no SOA record, no DS record in the authority > >section and maybe NSEC or NSEC3 records present in the authority > >section, and possibly A records in the additional section. The presence > >of the SOA record signals nodata instead of a referral. Trying to > >determine the message status by attempting to use (any present) NSEC > >records is error prone. The reason for the NSEC proof to fail may be a > >security failure, and using that to determine message status conflates > >security and message content. > > Why would there be NS records in the authority section of a negative > answer? (It's been a while for me, I am trying to recall negative > answers in the DNSSEC era.) > > If the NSEC records don't validate, what use is the response anyway? > I mean, if their is a security failure, why then use the response to > see if this is a referral or a negative answer? > > I'm also trying to figure out the normal use case of asking a cache a > non-RD bit query. I do it only for debugging, so see why a SERVFAIL > was returned. I can't really imagine any other reason to ask a cache > in a non-RD manner. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > Think glocally. Act confused. > > -- > to 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 Nov 28 20:14:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxXyc-0004J3-Gk; Wed, 28 Nov 2007 20:14:02 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxXyc-0004dp-5x; Wed, 28 Nov 2007 20:14:02 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxXoN-000N3Y-A8 for namedroppers-data@psg.com; Thu, 29 Nov 2007 01:03:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxXio-000Mlg-RO for namedroppers@ops.ietf.org; Thu, 29 Nov 2007 01:01:33 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2AE1711429; Thu, 29 Nov 2007 00:57:42 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Edward Lewis cc: gson@araneus.fi (Andreas Gustafsson), "W.C.A. Wijngaards" , Namedroppers Subject: Re: dnssec-updates text, include SOA in negative answers In-Reply-To: Your message of "Wed, 28 Nov 2007 14:31:16 EST." References: <474D5989.7000405@nlnetlabs.nl> <18253.40615.528242.228475@guava.gson.org> <18253.49030.412977.99950@guava.gson.org> X-Mailer: MH-E 8.0.2; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 29 Nov 2007 00:57:42 +0000 Message-ID: <15947.1196297862@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 > Ok, but I still think we ought to reinforce the "don't include the NS set" > in negative answers. i don't think that's useful. if the ns set is owned by a subdomain of the qname or final cname, you know it's a referral, which you shouldn't believe if it came from a full resolver (caching server) rather than from an authority. -- to unsubscribe send a message to namedroppers-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 Nov 29 16:30:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxqyC-0004yx-JA; Thu, 29 Nov 2007 16:30:52 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxqyA-0003TV-N4; Thu, 29 Nov 2007 16:30:52 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxqkT-000JyQ-11 for namedroppers-data@psg.com; Thu, 29 Nov 2007 21:16:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [216.82.241.179] (helo=mail119.messagelabs.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxqkC-000JxE-Ga for namedroppers@ops.ietf.org; Thu, 29 Nov 2007 21:16:35 +0000 X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1196370982!22850451!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12909 invoked from network); 29 Nov 2007 21:16:22 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-119.messagelabs.com with SMTP; 29 Nov 2007 21:16:22 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lATLGMNK028508 for ; Thu, 29 Nov 2007 14:16:22 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id lATLGMBG006716 for ; Thu, 29 Nov 2007 15:16:22 -0600 (CST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id lATLGLka006710 for ; Thu, 29 Nov 2007 15:16:21 -0600 (CST) 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: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS)IANA Considerations) to BCP Date: Thu, 29 Nov 2007 16:16:19 -0500 Message-ID: <3870C46029D1F945B1472F170D2D9790034C8131@de01exm64.ds.mot.com> In-Reply-To: <20071128100819.GA21382@nic.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS)IANA Considerations) to BCP thread-index: AcgxpuOZpBnu4u3WSCaAUd7OijeLWQBFEjMw References: <20071128100819.GA21382@nic.fr> From: "Eastlake III Donald-LDE008" To: "Stephane Bortzmeyer" , Cc: X-CFilter-Loop: Reflected Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Hi, Thanks for your comment on 2929bis. See response below at @@@ -----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr]=20 Sent: Wednesday, November 28, 2007 5:08 AM To: ietf@ietf.org Cc: namedroppers@ops.ietf.org Subject: Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS)IANA Considerations) to BCP On Mon, Nov 19, 2007 at 10:48:11AM -0500, The IESG wrote=20 a message of 24 lines which said: > The IESG has received a request from the DNS Extensions WG (dnsext) to > consider the following document: >=20 > - 'Domain Name System (DNS) IANA Considerations ' > as a BCP I approve the goal (the main change is to simplify the registration of new DNS Resource Record codes, from "IETF consensus" to the new "DNS RRTYPE Allocation Policy" in section 3.1.1 of the I-D). I've read the document and I've found only one typo (3.1.1: "a Meta-Type who processing is optional", I believe it should be "whose processing"). @@@ Thanks for finding this typo. But I find that the Expert Review process in section 3.1.1 may be described too lightly. I base my opinion on experience with the ietf-languages process (RFC 4646) which uses a similar expert review. There have been some problems such as deadlocking (the expert thought his previous comments were to be addressed, while the requester thought he had to wait the expert) or uncertainty about delays (does a new form, sent to address some comments, reset the period?). draft-ietf-ltru-4646bis-09 (section 3.5) specifically addresses these points, which seem to be ignored in draft-ietf-dnsext-2929bis-06.txt: * modifications made to the request during the course of the registration process (they extend the period, but do not reset it), @@@ I do not see any reason to provide for extension of consideration or mid-stream modification to applications. The Expert is required by 2929bis to monitor namedroppers discussion of applications for an RR Type and applicants are encouraged by 2929bis to informally post applications to get feedback. So the applicant should normally have early feedback from the Expert. In cases where the formal application is rejected and the Expert provides suggested changes, it seems simpler and cleaner for the applicant to resubmit, rather than modify. This also fits with the DNSEXT WG consensus that the namedroppers community have three weeks to examine any application, to reduce the chance of someone missing something because they are on vacation or the like, rather than the more common IETF posting requirement of two weeks (which is used in 4646bis). @@@ I personally don't see why someone would think there is a time extension or mid-stream change facility for 2929bis when none is provided in the document; but I don't object to adding a few words to make this clear. * clear indication of the outcome of the process (acceptance, rejection, extension). Some requests on ietf-languages saw the period pass and no decision taken, @@@ This is probably a good point. The addition of a specific requirement for the assigned Expert to post an acceptance or rejection (presumably to IANA, namedroppers, and the applicant) within a reasonable period of time, such as six weeks from the formal posting of the completed template to namedroppers, seems reasonable to me. * appeals to the IESG @@@ I see no need to include this. 2929bis normatively references RFC 2434 which says: @@@"Any decisions made by the designated expert can be appealed using the normal IETF appeals process as outlined in Section 6.5 of [IETF- PROCESS]. Since the designated experts are appointed by the IESG, they may be removed by the IESG." May be such wording should appear in draft-ietf-dnsext-2929bis? @@@ How about adding the following to Section 3.1.1? @@@ "After a completed template has been formally posted to namedroppers by IANA the Expert shall post a message, explicitly accepting or rejecting the application, to IANA, namedroppers, and the email address provided by the applicant not less than three weeks and not more than six weeks after the formal posting. If the Expert does not post such a message, the application shall be considered rejected but may be re-submitted to IANA." @@@ Thanks again, @@@ Donald -- to unsubscribe send a message to namedroppers-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 Nov 29 16:43:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixr9u-0005Mb-9v; Thu, 29 Nov 2007 16:42:58 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixr9t-0005rW-VF; Thu, 29 Nov 2007 16:42:58 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ixr4g-000Lek-Li for namedroppers-data@psg.com; Thu, 29 Nov 2007 21:37:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [80.67.170.53] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ixr4T-000Ldn-QA for namedroppers@ops.ietf.org; Thu, 29 Nov 2007 21:37:28 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id D6BF0240823; Thu, 29 Nov 2007 21:37:02 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id C950611835; Thu, 29 Nov 2007 22:35:47 +0100 (CET) Date: Thu, 29 Nov 2007 22:35:47 +0100 From: Stephane Bortzmeyer To: Eastlake III Donald-LDE008 Cc: ietf@ietf.org, namedroppers@ops.ietf.org Subject: Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS)IANA Considerations) to BCP Message-ID: <20071129213547.GA24704@sources.org> References: <20071128100819.GA21382@nic.fr> <3870C46029D1F945B1472F170D2D9790034C8131@de01exm64.ds.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3870C46029D1F945B1472F170D2D9790034C8131@de01exm64.ds.mot.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Thu, Nov 29, 2007 at 04:16:19PM -0500, Eastlake III Donald-LDE008 wrote a message of 103 lines which said: > How about adding the following to Section 3.1.1? > > "After a completed template has been formally posted to > namedroppers by IANA the Expert shall post a message, explicitly > accepting or rejecting the application, to IANA, namedroppers, > and the email address provided by the applicant not less than > three weeks and not more than six weeks after the formal > posting. If the Expert does not post such a message, the > application shall be considered rejected but may be re-submitted > to IANA." It seems fine to me. -- to unsubscribe send a message to namedroppers-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 Nov 29 19:36:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixtre-0004Bm-DA; Thu, 29 Nov 2007 19:36:18 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixtrc-0004hl-Pb; Thu, 29 Nov 2007 19:36:18 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ixtkz-0009ai-J3 for namedroppers-data@psg.com; Fri, 30 Nov 2007 00:29:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxtkP-0009Yb-Tl for namedroppers@ops.ietf.org; Fri, 30 Nov 2007 00:29:09 +0000 X-IronPort-AV: E=Sophos;i="4.23,231,1194220800"; d="scan'208";a="12922870" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 30 Nov 2007 00:28:48 +0000 To: namedroppers@ops.ietf.org Cc: ben@links.org, davidb@verisign.com, Sam Hartman , =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_=2FDNSEXT_chair?= , roy@dnss.ec, Sam Weiler , Mark Townsley Subject: NSEC3, version 13 MIME-Version: 1.0 X-Mailer: Lotus Notes Build V702MAC_11052006 November 05, 2006 Message-ID: From: Roy Arends Date: Fri, 30 Nov 2007 01:28:51 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 30/11/2007 12:28:48 AM, Serialize complete at 30/11/2007 12:28:48 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Dear WG, This is the latest version of the NSEC3 draft, version 13. Since the submission deadline for IETF 71 has passed, I've put the latest version online: http://www.nsec3.org/cgi-bin/trac.cgi/attachment/wiki/WikiStart/draft-ietf-dnsext-nsec3-13.txt?format=raw This version addresses the NSEC3 hash algorithm agility issue. Changes are: 1) Section 12.1.3 has been replaced with the following text: 12.1.3. Transitioning to a New Hash Algorithm Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm parameter, this document does not define a particular mechanism for safely transitioning from one NSEC3 hash algorithm to another. When specifying a new hash algorithm for use with NSEC3, a transition mechanism MUST also be defined. It is possible that the only practical and palatable transition mechanisms may require an intermediate transition to an insecure state, or to a state that uses NSEC records instead of NSEC3. 2) an addition to the IANA considerations: 11. IANA Considerations Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm parameter, this document does not define a particular mechanism for safely transitioning from one NSEC3 hash algorithm to another. When specifying a new hash algorithm for use with NSEC3, a transition mechanism MUST also be defined. 3) One typo was fixed, and two of the authors' addresses have changed Regards, Roy Arends Nominet UK -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Nov 30 00:53:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxyoR-0002Ci-01; Fri, 30 Nov 2007 00:53:19 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxyoP-0008EH-9t; Fri, 30 Nov 2007 00:53:18 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IxyhD-00061X-QQ for namedroppers-data@psg.com; Fri, 30 Nov 2007 05:45:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ixygc-0005ya-GX for namedroppers@ops.ietf.org; Fri, 30 Nov 2007 05:45:35 +0000 Received: from Puki.ogud.com (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id lAU5iq9B090383; Fri, 30 Nov 2007 00:44:52 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <200711300544.lAU5iq9B090383@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 30 Nov 2007 00:43:49 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: Re: NSEC3, version 13 Cc: ben@links.org, davidb@verisign.com, Sam Hartman , =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair , roy@dnss.ec, Sam Weiler , Mark Townsley , Roy Arends In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Please speak up if this change is of concern to you. If no one speaks up by Dec 7'th I will tell our AD the changes are fine. Olafur At 19:28 29/11/2007, Roy Arends wrote: >Dear WG, > >This is the latest version of the NSEC3 draft, version 13. > >Since the submission deadline for IETF 71 has passed, I've put the latest >version online: > >http://www.nsec3.org/cgi-bin/trac.cgi/attachment/wiki/WikiStart/draft-ietf-dnsext-nsec3-13.txt?format=raw > >This version addresses the NSEC3 hash algorithm agility issue. > >Changes are: > >1) Section 12.1.3 has been replaced with the following text: > >12.1.3. Transitioning to a New Hash Algorithm > > Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm > parameter, this document does not define a particular mechanism for > safely transitioning from one NSEC3 hash algorithm to another. When > specifying a new hash algorithm for use with NSEC3, a transition > mechanism MUST also be defined. It is possible that the only > practical and palatable transition mechanisms may require an > intermediate transition to an insecure state, or to a state that uses > NSEC records instead of NSEC3. > >2) an addition to the IANA considerations: > >11. IANA Considerations > > Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm > parameter, this document does not define a particular mechanism for > safely transitioning from one NSEC3 hash algorithm to another. When > specifying a new hash algorithm for use with NSEC3, a transition > mechanism MUST also be defined. > >3) One typo was fixed, and two of the authors' addresses have changed > >Regards, > >Roy Arends >Nominet UK > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-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 Nov 30 07:59:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy5T0-0008Hu-TJ; Fri, 30 Nov 2007 07:59:38 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy5Sx-0007s7-50; Fri, 30 Nov 2007 07:59:38 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iy5FO-0009EE-V0 for namedroppers-data@psg.com; Fri, 30 Nov 2007 12:45:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iy5Eu-0009Ae-78 for namedroppers@ops.ietf.org; Fri, 30 Nov 2007 12:45:19 +0000 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Nov 2007 07:45:03 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAUCj3Pc016424; Fri, 30 Nov 2007 07:45:03 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAUCiQBm006276; Fri, 30 Nov 2007 12:44:59 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 07:44:40 -0500 Received: from rtp-townsley-vpn1.cisco.com ([10.83.1.98]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 07:44:39 -0500 Message-ID: <475005B4.6020508@cisco.com> Date: Fri, 30 Nov 2007 13:44:36 +0100 From: Mark Townsley User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Sam Hartman CC: =?ISO-8859-1?Q?lafur_Gu=F0mundsson_/DNSEXT_chair?= , namedroppers@ops.ietf.org, ben@links.org, davidb@verisign.com, roy@dnss.ec, Sam Weiler , Roy Arends Subject: Re: NSEC3, version 13 References: <200711300544.lAU5iq9B090383@ogud.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Nov 2007 12:44:40.0018 (UTC) FILETIME=[C5DDEB20:01C8334E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1353; t=1196426703; x=1197290703; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20NSEC3,=20version=2013 |Sender:=20 |To:=20Sam=20Hartman=20; bh=MVt6PxgFvJ2yNHMB82bkJNzBaH17QIDj5B+evHwclxU=; b=SzLgntea/2r4Su7g9CVMpHPwAmeeWcCG1k5DK2R7giuQFW5oqgqr9IjS8JX1hRiFbxD09gn4 TCGjzMf5rpjoLRHNA/jjYqOVqTII84NO/JaQ+DTM+NRXC+95iX25cC63; Authentication-Results: rtp-dkim-1; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Sam Hartman wrote: > As an individual, I do not believe it is desirable to publish nsec3 > without a solution to the hash agility problem in hand. So, I object > to publishing this draft. > > I expect that I'm in the rough on this consensus issue and will not > block as an AD. I'd be delighted to find others agree, but doubt that > a sufficient number will. > > > However, since there are objections, I assume the chairs will also > call for support;silence in the presence of objections is not rough > consensus. > I'm not certain without going back and retracing the email threads, but I believe there may be enough calls for support in previous versions of the document to not ask people to raise their hand, yet again, whether they want to see hash agility or not before publishing this document. It may not be the exact text of -13 that was available during those previous calls, but certainly a version with and without hash agility was on the table. I'll leave it up to the Chair to make this call, and trust that he has a good backing. Olafur, if you don't have an email thread to back you up here, please do ask for one more call for support, not just silence, on the hash agility issue and the specific text in -13. You can even blame Sam (H) if you like ;-) - Mark > Thanks, > > --Sam > > -- to unsubscribe send a message to namedroppers-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 Nov 30 11:30:36 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy8lA-0006wk-Ia; Fri, 30 Nov 2007 11:30:36 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy8l8-0002ot-9U; Fri, 30 Nov 2007 11:30:36 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iy8bp-0001OG-P4 for namedroppers-data@psg.com; Fri, 30 Nov 2007 16:20:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM, RDNS_NONE autolearn=no version=3.2.3 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iy8be-0001NN-Th for namedroppers@ops.ietf.org; Fri, 30 Nov 2007 16:20:52 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id lAUGKgIH093825 for ; Fri, 30 Nov 2007 11:20:42 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id lAUGKgPg093824 for namedroppers@ops.ietf.org; Fri, 30 Nov 2007 11:20:42 -0500 (EST) (envelope-from namedroppers) Received: from [69.25.196.178] (helo=carter-zimmerman.suchdamage.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iy4z5-0007ii-56 for namedroppers@ops.ietf.org; Fri, 30 Nov 2007 12:29:14 +0000 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E12294815; Fri, 30 Nov 2007 07:28:35 -0500 (EST) From: Sam Hartman To: lafur =?iso-8859-1?Q?Gu=F0mundsson?= /DNSEXT chair Cc: namedroppers@ops.ietf.org, ben@links.org, davidb@verisign.com, roy@dnss.ec, Sam Weiler , Mark Townsley , Roy Arends Subject: Re: NSEC3, version 13 References: <200711300544.lAU5iq9B090383@ogud.com> Date: Fri, 30 Nov 2007 07:28:35 -0500 In-Reply-To: <200711300544.lAU5iq9B090383@ogud.com> (=?iso-8859-1?Q?=D3laf?= =?iso-8859-1?Q?ur=09Gu=F0mundsson's?= message of "Fri, 30 Nov 2007 00:43:49 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-id: DNSEXT discussion X-Spam-Score: -4.0 (----) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 [ 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. ] As an individual, I do not believe it is desirable to publish nsec3 without a solution to the hash agility problem in hand. So, I object to publishing this draft. I expect that I'm in the rough on this consensus issue and will not block as an AD. I'd be delighted to find others agree, but doubt that a sufficient number will. However, since there are objections, I assume the chairs will also call for support;silence in the presence of objections is not rough consensus. Thanks, --Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: