From owner-namedroppers@ops.ietf.org Tue Nov 01 02:40:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWql6-0003hE-O1 for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 02:40:40 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18239 for ; Tue, 1 Nov 2005 02:40:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWqfg-000OY5-90 for namedroppers-data@psg.com; Tue, 01 Nov 2005 07:35:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWqff-000OXB-5O for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 07:35:03 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jA17Z0ve087799 for ; Tue, 1 Nov 2005 08:35:00 +0100 (CET) (envelope-from olaf@open.nlnetlabs.nl) Received: (from olaf@localhost) by open.nlnetlabs.nl (8.13.4/8.13.4/Submit) id jA17Z0R9087798 for namedroppers@ops.ietf.org; Tue, 1 Nov 2005 08:35:00 +0100 (CET) (envelope-from olaf) Date: Tue, 1 Nov 2005 08:35:00 +0100 (CET) From: Olaf Kolkman Message-Id: <200511010735.jA17Z0R9087798@open.nlnetlabs.nl> To: namedroppers@ops.ietf.org Subject: DNSEXT list policy Sender: owner-namedroppers@ops.ietf.org Precedence: bulk - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". To counter a certain class of spam mails messages over 20000 characters, originating from list subscribers, will be held for moderations. Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e. follup with area directors, then iesg, etc.). There is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.8 2005/01/12 15:54:51 olaf Exp $ -- to unsubscribe send a message to namedroppers-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 01 07:06:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWuu3-0001sy-GX for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 07:06:11 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15239 for ; Tue, 1 Nov 2005 07:05:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWuph-0009ns-O5 for namedroppers-data@psg.com; Tue, 01 Nov 2005 12:01:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWupe-0009nZ-VL for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 12:01:39 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 19BB933C1C; Tue, 1 Nov 2005 12:01:37 +0000 (GMT) Message-ID: <43675923.5090108@algroup.co.uk> Date: Tue, 01 Nov 2005 12:01:39 +0000 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Marcus Better CC: namedroppers@ops.ietf.org Subject: Re: NSEC3 chain walking References: <436655E8.6030608@better.se> In-Reply-To: <436655E8.6030608@better.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Marcus Better wrote: > Hello, > > I have a comment concerning the problem of chain walking mentioned in > section 11 of draft-ietf-dnsext-nsec3-03: > > "Walking the NSEC3 RRs will reveal the total number of records in the > zone, and also what types they are. This could be mitigated by > adding dummy entries, but certainly an upper limit can always be > found." > > It seems that this little nuisance can be eliminated quite easily. > > (Disclaimer: I am not a DNS expert, so if this is really dumb or has > already been discussed, I apologize for wasting your time.) > > The following changes are made to the draft: > > 1. The Next Hash Ownername field is modified so that it contains a > _double_ hash of the next hashed ownername, i.e. H2(H1(name)) where H1 > and H2 are hash algorithms. (One could possibly take H1=H2.) > > 2. The hash order is now determined according to the double hash. > > Note that the ownername of the NSEC3 RR is still the single hash of the > owner name. So the record would look in principle like > H1(foo.example.) NSEC3 H2(H1(bar.example.)) > > This record would prove the non-existence of original ownernames > name.example such that > H2(H1(foo.example.)) < H2(H1(name.example.)) < H2(H1(bar.example.)) > > Since the RR only contains the double hash of the next name, which is > not used as an ownername in the zone, this information cannot be used to > make further queries. So it becomes impossible to walk the NSEC3 chain. > > An obvious drawback is that the verifier must do extra work to compute > the additional hashes. I don't think this works fantastically well. Whether the hash is single or double an attacker has to guess names that produce hashes in the intervals it has not yet explored. The difficulty of doing this is proportional to the zone size (i.e. not very hard even for very large zones) regardless of whether the hash is single or double. Assuming, that is, that we ban direct lookup of NSEC3 records. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 01 07:30:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWvHI-0000Ok-H0 for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 07:30:12 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16504 for ; Tue, 1 Nov 2005 07:29:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWvDd-000B1l-V1 for namedroppers-data@psg.com; Tue, 01 Nov 2005 12:26:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWvDc-000B1R-IK for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 12:26:24 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jA1CQ8gp013811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Nov 2005 13:26:09 +0100 From: Simon Josefsson To: Ben Laurie Cc: namedroppers@ops.ietf.org, Marcus Better Subject: Re: NSEC3 chain walking References: <436655E8.6030608@better.se> <43675923.5090108@algroup.co.uk> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051101:marcus@better.se::kVolqJkeOgBu9kM4:2Z18 X-Hashcash: 1:21:051101:ben@algroup.co.uk::ft/rFyNQWbvP14cP:Gb3G X-Hashcash: 1:21:051101:namedroppers@ops.ietf.org::AIJpA2qetNLEHK6e:7HpL Date: Tue, 01 Nov 2005 13:26:07 +0100 In-Reply-To: <43675923.5090108@algroup.co.uk> (Ben Laurie's message of "Tue, 01 Nov 2005 12:01:39 +0000") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben Laurie writes: > I don't think this works fantastically well. Whether the hash is single > or double an attacker has to guess names that produce hashes in the > intervals it has not yet explored. The difficulty of doing this is > proportional to the zone size (i.e. not very hard even for very large > zones) regardless of whether the hash is single or double. > > Assuming, that is, that we ban direct lookup of NSEC3 records. Baning direct lookup of NSEC3 records doesn't work well. You can make queries for random names until you got all NSEC3 records. Further, because hash output has a rectangular distribution, you know how large the zone is only after a few queries, so you know how many queries you will have to send, after seeing the response to a few queries. Regards, Simon -- to unsubscribe send a message to namedroppers-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 01 07:45:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWvWQ-0002lE-Jq for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 07:45:50 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17063 for ; Tue, 1 Nov 2005 07:45:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWvSx-000Bli-3J for namedroppers-data@psg.com; Tue, 01 Nov 2005 12:42:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWvSw-000BlV-CG for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 12:42:14 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 84B4FC2DA4; Tue, 1 Nov 2005 12:42:03 +0000 (GMT) Date: Tue, 01 Nov 2005 12:41:39 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Ben Laurie , Marcus Better Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: NSEC3 chain walking Message-ID: <863D71ECD691F4EF1368B2A6@[192.168.100.25]> In-Reply-To: <43675923.5090108@algroup.co.uk> References: <436655E8.6030608@better.se> <43675923.5090108@algroup.co.uk> X-Mailer: Mulberry/4.0.4 (Win32) 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 Content-Transfer-Encoding: 7bit --On 01 November 2005 12:01 +0000 Ben Laurie wrote: > Assuming, that is, that we ban direct lookup of NSEC3 records. Does that gain us much, other than a debugging nightmare and more special-case coding? All I can see it does is prevent one from making an exact enumeration of the NSEC3 records (as opposed to the other RRs) which is then equal in size to the zone, though one can (by virtue of the principle that good hash functions distribute values evenly amongst their range) make a very good guess with a minimum number of non-NSEC queries (make 1,000 queries and look at distribution of hash values). Given you only get an upper bound on the "true" content of the zone (as it's quite feasible to stuff it with NULL records if you want to make your TLD look bigger :-) ) through the NSEC query method, what in practice is the difference between getting an upper bound, and a very good estimate of an upper bound (I think you'd need to make something like K.log2 the number of size queries to get within a few percent with small K - given this, it's probably worth publishing an NSEC3 intelligent zone size estimator to prevent people guessing it by walking!) 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 01 08:04:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWvon-0005AP-Bi for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 08:04:50 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18291 for ; Tue, 1 Nov 2005 08:04:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWvlc-000Ckn-SH for namedroppers-data@psg.com; Tue, 01 Nov 2005 13:01:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.169.16.30] (helo=exchangebe.corporate.telin.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWvlX-000CkZ-2K for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 13:01:27 +0000 Received: from netinfo.corporate.telin.nl ([195.169.16.63]) by exchangebe.corporate.telin.nl with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Nov 2005 14:01:25 +0100 Date: Tue, 1 Nov 2005 14:01:25 +0100 (CET) From: Roy Arends X-X-Sender: roy@netinfo.corporate.telin.nl To: Simon Josefsson cc: Ben Laurie , namedroppers@ops.ietf.org, Marcus Better Subject: Re: NSEC3 chain walking In-Reply-To: Message-ID: References: <436655E8.6030608@better.se> <43675923.5090108@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 01 Nov 2005 13:01:25.0393 (UTC) FILETIME=[5D95B810:01C5DEE4] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 1 Nov 2005, Simon Josefsson wrote: > Ben Laurie writes: > >> I don't think this works fantastically well. Whether the hash is single >> or double an attacker has to guess names that produce hashes in the >> intervals it has not yet explored. The difficulty of doing this is >> proportional to the zone size (i.e. not very hard even for very large >> zones) regardless of whether the hash is single or double. >> >> Assuming, that is, that we ban direct lookup of NSEC3 records. > > Baning direct lookup of NSEC3 records doesn't work well. You can make > queries for random names until you got all NSEC3 records. We're not banning nsec3 to avoid enumeration. From the current draft: 7. Responding to NSEC3 Queries Since NSEC3 records do not correspond to names that exist within the zone, there is the potential for confusion when responding to queries that have the QTYPE set to NSEC3 (or ANY). In order to avoid creating an infinite recursion, there is only one consistent way to respond to NSEC3 queries, and that is to act as if the NSEC3 record did not exist. So, if presented with a query where QTYPE is NSEC3 and QNAME is a name that exists in the zone with an RRTYPE other than NSEC3, then the responder should deny the existence of the NSEC3 RRSet and prove it with an NSEC3 record corresponding to the hash of the QNAME (which will, of course, exist), as usual. If the QTYPE is NSEC3 and QNAME is a name that only exists by virtue of an NSEC3 record at that name, then the response should be an NXDOMAIN with appropriate NSEC3 records as proof. 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 Tue Nov 01 08:05:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWvpv-00069n-9P for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 08:05:59 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18514 for ; Tue, 1 Nov 2005 08:05:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWvnp-000Ctt-Uz for namedroppers-data@psg.com; Tue, 01 Nov 2005 13:03:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWvnp-000CtG-1v for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 13:03:49 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 8CD4533C3F; Tue, 1 Nov 2005 13:03:47 +0000 (GMT) Message-ID: <436767B5.5050602@algroup.co.uk> Date: Tue, 01 Nov 2005 13:03:49 +0000 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Alex Bligh CC: Marcus Better , namedroppers@ops.ietf.org Subject: Re: NSEC3 chain walking References: <436655E8.6030608@better.se> <43675923.5090108@algroup.co.uk> <863D71ECD691F4EF1368B2A6@[192.168.100.25]> In-Reply-To: <863D71ECD691F4EF1368B2A6@[192.168.100.25]> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alex Bligh wrote: > > > --On 01 November 2005 12:01 +0000 Ben Laurie wrote: > >> Assuming, that is, that we ban direct lookup of NSEC3 records. > > Does that gain us much, other than a debugging nightmare and more > special-case coding? No :-) > All I can see it does is prevent one from making an > exact enumeration of the NSEC3 records (as opposed to the other RRs) which > is then equal in size to the zone, though one can (by virtue of the > principle that good hash functions distribute values evenly amongst their > range) make a very good guess with a minimum number of non-NSEC queries > (make 1,000 queries and look at distribution of hash values). Given you > only get an upper bound on the "true" content of the zone (as it's quite > feasible to stuff it with NULL records if you want to make your TLD look > bigger :-) ) through the NSEC query method, what in practice is the > difference between getting an upper bound, and a very good estimate of an > upper bound (I think you'd need to make something like K.log2 the number of > size queries to get within a few percent with small K - given this, > it's probably worth publishing an NSEC3 intelligent zone size estimator > to prevent people guessing it by walking!) I can't get excited about zone size estimation. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 01 08:06:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWvpy-0006C5-ON for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 08:06:02 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18523 for ; Tue, 1 Nov 2005 08:05:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWvmL-000Cmt-4s for namedroppers-data@psg.com; Tue, 01 Nov 2005 13:02:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWvmK-000Cmh-7s for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 13:02:16 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id AE9F833C45; Tue, 1 Nov 2005 13:02:14 +0000 (GMT) Message-ID: <43676758.9000707@algroup.co.uk> Date: Tue, 01 Nov 2005 13:02:16 +0000 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Simon Josefsson CC: namedroppers@ops.ietf.org, Marcus Better Subject: Re: NSEC3 chain walking References: <436655E8.6030608@better.se> <43675923.5090108@algroup.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Simon Josefsson wrote: > Ben Laurie writes: > >> I don't think this works fantastically well. Whether the hash is single >> or double an attacker has to guess names that produce hashes in the >> intervals it has not yet explored. The difficulty of doing this is >> proportional to the zone size (i.e. not very hard even for very large >> zones) regardless of whether the hash is single or double. >> >> Assuming, that is, that we ban direct lookup of NSEC3 records. > > Baning direct lookup of NSEC3 records doesn't work well. You can make > queries for random names until you got all NSEC3 records. It works as well as I stated above :-) > Further, because hash output has a rectangular distribution, you know > how large the zone is only after a few queries, so you know how many > queries you will have to send, after seeing the response to a few > queries. True. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 01 08:19:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWw2Y-0003Pr-K2 for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 08:19:02 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19164 for ; Tue, 1 Nov 2005 08:18:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWvzW-000Drx-5t for namedroppers-data@psg.com; Tue, 01 Nov 2005 13:15:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWvzT-000DrL-CS for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 13:15:51 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jA1DFaWR017918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Nov 2005 14:15:37 +0100 From: Simon Josefsson To: Roy Arends Cc: Ben Laurie , namedroppers@ops.ietf.org, Marcus Better Subject: Re: NSEC3 chain walking References: <436655E8.6030608@better.se> <43675923.5090108@algroup.co.uk> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051101:roy@dnss.ec::dK7KZJDRIxMKCOip:g4g X-Hashcash: 1:21:051101:marcus@better.se::YYI1fpv6mEnkZYLS:lab X-Hashcash: 1:21:051101:namedroppers@ops.ietf.org::ftde8fBE8maZmGu+:01fK X-Hashcash: 1:21:051101:ben@algroup.co.uk::pwcaEDqFBDhfC5np:Z4RT Date: Tue, 01 Nov 2005 14:15:35 +0100 In-Reply-To: (Roy Arends's message of "Tue, 1 Nov 2005 14:01:25 +0100 (CET)") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends writes: > We're not banning nsec3 to avoid enumeration. > > From the current draft: I see, I had missed that section. > 7. Responding to NSEC3 Queries > > Since NSEC3 records do not correspond to names that exist within the > zone, there is the potential for confusion when responding to queries > that have the QTYPE set to NSEC3 (or ANY). In order to avoid > creating an infinite recursion, there is only one consistent way to > respond to NSEC3 queries, and that is to act as if the NSEC3 record > did not exist. > > So, if presented with a query where QTYPE is NSEC3 and QNAME is a > name that exists in the zone with an RRTYPE other than NSEC3, then > the responder should deny the existence of the NSEC3 RRSet and prove > it with an NSEC3 record corresponding to the hash of the QNAME (which > will, of course, exist), as usual. > > If the QTYPE is NSEC3 and QNAME is a name that only exists by virtue > of an NSEC3 record at that name, then the response should be an > NXDOMAIN with appropriate NSEC3 records as proof. I don't see why this is the only way to handle the problem. This text create a special case, that will require special care in implementation. What's wrong with returning the NSEC3 a client asks for? Assuming the NSEC3 the client asked for exist, that is. If it does not exist, the client get the usual NSEC3 records that deny existence. The only problem I can see is that an attack can replace the reply with the real NSEC3 with another NSEC3 record that deny the first NSEC3's existence. But you could simply document that this is not protected against. The attacker doesn't gain anything by this, as far as I can tell. I don't see how this would cause infinite recursion. With this approach, there is no additional code complexity, that I can see. Thanks, Simon -- to unsubscribe send a message to namedroppers-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 01 08:21:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWw5G-0004IL-Pk for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 08:21:50 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19370 for ; Tue, 1 Nov 2005 08:21:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWw2L-000DzH-Ib for namedroppers-data@psg.com; Tue, 01 Nov 2005 13:18:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWw2K-000Dz3-P3 for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 13:18:48 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2EE1733C3F; Tue, 1 Nov 2005 13:18:47 +0000 (GMT) Message-ID: <43676B39.2080305@algroup.co.uk> Date: Tue, 01 Nov 2005 13:18:49 +0000 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Ben Laurie CC: Alex Bligh , Marcus Better , namedroppers@ops.ietf.org Subject: Re: NSEC3 chain walking References: <436655E8.6030608@better.se> <43675923.5090108@algroup.co.uk> <863D71ECD691F4EF1368B2A6@[192.168.100.25]> <436767B5.5050602@algroup.co.uk> In-Reply-To: <436767B5.5050602@algroup.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ben Laurie wrote: > Alex Bligh wrote: >> >> --On 01 November 2005 12:01 +0000 Ben Laurie wrote: >> >>> Assuming, that is, that we ban direct lookup of NSEC3 records. >> Does that gain us much, other than a debugging nightmare and more >> special-case coding? > > No :-) BTW, when I say "no" I mean in respect of zone walking or size estimation. As Roy says we ban them for other reasons. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 01 08:47:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWwUN-0005nW-5U for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 08:47:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21362 for ; Tue, 1 Nov 2005 08:47:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWwQc-000FRQ-36 for namedroppers-data@psg.com; Tue, 01 Nov 2005 13:43:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWwQb-000FRC-DW for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 13:43:53 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 53E38C2DA4; Tue, 1 Nov 2005 13:43:52 +0000 (GMT) Date: Tue, 01 Nov 2005 13:43:39 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Ben Laurie Cc: Marcus Better , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: NSEC3 chain walking Message-ID: In-Reply-To: <43676B39.2080305@algroup.co.uk> References: <436655E8.6030608@better.se> <43675923.5090108@algroup.co.uk> <863D71ECD691F4EF1368B2A6@[192.168.100.25]> <436767B5.5050602@algroup.co.uk> <43676B39.2080305@algroup.co.uk> X-Mailer: Mulberry/4.0.4 (Win32) 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 Content-Transfer-Encoding: 7bit --On 01 November 2005 13:18 +0000 Ben Laurie wrote: > BTW, when I say "no" I mean in respect of zone walking or size > estimation. As Roy says we ban them for other reasons. I see. 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 01 09:54:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWxXC-0002P9-EN for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 09:54:49 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24973 for ; Tue, 1 Nov 2005 09:54:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWxRv-000IS8-0W for namedroppers-data@psg.com; Tue, 01 Nov 2005 14:49:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWxRu-000IRm-E4 for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 14:49:18 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 073F811425 for ; Tue, 1 Nov 2005 14:49:16 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NSEC3 chain walking In-Reply-To: Your message of "Tue, 01 Nov 2005 13:03:49 GMT." <436767B5.5050602@algroup.co.uk> References: <436655E8.6030608@better.se> <43675923.5090108@algroup.co.uk> <863D71ECD691F4EF1368B2A6@[192.168.100.25]> <436767B5.5050602@algroup.co.uk> Date: Tue, 01 Nov 2005 14:49:16 +0000 Message-Id: <20051101144916.073F811425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # I can't get excited about zone size estimation. me neither. but i can't get excited about zone content enumeration, either, and yet here we are trying to solve it, and more or less proposing an N+1'th flag day for DNSSEC before deployment has begun on #N, all because this risk does matter to some folks. can we find out if this is a serious problem or showstopper for somebody BEFORE we make decisions about addressing it? (for a pleasant change of pace?) -- to unsubscribe send a message to namedroppers-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 01 10:26:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWy1k-0003Q7-Rv for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 10:26:20 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26418 for ; Tue, 1 Nov 2005 10:26:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWxwN-000K5G-Ex for namedroppers-data@psg.com; Tue, 01 Nov 2005 15:20:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [202.214.123.2] (helo=angola.64translator.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWxwK-000K4e-Ic for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 15:20:44 +0000 Received: from localhost (localhost [IPv6:::1]) by angola.64translator.com (8.13.3/8.13.3) with SMTP id jA1FUm75008448; Wed, 2 Nov 2005 00:30:48 +0900 (JST) (envelope-from Nobumichi.Ozoe@jp.yokogawa.com) Date: Wed, 2 Nov 2005 00:30:47 +0900 From: Nobumichi Ozoe To: namedroppers@ops.ietf.org Cc: dnstest@tahi.org Subject: DNS client test tool ver 0.1 Message-Id: <20051102003047.0a8ddcb6.Nobumichi.Ozoe@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 1.9.6 (GTK+ 2.6.4; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, The TAHI project has released conformance test tool for DNS client. You can download it freely from following URL. http://www.tahi.org/dns/ We have tested DNS client using this test tool at 6th ETSI IPv6 PLUGTESTS. If you have any question, please contact dnstest@tahi.org. Best regards, -- Nobumichi Ozoe IPv6 Business Network & Software Development Dept. Yokogawa Electric Corporation E-mail: Nobumichi.Ozoe@jp.yokogawa.com URL: http://www.yokogawa.com/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 01 10:36:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWyBe-0000ZC-Hl for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 10:36:34 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27058 for ; Tue, 1 Nov 2005 10:36:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWy88-000Km7-D1 for namedroppers-data@psg.com; Tue, 01 Nov 2005 15:32:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWy87-000Klr-4h for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 15:32:55 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id B291C33C1C; Tue, 1 Nov 2005 15:32:53 +0000 (GMT) Message-ID: <43678AA7.4050601@algroup.co.uk> Date: Tue, 01 Nov 2005 15:32:55 +0000 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: NSEC3 chain walking References: <436655E8.6030608@better.se> <43675923.5090108@algroup.co.uk> <863D71ECD691F4EF1368B2A6@[192.168.100.25]> <436767B5.5050602@algroup.co.uk> <20051101144916.073F811425@sa.vix.com> In-Reply-To: <20051101144916.073F811425@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > # I can't get excited about zone size estimation. > > me neither. > > but i can't get excited about zone content enumeration, either, and yet here > we are trying to solve it, and more or less proposing an N+1'th flag day for > DNSSEC before deployment has begun on #N, all because this risk does matter > to some folks. > > can we find out if this is a serious problem or showstopper for somebody > BEFORE we make decisions about addressing it? (for a pleasant change of pace?) We decided in http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signed-nonexistence-requirements-02.txt that it was "nice to have" and not an actual requirement. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 01 10:48:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWyNf-0004Rn-9a for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 10:48:59 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28281 for ; Tue, 1 Nov 2005 10:48:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWyKO-000LXN-K0 for namedroppers-data@psg.com; Tue, 01 Nov 2005 15:45:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.52 (FreeBSD)) id 1EWyKL-000LWW-F1 for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 15:45:34 +0000 Received: from tyrannia.TechFak.Uni-Bielefeld.DE (tyrannia.TechFak.Uni-Bielefeld.DE [129.70.137.5]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/05/30/sjaenick) with ESMTP id jA1FjVIi012977 for ; Tue, 1 Nov 2005 16:45:31 +0100 (MET) Received: from localhost (pk@localhost) by tyrannia.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id jA1FjVR04049 for ; Tue, 1 Nov 2005 16:45:31 +0100 (MET) Message-Id: <200511011545.jA1FjVR04049@tyrannia.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: IETF DNSEXT WG From: Peter Koch Subject: Re: NSEC3 chain walking In-reply-to: Your message of "Tue, 01 Nov 2005 15:32:55 GMT." <43678AA7.4050601@algroup.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4043.1130859928.1@tyrannia.TechFak.Uni-Bielefeld.DE> Date: Tue, 01 Nov 2005 16:45:31 +0100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben Laurie wrote: > We decided in > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signed-nonexistence-req >uirements-02.txt > that it was "nice to have" and not an actual requirement. not to question your assessment in this case, but the message should probably be that "we" (be that the editors or the WG) should be careful about other people's requirements, especially if they are crucial for a deployment success. It might be quite easy to get feedback from TLD registries, but there are other DNS operators who may not have made their mind and, if they do, might disagree with the above categorization (as "nice to have"). When it comes to "zone size" and "zone enumeration", it's also important to view the first order differential, i.e. dies NSEC++ make it easier (than pre-DNSSEC DNS) to find the [number of] changes applied to zone? (This is not to introduce new hurdles, just completeness of the requirements list). -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 01 10:56:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWyUh-0003UZ-MK for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 10:56:18 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28703 for ; Tue, 1 Nov 2005 10:55:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWyQA-000Lu5-E1 for namedroppers-data@psg.com; Tue, 01 Nov 2005 15:51:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWyQ9-000Lti-20 for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 15:51:33 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO002A72; 1 Nov 2005 10:56:22 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 1 Nov 2005 10:56:02 -0500 Received: from connotech.com (209.71.204.105) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG002A71; 1 Nov 2005 10:55:58 -0500 Message-ID: <436796CD.9010100@connotech.com> Date: Tue, 01 Nov 2005 11:24:45 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: NSEC3 chain walking References: <436655E8.6030608@better.se> <43675923.5090108@algroup.co.uk> <863D71ECD691F4EF1368B2A6@[192.168.100.25]> <436767B5.5050602@algroup.co.uk> <20051101144916.073F811425@sa.vix.com> In-Reply-To: <20051101144916.073F811425@sa.vix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > [...] > > can we find out if this is a serious problem or showstopper for somebody > BEFORE we make decisions about addressing it? (for a pleasant change of pace?) > Here is a totally un-informed guess (as the adage says, "those wo know don't speak, those who speak don't know"). The concealed organization behind org-AB7C7F580FF653D4648C.example.com might be concerned, yet would be reluctant to reply to your post. There are perhaps other legitimate arguments for domain name privacy protection. That's the nature of the privacy concern that it covers a wide rance of motives, ... Enough of minding someone else's business ... good luck all for resolving this issue! -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 01 11:39:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWzAf-00050h-DH for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 11:39:37 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00821 for ; Tue, 1 Nov 2005 11:39:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWz6w-000OH8-5B for namedroppers-data@psg.com; Tue, 01 Nov 2005 16:35:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWz6t-000OGq-Dk for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 16:35:43 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id AE3AF33C45; Tue, 1 Nov 2005 16:35:41 +0000 (GMT) Message-ID: <43679960.90902@algroup.co.uk> Date: Tue, 01 Nov 2005 16:35:44 +0000 From: Ben Laurie User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Peter Koch CC: IETF DNSEXT WG Subject: Re: NSEC3 chain walking References: <200511011545.jA1FjVR04049@tyrannia.TechFak.Uni-Bielefeld.DE> In-Reply-To: <200511011545.jA1FjVR04049@tyrannia.TechFak.Uni-Bielefeld.DE> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Peter Koch wrote: > Ben Laurie wrote: > >> We decided in >> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signed-nonexistence-req >> uirements-02.txt >> that it was "nice to have" and not an actual requirement. > > not to question your assessment in this case, but the message should > probably be that "we" (be that the editors or the WG) should be careful > about other people's requirements, especially if they are crucial for a > deployment success. This was on the basis that no-one said it was their requirement. > It might be quite easy to get feedback from TLD registries, but there are > other DNS operators who may not have made their mind and, if they do, might > disagree with the above categorization (as "nice to have"). True. However, given that we have established the impossibility of satisfying all plausible requirements we are obliged to choose amongst them, are we not? I'd also note that it is not generally required of WGs that they should attempt to achieve consensus with non-participants! > When it comes to "zone size" and "zone enumeration", it's also important > to view the first order differential, i.e. dies NSEC++ make it easier (than > pre-DNSSEC DNS) to find the [number of] changes applied to zone? > (This is not to introduce new hurdles, just completeness of the requirements > list). Surely the appropriate differential is against NSEC in this case, since NSEC3 is not designed to solve this particular problem, so the requirement is surely to not make it worse than NSEC, if possible, and if anyone cares at all. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 01 13:15:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX0fQ-0001Zb-Nn for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 13:15:29 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05833 for ; Tue, 1 Nov 2005 13:15:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EX0a9-0002XK-Uu for namedroppers-data@psg.com; Tue, 01 Nov 2005 18:10:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EX0a9-0002Wk-77 for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 18:10:01 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id BC2A8C2DA4; Tue, 1 Nov 2005 18:09:59 +0000 (GMT) Date: Tue, 01 Nov 2005 18:09:50 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: NSEC3 chain walking Message-ID: <2E98D4FEAEFF40E41277E0B2@[192.168.100.25]> In-Reply-To: <20051101144916.073F811425@sa.vix.com> References: <436655E8.6030608@better.se> <43675923.5090108@algroup.co.uk> <863D71ECD691F4EF1368B2A6@[192.168.100.25]> <436767B5.5050602@algroup.co.uk> <20051101144916.073F811425@sa.vix.com> X-Mailer: Mulberry/4.0.4 (Win32) 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 Content-Transfer-Encoding: 7bit --On 01 November 2005 14:49 +0000 Paul Vixie wrote: > can we find out if this is a serious problem or showstopper for somebody > BEFORE we make decisions about addressing it? (for a pleasant change of > pace? Didn't we do this with the requirements doc? And I thought noone in particular much cared. 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 01 13:23:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX0n9-0008EU-TG for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 13:23:28 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06291 for ; Tue, 1 Nov 2005 13:23:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EX0kU-00035j-1Q for namedroppers-data@psg.com; Tue, 01 Nov 2005 18:20:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EX0kT-00035T-0m for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 18:20:41 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 1F326C2DA4; Tue, 1 Nov 2005 18:20:40 +0000 (GMT) Date: Tue, 01 Nov 2005 18:20:30 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Peter Koch , IETF DNSEXT WG Cc: Alex Bligh Subject: Re: NSEC3 chain walking Message-ID: <20A45FDD3C010C298BE55723@[192.168.100.25]> In-Reply-To: <200511011545.jA1FjVR04049@tyrannia.TechFak.Uni-Bielefeld.DE> References: <200511011545.jA1FjVR04049@tyrannia.TechFak.Uni-Bielefeld.DE> X-Mailer: Mulberry/4.0.4 (Win32) 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 Content-Transfer-Encoding: 7bit --On 01 November 2005 16:45 +0100 Peter Koch wrote: > When it comes to "zone size" and "zone enumeration", it's also important > to view the first order differential, i.e. dies NSEC++ make it easier > (than pre-DNSSEC DNS) to find the [number of] changes applied to zone? I'm pretty sure that a bit of relatively trivial maths based on NSEC results from a relatively small number of random queries (O(log(zonesize))will give you a relatively accurate zone size estimate, and from there to a first differential is merely a case of repeating the process several times. That said, I think /any/ NSEC variant with a finite number of possible denials (or at least a finite number of denials that is in some manner linked to the number of zone entries) will suffer the same 'problem' to a greater or lesser extent. Including double hashes, etc. The only way of completely solving this that I'm aware of would be the white-lies method plus epsilons which in essence means online signing. An advantage to supporting multiple hash types is that it would be possible to introduce a certain amount of bogosity into the hash space (deliberately giving non-rectangularly distributed hash functions which are still unique, e.g. by truncating the hash then duplicating a random number of bits). This would make evaluation of zone size mildly less trivial, though not (I fear) much less trivial if you are looking for broad estimates over time. I think it would be waste of time & effort to do this (interesting mathematically as it might be) With my ccTLD hat on, I can't see many TLD operators caring too much given most of them publish this information anyhow. The ones that don't tend to have very small zones where artificially increasing the number of zone entries by inserting random NULL records is going to be a trivial thing to do in resource terms. Those that want to pretend claim zones are smaller can always claim they HAVE stuffed the zone with NULL records when they haven't. Given the zones can't be walked, this would seem not to be disprovable :-) 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 01 13:47:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX1Aq-0004yz-Fj for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 13:47:57 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07645 for ; Tue, 1 Nov 2005 13:47:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EX16f-0004KQ-9O for namedroppers-data@psg.com; Tue, 01 Nov 2005 18:43:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [149.8.64.10] (helo=mclmx.mail.saic.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EX16e-0004K9-1U for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 18:43:36 +0000 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Tue, 1 Nov 2005 13:43:22 -0500 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005110113432201283 ; Tue, 01 Nov 2005 13:43:22 -0500 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Tue, 1 Nov 2005 13:43:22 -0500 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE1059AC@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: "'Ben Laurie'" , Peter Koch Cc: IETF DNSEXT WG Subject: NSEC++ and protecting zone metrics (was: NSEC3 chain walking) Date: Tue, 1 Nov 2005 13:37:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mostly a for what Ben just said, but a few additional thoughts, and a poor attempt at a modified subject line in the hopes that anyone who cares might actually read it: > >> We decided in > >> [[draft-ietf-dnsext-signed-nonexistence-requirements-02.txt]] > >> that it was "nice to have" and not an actual requirement. > > > > not to question your assessment in this case, but the message > > should probably be that "we" (be that the editors or the WG) > > should be careful about other people's requirements, especially > > if they are crucial for a deployment success. > > This was on the basis that no-one said it was their requirement. More specifically: This was postulated as an attribute that "someone might want" but no one from the WG or the larger community did in fact state any need for this attribute. Between Ben and I, and several other folks who we asked, no one was able to even come up with a situation where this attribute was at all of concern. My professional opinion: An organization which is so paranoid about its DNS information that it considers the number/type of RRs in a zone file to be sensitive needs to move that zone off the Internet and protect it appropriately--one simply cannot expect to have a registry of public information that provides these additional security features (DNSSEC extensions) while simultaneously protecting such seemingly innocuous information. Even having used DNS information as part of security evaluations and "penetration testing" I still can't postulate a way that this particular information could be usefully (or even non-usefully) abused. That being said: If someone really needs this attribute or considers it a highly desirable feature, then they need to make the case and it would go from 'desirement' to 'requirement'. I have no problem editing the draft based on actual input, but I have little interest in making all possible attributes equally desirable/needed. > > It might be quite easy to get feedback from TLD registries, > > but there are other DNS operators who may not have made > > their mind and, if they do, might disagree with the above > > categorization (as "nice to have"). > > True. However, given that we have established the impossibility of > satisfying all plausible requirements we are obliged to choose amongst > them, are we not? > > I'd also note that it is not generally required of WGs that > they should attempt to achieve consensus with non-participants! What he said. More specifically, having some background in both security and system administration I've really tried hard to think about the types of information that warrant protection--and other folks smarter than I am have done the same. The fact is that this remains a "postulated useful attribute" that no one has actually requested. > > When it comes to "zone size" and "zone enumeration", it's > > also important to view the first order differential, i.e. > > dies NSEC++ make it easier (than pre-DNSSEC DNS) to find > > the [number of] changes applied to zone? > > (This is not to introduce new hurdles, just completeness of > > the requirements list). > > Surely the appropriate differential is against NSEC in this > case, since NSEC3 is not designed to solve this particular > problem, so the requirement is surely to not make it worse > than NSEC, if possible, and if anyone cares at all. For my part, I considered the way NXT created a linked list to be "bad" back in 1999 when I first stuck my nose into it--so I want to actually do things sufficiently correctly this time baselined against plain-old-DNS-today. I also want this to be the last flag day that is even contemplated for quite a while, which implies fixing things both *soon* and *well*. But again, although metrics such as zone size, zone RRtype composition, and zone entry thrash/change percentage are all possibly of interest to someone (for some perceived competitive advantage even if not from a security perspective), no entity to date has stated a need much less a clear basis for that need. Comments requested, preferably clear statements of need (with basis) or clear statements that this sort of thing is *not* an issue for $organization. I don't disagree with Peter K. for raising the issue again, since we need quickly to agree on the basis for reviewing any proposed NSEC++ methods. Rip Loomis, CISSP, PMP =-=-=-=-=-= Senior Systems Security Engineer http://www.saic.com/infosec/ SAIC - Integrated Security and Systems Solutions -- to unsubscribe send a message to namedroppers-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 01 14:29:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX1pO-0001ai-Vj for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 14:29:51 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09563 for ; Tue, 1 Nov 2005 14:29:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EX1lb-0006Rd-Cr for namedroppers-data@psg.com; Tue, 01 Nov 2005 19:25:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EX1la-0006RP-LW for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 19:25:54 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 4195011425 for ; Tue, 1 Nov 2005 19:25:54 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: NSEC3 chain walking In-Reply-To: Your message of "Tue, 01 Nov 2005 16:45:31 +0100." <200511011545.jA1FjVR04049@tyrannia.TechFak.Uni-Bielefeld.DE> References: <200511011545.jA1FjVR04049@tyrannia.TechFak.Uni-Bielefeld.DE> Date: Tue, 01 Nov 2005 19:25:54 +0000 Message-Id: <20051101192554.4195011425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # not to question your assessment in this case, but the message should # probably be that "we" (be that the editors or the WG) should be careful # about other people's requirements, especially if they are crucial for a # deployment success. indeed, everyone who came forward when DNSSEC and DNSSEC-bis were planned said that enumeration was an evil they could live with. then things changed. apparently, the people who would later on care very much, were not asked. (that's the loop i'm hoping we find a way to break out of.) -- to unsubscribe send a message to namedroppers-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 01 14:40:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX1ze-00076Z-BD for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 14:40:26 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10069 for ; Tue, 1 Nov 2005 14:40:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EX1wn-00079Z-TK for namedroppers-data@psg.com; Tue, 01 Nov 2005 19:37:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EX1wn-00079O-C9 for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 19:37:29 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 024A711426 for ; Tue, 1 Nov 2005 19:37:29 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NSEC3 chain walking In-Reply-To: Your message of "Tue, 01 Nov 2005 18:09:50 GMT." <2E98D4FEAEFF40E41277E0B2@[192.168.100.25]> References: <436655E8.6030608@better.se> <43675923.5090108@algroup.co.uk> <863D71ECD691F4EF1368B2A6@[192.168.100.25]> <436767B5.5050602@algroup.co.uk> <20051101144916.073F811425@sa.vix.com> <2E98D4FEAEFF40E41277E0B2@[192.168.100.25]> Date: Tue, 01 Nov 2005 19:37:29 +0000 Message-Id: <20051101193729.024A711426@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # Didn't we do this with the requirements doc? And I thought noone in # particular much cared. had we done a requirements doc ten years ago that nominet and others would not have read because they might not have noticed that it would intersect their national privacy laws or business requirements, we might still have run into the NSEC3 juggernaut and be just as far off the rails now as we actually are now. perhaps something more should be done then write a draft and hope that the right people read it and understand its implications on their businesses? something like, oh, let's say, a market requirements survey? -- to unsubscribe send a message to namedroppers-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 01 15:08:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX2R0-0004np-Hr for dnsext-archive@megatron.ietf.org; Tue, 01 Nov 2005 15:08:42 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11597 for ; Tue, 1 Nov 2005 15:08:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EX2N2-0008np-3B for namedroppers-data@psg.com; Tue, 01 Nov 2005 20:04:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EX2N0-0008nb-Mz for namedroppers@ops.ietf.org; Tue, 01 Nov 2005 20:04:34 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id jA1K4Y7b009525; Tue, 1 Nov 2005 20:04:34 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id jA1K4XXg009522; Tue, 1 Nov 2005 20:04:34 GMT Date: Tue, 1 Nov 2005 20:04:28 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: NSEC3 chain walking Message-ID: <20051101200428.GB9453@vacation.karoshi.com.> References: <436655E8.6030608@better.se> <43675923.5090108@algroup.co.uk> <863D71ECD691F4EF1368B2A6@[192.168.100.25]> <436767B5.5050602@algroup.co.uk> <20051101144916.073F811425@sa.vix.com> <2E98D4FEAEFF40E41277E0B2@[192.168.100.25]> <20051101193729.024A711426@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051101193729.024A711426@sa.vix.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Nov 01, 2005 at 07:37:29PM +0000, Paul Vixie wrote: > # Didn't we do this with the requirements doc? And I thought noone in > # particular much cared. > > had we done a requirements doc ten years ago that nominet and others would > not have read because they might not have noticed that it would intersect > their national privacy laws or business requirements, we might still have a decade ago, the EU privacy laws were not anywhere near the state they are in now... > run into the NSEC3 juggernaut and be just as far off the rails now as we > actually are now. > > something like, oh, let's say, a market requirements survey? might as well also include potential shifts in the political climate as well... It is -possible- that a new McCarthy could arise and change the US landscape, or that the UN opts for the reestablishment of aparthide... (it is scary to me that the EU political process moves faster than the IETF...:) Seriously, if the IETF starts in on marketing requirements surveys, then i'm ready to espouse friend Bushs' rebranding as the IVTF. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 02 23:05:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXWMA-0004Yt-NG for dnsext-archive@megatron.ietf.org; Wed, 02 Nov 2005 23:05:43 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29159 for ; Wed, 2 Nov 2005 23:05:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXWF5-000AXl-KQ for namedroppers-data@psg.com; Thu, 03 Nov 2005 03:58:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXWF4-000AXP-7P for namedroppers@ops.ietf.org; Thu, 03 Nov 2005 03:58:22 +0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jA34AT2l006021 for ; Wed, 2 Nov 2005 21:10:29 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id jA348ZGj014369 for ; Wed, 2 Nov 2005 22:08:35 -0600 (CST) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Wed, 2 Nov 2005 22:58:19 -0500 Message-ID: <62173B970AE0A044AED8723C3BCF23810B721AAA@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: Harald Tveit Alvestrand , namedroppers@ops.ietf.org Subject: RE: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Wed, 2 Nov 2005 22:58:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, Thanks to everyone who commented on this draft. RFC 2606 documents three things: The rational for reserving certain names at the top and second level. The agreement of IANA to reserve 4 TLDs. And the policy of IANA to reserve the second level label "example" in .com, .net, and .org. At the time of the issuance of RFC 2606, IANA was under the direction of the IAB and was a part of the IETF and was Jon Postel, who was also RFC editor. The idea of 2606bis is to update RFC 2606. The policy function of IANA for most of domain name registration and registry selection is now performed by ICANN. So I obtained the closest ICANN policy statement I could to the IANA 2nd level label policy, spliced it in, and produced draft 2606bis. I should probably have included an Informational reference to RFC 2860 (and possibly RFC 2826) in the draft and plan to do so in the next version which I won't be able to post until after the IETF meeting in Vancouver, which I will be attending. I have read the entire thread so far with this subject line. Hope people don't mind that I'm just replying to the first message. Anyway, there seems to be considerable desire to include something about prohibition of numeric TLDs. At this time, I would think that all the IETF can say is that such TLDs SHOULD be reserved, since it is ICANN's call. (Also, a quick note on ccTLDs. This draft says nothing about them. It certainly doesn't say that anything is reserved at lower levels in them. Nor does it state that they are not reserved. It does not state that ICANN has the authority to regulate ccTLDs or their contents, nor does it say ICANN does not have that authority. All it says is that, by contract, ICANN imposes restrictions on 'many TLDs' and provides a pointer to a list of TLDs which do not include any ccTLDs. I was really trying to avoid controversy. But I've already gotten troll mail anyway.) See also below at @@@ -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Harald Tveit Alvestrand Sent: Thursday, October 20, 2005 6:56 AM To: namedroppers@ops.ietf.org Subject: draft-eastlake-2606bis-00.txt: Suggestions for modifications Hi, I couldn't find any discussion of this draft on the mailing list, but the draft says that it should be discussed here, so here it goes... WG chairs, please rule me out of order if it isn't appropriate (and ask the author to update the draft...) draft-eastlake-2606bis-00, "Reserved Top Level DNS Names", tries to update the old RFC that reserved ".test", ".example", ".invalid" and ".localhost". @@@ The old RFC also documents the IANA policy on example.{com|net|org}. RFC 2606 is a BCP, so presumably this document aims for the same status. Summary: This is definitely not a document that I think the IETF should publish as-is. My detailed comments: 1) I believe section 3.1 and 3.4 (reservation of "aso", "gnso", "afrinic", "rfc-editor" and so on) is inappropriate for the IETF and should be removed. This is ICANN's business. Optionally, I could argue that it should be reduced to "example", so that we could use "example.fr" as well as "example.com" in examples. @@@ Well, that's why I say that it is ICANN policy. So I gather you would prefer that the document, perhaps, only document ICANN reservation policy for things reserved for the same reason as the TLD reservations? If so, I would think it should also state that there are other labels, not listed, that ICANN has a policy of reserving in some TLDs. But it doesn't seem that bad to me and of interest to the IETF to know that "ietf", "rfc-editor", etc are being reserved. I am less sure about section 3.3 (prohibition of single character and two letter names). There may be technical justification for these (see the RFC describing the "com.com" problem, and how to fix it - the number escapes me) - but I know for a fact that multiple registries do hand out two-letter domain names today, and are likely to continue to do so no matter what the IETF says - so this needs *heavy* justification - my default proposal would be "remove". @@@ But this document isn't, currently, IETF policy. It just motivated and documents IANA/ICANN commitments/policy. @@@ Actually, in the past there was a theory that some mechanism might distribute the contents of a zone between servers based on the value of the first label byte. So, though not mentioned in RFC 2606 and possibly not documented anywhere but in moldy old emails, there was an IANA policy not to register single letter 2nd level domain names in .com, .net, or .org. But a few had already been registered by the time this policy was adopted and IANA did not de-register any of those. 2) A different conversation led to the (to me) surprising conclusion that there is no IETF document that conclusively states that top level domains shouldn't be all numeric. I think this is an appropriate thing for the IETF to state in a BCP, since 4-component all-numeric domain names are hard to tell from IP addresses - a technical consideration in many protocols. This could be added as a subsection of section 2 - since it's a new reason for reserving TLDs. @@@ Right, but, as I say above, I don't think the IETF can say anything stronger than SHOULD at this point, at least not without explicit agreement of ICANN. 3) The nature of the reservation of tagged domain names (xn--) in section 3.3 needs to be explained - the sentence is even grammatically incomplete. I *think* it's intended to reserve these labels at all levels until a normative interpretation is given in an IETF standard. But the para does not say. @@@ My source of ICANN policy didn't state motivation but it might be useful to mention the IDN use and clarify this. I believe there might be an IANA registry of those tags somewhere? If so, this should be mentioned. @@@ I'll check on this. Harald @@@ Anyway, I do plan to do another version improved in various ways as above and with a more clearly stated scope and intent. @@@ Thanks, @@@ 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 03 03:53:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXaqo-0001ZS-Md for dnsext-archive@megatron.ietf.org; Thu, 03 Nov 2005 03:53:39 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15375 for ; Thu, 3 Nov 2005 03:53:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXakT-000Mia-3x for namedroppers-data@psg.com; Thu, 03 Nov 2005 08:47:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXakS-000MiN-A0 for namedroppers@ops.ietf.org; Thu, 03 Nov 2005 08:47:04 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id A88FCC2DFF; Thu, 3 Nov 2005 08:47:00 +0000 (GMT) Date: Thu, 03 Nov 2005 08:46:48 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Eastlake III Donald-LDE008 , Harald Tveit Alvestrand , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: RE: draft-eastlake-2606bis-00.txt: Suggestions for modifications Message-ID: In-Reply-To: <62173B970AE0A044AED8723C3BCF23810B721AAA@ma19exm01.e6.bcs.mot.com> References: <62173B970AE0A044AED8723C3BCF23810B721AAA@ma19exm01.e6.bcs.mot.c om> X-Mailer: Mulberry/4.0.4 (Win32) 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 Content-Transfer-Encoding: 7bit --On 02 November 2005 22:58 -0500 Eastlake III Donald-LDE008 wrote: > So I obtained the closest ICANN policy statement I could to the IANA 2nd > level label policy, spliced it in, To what extent should we be reproducing ICANN policy in RFCs? 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 SallyRodriquez@holisticmom.net Thu Nov 03 04:02:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXazh-0006VU-To for dnsext-archive@megatron.ietf.org; Thu, 03 Nov 2005 04:02:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15861 for ; Thu, 3 Nov 2005 04:02:26 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXbEQ-0006t9-IO for dnsext-archive@ietf.org; Thu, 03 Nov 2005 04:18:05 -0500 Received: from [83.228.34.34] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1EXaye-0004aU-GU for dnsext-archive@ietf.org; Thu, 03 Nov 2005 04:01:44 -0500 Received: from MfQG@localhost by V02.int (8.11.6/8.11.6); Thu, 03 Nov 2005 12:18:16 +0600 Message-ID: From: "Nicole Ramos" Reply-To: "Nicole Ramos" To: dnsext-archive@ietf.org Subject: Top of the Line Photoshop Software at Guaranteed L0W PRlCES Date: Thu, 03 Nov 2005 11:10:16 +0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: SallyRodriquez@holisticmom.net Content-Type: multipart/mixed; boundary="--EvhlwLqnVtzhz0KoYJ" X-Spam-Score: 3.5 (+++) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 EY6m ----EvhlwLqnVtzhz0KoYJ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Y
Opt-in Email Special Offer   = ;  unsubscribe me
SEARCH

TOP 10 NEW TITLES

=
= = = <= td width=3D4> 
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&n= bsp;2 Creative Suite 2
&= nbsp;3 MS Office 2003 Pro
 4 Adobe Acrobat 7 Pro
 5 Macromedia Flash 8
 6<= /td> Dreamweaver 8
 7 Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
 10 Borland Architect 2005
  See more by this manufact= urer
   Microsoft
  = Macromedia
 =   = Adobe
  Customers also bought
   <= font face=3Dverdana,arial,helvetica size=3D1> these other items...

Microsoft Windows XP Professional *w/SP2*
Microsoft

Choose:<= td width=3D135>
 

=
List Pr= ice:$299.00
Pric= e:$49.99
You Save:$249.01 (80%)



Availability: Available for INSTANT download!
Coup= on Code: uQiUrcW
Platform: Windows XP

Sales R= ank: #1
System requirements  |  Other Versions
Date Coupon Exp= ires: December 31st, 2005
Average Cus= tomer Review:3D"5 Based on 14923 reviews. Write a review.

Adobe Creative Suite 2 *Premi= um*
Adobe=

Choose:
 

List Pr= ice:$1199.00
Pri= ce:$149.99
You Save:= $1049.01 (95%)

=

Availability: Available for INSTANT download!
C= oupon Code: JqCq3J
Platform: Windows XP

Sales= Rank: #2
System requirements  |  Other Versions
Date Coupon E= xpires: December 31st, 2005
Average C= ustomer Review:3D"5 Based on 1251 reviews. Write a review.

<= /td>

Microsoft Off= ice 2003 *Professional*
Microsoft

<= /tr>
Choose:=
 

List Price:$499.00
Price:$69.99
You Save:$429.0= 1 (85%)

<= img border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/buttons/add-to= -cart-yellow-short.gif width=3D113 height=3D23>

Availabilit= y: Available for INSTANT download!
Coupon Code: ZGXkAR
= Platform: Wind= ows XP

Sales Rank: #3
System requirements=   |  Other Versions=
Date Coupon Expires: December 31st, = 2005
Average Customer Review:3D"5= Based on 1171 reviews. Write a revie= w.

Adobe Acrobat Professional V 7.0
= Adobe

=
Choose:
=  

List Price:$499.00
Price:$69.99
You Save:$429.0= 1 (85%)

<= img border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/buttons/add-to= -cart-yellow-short.gif width=3D113 height=3D23>

Availabilit= y: Available for INSTANT download!
Coupon Code: ON0dN
<= b>Platform: Windo= ws XP

Sales Rank: #4
System requirements<= /a>  |  Other Versions<= /span>
Date Coupon Expires: December 31st, 2= 005
Average Customer Review:3D"5 = Based on 18431 reviews. Write a revie= w.

----EvhlwLqnVtzhz0KoYJ-- From SallyRodriquez@holisticmom.net Thu Nov 03 04:03:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXb0C-0006hc-Np for dnsext-archive@megatron.ietf.org; Thu, 03 Nov 2005 04:03:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15876 for ; Thu, 3 Nov 2005 04:02:57 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXbEx-0006tw-OH for dnsext-archive@ietf.org; Thu, 03 Nov 2005 04:18:36 -0500 Received: from cpe-70-95-3-106.hawaii.res.rr.com ([70.95.3.106]) by mx2.foretec.com with smtp (Exim 4.24) id 1EXb04-0004fw-C8 for dnsext-archive@ietf.org; Thu, 03 Nov 2005 04:03:15 -0500 Received: from MfQG@localhost by V02.int (8.11.6/8.11.6); Thu, 03 Nov 2005 12:18:16 +0600 Message-ID: From: "Nicole Ramos" Reply-To: "Nicole Ramos" To: dnsext-archive@ietf.org Subject: Top of the Line Photoshop Software at Guaranteed L0W PRlCES Date: Thu, 03 Nov 2005 11:10:16 +0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: SallyRodriquez@holisticmom.net Content-Type: multipart/mixed; boundary="--EvhlwLqnVtzhz0KoYJ" X-Spam-Score: 0.2 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 EY6m ----EvhlwLqnVtzhz0KoYJ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Y
Opt-in Email Special Offer   = ;  unsubscribe me
SEARCH

TOP 10 NEW TITLES

=
= = = <= td width=3D4> 
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&n= bsp;2 Creative Suite 2
&= nbsp;3 MS Office 2003 Pro
 4 Adobe Acrobat 7 Pro
 5 Macromedia Flash 8
 6<= /td> Dreamweaver 8
 7 Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
 10 Borland Architect 2005
  See more by this manufact= urer
   Microsoft
  = Macromedia
 =   = Adobe
  Customers also bought
   <= font face=3Dverdana,arial,helvetica size=3D1> these other items...

Microsoft Windows XP Professional *w/SP2*
Microsoft

Choose:<= td width=3D135>
 

=
List Pr= ice:$299.00
Pric= e:$49.99
You Save:$249.01 (80%)



Availability: Available for INSTANT download!
Coup= on Code: uQiUrcW
Platform: Windows XP

Sales R= ank: #1
System requirements  |  Other Versions
Date Coupon Exp= ires: December 31st, 2005
Average Cus= tomer Review:3D"5 Based on 14923 reviews. Write a review.

Adobe Creative Suite 2 *Premi= um*
Adobe=

Choose:
 

List Pr= ice:$1199.00
Pri= ce:$149.99
You Save:= $1049.01 (95%)

=

Availability: Available for INSTANT download!
C= oupon Code: JqCq3J
Platform: Windows XP

Sales= Rank: #2
System requirements  |  Other Versions
Date Coupon E= xpires: December 31st, 2005
Average C= ustomer Review:3D"5 Based on 1251 reviews. Write a review.

<= /td>

Microsoft Off= ice 2003 *Professional*
Microsoft

<= /tr>
Choose:=
 

List Price:$499.00
Price:$69.99
You Save:$429.0= 1 (85%)

<= img border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/buttons/add-to= -cart-yellow-short.gif width=3D113 height=3D23>

Availabilit= y: Available for INSTANT download!
Coupon Code: ZGXkAR
= Platform: Wind= ows XP

Sales Rank: #3
System requirements=   |  Other Versions=
Date Coupon Expires: December 31st, = 2005
Average Customer Review:3D"5= Based on 1171 reviews. Write a revie= w.

Adobe Acrobat Professional V 7.0
= Adobe

=
Choose:
=  

List Price:$499.00
Price:$69.99
You Save:$429.0= 1 (85%)

<= img border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/buttons/add-to= -cart-yellow-short.gif width=3D113 height=3D23>

Availabilit= y: Available for INSTANT download!
Coupon Code: ON0dN
<= b>Platform: Windo= ws XP

Sales Rank: #4
System requirements<= /a>  |  Other Versions<= /span>
Date Coupon Expires: December 31st, 2= 005
Average Customer Review:3D"5 = Based on 18431 reviews. Write a revie= w.

----EvhlwLqnVtzhz0KoYJ-- From owner-namedroppers@ops.ietf.org Thu Nov 03 10:56:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXhRZ-0006HU-Rm for dnsext-archive@megatron.ietf.org; Thu, 03 Nov 2005 10:56:01 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07863 for ; Thu, 3 Nov 2005 10:55:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXhMN-000FVb-Qa for namedroppers-data@psg.com; Thu, 03 Nov 2005 15:50:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [144.189.100.103] (helo=motgate3.mot.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXhMM-000FV6-Ok for namedroppers@ops.ietf.org; Thu, 03 Nov 2005 15:50:38 +0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id jA3G6hKD022936 for ; Thu, 3 Nov 2005 09:06:43 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id jA3FwKO2014737 for ; Thu, 3 Nov 2005 09:58:21 -0600 (CST) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Thu, 3 Nov 2005 10:50:34 -0500 Message-ID: <62173B970AE0A044AED8723C3BCF23810B721F2B@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: namedroppers@ops.ietf.org Subject: RE: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Thu, 3 Nov 2005 10:50:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alex, Well, I can't see any problem with just putting it "in RFCs". RFCs are frequently used to provide more convenient access to standards/policies of other organizations. Presumably the questions is whether it should be in a Best Current Practice. As the specifier and maintainer of the DNS protocol, it seems to me reasonable for the IETF to specify Best Current Practices for test / example domain names. Furthermore, if there are labels that might best be reserved and not used or reserved for certain purposes due to widespread use, such as .localhost, or IETF specified and maintained syntax, such as numeric TLDs, or to avoid confusion with IETF organizations, such as "ietf" as a 2nd level domain name, or which the IETF might want to reserve for future syntax/protocol development, such as "tagged" labels or one character labels, it seems reasonable to document such things in a Best Current Practice RFC. If the reservation is by another organization, such as ICANN/IANA in this case, then it seems reasonable to me for the BCP to document agreements with this other organization, state requests to the other organization (presumably as SHOULDs), and, to the extent that it fits into or reasonably close to all this, state poli! cies of the other organization. In this case, it is important to be clearer about who is in charge of what than I was in this -00 draft. Thanks, Donald PS: There certainly exist many old registrations which violate the desired policies. ietf.com and x.com resolve just fine. -----Original Message----- From: Alex Bligh [mailto:alex@alex.org.uk] Sent: Thursday, November 03, 2005 3:47 AM To: Eastlake III Donald-LDE008; Harald Tveit Alvestrand; namedroppers@ops.ietf.org Cc: Alex Bligh Subject: RE: draft-eastlake-2606bis-00.txt: Suggestions for modifications --On 02 November 2005 22:58 -0500 Eastlake III Donald-LDE008 wrote: > So I obtained the closest ICANN policy statement I could to the IANA > 2nd level label policy, spliced it in, To what extent should we be reproducing ICANN policy in RFCs? 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 03 11:42:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXiAq-0004Rf-4N for dnsext-archive@megatron.ietf.org; Thu, 03 Nov 2005 11:42:50 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11349 for ; Thu, 3 Nov 2005 11:42:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXi6a-000Hw4-DW for namedroppers-data@psg.com; Thu, 03 Nov 2005 16:38:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [32.97.182.145] (helo=e5.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EXi6Z-000Hvt-4a for namedroppers@ops.ietf.org; Thu, 03 Nov 2005 16:38:23 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jA3GcBt2019921 for ; Thu, 3 Nov 2005 11:38:12 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id jA3GcBg6048972 for ; Thu, 3 Nov 2005 11:38:11 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jA3Gc0Q1027127 for ; Thu, 3 Nov 2005 11:38:01 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-248-18.mts.ibm.com [9.65.248.18]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jA3Gbxog026625; Thu, 3 Nov 2005 11:38:00 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id jA3Gbl0C006036; Thu, 3 Nov 2005 11:37:47 -0500 Message-Id: <200511031637.jA3Gbl0C006036@cichlid.raleigh.ibm.com> To: Alex Bligh cc: Eastlake III Donald-LDE008 , Harald Tveit Alvestrand , namedroppers@ops.ietf.org Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications In-Reply-To: Message from Alex Bligh of "Thu, 03 Nov 2005 08:46:48 GMT." Date: Thu, 03 Nov 2005 11:37:47 -0500 From: Thomas Narten Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > So I obtained the closest ICANN policy statement I could to the IANA 2nd > > level label policy, spliced it in, > To what extent should we be reproducing ICANN policy in RFCs? IMO, we should not at all. At best, include a pointer to ICANN and say "their turf". RFCs are around forever. ICANN policy can and will change. Indeed, ICANN/registry contracts are an area of active evolution at the moment. After reading the text, I'd say pretty much all of the new material that got added to Section 3 should be removed. Specifically: > 3. Reserved Second Level Domain Names > > At the time of the issuance of [RFC 2606], the Internet Assigned > Numbers Authority (IANA, http://www.iana.org) had reserved the > following second level domain names reserved which can be used as > examples. > > example.com > example.net > example.org OK so far... > > At this time, similar restrictions are by way of contract between the > Internet Corporation for Assigned Names and Numbers (ICANN, > http://www.icann.org) and the Registry Operators of many top level > domains. See . I don't think the above should be said. It sugggests that example. are safe to use for testing. Should we suggest that? Do we even need to? I confess to having chatted with Don about this document before -00 appeared. At the time, I sort of assumed that "example" might need reserving in all the TLDs, since new ones had been added. But thinking some more about this, I have to actually wonder, what problem are we trying to fix here? Is there _really_ a need (for, e.g., documentation) to be able to use example., for any TLD that exists? The answer is not an obvious yes to me. Just use example.com. Or example.example, etc. If we were to conclude that example should be reserved in all TLDs, I think we'd have to do a careful dance with ICANN before publishing that in a BCP. I.e., get them to review the proposal, have the board agree to it, and then somehow both agree this is a recommendation going forward. But, I'm not at all convinced this needs doing, as in, this fixes a known problem. > > The ICANN "Schedule of Reserved Names" most recent version, as of the > date of this document, is at > agreement-01jul05.pdf>. It reserves the labels listed in the > following subsections, except when released by ICANN. Again, this will change. At most, I'd suggestion text like: A number of second-level domains are reserved via ICANN policy, see [XXX] for details. with [XXX] being a generic reference to policies, not one policy in particular. > 3.1 Labels Reserved at All Levels > > These are reserved from initial registration, unless ICANN grants an > exemption, at the second level and at all deeper levels where the top > level registry operator performs registration. If they have been > previously registered, they may be renewed and there is no > restriction on their existence in delegated zones. > > ICANN-related names: > aso > gnso > icann > internic > ccnso > IANA-related names: > afrinic > apnic > arin > example > gtld-servers > iab > iana > iana-servers > iesg > ietf > irtf > istf > lacnic > latnic > rfc-editor > ripe > root-servers Just remove this entire section. We don't need to document this. It's not necessary to even know about these from the perspective of testing/documentation (which is what the introduction talks about). > > 3.2 Additional Second-Level Reservations > > The follows labels are prohibited as second level domain names: > > All single character labels. There is history here, and I think it would be good to document this somewhere (especially the reasoning behind the prohibition), but I'm not at all sure that this document is a good place to do it. Again, it doesn't seem directly relevant to the scope of this draft. > All two character labels unless a release is obtained from the > government and country-code manager if that two letter > combination is an assigned country-code or a release from the > ISO 3166 maintenance agency if it has not been so assigned. Why mention this? > > 3.3 Tagged Domain Names > > All labels with hyphens in the third and fourth character positions > such as "bq--1k2n4h4b" or "xn--ndk061n". Why does this need to be mentioned? > 3.4 Second-Level Reservations for Registry Operators > > The following are reserved for the use of the top level domain > Registry Operator and will be transferred whenever the Operator > changes: > > nic > whois > www > > Again, ICANN business. No need to say anything here. Now, having written all the above, I'm back to trying to understand something very basic: what is the problem with 2606 that needs fixing/updating? Do we actually need an updated to 2606? Thomas -- to unsubscribe send a message to namedroppers-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 03 13:24:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXjlG-0001oF-Mo for dnsext-archive@megatron.ietf.org; Thu, 03 Nov 2005 13:24:31 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18655 for ; Thu, 3 Nov 2005 13:24:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXjhB-000MyU-Az for namedroppers-data@psg.com; Thu, 03 Nov 2005 18:20:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EXjh9-000MyH-V3 for namedroppers@ops.ietf.org; Thu, 03 Nov 2005 18:20:16 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jA3IKBaq062361 for ; Thu, 3 Nov 2005 19:20:12 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-32-263472230" To: Namedroppers From: "Olaf M. Kolkman" Subject: DNSKEY size calculator and implementation question Date: Thu, 3 Nov 2005 10:20:10 -0800 X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-32-263472230 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Colleagues, One of the questions that one may ask oneself is how much DNSKEYs can I put into a keyset before truncation happens. In order to calculate the amount of truncation my co-worker Jelte Jansen whipped up a small script at http://www.nlnetlabs.nl/dnssec/ packetsize.html. The script calculates the packet size for a response to (QNAME="." QTYPE=DNSKEY) query at one of the root servers. Given a distribution of EDNS0 sizes it calculates the fraction replies to "DNSSEC" queries that are truncated. The default distribution is taken from a recent query trace from k.root-servers.net (See RIPE 352). I think this comes in handy in the discussions of key-rollover, hence the plug. If you have any suggestions to improve this very trivial tool we'd welcome them off-band. Now for the implementation question. BIND has been returning an NS RR set in the authority section for positive answers from authoritative servers. To my understanding this is not needed. If one follows the algorithm from 1034 section 4.3.2 for authoritative data one finds that, when resolving an existing name,type combination one hits 3.a and continues to step 6, which is adding material to the additional section. For authoritative only servers one never hits step 4 which is the step that adds data from the authority section. Step 4 is only 'hit' when you have no authoritative answer available. No I do understand that there are reasons to include the NS RRset in the authority section anyway but as far as I know these reasons have never been documented. My first question is: are these reasons documented? The assumption we made in the calculator above is that the NS RR set can be removed from the authority section _without_ setting the TC bit because we think that there is no requirement to have that NS set there in the first place (for authoritative servers). My second question is: Is this a valid assumption if not what are we missing, where is the behavior specified? No hats, --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-32-263472230 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.1 (Darwin) Comment: This message is locally signed. iD8DBQFDalTbtN/ca3YJIocRAoRVAJ0bqgcz4rTtfvcvNr+TD6JnMqlTDgCfQJaa LgLZl/5MNcsSoCsfKjv29ho= =Rkdd -----END PGP SIGNATURE----- --Apple-Mail-32-263472230-- -- to unsubscribe send a message to namedroppers-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 03 13:37:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXjxe-0004t4-Oo for dnsext-archive@megatron.ietf.org; Thu, 03 Nov 2005 13:37:20 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19227 for ; Thu, 3 Nov 2005 13:36:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXjuh-000NgR-4z for namedroppers-data@psg.com; Thu, 03 Nov 2005 18:34:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EXjue-000NgE-Mn for namedroppers@ops.ietf.org; Thu, 03 Nov 2005 18:34:12 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 4A68911425 for ; Thu, 3 Nov 2005 18:34:12 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: requesting a 5 minute slot on the DNSEXT agenda in vancouver Date: Thu, 03 Nov 2005 18:34:12 +0000 Message-Id: <20051103183412.4A68911425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk olaf and olafur, i'd like to present an idea i've got for a simple key rollover scheme and get some audience feedback so i'll know whether it's worth writing an i-d. paul -- to unsubscribe send a message to namedroppers-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 03 13:48:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXk8W-0008RB-Nd for dnsext-archive@megatron.ietf.org; Thu, 03 Nov 2005 13:48:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19820 for ; Thu, 3 Nov 2005 13:48:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXk5X-000OMX-W3 for namedroppers-data@psg.com; Thu, 03 Nov 2005 18:45:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [200.34.200.188] (helo=as2.itesm.mx) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXk5X-000OMM-7g for namedroppers@ops.ietf.org; Thu, 03 Nov 2005 18:45:27 +0000 X-IronPort-AV: i="3.97,288,1125896400"; d="scan'208"; a="61387142:sNHT21625176" Received: from [10.17.135.231] by itesm.mx with HTTP; Thu, 3 Nov 2005 12:45:25 -0600 Date: Thu, 3 Nov 2005 12:45:25 -0600 Message-ID: <43629E0400000C1D@mailserver3.itesm.mx> From: albertof_mtzherrera@itesm.mx Subject: Subject: key rollover proposals comparison To: namedroppers@ops.ietf.org, dnssec-deployment@shinkuro.com Cc: glozano@nic.mx MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I am working in a document that tries to explain the different key rollo= ver drafts (in band, revokation bit, takrem and dlv) that have been circulati= ng using conceptual diagrams. At the end of this document I have made a comp= arison of the different proposals. I think this WG could find interest in this _= document_._ =A0 I will keep this document ?up-to-date? and if someone wants to participa= te contact me. Suggestions and corrections are appreciated. URL: http://docs.nicmxlabs.org.mx/itesm/dnsseckeyrolloverproposals.pdf =A0 Thank you. Alberto Mart=EDnez Herrera -- to unsubscribe send a message to namedroppers-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 03 13:57:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXkH4-0002MJ-Qq for dnsext-archive@megatron.ietf.org; Thu, 03 Nov 2005 13:57:22 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20215 for ; Thu, 3 Nov 2005 13:57:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXkDI-000OqK-0q for namedroppers-data@psg.com; Thu, 03 Nov 2005 18:53:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EXkDH-000Oq9-6V for namedroppers@ops.ietf.org; Thu, 03 Nov 2005 18:53:27 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jA3IrLot063026; Thu, 3 Nov 2005 19:53:22 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <20051103183412.4A68911425@sa.vix.com> References: <20051103183412.4A68911425@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-33-265456468" Message-Id: Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: requesting a 5 minute slot on the DNSEXT agenda in vancouver Date: Thu, 3 Nov 2005 10:53:15 -0800 To: Paul Vixie X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-33-265456468 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit > > i'd like to present an idea i've got for a simple key rollover > scheme and > get some audience feedback so i'll know whether it's worth writing > an i-d. > As rollover schemes are on the agenda I think we can squeeze you in. You'll have about 5 to 7 minutes. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-33-265456468 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.1 (Darwin) Comment: This message is locally signed. iD8DBQFDalyhtN/ca3YJIocRAkICAKCHiPI0do857eg0g09IgPMCz4wPTQCgwT9Z SdQxrkbfRI2RxGNtDNWDEio= =RIcZ -----END PGP SIGNATURE----- --Apple-Mail-33-265456468-- -- to unsubscribe send a message to namedroppers-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 03 14:15:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXkYy-00079H-NA for dnsext-archive@megatron.ietf.org; Thu, 03 Nov 2005 14:15:53 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20740 for ; Thu, 3 Nov 2005 14:15:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXkW2-000PsL-9Q for namedroppers-data@psg.com; Thu, 03 Nov 2005 19:12:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EXkW1-000Ps8-5z for namedroppers@ops.ietf.org; Thu, 03 Nov 2005 19:12:49 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id jA3JCZDt090156 for ; Thu, 3 Nov 2005 14:12:35 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id jA3JCZiV090155 for namedroppers@ops.ietf.org; Thu, 3 Nov 2005 14:12:35 -0500 (EST) (envelope-from namedroppers) Received: from [138.25.6.6] (helo=succubus.progsoc.uts.edu.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EWU3A-0006Ui-Is for namedroppers@ops.ietf.org; Mon, 31 Oct 2005 07:25:49 +0000 Received: from wildfire by succubus.progsoc.uts.edu.au with local (Exim 4.50) id 1EWU2v-0000GZ-4Z; Mon, 31 Oct 2005 18:25:33 +1100 Date: Mon, 31 Oct 2005 18:25:32 +1100 To: atom@smasher.org, simon@josefsson.org Cc: namedroppers@ops.ietf.org, ietf-openpgp@imc.org Subject: draft-josefsson-openpgp-mailnews-header and draft-ietf-dnsext-rfc2538bis-09.txt Message-ID: <20051031072532.GC29693@progsoc.uts.edu.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rUQ1rXFx4trAG42S" Content-Disposition: inline User-Agent: Mutt/1.5.9i From: Anand Kumria X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: wildfire@progsoc.uts.edu.au X-SA-Exim-Scanned: No (on succubus.progsoc.uts.edu.au); SAEximRunCond expanded to false X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ 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. ] --rUQ1rXFx4trAG42S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi there, The openpgp-mailnews-header defines a mechanism for senders to notify recipients of both their preferences (w.r.t OpenPGP keys) and the keying material to be used (e.g. keyid). dnsext-rfc2538bis defines a mechanism where keying material is stored within the DNS (e.g. OpenPGP). The overlap here is that users may wish to store their key in the DNS (via dnsext-rfc2538bis) and refer to them using openpgp-mailnews-header. Since openpgp-mailnews-header specifies using a URI to refer to the location, it would seem -- to me at least -- that there needs to be some kind of URI specification to allow you to refer to DNS resource records. Is there one already, or work underway to produce a DNS URI spec.? Cheers, Anand --=20 `When any government, or any church for that matter, undertakes to say to its subjects, "This you may not read, this you must not see, this you are forbidden to know," the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, "If this goes on --" --rUQ1rXFx4trAG42S Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQCVAwUBQ2XG7GRmcAD8BdppAQKJQAQAh3AN51i/TNMRPueGAaid+rwwe1ATT8Fp K6h9kgRMG7pyiAGobvh+/on91cnm1c6Zu5oXB228LupZlyniHkZYsTCuL1DNoEU3 B+nu+lv+3Sh8aE1D8zc4zgI8FLQ02E3rFStCZDDCz4FThwZ6RE6n07RMVQgkCA/Z BUvxXbu0Sy4= =nGK2 -----END PGP SIGNATURE----- --rUQ1rXFx4trAG42S-- -- to unsubscribe send a message to namedroppers-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 03 14:34:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXkr8-0003X8-1l for dnsext-archive@megatron.ietf.org; Thu, 03 Nov 2005 14:34:38 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21662 for ; Thu, 3 Nov 2005 14:34:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXknd-0006O7-4Z for namedroppers-data@psg.com; Thu, 03 Nov 2005 19:31:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [216.148.227.117] (helo=rwcrmhc11.comcast.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXknb-0006Nl-Gd for namedroppers@ops.ietf.org; Thu, 03 Nov 2005 19:30:59 +0000 Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc11) with ESMTP id <2005110319305401300g34ase>; Thu, 3 Nov 2005 19:30:56 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jA3JUsX6022478; Thu, 3 Nov 2005 14:30:54 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jA3JUqd5001689; Thu, 3 Nov 2005 14:30:52 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jA3JUpF1001688; Thu, 3 Nov 2005 14:30:51 -0500 Date: Thu, 3 Nov 2005 14:30:51 -0500 From: David Shaw To: Anand Kumria Cc: atom@smasher.org, simon@josefsson.org, namedroppers@ops.ietf.org, ietf-openpgp@imc.org Subject: Re: draft-josefsson-openpgp-mailnews-header and draft-ietf-dnsext-rfc2538bis-09.txt Message-ID: <20051103193051.GA1671@jabberwocky.com> Mail-Followup-To: Anand Kumria , atom@smasher.org, simon@josefsson.org, namedroppers@ops.ietf.org, ietf-openpgp@imc.org References: <20051031072532.GC29693@progsoc.uts.edu.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051031072532.GC29693@progsoc.uts.edu.au> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Oct 31, 2005 at 06:25:32PM +1100, Anand Kumria wrote: > Hi there, > > The openpgp-mailnews-header defines a mechanism for senders to notify > recipients of both their preferences (w.r.t OpenPGP keys) and the keying > material to be used (e.g. keyid). > > dnsext-rfc2538bis defines a mechanism where keying material is stored > within the DNS (e.g. OpenPGP). The overlap here is that users may wish > to store their key in the DNS (via dnsext-rfc2538bis) and refer to them > using openpgp-mailnews-header. > > Since openpgp-mailnews-header specifies using a URI to refer to the > location, it would seem -- to me at least -- that there needs to be some > kind of URI specification to allow you to refer to DNS resource records. > > Is there one already, or work underway to produce a DNS URI spec.? There is this, by the same author as rfc2538bis: http://josefsson.org/dns-url/draft-josefsson-dns-url-13.txt David -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 03 17:25:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXnWD-0007k1-9E for dnsext-archive@megatron.ietf.org; Thu, 03 Nov 2005 17:25:13 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01927 for ; Thu, 3 Nov 2005 17:24:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXnQX-000I7X-Dr for namedroppers-data@psg.com; Thu, 03 Nov 2005 22:19:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EXnQW-000I6T-KY for namedroppers@ops.ietf.org; Thu, 03 Nov 2005 22:19:20 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 7E903677FD for ; Thu, 3 Nov 2005 22:19:19 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id jA3MJ7pG022100; Fri, 4 Nov 2005 09:19:09 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200511032219.jA3MJ7pG022100@drugs.dv.isc.org> To: "Olaf M. Kolkman" Cc: Namedroppers From: Mark Andrews Subject: Re: DNSKEY size calculator and implementation question In-reply-to: Your message of "Thu, 03 Nov 2005 10:20:10 -0800." Date: Fri, 04 Nov 2005 09:19:07 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Colleagues, > > One of the questions that one may ask oneself is how much DNSKEYs can > I put into a keyset before truncation happens. > > In order to calculate the amount of truncation my co-worker Jelte > Jansen whipped up a small script at http://www.nlnetlabs.nl/dnssec/ > packetsize.html. > > The script calculates the packet size for a response to (QNAME="." > QTYPE=DNSKEY) query at one of the root servers. Given a distribution > of EDNS0 sizes it calculates the fraction replies to "DNSSEC" queries > that are truncated. The default distribution is taken from a recent > query trace from k.root-servers.net (See RIPE 352). > > I think this comes in handy in the discussions of key-rollover, hence > the plug. If you have any suggestions to improve this very trivial > tool we'd welcome them off-band. > > Now for the implementation question. > > BIND has been returning an NS RR set in the authority section for > positive answers from authoritative servers. To my understanding this > is not needed. It is actually. There are configurations where caches can't learn the set of servers they should be querying without it. They end up only querying the parent servers which may or may not be the complete set of servers for the zone. > If one follows the algorithm from 1034 section 4.3.2 for > authoritative data one finds that, when resolving an existing > name,type combination one hits 3.a and continues to step 6, which is > adding material to the additional section. For authoritative only > servers one never hits step 4 which is the step that adds data from > the authority section. Step 4 is only 'hit' when you have no > authoritative answer available. > > No I do understand that there are reasons to include the NS RRset in > the authority section anyway but as far as I know these reasons have > never been documented. My first question is: are these reasons > documented? > > The assumption we made in the calculator above is that the NS RR set > can be removed from the authority section _without_ setting the TC > bit because we think that there is no requirement to have that NS set > there in the first place (for authoritative servers). > > My second question is: Is this a valid assumption if not what are we > missing, where is the behavior specified? > > No hats, > > --Olaf > > ----------------------------------------------------------- > Olaf M. Kolkman > NLnet Labs > http://www.nlnetlabs.nl/ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 03 18:53:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXotG-00031O-KM for dnsext-archive@megatron.ietf.org; Thu, 03 Nov 2005 18:53:06 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05428 for ; Thu, 3 Nov 2005 18:52:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXop7-0001A2-OQ for namedroppers-data@psg.com; Thu, 03 Nov 2005 23:48:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EXop6-00018g-8q for namedroppers@ops.ietf.org; Thu, 03 Nov 2005 23:48:48 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jA3NmfbV066382; Fri, 4 Nov 2005 00:48:42 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <200511032219.jA3MJ7pG022100@drugs.dv.isc.org> References: <200511032219.jA3MJ7pG022100@drugs.dv.isc.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2-283181776" Message-Id: Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: DNSKEY size calculator and implementation question Date: Thu, 3 Nov 2005 15:48:40 -0800 To: Mark Andrews X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2-283181776 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Nov 3, 2005, at 14:19 , Mark Andrews wrote: >> BIND has been returning an NS RR set in the authority section for >> positive answers from authoritative servers. To my understanding this >> is not needed. > > It is actually. There are configurations where caches can't > learn the set of servers they should be querying without it. > They end up only querying the parent servers which may or > may not be the complete set of servers for the zone. > Let me rephrase: To my understanding this is not required by the RFCs? Is the need you describe above documented somewhere? If this behavior is so important should it be standardized? --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-2-283181776 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.1 (Darwin) Comment: This message is locally signed. iD8DBQFDaqHYtN/ca3YJIocRApQqAJ4zzMcEumG/9EZqKwuUDPHxgWAahQCg2/HQ j6YcD9VK1JKLNJQFzXnljWw= =Ul1s -----END PGP SIGNATURE----- --Apple-Mail-2-283181776-- -- to unsubscribe send a message to namedroppers-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 03 19:18:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXpHT-0008NW-Uk for dnsext-archive@megatron.ietf.org; Thu, 03 Nov 2005 19:18:08 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06539 for ; Thu, 3 Nov 2005 19:17:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXpEI-000BgT-GI for namedroppers-data@psg.com; Fri, 04 Nov 2005 00:14:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EXpEH-000BgH-Pl for namedroppers@ops.ietf.org; Fri, 04 Nov 2005 00:14:49 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 27D7D677FD for ; Fri, 4 Nov 2005 00:14:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id jA40Egit079673; Fri, 4 Nov 2005 11:14:42 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200511040014.jA40Egit079673@drugs.dv.isc.org> To: "Olaf M. Kolkman" Cc: Namedroppers From: Mark Andrews Subject: Re: DNSKEY size calculator and implementation question In-reply-to: Your message of "Thu, 03 Nov 2005 15:48:40 -0800." Date: Fri, 04 Nov 2005 11:14:42 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --Apple-Mail-2-283181776 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; charset=US-ASCII; format=flowed > > > On Nov 3, 2005, at 14:19 , Mark Andrews wrote: > > >> BIND has been returning an NS RR set in the authority section for > >> positive answers from authoritative servers. To my understanding this > >> is not needed. > > > > It is actually. There are configurations where caches can't > > learn the set of servers they should be querying without it. > > They end up only querying the parent servers which may or > > may not be the complete set of servers for the zone. > > > > Let me rephrase: To my understanding this is not required by the RFCs? > > Is the need you describe above documented somewhere? > If this behavior is so important should it be standardized? Yes. You really need to make sure the NS RRset is returned by the auth servers so DNSSEC aware caches can set AD on their replies. Mark > --Olaf > > ----------------------------------------------------------- > Olaf M. Kolkman > NLnet Labs > http://www.nlnetlabs.nl/ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 03 20:31:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXqQj-0000fL-Dw for dnsext-archive@megatron.ietf.org; Thu, 03 Nov 2005 20:31:45 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11916 for ; Thu, 3 Nov 2005 20:31:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXqMy-000Eqe-3N for namedroppers-data@psg.com; Fri, 04 Nov 2005 01:27:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EXqMx-000EpS-2c for namedroppers@ops.ietf.org; Fri, 04 Nov 2005 01:27:51 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jA41Rfxp067140; Fri, 4 Nov 2005 02:27:43 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <200511040014.jA40Egit079673@drugs.dv.isc.org> References: <200511040014.jA40Egit079673@drugs.dv.isc.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5-289119466" Message-Id: Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: DNSKEY size calculator and implementation question Date: Thu, 3 Nov 2005 17:27:37 -0800 To: Mark Andrews X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-5-289119466 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit > > Yes. You really need to make sure the NS RRset is returned > by the auth servers so DNSSEC aware caches can set AD on > their replies. So let me try to construct the reasoning here. I do not want to put words into your mouth Mark. I want to try and understand the need for this data and see if we need clarifying documentation. And if not for that then for my own understanding and piece of mind. So we look at what happens in caching name servers: 1034 sect 4.2.3 Step 4 tells us: If there was no delegation from authoritative data, look for the best one from the cache, and put it in the authority section. Go to step 6. 4035 sect 3.1.6 A security-aware name server MUST NOT set the AD bit in a response unless the name server considers all RRsets in the Answer and Authority sections of the response to be authentic. Clearly this means that if a caching forwarder does not have a forwarding name server RR set in its cache it cannot set the AD bit for such a response. You seem to turn this reasoning into the following requirement; In order to be able to set the AD bit a forwarding name server needs to have validated NS RR sets in its cache. In order to fulfill this requirement a signed NS RR set needs to be provided to the forwarding name server. Hence authoritative servers need to add a signed NS RR set in the authority section. So far so good? --Olaf [1] See http://www.ripe.net/ripe/docs/ripe-352/img4.png ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-5-289119466 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.1 (Darwin) Comment: This message is locally signed. iD8DBQFDarkKtN/ca3YJIocRAs0FAJ0b1ICM835CZ4cjxg33PsHd6T4hBgCeN21Z qKfjwpk0qZVngZ7ok3xOcwI= =zi6v -----END PGP SIGNATURE----- --Apple-Mail-5-289119466-- -- to unsubscribe send a message to namedroppers-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 03 20:38:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXqWn-0002LA-0N for dnsext-archive@megatron.ietf.org; Thu, 03 Nov 2005 20:38:01 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12343 for ; Thu, 3 Nov 2005 20:37:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXqTh-000HYn-L5 for namedroppers-data@psg.com; Fri, 04 Nov 2005 01:34:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EXqTg-000HXg-Vy for namedroppers@ops.ietf.org; Fri, 04 Nov 2005 01:34:49 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id F07D8677F6 for ; Fri, 4 Nov 2005 01:34:47 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id jA41Ydfx003842; Fri, 4 Nov 2005 12:34:39 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200511040134.jA41Ydfx003842@drugs.dv.isc.org> To: "Olaf M. Kolkman" Cc: Namedroppers From: Mark Andrews Subject: Re: DNSKEY size calculator and implementation question In-reply-to: Your message of "Thu, 03 Nov 2005 17:27:37 -0800." Date: Fri, 04 Nov 2005 12:34:39 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --Apple-Mail-5-289119466 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > > > Yes. You really need to make sure the NS RRset is returned > > by the auth servers so DNSSEC aware caches can set AD on > > their replies. > > So let me try to construct the reasoning here. I do not want to put > words into your mouth Mark. I want to try and understand the need for > this data and see if we need clarifying documentation. And if not for > that then for my own understanding and piece of mind. > > So we look at what happens in caching name servers: > > 1034 sect 4.2.3 Step 4 tells us: > If there was no delegation from authoritative data, look for > the best one from the cache, > and put it in the authority section. Go to step 6. > > 4035 sect 3.1.6 > A security-aware name server MUST NOT set the AD bit in a response > unless the name server considers all RRsets in the Answer and > Authority sections of the response to be authentic. > > Clearly this means that if a caching forwarder does not have a > forwarding name server RR set in its cache it cannot set the AD bit > for such a response. > > You seem to turn this reasoning into the following requirement; In > order to be able to set the AD bit a forwarding name server needs to > have validated NS RR sets in its cache. > > In order to fulfill this requirement a signed NS RR set needs to be > provided to the forwarding name server. Hence authoritative servers > need to add a signed NS RR set in the authority section. > > So far so good? Yep. > --Olaf > > [1] See http://www.ripe.net/ripe/docs/ripe-352/img4.png > > ----------------------------------------------------------- > Olaf M. Kolkman > NLnet Labs > http://www.nlnetlabs.nl/ > > > > > --Apple-Mail-5-289119466 > 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.1 (Darwin) > Comment: This message is locally signed. > > iD8DBQFDarkKtN/ca3YJIocRAs0FAJ0b1ICM835CZ4cjxg33PsHd6T4hBgCeN21Z > qKfjwpk0qZVngZ7ok3xOcwI= > =zi6v > -----END PGP SIGNATURE----- > > --Apple-Mail-5-289119466-- -- 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 04 03:40:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXx7w-0005YS-2p for dnsext-archive@megatron.ietf.org; Fri, 04 Nov 2005 03:40:48 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02271 for ; Fri, 4 Nov 2005 03:40:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EXx2M-0002DP-He for namedroppers-data@psg.com; Fri, 04 Nov 2005 08:35:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXx2L-0002Cq-OH for namedroppers@ops.ietf.org; Fri, 04 Nov 2005 08:35:01 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 7FD4026C07A for ; Fri, 4 Nov 2005 09:35:00 +0100 (CET) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 9F06726C0C0 for ; Fri, 4 Nov 2005 09:34:54 +0100 (CET) Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id jA48YsYa918243 for ; Fri, 4 Nov 2005 09:34:54 +0100 (CET) Received: by batilda.nic.fr (Postfix, from userid 1000) id 2EBBB16A9A4; Fri, 4 Nov 2005 09:34:54 +0100 (CET) Date: Fri, 4 Nov 2005 09:34:54 +0100 From: Stephane Bortzmeyer To: namedroppers@ops.ietf.org Subject: Re: draft-eastlake-2606bis-00.txt: Suggestion for removal Message-ID: <20051104083454.GA7924@nic.fr> References: <200511031637.jA3Gbl0C006036@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200511031637.jA3Gbl0C006036@cichlid.raleigh.ibm.com> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Nov 03, 2005 at 11:37:47AM -0500, Thomas Narten wrote a message of 160 lines which said: > IMO, we should not at all. At best, include a pointer to ICANN and > say "their turf". Not even that, IMHO. THere is no reason for the IETF to endorse ICANN or to imply that it has a role here. > what is the problem with 2606 that needs fixing/updating? Nobody documentd that. > Do we actually need an updated to 2606? No. -- to unsubscribe send a message to namedroppers-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 04 08:59:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY25u-0001Xh-Ph for dnsext-archive@megatron.ietf.org; Fri, 04 Nov 2005 08:59:03 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21699 for ; Fri, 4 Nov 2005 08:58:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EY22E-000Ptc-M1 for namedroppers-data@psg.com; Fri, 04 Nov 2005 13:55:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EY22D-000PsT-6m for namedroppers@ops.ietf.org; Fri, 04 Nov 2005 13:55:13 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jA4Dt5MM023155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Nov 2005 14:55:06 +0100 From: Simon Josefsson To: "Olaf M. Kolkman" Cc: Namedroppers Subject: Re: DNSKEY size calculator and implementation question References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051104:olaf@nlnetlabs.nl::yb4B2TyxFkJ3Mbuj:4MZj X-Hashcash: 1:21:051104:namedroppers@ops.ietf.org::IAlr+apL3LygYcY5:HQAq X-Hashcash: 1:21:051104:olaf@nlnetlabs.nl::Jec3Noy24nR3P7Ek:4Re7 Date: Fri, 04 Nov 2005 14:55:02 +0100 In-Reply-To: (Olaf M. Kolkman's message of "Thu, 3 Nov 2005 10:20:10 -0800") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Olaf M. Kolkman" writes: > Colleagues, > > One of the questions that one may ask oneself is how much DNSKEYs can > I put into a keyset before truncation happens. > > In order to calculate the amount of truncation my co-worker Jelte > Jansen whipped up a small script at http://www.nlnetlabs.nl/dnssec/ > packetsize.html. I believe you shouldn't even consider 512 bit keys. In 1995, the minimum recommended RSA key size was 768 bits for _end users_ keys. Things have changed in ten years. A conservative key size discussion from 2003 can be found in: http://www.rsasecurity.com/rsalabs/node.asp?id=2004 Things have changed since 2003 too, but I can't find a good summary that include key size recommendations. Perhaps someone else know a good link? Depending on your threat model, 1024 bit keys are questionable. The 1995 recommendation for root keys was 2048 bits. If this WG can solve the root key roll-over issue, DNSSEC root keys could have a shorter life length than typical X.509 root keys. If so, 2048 bit keys may be sufficient for the root. However, considering that there is only one DNSSEC root, it become a much more interesting attack vector. Thanks, Simon -- to unsubscribe send a message to namedroppers-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 04 12:14:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY59M-0004Hl-38 for dnsext-archive@megatron.ietf.org; Fri, 04 Nov 2005 12:14:50 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01918 for ; Fri, 4 Nov 2005 12:14:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EY55P-000P9V-1i for namedroppers-data@psg.com; Fri, 04 Nov 2005 17:10:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EY55F-000P3Y-Nh for namedroppers@ops.ietf.org; Fri, 04 Nov 2005 17:10:33 +0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jA4HMfg5013937 for ; Fri, 4 Nov 2005 10:22:42 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id jA4HJRmX025175 for ; Fri, 4 Nov 2005 11:19:27 -0600 (CST) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Fri, 4 Nov 2005 12:10:28 -0500 Message-ID: <62173B970AE0A044AED8723C3BCF23810B772369@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: Thomas Narten Cc: namedroppers@ops.ietf.org Subject: RE: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Fri, 4 Nov 2005 12:10:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi Thomas, See below at @@@ -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Thursday, November 03, 2005 11:38 AM To: Alex Bligh Cc: Eastlake III Donald-LDE008; Harald Tveit Alvestrand; namedroppers@ops.ietf.org Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications > > So I obtained the closest ICANN policy statement I could to the IANA > > 2nd level label policy, spliced it in, > To what extent should we be reproducing ICANN policy in RFCs? IMO, we should not at all. At best, include a pointer to ICANN and say "their turf". @@@ To some extent this draft was written to get reaction to check that. Things like http://www.icann.org/tlds/tld-faqs.htm#FAQ36 seem to imply that, at least on some points, ICANN would be happy to follow IETF decisions, even if ICANN is not obliged to do so. RFCs are around forever. ICANN policy can and will change. Indeed, ICANN/registry contracts are an area of active evolution at the moment. @@@ Everything can and will change. I don't see that as a reason not to produce RFCs. In fact, assuming the relevant parts are not changing *too* quickly, one can argue that change makes efforts to update Best Practices more valuable. Also by documenting reasons for some reservations we might increase their stability. After reading the text, I'd say pretty much all of the new material that got added to Section 3 should be removed. Specifically: > 3. Reserved Second Level Domain Names > > At the time of the issuance of [RFC 2606], the Internet Assigned > Numbers Authority (IANA, http://www.iana.org) had reserved the > following second level domain names reserved which can be used as > examples. > > example.com > example.net > example.org OK so far... @@@ I don't think stopping there is very good. It was just a policy of IANA but such policies are, as I understand it, now set by ICANN. Since the draft has already made the point of the value of "example" domain names, to merely state a historic fact like this, with no indication of whether it is still true, or what the current source of authority is for it, or whether that authority still supports it, would be a disservice. > At this time, similar restrictions are by way of contract between the > Internet Corporation for Assigned Names and Numbers (ICANN, > http://www.icann.org) and the Registry Operators of many top level > domains. See . I don't think the above should be said. It suggests that example. are safe to use for testing. Should we suggest that? Do we even need to? @@@ It tries to accurate state the current status of these names, which are not primarily intended for testing but for documentation example. I do not consider this statement of fact to be suggestive or inappropriate. I do think we should provide this information. I'd be happy to change "many top level domains" to "many but not all top level domains". I confess to having chatted with Don about this document before -00 appeared. At the time, I sort of assumed that "example" might need reserving in all the TLDs, since new ones had been added. @@@ Now you are talking about controversial things. Imposing some such a mandatory requirement on "all TLDs", including ccTLDs, is a political area you don't want to go into. Or did you actually mean all non-cc TLDs or something? I think it is best to avoid saying "all". (But it does seem to me that we should reserve example.arpa.) But thinking some more about this, I have to actually wonder, what problem are we trying to fix here? Is there _really_ a need (for, e.g., documentation) to be able to use example., for any TLD that exists? The answer is not an obvious yes to me. Just use example.com. Or example.example, etc. @@@ The original impetus for this update draft came from putting out a public service announcement pointing out that TLDs, such as .info and .museum, can be more than three characters. It seemed desirable to use reserved 2nd level domain names for examples in real zones of this type. But I do not see that the update should be limited to that. If we were to conclude that example should be reserved in all TLDs, I think we'd have to do a careful dance with ICANN before publishing that in a BCP. I.e., get them to review the proposal, have the board agree to it, and then somehow both agree this is a recommendation going forward. @@@ Again, "all TLDs" is dangerous. But, as per the URL above, it may turn out to be relatively easy to get ICANN to agree to reasonable policies recommended by the IETF or have a BCP which, in so far at it specified policies within ICANN purview, takes effect when ratified by ICANN, or the like. Whether such restriction on *all TLDs" are reasonable is another question I don't think we want to go into. But, I'm not at all convinced this needs doing, as in, this fixes a known problem. > The ICANN "Schedule of Reserved Names" most recent version, as of the > date of this document, is at > agreement-01jul05.pdf>. It reserves the labels listed in the > following subsections, except when released by ICANN. Again, this will change. At most, I'd suggestion text like: A number of second-level domains are reserved via ICANN policy, see [XXX] for details. with [XXX] being a generic reference to policies, not one policy in particular. @@@ But some of these reservations, such as tagged labels and single byte labels, are reserved for prospective IETF protocol reasons. Other are reserved to decrease confusion related to IETF component organizations. In any case, I don't think this policy changes all that often and when it has changed I believe it has mostly been for the addition of more reservations. > 3.1 Labels Reserved at All Levels > > These are reserved from initial registration, unless ICANN grants an > exemption, at the second level and at all deeper levels where the top > level registry operator performs registration. If they have been > previously registered, they may be renewed and there is no > restriction on their existence in delegated zones. > > ICANN-related names: > aso > gnso > icann > internic > ccnso > IANA-related names: > afrinic > apnic > arin > example > gtld-servers > iab > iana > iana-servers > iesg > ietf > irtf > istf > lacnic > latnic > rfc-editor > ripe > root-servers Just remove this entire section. We don't need to document this. It's not necessary to even know about these from the perspective of testing/documentation (which is what the introduction talks about). @@@ I reject your repeated use of the word "need". This document is not intended to be a Needful Current Practice, that is, the equivalent of a MUST standard provision. This is intended to be a Best Current Practice and it is entirely the point of such documents to mention non-essential but good things. @@@ I agree that the introduction and possibly the title of the draft and some section names should be clearer and more accurate as to their actual scope. But I think it is just obviously the right thing for the IETF to document and support such confusion-avoiding things as the reservation of "ietf", "iab", etc., in many TLDs. > 3.2 Additional Second-Level Reservations > > The follows labels are prohibited as second level domain names: > > All single character labels. There is history here, and I think it would be good to document this somewhere (especially the reasoning behind the prohibition), but I'm not at all sure that this document is a good place to do it. Again, it doesn't seem directly relevant to the scope of this draft. @@@ As above, the introduction/title should more clearly and accurately correspond to the actual scope of the document. I don't see any particular reason to have yet another document to put that history in. Notwithstanding its title, the current RFC 2606 talks about "example" as a 2nd level domain name and does so because inclusion of this was suggested by Jon Postel. > All two character labels unless a release is obtained from the > government and country-code manager if that two letter > combination is an assigned country-code or a release from the > ISO 3166 maintenance agency if it has not been so assigned. Why mention this? @@@ I'd agree that this is probably the least important to include, but why not? If there are reasons for listing almost all of ICANN's policy, why bother cutting out a small part of it? > 3.3 Tagged Domain Names > > All labels with hyphens in the third and fourth character positions > such as "bq--1k2n4h4b" or "xn--ndk061n". Why does this need to be mentioned? @@@ It appears to me that tagged domain names are reserved so that the IETF can define things like Internationalized Domain Names. If there doesn't exist a current IANA registry/policy for classes of tagged domain names and if ICANN would ratify such a policy, then this document seems like a reasonable place for IANA Considerations for the allocation of tagged domain name prefixes, perhaps requiring an IETF Standards Action for their allocation. > 3.4 Second-Level Reservations for Registry Operators > > The following are reserved for the use of the top level domain > Registry Operator and will be transferred whenever the Operator > changes: > > nic > whois > www Again, ICANN business. No need to say anything here. @@@ Again, need is not the right criterion. It seems to me useful to have some uniform 2nd level domain names for Registry Operators and I don't see any reason not to document and support that here. Now, having written all the above, I'm back to trying to understand something very basic: what is the problem with 2606 that needs fixing/updating? Do we actually need an updated to 2606? @@@ Well, it is always a judgment call whether it is worth updating something. But it seems useful to add to 2606 information about other label which are or should be reserved under various circumstances including "example" in some TLDs beyond .com, .net, and .org, numeric TLDs, tagged labels, single character 2nd level labels, labels corresponding to IETF organizational components, etc. And it seems useful to state, to the extent practical, the current situation concerning the authority for such policies. Thomas @@@ 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 Fri Nov 04 14:00:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY6nL-0000AR-25 for dnsext-archive@megatron.ietf.org; Fri, 04 Nov 2005 14:00:11 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07476 for ; Fri, 4 Nov 2005 13:59:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EY6jC-000GCV-GS for namedroppers-data@psg.com; Fri, 04 Nov 2005 18:55:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EY6j9-000GBF-MK for namedroppers@ops.ietf.org; Fri, 04 Nov 2005 18:55:52 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jA4ItiKu096638 for ; Fri, 4 Nov 2005 13:55:44 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20051104103943.03a4b410@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 04 Nov 2005 13:55:21 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Re: IETF-64 DNSEXT Agenda In-Reply-To: <6.2.5.6.2.20051027001221.03f0a480@ogud.com> References: <6.2.5.6.2.20051027001221.03f0a480@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable WG administration: At 23:18 26/10/2005, =D3lafur Gu=F0mundsson wrote: >As we have now a new tool to post agenda's on-line in real time newer >versions of this agenda may get posted at=20 >http://www3.ietf.org/proceedings/05nov/agenda/dnsext.html > > Olafur & Olaf The version on-line is now up to 1.3, I will try to keep the on-line version current so please check it for last minute agenda changes. If you are on the agenda, please send me your presentations ASAP so I can upload them before the meeting. If you are on the agenda and you are not going to be there please drop me a note. thanks Olafur (who will be off-line on Saturday) -- to unsubscribe send a message to namedroppers-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 04 15:03:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY7mY-0000iT-1r for dnsext-archive@megatron.ietf.org; Fri, 04 Nov 2005 15:03:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09975 for ; Fri, 4 Nov 2005 15:03:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EY7jU-000GvF-02 for namedroppers-data@psg.com; Fri, 04 Nov 2005 20:00:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_HOME_NL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.0 Received: from [82.75.151.113] (helo=cc730311-a.ensch1.ov.home.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EY7jS-000GtC-M9 for namedroppers@ops.ietf.org; Fri, 04 Nov 2005 20:00:14 +0000 Received: from roy (helo=localhost) by cc730311-a.ensch1.ov.home.nl with local-esmtp (Exim 4.54) id IPG4W9-0001H0-CZ; Fri, 04 Nov 2005 21:00:09 +0100 Date: Fri, 4 Nov 2005 21:00:06 +0100 From: Roy Arends X-X-Sender: roy@cc730311-a To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair cc: namedroppers@ops.ietf.org Subject: Re: IETF-64 DNSEXT Agenda In-Reply-To: <6.2.5.6.2.20051104103943.03a4b410@ogud.com> Message-ID: References: <6.2.5.6.2.20051027001221.03f0a480@ogud.com> <6.2.5.6.2.20051104103943.03a4b410@ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 4 Nov 2005, =D3lafur Gu=F0mundsson /DNSEXT co-chair wrote: > WG administration: > At 23:18 26/10/2005, =D3lafur Gu=F0mundsson wrote: > > >As we have now a new tool to post agenda's on-line in real time newer > >versions of this agenda may get posted at > >http://www3.ietf.org/proceedings/05nov/agenda/dnsext.html > > > > Olafur & Olaf > > The version on-line is now up to 1.3, > I will try to keep the on-line version current so please check it > for last minute agenda changes. Please change the nsec3 draft url to the current version: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec3-03.txt Thanks 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 LindseyCox@gamesoft.com Sat Nov 05 20:31:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYZNv-00054Z-Fs for dnsext-archive@megatron.ietf.org; Sat, 05 Nov 2005 20:31:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01112 for ; Sat, 5 Nov 2005 20:31:27 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYZd8-0000i9-8a for dnsext-archive@ietf.org; Sat, 05 Nov 2005 20:47:40 -0500 Received: from [200.97.28.54] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1EYZNZ-00029h-Hp for dnsext-archive@ietf.org; Sat, 05 Nov 2005 20:31:30 -0500 Received: from vNh@localhost by dnX.int (8.11.6/8.11.6); Sat, 05 Nov 2005 20:02:02 -0600 Message-ID: From: "Sally Stern" Reply-To: "Sally Stern" To: dnsext-archive@ietf.org Subject: 100's of titles by Microsoft AutoCAD & XP starting @ 9.99 Date: Sat, 05 Nov 2005 20:02:02 -0600 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: LindseyCox@gamesoft.com Content-Type: multipart/mixed; boundary="--o3A9CA2w9caO5Xjjq" X-Spam-Score: 3.6 (+++) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 zo1 ----o3A9CA2w9caO5Xjjq Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 4
Opt-in Email Special Offer   = ;  unsubscribe me
SEARCH

<= /table>

TOP 10 NEW TITLES

=
 <= /tr>
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&nbs= p;2 Creative Suite 2
 <= /td>3 MS Office 2003 Pro
 = 4 Adobe Acrobat 7 Pro
&nbs= p;5 Macromedia Flash 8
&nbs= p;6 Dreamweaver 8
 7 Norton Sysworks 2005
 = 8 Adobe GoLive CS2
 = 9 Adobe Illustrator CS2
&= nbsp;10 Borland Architect 2005
  See more by this manufacturer
   Microsoft
 = Macromedia
  = Adobe
  Cu= stomers also bought
   these other items...

M= icrosoft Windows XP Professional *w/SP2*
Microsoft

Choose:
 

List Price:$= 299.00
Price:= $49.99=
You Save:$249.01 (80= %)



Availability: = Available for INSTANT download!
Coupon Code: z44Ner
Plat= form: Windows XP<= /p>

Sales Rank: #1
System requirements = ; |  Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer Review: Based on 1= 848 reviews. Write a review.=

Adobe Creative Suite 2 *Premium*
Adobe

Choose:
 

List Price:$1199.= 00
Price:$149.99
You Save:$1049.01 (95= %)



Availability: = Available for INSTANT download!
Coupon Code: xmDJJcUO
Pl= atform: Windows X= P

Sales Rank: #2
System requirements&nb= sp; |  Other Versions
Date Coupon Expires: December 31st, 2005
= Average Customer Review:3D"5 Based on= 1936 reviews. Write a review.

Microsoft Office 2003 *Professional*<= br> Microsoft

Choose:
 

<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 height=3D21 width=3D189><= tr>		 List Price:$499.00
Price:$69.99
You = Save:$429.01 (85%)

<= a href=3Dhttp://thebestoem.com/?u>

Availability: Available for INSTANT download!=
Coupon Code: FSXsSiF2u
Platform: Windows XP

Sales Rank: #3
System requirements  |  Other Versions
Date = Coupon Expires: December 31st, 2005
A= verage Customer Review:3D"5 Based on 1925 reviews. Write a review.

Adobe Acro= bat Professional V 7.0
Adobe

Choose:
 
=
List Pr= ice:$499.00
Pric= e:$69.99
You Save:$429.01 (85%)

<= br>
Availability: Available for INSTANT download!
Coupon= Code: rNbAV3FSq
Platform: Windows XP

Sales R= ank: #4<= br> System requirements  |  Other Versions
Date Coupon Expires= : December 31st, 2005
Average Custome= r Review:3D"5 Based on 155633 reviews. Write a review.

----o3A9CA2w9caO5Xjjq-- From s_vanderperren@edusigorta.com Sun Nov 06 09:42:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYljF-00030F-El for dnsext-archive@megatron.ietf.org; Sun, 06 Nov 2005 09:42:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00767 for ; Sun, 6 Nov 2005 09:42:16 -0500 (EST) Received: from [222.255.184.172] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EYlya-00042t-VH for dnsext-archive@ietf.org; Sun, 06 Nov 2005 09:58:37 -0500 Message-ID: <000001c5e2df$e6576a00$0100007f@localhost> From: "Ethan Gonzales" To: Subject: Three Steps to the Software You Need at the Prices You Want Date: Sun, 06 Nov 2005 14:47:38 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5E2DF.E6576A00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.2 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5E2DF.E6576A00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 35 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 45 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5E2DF.E6576A00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 38 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: ! $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 44 reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 49 reviews)

------=_NextPart_000_0001_01C5E2DF.E6576A00-- From FranDuvall@morem.com Tue Nov 08 07:34:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZSgA-0000wy-Os for dnsext-archive@megatron.ietf.org; Tue, 08 Nov 2005 07:34:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02192 for ; Tue, 8 Nov 2005 07:33:55 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZSsR-0001sC-En for dnsext-archive@ietf.org; Tue, 08 Nov 2005 07:47:04 -0500 Received: from cm61-10-135-219.hkcable.com.hk ([61.10.135.219]) by mx2.foretec.com with smtp (Exim 4.24) id 1EZScN-0003r8-T2 for dnsext-archive@ietf.org; Tue, 08 Nov 2005 07:30:29 -0500 Received: from 6MCu@localhost by Mn8.int (8.11.6/8.11.6); Tue, 08 Nov 2005 03:38:13 -0600 Message-ID: From: "Erica Murillo" Reply-To: "Erica Murillo" To: dnsext-archive@ietf.org Cc: nona.dwyer@ietf.org Subject: Microsoft Special Deals today 0nly Date: Tue, 08 Nov 2005 05:43:13 -0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: FranDuvall@morem.com Content-Type: multipart/mixed; boundary="--ioAjFSNIiEZ30cJRqUOf" X-Spam-Score: 2.6 (++) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 sjl2 ----ioAjFSNIiEZ30cJRqUOf Content-Type: text/html; Content-Transfer-Encoding: quoted-printable U
Opt-in Email Special Offer   = ;  unsubscribe me
<= tr vAlign=3Dbottom align=3Dmiddle>
SEARCH
<= /td>
=

T= OP 10 NEW TITLES
<= /tr><= tr> <= td width=3D132> Dreamweaver 8

 ON SALE NOW!

 1 Windows XP Pro SP2
 2<= /font> Creative Suite 2
3 MS Office 2003 Pro
 4 Adobe Acrobat 7 Pro
 5 Macromedia Flash 8
 6
&n= bsp;7 Norton Sysworks 2005
&nb= sp;8 Adobe GoLive CS2
 <= /td>9 Adobe Illustrator CS2
 = 10 Borland Architect 2005
&nbs= p; See more by this manufacturer
   M= icrosoft
 &n= bsp; Macromedia
   Adobe
  Customers also bought
   these other items...
<= /td>

Microsoft Windows XP Professi= onal *w/SP2*
Mi= crosoft

=
Choose:
 

List Price:= $299.00
Price:$49.99
You Save:$249.01 (80%)



Av= ailability: Available for INSTANT download!
Coupon Code: IY= QVXm
Platform: Windows XP

Sales Rank: #1
<= /span>System requiremen= ts  |  Other Versions
Date Coupon Expires: December 31st, 2005=
Average Customer Review:3D"5 Based= on 198997 reviews. Write a review.

Adobe Creative Suite 2 *Premium*
Adobe

=
Choose:
 

= =
List Price:$1199.00
Price:$149.99
Yo= u Save:$1049.01 (95%)
<= p>

Availability: Available for INSTANT download!<= br> Coupon Code: De3LqLCF
Platform: Windows XP

Sales Rank: #2
System requirements  |  Other Versions
Date Coupon Exp= ires: December 31st, 2005
Average Cus= tomer Review:3D"5 Based on 125621 reviews. Write a review.

Microsoft Office 20= 03 *Professional*
Microsoft

Choose:
 

You Save:



Availability: Available for INSTANT download= !
Coupon Code: 5S2DEO
Platform: Windows XP

Sales Rank: #3
System requirements  |  Other Versions
Date Coupon Exp= ires: December 31st, 2005
Average Cus= tomer Review:3D"5 Based on 13814 reviews. Write a review.

List Price:$499.00
Price:$69.99
$429.01 (85%)

Adobe Acrobat Profes= sional V 7.0
Ad= obe

Choose:<= tr>
 

List Price:$499.00
Price:$69.99
You Save:<= /td>$429.01 (= 85%)



Availability: Av= ailable for INSTANT download!
Coupon Code: 6CdB30
Platfo= rm: Windows XP

Sales Rank: #4
System requirements  |&nb= sp; Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 17735 revie= ws. Write a review.

<= p>

----ioAjFSNIiEZ30cJRqUOf-- From owner-namedroppers@ops.ietf.org Tue Nov 08 21:30:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZfjX-00064Y-FN for dnsext-archive@megatron.ietf.org; Tue, 08 Nov 2005 21:30:43 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05434 for ; Tue, 8 Nov 2005 21:30:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZfcE-0001kn-OU for namedroppers-data@psg.com; Wed, 09 Nov 2005 02:23:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZfcD-0001kb-SI for namedroppers@ops.ietf.org; Wed, 09 Nov 2005 02:23:10 +0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jA92ZRHx029875 for ; Tue, 8 Nov 2005 19:35:27 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id jA92Vbto027990 for ; Tue, 8 Nov 2005 20:31:38 -0600 (CST) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Tue, 8 Nov 2005 21:23:08 -0500 Message-ID: <62173B970AE0A044AED8723C3BCF23810B844853@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: namedroppers@ops.ietf.org Subject: RE: DNSEXT WGLC: RFC2536bis and RFC2539bis Date: Tue, 8 Nov 2005 21:23:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, As you might guess form the version numbers these drafts have been = around for a fairly long time. The previous RFCs were tied to the SIG = and KEY RRs only and reference only the old DNSSEC RFCs. The idea is = that these updates are part of DNSSEC updating. As far as I know, there isn't any technical difference between the = RDATA format in these drafts and in the RFCs they update. There is a minor technical addition in = draft-ietf-dnsext-rfc2539bis-dhk-06.txt which has an additional = pre-defined D-H group taken from IPSEC (and probably there are 1 or = more further additional D-H groups specified in IPSEC or other IETF = protocols that should be added). I plan to spin new versions of these which list all changes from the = RFC they are obsoleting and fix nits. Thanks, Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org = [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Samuel Weiler Sent: Thursday, October 27, 2005 2:08 AM To: =D3lafur Gu=F0mundsson /DNSEXT co-chair Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: RFC2536bis and RFC2539bis > This message starts a 2 week Working Group Last call ending on=20 > November 1, for the two following documents: > = http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-06.= txt=20 > = http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-06.= txt I have not thoroughly reviewed either of these drafts, nor do I plan to = do so in the immediate future. > The default action is to advance these documents, if you find any=20 > issues with the documents please raise them now. I oppose this default and, in particular, I oppose publication of these = two documents under this WG's name without a meaningful review. If the WG cannot find the resources to review these documents, then we = should consider dropping them as WG work items. -- 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 Tue Nov 08 22:12:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZgOD-0004LR-Vx for dnsext-archive@megatron.ietf.org; Tue, 08 Nov 2005 22:12:46 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07681 for ; Tue, 8 Nov 2005 22:12:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZgL8-0004Z9-2H for namedroppers-data@psg.com; Wed, 09 Nov 2005 03:09:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EZgL5-0004Ym-Vt for namedroppers@ops.ietf.org; Wed, 09 Nov 2005 03:09:32 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id jA939EFd023597 for ; Tue, 8 Nov 2005 22:09:14 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id jA939E8U023596 for namedroppers@ops.ietf.org; Tue, 8 Nov 2005 22:09:14 -0500 (EST) (envelope-from namedroppers) Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EZe2D-000Ljq-51 for namedroppers@ops.ietf.org; Wed, 09 Nov 2005 00:41:54 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jA90fYXr022928 for ; Tue, 8 Nov 2005 19:41:35 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20051108193850.0420fa40@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 08 Nov 2005 19:41:36 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: IETF-64 DNSEXT draft minutes Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_13825700==_" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ 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. ] --=====================_13825700==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Thanks to Wes Griffin for turning the minutes around in record time. Draft minutes attached and available on-line: http://onsite.ietf.org/proceedings/05nov/minutes/dnsext.txt Please send in comments or corrections by Nov 24'th 2005 Olafur --=====================_13825700==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="20051107 Minutes.txt" DNSEXT IETF64 Meeting Minutes (draft) Scribe: Wes Griffin Chairs: Olafur Gudmundsson & Olaf Kolkman Date: 2005/Nov/08 Document Updates draft-ietf-dnsext-mdns-45.txt IETF Last Call comments have been incorporated. Chairs will go over latest version and check against comments and then post a summary to the mailing list with a request for review. draft-ietf-dnsext-insensitive-06.txt draft-ietf-dnsext-rfc2538bis-09.txt In RFC-Editors queue. draft-ietf-dnsext-tsig-sha-05.txt draft-ietf-dnsext-dhcid-rr-09.txt draft-ietf-dnsext-wcard-clarify-08.txt draft-ietf-dnsext-dns-name-p-s-01.txt Advanced to IESG, waiting for IETF Last Call. The chairs expect IETF Last Call shortly on most of these documents. draft-ietf-dnsext-nsid-00.txt Passed Working Group Last Call, waiting on write-up from chairs to advance to IESG. draft-ietf-dnsext-rfc2536bis-dsa-06.txt draft-ietf-dnsext-rfc2539bis-dhk-06.txt The documents passed Working Group Last Call, will be advanced. Sam Weiler asked the chairs whether there was any evidence these document had been reviewed. The chairs said that no comments at all were received during the Last Call and the default action to advance was in effect. Thomas Narten feels there is an issue with the default action of advancing work that no one seems to care about. At the end of the meeting (see later minutes) a discussion was held about the default action. The chairs still felt that advancing these specific documents was fine. From the editor, these documents do not change the RDATA format. They only update the specifications to refer to DNSKEY and RRSIG instead of the old 2535 RRs. Additionally, rfc2539bis-dhk updates the list of Diffie-Hellman groups to match the IPSEC DH groups. There are no drafts currently in Working Group Last Call. One draft has been "lost": draft-ietf-dnsext-axfr-clarify This draft will be resurrected by the chairs. There are some drafts that are queued for Working Group Last Call. These drafts have been queued so as not to overload the working group with work. draft-ietf-dnsext-dnssec-trans-03.txt Peter Koch said this draft is ready for Last Call. draft-ietf-dnsext-dnssec-experiments-01.txt This document has been on the table for a while and will be Last Called. draft-ietf-dnsext-ecc-key-08.txt The editor requested more feedback on this document, specifically from implementors. Olafur Gudmundsson asked if the current loose specification for key format could cause interoperability problems? Donald Eastlake felt that implementors are better suited to answer that question. A handful of people in the room have read the draft and one person has attempted implemented it. Ongoing Work draft-ietf-dnsext-dnssec-bis-updates-01.txt This is a running request for implementors to document design decisions and provide input to this document. draft-ietf-dnsext-2929bis-01.txt This document is attempting to address the perceived problem that it is difficult to get IETF Consensus or Specification Required for allocation of new RR Type Codes. The -00 version liberalized the early allocation process and also included a number of other updates to the IANA Considerations for the various DNS IANA Registries. This version met with considerable negative feedback at IETF63. The new version changes the allocation to half requiring Expert Review and half requiring Specification Required. The Expert Review process begins with a DNS RR Type Allocation template being filled out and posted to the namedroppers mailing list for 3 weeks. Rob Austein asked if the latest version had Specification Required for RCODE Types. The answer was yes it does, and he asked that those be removed, as having RCODEs that implementations don't know about is bad. Thomas Narten asked if there were criteria for reviewing new RR Type Codes. He thinks there are a set of valid criteria for determining if new RR Type Codes can be allocated. He will prepare a document discussing these and post it to the mailing list. draft-ietf-dnsext-signed-nonexistence-requirements-02.txt This document has been updated and needs reviewing. draft-ietf-dnsext-nsec3-03.txt See later minutes. Possible New Work draft-andrews-dnsext-soa-discovery-00.txt During implementation of dynamic update clients, it's been found that if a client only has the name needing an update and not the enclosing zone, there is no easy way for the client to determine the zone. Additionally, if the name doesn't exist, there are major negative caching issues with trying to determine the zone. The editor asked the working group to adopt this work. A handful of people have reviewed this document. The chairs asked how many people feel this document is solving a real problem, a few raised their hands. A handful of people said they would review this document. The chairs will propose to the mailing list to adopt it. Interoperability Testing Report Nobumichi Ozoe is part of the TAHI DNS Interoperability Testing project. They tested one DNS client and found some bugs in the client and some bugs in the testing tool. They did not find any issues with the basic DNS specifications. Version 0.1 of the test tool was released 2005/11/01 and is a free download. Current coverage includes the client functionality, basic extensions and TCP/UDP over IPv4. Future coverage will include server functionality and IPv6 transport. The next scheduled TAHI testing event is end of January 2006. There is now a mailing list: dnstest@tahi.org and interested people can subscribe via dnstest-ctl@tahi.org NSEC3 Report and Discussion There is an issue tracker available for NSEC3: http://nsec3.nominum.org.uk/ Issues, both open and closed: Issue 1: Signaling NSEC3 to NSEC3-unaware resolvers. Mark Andrews strongly objected to a flag day and so we need signaling. Ben Laurie answered that if we're going to do signaling, we need to decide how to do it. Issue 2: Transition from NSEC to NSEC3 by being insecure is fine. Issue 3: RFC2932 Base32 encoding is used to solve the sort order issue. Issue 4: NSEC3 hashes have owner names whose existence is denied. No one has yet to present a technical argument on how this is a problem. Peter Koch felt that we don't know yet whether this will be a problem and as such we can't summarily dismiss it. Especially considering we have a precedent of ignoring "problems" that have come back to haunt us. He has half-seriously proposed on the mailing list a solution involving using a new label type. Olafur Gudmundsson felt that we should do some experimentation to better determine if this will be a problem and keep this issue open until then. Olaf Kolkman said that the working group has agreed that for this document, it will not proceed until and engineering workshop has occurred and code has been tested. Ben Laurie stated that there are 3 implementations close to being completed. Ed Lewis said he won't consider this issue closed until he sees it in working operation. Russ Mundy said he wants the working group to figure out a way we can move forward. Mark Andrews stated that there is a way to do this that will have zero impact on the namespace of the zone. Issue 5: NSEC3 hash name and legitimate zone name collision is okay. The editor believes this is not an issue. Rob Austein said that he's 3/4 close to leaning towards Peter Koch's half-serious new label type proposal. He feels this is a much cleaner solution to all this collision stuff and has the added benefit that it can be defined as a binary-only label type which removes the sort order issue as well. Ben Laurie asked how this would interact with caches that don't grok the new label type. Rob replied that dnssec-bis doesn't work through dnssec-oblivious middle boxes, so this might just be a non-issue. Paul Vixie stated that the original idea behind the separate label type was to provide a way to store the various sets of metadata that aren't truly dns data and hence don't really belong in the actual database proper. This data we're talking about here is also not dns data and so a separate label type would go a long way to helping this. Ben asked if people were okay waiting until implementations were done before deciding on this. Issue 6: There is a potential DoS attack on resolvers. Evil editoritative servers can select such a high number of iterations that resolvers are overwhelmed. The proposal is to allow resolvers to specify an upper limit for iterations that it will accept and if a response has a higher number the resolver will treat is as bogus. Olafur Gudmundsson asked why we can't get rid of iterations and just use the salt. Ben explained that the iterations are designed to increase the cost of a dictionary attack, while the salt is used to increase the cost of a pre-computed dictionary attack. Olafur rephrased his question to is the salt sufficient for the threats people are seeing? Ben feels this is no, as a single iteration is very easy to handle with a network probe. Olaf expressed a concern that leaving this up to resolvers will cause some resolvers to set a low number and some a high number causing a zone to appear secure or bogus to different resolvers. Ben answered that by picking a sufficiently high number this shouldn't be a problem. It should be a single number and not in the draft. Mike St.Johns said that if a number is going to be chosen, please put it in the draft and be nice to implementors and users, don't make it configurable, just set it across the board. Ben says if the working group feels strongly about this it will be done. Someone asked if a mechanism could be added such that parent zones can set limits for the iterations. The room response was highly negative. Issue 7: How secondaries know the NSEC3 parameters a zone is using. The solution is that any parameter set present at the apex will be present in the entire zone. Issue 8: The next version of the document will include additional detail about the design choices and rationale. Issue 9: The next version will have the hash algorithm field set to 8 bits so that it can share the hash algorithm registry with the DS RR. Sam Weiler asked about his proposal to get rid of the algorithm field in the NSEC3 RR and just inherit the algorithm used by the DS RR. Olaf Kolkman asked how this would work if there was no parent. Mike St.Johns asked what if a zone is using multiple hash algorithms. Trust Anchor Management Reports and Discussion This space is rapidly growing with drafts and there has been very little review by non-involved participants. The chairs urge the working group to pay attention because this item is very important to deployment. Current Work: draft-ietf-dnsext-trustupdate-threshold-01.txt A co-editor stated that this update was primarily to boilerplate to refresh the draft so that it would be available for consideration. A prototype implementation is currently being worked on. This and the following 2 drafts have IPR claims on file with the IETF. The co-editor stated that he's been working with his university lawyer and can proceed on a prototype implementation. He expects it will be ready by the end of the year and will make it available to a select group of people who will not be affected by the IPR. draft-ietf-dnsext-trustupdate-timers-01.txt The editor said this version is almost a boilerplate change to refresh the document. He has started an implementation in dnsjava. draft-moreau-dnsext-takrem-dns-00.txt draft-moreau-dnsext-sdda-rr-00.txt The author presented slides on some basics of trust anchor management including some discussion of requirements and how the TAKREM proposal works. Ben Laurie asked why, since emergency key rollover doesn't depend on key revocation and there will be some other mechanism to do revocation, why not just use that? Mike St.Johns asked about how previous keys are revoked. The author said the TTL would revoke the keys, it was pointed out that there is no built-in lifetime on keys. He said this would be addressed. Bill Manning asked about one slide bullet that said change control had been handed over to the IETF and if this meant the IPR claim no longer applied? The author said no. Steve Crocker said it would be much easier if the technology was unencumbered so that we could get on with implementation and testing. The editor said there was already an licence for GPL implementations. Ben Laurie, Paul Vixie, Matt Larson and a Cisco gentleman all said GPL was insufficient for their needs. Olaf Kolkman summed this as a requirement for the trust anchor management requirements document. The author stated a requirements document by the working group would be useful. draft-laurie-dnssec-key-distribution-00.txt The author said the original idea behind this proposal was to do it with x.509, but that x.509 has some issues with cross-signing and so a future version will use PGP signatures. This is the only proposal on the table that has no known IPR issues. Bill Manning asked about what transport this will use, as the user is expected to visit a URL and follow a signature chain. His concern is that the end-to-end assumption is increasingly wrong. Also, how does the proposal cope when data can't be pulled from the URL? The editor responded that http is the current transport, but really anything can be used. Also, the data can be pulled from any location so this shouldn't be an issue. Russ Housley asked why this is solving the problem, as he thinks it doesn't. Also, this looks exactly like what x.509 was designed to do. The author said that x.509 doesn't support multiple certificates with the same DN, Russ said it did. Michael Richardson asked if there could be some sort of cross signature threshold mechanism added so that resolvers only trust what's going on when there are a minimum number of signatures. The author said that this proposal was such that if a resolver trusts a zone, then it trusts what the zone signs (and cross-signs). Paul Vixie: Simple Key Rollover All of the current mechanisms seem overly complicated. This method: Adds a new zone apex RR that expresses H(keyset). This is included in the authority section in replies. Interested validators can track this RR. When it changes, the validators can fetch the new keyset. If the new keyset validates it becomes the new trust anchor. Interested validators can also pull. This pulling is based on the half-life of the current keyset signature lifetime and the half-life of the current keyset TTL. The pulling is obviated by the new zone apex RR if seen. This new zone apex RR is an opportunistic optimization. This differs from the N-of-M proposal: N is now a per-algorithm constant, and 2 seems to be fine. Removes a policy knob from the client. The new zone apex RR trumpets new keysets. Most validators won't have to pull. Revocation is by omission only. It is always good to have more than one key. This is very lightweight, but doesn't solve emergency rollover. Puts most of the policy on the server-side. Validator policy is simple. All a validator does is track static configured trust anchors. Possible Server Side Policy: Never use a key without also publishing the next one (or the next several). Never use a key without also publishing a backup at the same time (for revocation purposes). Overlap current/next key lifetimes by 50%. Start using a new key at the second half-life (25% remaining) of the existing key. Roy Arends asked why we need to add a new zone apex RR, why not just publish the keys? Olaf Kolkman responded that there are size issues with publishing all the keys. Ed Lewis noted that while server side policy may not be an issue, DNSSEC has always been about the view of the DNS at the resolver. General Discussion: Margaret Wasserman stated that all of these mechanisms appear to be very different in everything that they're trying to do. For example, do we have consensus on needing emergency key rollover, or do we have ideas on requirements or threat models? Olafur Gudmundsson asked what do we have to do with trust anchors? For example, should a trust anchor management protocol be able to turn off DNSSEC for a zone? We need a better handle on the key rollover requirements. Olaf Kolkman stated that this work has come up through the mailing list and the solution space is expanding without the working group knowing which metrics we want to apply to make a choice. He asked for a volunteer to start a draft outlining the requirements. He also asked if this is work that interests the working group. If there is no work currently being done in the working group do we care about the work? A room hum is overwhelmingly in favor of the work. Olafur says we need volunteers to work on requirements, review documents, and do work. The chairs will ask on the mailing list for a deadline for requirements being done. Thomas Narten is troubled in that there seems to be some sort-of interest in this work, but the work itself is not getting done. Perhaps the wrong questions are being asked, how about asking something like "What are our 3 top priorities, the 3 most important things to get off the table?" Ed Lewis stated that as a consumer of an ISP, I don't care about what keys zone operators are pushing out, but I do care about my ISP and what keys they are using. Olaf felt that we can't make further decisions here on a way forward. We need requirements and metrics on what is sensible and what the group wants. Default Action For Document Review Discussion The chairs ask if the best way to handle review is to set a lower limit, on the order of 4 or 5 people, that must review a document before it is advanced. The room hums consensus. Peter Koch asks what will happen if the document doesn't reviewed, will it get dropped or will it remain on the work items list indefinitely? The chairs state that the document will be dropped and authors will have to do a personal submission. Sam Weiler asks that before the drop occurs, we keep it as a work item and have a review by name and then if there is still no movement, drop it. Priorities The chairs see 3 major work items: NSEC3 Trust Anchor Management Work dealing with forwarding documents along the standards track This includes rewriting any documents that need clarification. The chairs ask for a hand show of what is more important: NSEC3: 10 TAM: 15 The chairs asked if there is a reason we should NOT do this work in parallel? Sam Weiler said that as long as there is a critical mass of people working on each item, then we should do the work in parallel. Thomas Narten mentioned that even thought requirements documents have bad reputations, without them, important discussions are often side-stepped and not resolved. The requirements documents should be short-fused, if one cannot be completed in 3 months, the work has a serious problem. The chairs responded by saying that requirements are needed, and if the requirements are not completed in a timely manner the work will be dropped. --=====================_13825700==_-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From a3155@whizzquiz.biz Wed Nov 09 07:52:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZpRg-00031I-Nv for dnsext-archive@megatron.ietf.org; Wed, 09 Nov 2005 07:52:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06434 for ; Wed, 9 Nov 2005 07:52:29 -0500 (EST) Received: from [201.15.110.167] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZphc-0003FS-4a for dnsext-archive@ietf.org; Wed, 09 Nov 2005 08:09:29 -0500 Message-ID: <000001c5e52b$b43a4800$0100007f@localhost> From: "Julian Coleman" To: Subject: Office 2003 Date: Wed, 09 Nov 2005 18:00:21 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5E52B.B43A4800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5E52B.B43A4800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 41 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 33 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 36 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5E52B.B43A4800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES
Microsoft

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 33 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 42 review! s)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 46 reviews)

------=_NextPart_000_0001_01C5E52B.B43A4800-- From owner-namedroppers@ops.ietf.org Wed Nov 09 09:43:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZrB2-0000aJ-U0 for dnsext-archive@megatron.ietf.org; Wed, 09 Nov 2005 09:43:55 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13338 for ; Wed, 9 Nov 2005 09:43:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZr5X-0001DH-Lx for namedroppers-data@psg.com; Wed, 09 Nov 2005 14:38:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EZr5W-0001D2-In for namedroppers@ops.ietf.org; Wed, 09 Nov 2005 14:38:10 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jA9EbvV8000565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Nov 2005 15:37:58 +0100 From: Simon Josefsson To: Margaret Wasserman Cc: namedroppers@ops.ietf.org Subject: Re: IETF-64 DNSEXT draft minutes References: <6.2.5.6.2.20051108193850.0420fa40@ogud.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051109:ogud@ogud.com::X+cfvqncwZfybRAd:0HG2 X-Hashcash: 1:21:051109:namedroppers@ops.ietf.org::+u8RluT7+AXNcuKe:65Tz X-Hashcash: 1:21:051109:margaret@thingmagic.com::GqHZIrhgAsTMNoHS:1zi5 Date: Wed, 09 Nov 2005 15:37:52 +0100 In-Reply-To: <6.2.5.6.2.20051108193850.0420fa40@ogud.com> (=?iso-8859-1?Q?=D3lafur=09Gu=F0mundsson's?= message of "Tue, 08 Nov 2005 19:41:36 -0500") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA13338 =D3lafur Gu=F0mundsson writes: > draft-ietf-dnsext-rfc2538bis-09.txt > In RFC-Editors queue. Actually, it is still in the AD Followup state, see: https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D12720&rfc_flag=3D0 I e-mailed Margaret late October asking for the status of this, but there was no reply. I have no idea what's holding up the document now. Thanks, Simon -- to unsubscribe send a message to namedroppers-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 09 11:52:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtBx-0006Av-63 for dnsext-archive@megatron.ietf.org; Wed, 09 Nov 2005 11:52:57 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21323 for ; Wed, 9 Nov 2005 11:52:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZt8b-000JrZ-49 for namedroppers-data@psg.com; Wed, 09 Nov 2005 16:49:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EZt8Z-000JrN-Dd for namedroppers@ops.ietf.org; Wed, 09 Nov 2005 16:49:27 +0000 Received: from [IPv6:::1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id E9EE133C1C; Wed, 9 Nov 2005 16:49:24 +0000 (GMT) Message-ID: <43723634.9040906@algroup.co.uk> Date: Wed, 09 Nov 2005 17:47:32 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050405) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= CC: namedroppers@ops.ietf.org Subject: Re: IETF-64 DNSEXT draft minutes References: <6.2.5.6.2.20051108193850.0420fa40@ogud.com> In-Reply-To: <6.2.5.6.2.20051108193850.0420fa40@ogud.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA21323 =D3lafur Gu=F0mundsson wrote: > NSEC3 Report and Discussion > There is an issue tracker available for NSEC3: > http://nsec3.nominum.org.uk/ I guess things to do with "name" in Latin are popular, but actually its Nominet, and the URL is really: http://dnssec.nominet.org.uk/nsec3 > Issue 6: There is a potential DoS attack on resolvers. > Evil editoritative servers can select such a high number of ite= rations typo: s/editoritative/authoritative/ > that resolvers are overwhelmed. The proposal is to allow resolv= ers to > specify an upper limit for iterations that it will accept and i= f a > response has a higher number the resolver will treat is as bogu= s. > =20 > Olafur Gudmundsson asked why we can't get rid of iterations and= just > use the salt. Ben explained that the iterations are designed to > increase the cost of a dictionary attack, while the salt is use= d to > increase the cost of a pre-computed dictionary attack. Olafur > rephrased his question to is the salt sufficient for the threat= s > people are seeing? Ben feels this is no, as a single iteration = is > very easy to handle with a network probe. This is garbled: my point was that it is a requirement to make enumeration "as hard" in DNSSEC as it is in DNS. It is clear that this is not 100% meaningful, since the mechanisms are different, but NSEC3 at least means they both need a dictionary attack - in order to make the dictionary attack "as hard" then we need a knob we can turn to adjust the cost of computing whether a name is a match for a hash (corresponding to the effort required to send a query in DNS). Iterations is that knob. > Mike St.Johns said that if a number is going to be chosen, plea= se put > it in the draft and be nice to implementors and users, don't ma= ke it > configurable, just set it across the board. Ben says if the wor= king > group feels strongly about this it will be done. I would still argue that it should be configurable, but I'm OK with the draft stating a sensible default. > Trust Anchor Management Reports and Discussion > This space is rapidly growing with drafts and there has been very l= ittle > review by non-involved participants. The chairs urge the working gr= oup to > pay attention because this item is very important to deployment. > =20 > Current Work: > =20 > draft-ietf-dnsext-trustupdate-threshold-01.txt > A co-editor stated that this update was primarily to boilerplat= e to > refresh the draft so that it would be available for considerati= on. > A prototype implementation is currently being worked on. This a= nd the > following 2 drafts have IPR claims on file with the IETF. The > co-editor stated that he's been working with his university law= yer > and can proceed on a prototype implementation. He expects it wi= ll be > ready by the end of the year and will make it available to a se= lect > group of people who will not be affected by the IPR. > =20 > draft-ietf-dnsext-trustupdate-timers-01.txt > The editor said this version is almost a boilerplate change to > refresh the document. He has started an implementation in dnsja= va. > =20 > draft-moreau-dnsext-takrem-dns-00.txt > draft-moreau-dnsext-sdda-rr-00.txt > The author presented slides on some basics of trust anchor mana= gement > including some discussion of requirements and how the TAKREM pr= oposal > works. > =20 > Ben Laurie asked why, since emergency key rollover doesn't depe= nd _does_ depend on revocation > on key revocation and there will be some other mechanism to do > revocation, why not just use that? > draft-laurie-dnssec-key-distribution-00.txt > The author said the original idea behind this proposal was to d= o it > with x.509, but that x.509 has some issues with cross-signing a= nd so > a future version will use PGP signatures. This is the only prop= osal > on the table that has no known IPR issues. > =20 > Bill Manning asked about what transport this will use, as the u= ser > is expected to visit a URL and follow a signature chain. His co= ncern > is that the end-to-end assumption is increasingly wrong. Also, = how > does the proposal cope when data can't be pulled from the URL? = The > editor responded that http is the current transport, but really > anything can be used. Also, the data can be pulled from any loc= ation > so this shouldn't be an issue. I also think its kinda weird to have to deal with "the Internet doesn't work like its sposed to" in this draft - is Bill proposing that we also rework, say, HTTP, to fix this problem? > Russ Housley asked why this is solving the problem, as he think= s it > doesn't. I obviously blanked at this point, because I have no idea what Russ' problem was - it would be good to get a statement from him on this. > Also, this looks exactly like what x.509 was designed to do. > The author said that x.509 doesn't support multiple certificate= s with > the same DN, Russ said it did. I will be clarifying this with Russ later today. > Michael Richardson asked if there could be some sort of cross > signature threshold mechanism added so that resolvers only trus= t > what's going on when there are a minimum number of signatures. > The author said that this proposal was such that if a resolver > trusts a zone, then it trusts what the zone signs (and cross-si= gns). I should also note that (as I understand it) introducing thresholds would introduce IPR issues. Cheers, Ben. -- to unsubscribe send a message to namedroppers-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 09 13:04:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZuIv-0006mE-AF for dnsext-archive@megatron.ietf.org; Wed, 09 Nov 2005 13:04:13 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26431 for ; Wed, 9 Nov 2005 13:03:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZuFV-000Ob3-50 for namedroppers-data@psg.com; Wed, 09 Nov 2005 18:00:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,INFO_TLD autolearn=no version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EZuFR-000Oa4-V8 for namedroppers@ops.ietf.org; Wed, 09 Nov 2005 18:00:38 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jA9I0Z0g045378 for ; Wed, 9 Nov 2005 19:00:35 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <52A9E370-5232-4A18-913B-BE6910DE86D6@NLnetLabs.nl> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3-780695397" To: Namedroppers From: "Olaf M. Kolkman" Subject: Key Maintenance requirements draft. Date: Wed, 9 Nov 2005 10:00:34 -0800 X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-3-780695397 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Dear Colleagues, In order to get forward progress on the key-management issues we decided to do one little step back and concentrate on a requirements document. We have found two volunteers to edit such document: Howard Eland and Russ Mundy The timeline for this requirements draft is tight: Version 00 in a month from now. Version 01 in two months from now. Last call shortly after that. In order to bootstrap the work please mail any requirements you might have directly to the editors, alternatively talk to them in the Vancouver hallways. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-3-780695397 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.1 (Darwin) Comment: This message is locally signed. iD8DBQFDcjlCtN/ca3YJIocRAtC4AKCswpmiUA036auostcYnNwC5QDm5ACfWiK6 y1C34TMFuNsTBqXjOlJnr0Y= =mrux -----END PGP SIGNATURE----- --Apple-Mail-3-780695397-- -- to unsubscribe send a message to namedroppers-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 09 13:28:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZugJ-0007Ik-7y for dnsext-archive@megatron.ietf.org; Wed, 09 Nov 2005 13:28:23 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28055 for ; Wed, 9 Nov 2005 13:27:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZudu-0000Je-Bi for namedroppers-data@psg.com; Wed, 09 Nov 2005 18:25:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EZudt-0000J3-PS for namedroppers@ops.ietf.org; Wed, 09 Nov 2005 18:25:53 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 14CDD56947; Wed, 9 Nov 2005 10:25:53 -0800 (PST) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.0.10.2.20051109132459.0395c878@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Wed, 09 Nov 2005 13:26:15 -0500 To: Ben Laurie , =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= From: Mike StJohns Subject: Re: IETF-64 DNSEXT draft minutes Cc: namedroppers@ops.ietf.org In-Reply-To: <43723634.9040906@algroup.co.uk> References: <6.2.5.6.2.20051108193850.0420fa40@ogud.com> <43723634.9040906@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:47 PM 11/9/2005, Ben Laurie wrote: > > Mike St.Johns said that if a number is going to be > chosen, please put > > it in the draft and be nice to implementors and users, > don't make it > > configurable, just set it across the board. Ben says if the working > > group feels strongly about this it will be done. > >I would still argue that it should be configurable, but I'm OK with the >draft stating a sensible default. Slight clarification. What I meant was that the implementers didn't get to pick the max, not that the zone operators couldn't select something smaller. Pick one value, put it in the document and have all the implementers use 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 Wed Nov 09 13:37:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZupV-000426-7V for dnsext-archive@megatron.ietf.org; Wed, 09 Nov 2005 13:37:53 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28817 for ; Wed, 9 Nov 2005 13:37:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EZunB-0001KS-Fo for namedroppers-data@psg.com; Wed, 09 Nov 2005 18:35:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [203.174.79.138] (helo=zns001-0m9001.yokogawa.co.jp) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZun8-0001K3-Pq for namedroppers@ops.ietf.org; Wed, 09 Nov 2005 18:35:27 +0000 Received: from zns001-0m9001.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id jA9IZEhD013570; Thu, 10 Nov 2005 03:35:14 +0900 (JST) Received: from EXCHANGE02.jp.ykgw.net (zex001-0m9002.jp.ykgw.net [10.0.11.22]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id jA9IZDrj013567; Thu, 10 Nov 2005 03:35:13 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: 8th TAHI IPv6 Interoperability Test Event - 23 - 27 January 2006, Chiba, Japan Date: Thu, 10 Nov 2005 03:35:13 +0900 Message-ID: <2B29614385FE6F47BF39423C0AB1524E01394AA4@EXCHANGE02.jp.ykgw.net> Thread-Topic: 8th TAHI IPv6 Interoperability Test Event - 23 - 27 January 2006, Chiba, Japan Thread-Index: AcXlXFJ+gj0f66juTP2rey6un4zgnA== From: Cc: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear All, TAHI Projcet is organizing its 8th TAHI IPv6 Interoperability Test Event. The event will be held from 23th - 27th January 2006 at the Makuhari messe of Chiba Japan. Registration are avairable from 10 November 2005 at: http://www.tahi.org/inop/8thinterop.html Early registration discount is until 16 December 2005. Registration deadline is 31 December 2005. This time we will provide the following tests: o Conformance test: IPv6 Ready Logo Phase-1, IPv6 Ready Logo Phase-2 (IPv6 Core Protocol, IPsec, MIPv6), IKEv1, NEMO Basic Support, DNS, DHCPv6, SIP, MIB, RIPng, OSPFv3, NAT-PT, 6to4 o Interoperability test: IPv6 Ready Logo Phase-1, IPv6 Ready Logo Phase-2 (IPv6 Core Protocol, IPsec, MIPv6), MIPv6(not focussing on IPv6 Ready Logo), NEMO Basic Support, SIP, IPsec(not focussing on IPv6 Ready Logo), IKEv1/v2, DHCPv6, MLDv2, Application(DNS, HTTP...), etc. Best regards, -- Nobumichi Ozoe IPv6 Business Network & Software Development Dept. Yokogawa Electric Corporation E-mail: Nobumichi.Ozoe@jp.yokogawa.com URL: http://www.yokogawa.com/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 09 21:18:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea20v-0003jI-J3 for dnsext-archive@megatron.ietf.org; Wed, 09 Nov 2005 21:18:09 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27090 for ; Wed, 9 Nov 2005 21:17:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ea1wZ-0006MF-JZ for namedroppers-data@psg.com; Thu, 10 Nov 2005 02:13:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Ea1wW-0006Lm-LH for namedroppers@ops.ietf.org; Thu, 10 Nov 2005 02:13:37 +0000 Received: from [IPv6:::1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 123F133C1C for ; Thu, 10 Nov 2005 02:13:28 +0000 (GMT) Message-ID: <4372BA6A.4030809@algroup.co.uk> Date: Thu, 10 Nov 2005 03:11:38 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050405) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: IETF-64 DNSEXT draft minutes References: <6.2.5.6.2.20051108193850.0420fa40@ogud.com> <43723634.9040906@algroup.co.uk> In-Reply-To: <43723634.9040906@algroup.co.uk> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id VAA27090 Ben Laurie wrote: > =D3lafur Gu=F0mundsson wrote: >> Russ Housley asked why this is solving the problem, as he think= s it >> doesn't. >=20 > I obviously blanked at this point, because I have no idea what Russ' > problem was - it would be good to get a statement from him on this. OK, I've had this explained, and it was basically that I didn't say how I planned to convert initial key setup into key rollover. I now know how to do that, and it'll all become clear in the next version of 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 Thu Nov 10 10:45:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaEc2-0008GP-9f for dnsext-archive@megatron.ietf.org; Thu, 10 Nov 2005 10:45:18 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11431 for ; Thu, 10 Nov 2005 10:44:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EaEVu-0007GP-RX for namedroppers-data@psg.com; Thu, 10 Nov 2005 15:38:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EaEVt-0007GA-Ky for namedroppers@ops.ietf.org; Thu, 10 Nov 2005 15:38:58 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jAAFcMMO024247; Thu, 10 Nov 2005 16:38:23 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <200511040134.jA41Ydfx003842@drugs.dv.isc.org> References: <200511040134.jA41Ydfx003842@drugs.dv.isc.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-26-858556375" Message-Id: <9E0FB904-3417-43CE-A5E4-EEDF11B5986E@NLnetLabs.nl> Cc: Namedroppers , Howard Eland Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: DNSKEY size calculator and implementation question Date: Thu, 10 Nov 2005 07:38:15 -0800 To: Mark Andrews X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-26-858556375 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit [Howard, you are explicitly CC-ed, there is a requirement for keyrollover buried in here] >> You seem to turn this reasoning into the following requirement; In >> order to be able to set the AD bit a forwarding name server needs to >> have validated NS RR sets in its cache. >> >> In order to fulfill this requirement a signed NS RR set needs to be >> provided to the forwarding name server. Hence authoritative servers >> need to add a signed NS RR set in the authority section. >> >> So far so good? > > Yep. One could argue that the above requirement could be fulfilled by requiring the resolver to do an authoritative query for the NS RR set at one of the servers that it was referred to by the parent. I think that is more appropriate but for now, let us not go there. The reason why this discussion started was that I wanted to know if the TC bit needed to be set when an authoritative NS server would drop the NS RR set from the authority section. I think a liberal interpretation is allowed and needed in this case. The need comes from a requirement that I want to set for key-rollover mechanisms. A key-rollover mechanism should not _require_ packets that cause truncation and queries to authoritative servers over TCP. - One could strike the word authoritative in this requirement, caching forwarding servers are not eager for TCP. - With EDNS0 it is hard to say what size is 'advertised' by the client. (Data point: One sees EDNS0 packets with sizes 1280 (none of those with the DO bit), 2048 and 4096 in the wild.) - One also wants to avoid UDP fragmentation. I am not sure what would be the appropriate size to recommend. Note that a caching forwarder server will need to set the TC bit, for a caching forwarding server the requirement for inclusion of the NS RR set is unambiguous. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-26-858556375 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.1 (Darwin) Comment: This message is locally signed. iD8DBQFDc2lutN/ca3YJIocRAmSKAJwPG5+WZSJ2WxiM5QO8e7rsEf8lVQCeJcCA jf+J6evV5o3kuK5f/xb0CUo= =Ts77 -----END PGP SIGNATURE----- --Apple-Mail-26-858556375-- -- to unsubscribe send a message to namedroppers-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 11 03:03:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaTsr-0001gI-Sp for dnsext-archive@megatron.ietf.org; Fri, 11 Nov 2005 03:03:41 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21625 for ; Fri, 11 Nov 2005 03:03:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EaTo2-000Op6-AZ for namedroppers-data@psg.com; Fri, 11 Nov 2005 07:58:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,INFO_TLD autolearn=no version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EaTo1-000Oou-Dr for namedroppers@ops.ietf.org; Fri, 11 Nov 2005 07:58:41 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jAB7wYYq033680; Fri, 11 Nov 2005 08:58:35 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <52A9E370-5232-4A18-913B-BE6910DE86D6@NLnetLabs.nl> References: <52A9E370-5232-4A18-913B-BE6910DE86D6@NLnetLabs.nl> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-7-917360146" Message-Id: <0599BC0C-4E77-47ED-B64D-7DB92B08693D@NLnetLabs.nl> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Key Maintenance requirements draft. Date: Thu, 10 Nov 2005 23:58:18 -0800 To: "Olaf M. Kolkman" X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-7-917360146 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit I wrote: > In order to get forward progress on the key-management issues we > decided to do one little step back and concentrate on a > requirements document. > > We have found two volunteers to edit such document: > Howard Eland > and > Russ Mundy and forgot to add Steve Crocker . If we could meet an earlier closure of this document we obviously should. Please send your requirements fast. --Olaf ------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-7-917360146 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.1 (Darwin) Comment: This message is locally signed. iD8DBQFDdE8ptN/ca3YJIocRApi3AKDILRTYvk7wyvgU2x5AP0qV0odUzACfSR4Q d96gMHyXRiDwsltOZ9bGhhQ= =y95s -----END PGP SIGNATURE----- --Apple-Mail-7-917360146-- -- to unsubscribe send a message to namedroppers-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 11 11:55:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EacBb-000643-Cg for dnsext-archive@megatron.ietf.org; Fri, 11 Nov 2005 11:55:37 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19273 for ; Fri, 11 Nov 2005 11:55:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Eac2x-00029V-Cz for namedroppers-data@psg.com; Fri, 11 Nov 2005 16:46:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Eac2w-00029J-Pw for namedroppers@ops.ietf.org; Fri, 11 Nov 2005 16:46:38 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 4067711425 for ; Fri, 11 Nov 2005 16:46:38 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: counterproposal (Re: Key Maintenance requirements draft. ) In-Reply-To: Your message of "Thu, 10 Nov 2005 23:58:18 PST." <0599BC0C-4E77-47ED-B64D-7DB92B08693D@NLnetLabs.nl> References: <52A9E370-5232-4A18-913B-BE6910DE86D6@NLnetLabs.nl> <0599BC0C-4E77-47ED-B64D-7DB92B08693D@NLnetLabs.nl> Date: Fri, 11 Nov 2005 16:46:38 +0000 Message-Id: <20051111164638.4067711425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # > In order to get forward progress on the key-management issues we decided # > to do one little step back and concentrate on a requirements document. i propose that "back" is not the direction we should step. if it takes two months (best case) to agree on requirements, it'll take more months to agree on an approach, more months after that to code it and interoperability-test it. and this assumes no IPR-related debates or delays. right now the best case is "dnssec in 2007". if we "step back" and work on requirements in the usual way, the best case will become "dnssec in 2008". i have a counter-proposal. google for "kde developer days" to see how another community, larger and more diverse than this one, tries to get things done. if the three original members of MODA were to arrange for conference rooms in tokyo, redwood city, and stockholm to be dedicated to "dnssec developer days" for a week, with videoconferencing, sake/beer/glug, and so on, and opened this up to anyone in the namedroppers community who could afford the travel costs... ...could we possibly explore the key management space from a "what's desired, what's the minimum we can all live with, what will actually work?" point of view, including writing two I-D's (one justifying the selection and one describing it) and coding it up and testing it? it's possible that the videoconferencing could be multicast somehow, and made available to folks who couldn't travel. there'd be jabber rooms, shared whiteboards, voip-reachable conference calls and speakerphones, etc. i think the infrastructure could be in place by the second/third week in jan06, if the WGchairs don't shoot this down and if there's general interest in it. (note that i've not spoken to johan or kato about the tokyo/stockholm rooms.) if this worked, we could stand to do it once a quarter until dnssec is "out". -- to unsubscribe send a message to namedroppers-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 11 14:17:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaeOh-000713-CC for dnsext-archive@megatron.ietf.org; Fri, 11 Nov 2005 14:17:15 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29035 for ; Fri, 11 Nov 2005 14:16:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EaeJh-000D1a-Sx for namedroppers-data@psg.com; Fri, 11 Nov 2005 19:12:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EaeJh-000D1E-2F for namedroppers@ops.ietf.org; Fri, 11 Nov 2005 19:12:05 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id jABJC47b007679; Fri, 11 Nov 2005 19:12:04 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id jABJC4GI007676; Fri, 11 Nov 2005 19:12:04 GMT Date: Fri, 11 Nov 2005 19:12:04 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: Namedroppers Subject: Re: counterproposal (Re: Key Maintenance requirements draft. ) Message-ID: <20051111191204.GA7619@vacation.karoshi.com.> References: <52A9E370-5232-4A18-913B-BE6910DE86D6@NLnetLabs.nl> <0599BC0C-4E77-47ED-B64D-7DB92B08693D@NLnetLabs.nl> <20051111164638.4067711425@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051111164638.4067711425@sa.vix.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Nov 11, 2005 at 04:46:38PM +0000, Paul Vixie wrote: > # > In order to get forward progress on the key-management issues we decided > # > to do one little step back and concentrate on a requirements document. > > i propose that "back" is not the direction we should step. > > if the three original members of MODA were to arrange for conference rooms shouldn't that be a big IF? > ...could we possibly explore the key management space from a "what's desired, > what's the minimum we can all live with, what will actually work?" point of > view, including writing two I-D's (one justifying the selection and one > describing it) and coding it up and testing it? hum... from what i heard during the YVR mtgs, there are now five(5) varients on key mgmt/rollover and more may emerge from the woodwork. from what i can deduce, three of the five have workable (sort of) methods in place now... if they would like to test them, i offer up the rs.net testbed. (now that I have the KSKs in place to get the ZSK signed...) > it's possible that the videoconferencing could be multicast somehow, and made > available to folks who couldn't travel. there'd be jabber rooms, shared > whiteboards, voip-reachable conference calls and speakerphones, etc. so we "don't" have to travel to a MODA site... wonderful! > i think the infrastructure could be in place by the second/third week in jan06, > if the WGchairs don't shoot this down and if there's general interest in it. > (note that i've not spoken to johan or kato about the tokyo/stockholm rooms.) we -could- do this, even w/o IETF permission/approval. and we don't need conference rooms and shared video, et.al. to get started. Shared jabber space and a framework to hang the keys on/in is needed. Perhaps a M/L to create/keep an archive of discussion. > if this worked, we could stand to do it once a quarter until dnssec is "out". er, yeah.. We -COULD- do the engineering evaluation independently of the politics and (possibly) the IPR headaches. --bill (ready and willing) -- to unsubscribe send a message to namedroppers-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 11 15:56:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EafwV-0003fS-HP for dnsext-archive@megatron.ietf.org; Fri, 11 Nov 2005 15:56:15 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06474 for ; Fri, 11 Nov 2005 15:55:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EafqW-000Jvw-2h for namedroppers-data@psg.com; Fri, 11 Nov 2005 20:50:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EafqV-000JvI-C8 for namedroppers@ops.ietf.org; Fri, 11 Nov 2005 20:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EafqU-00080q-A1; Fri, 11 Nov 2005 15:50: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-ds-sha256-00.txt Message-Id: Date: Fri, 11 Nov 2005 15:50:02 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) Author(s) : W. Hardaker Filename : draft-ietf-dnsext-ds-sha256-00.txt Pages : 7 Date : 2005-11-11 This document defines the use of the SHA-256 digest type for creating digests of DNSKEY Resource Records (RRs). These digests can then be published in Delegation Signer (DS) resource records (RRs) by a parent zone. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ds-sha256-00.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-ds-sha256-00.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-ds-sha256-00.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: <2005-11-11131102.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ds-sha256-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ds-sha256-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-11131102.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 Fri Nov 11 16:56:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eagt2-0001g5-Q6 for dnsext-archive@megatron.ietf.org; Fri, 11 Nov 2005 16:56:45 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20819 for ; Fri, 11 Nov 2005 16:56:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EagoX-000ONr-4i for namedroppers-data@psg.com; Fri, 11 Nov 2005 21:52:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EagoW-000ONe-BP for namedroppers@ops.ietf.org; Fri, 11 Nov 2005 21:52:04 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jABLpreV040280; Fri, 11 Nov 2005 16:51:54 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20051111162442.03db58f8@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 11 Nov 2005 16:51:55 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Fast Track document: Re: I-D ACTION:draft-ietf-dnsext-ds-sha256-00.txt Cc: dnsop@lists.uoregon.edu In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Based on guidance from the security area, we will be fast tracking this document. DS algorithm has been determined to be the weakest link in the DNSSEC chain, thus we are adding new stronger algorithm now and retiring SHA-1 from use in 2 years after this is published as RFC. The expectation is that there will one more algorithm roll in about 5 years when new generations of digest algorithm(s) has been reviewed and standardized. Please send comment on this version NOW to namedroppers, the plan is to start DNSEXT WG last call around Nov 20'th. The plan is to update digest algorithms used in signatures (RRSIG) in the near future, along with the retirement of TSIG/MD5. Olafur (DNSEXT co-chair) At 15:50 11/11/2005, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the DNS Extensions Working Group of the IETF. > > Title : Use of SHA-256 in DNSSEC Delegation > Signer (DS) Resource Records (RRs) > Author(s) : W. Hardaker > Filename : draft-ietf-dnsext-ds-sha256-00.txt > Pages : 7 > Date : 2005-11-11 > > This document defines the use of the SHA-256 digest type for creating > digests of DNSKEY Resource Records (RRs). These digests can then be > published in Delegation Signer (DS) resource records (RRs) by a > parent zone. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ds-sha256-00.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From DorianBoucher@ghgriggslaw.com Sat Nov 12 04:07:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EarMN-0007kI-RW for dnsext-archive@megatron.ietf.org; Sat, 12 Nov 2005 04:07:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21505 for ; Sat, 12 Nov 2005 04:07:14 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Earcy-0003yI-48 for dnsext-archive@ietf.org; Sat, 12 Nov 2005 04:24:52 -0500 Received: from yahoobb219176104130.bbtec.net ([219.176.104.130]) by mx2.foretec.com with smtp (Exim 4.24) id 1EarMG-0006sy-Bh for dnsext-archive@ietf.org; Sat, 12 Nov 2005 04:07:37 -0500 Received: from qxC@localhost by v49.int (8.11.6/8.11.6); Sat, 12 Nov 2005 05:04:27 -0400 Message-ID: From: "Jody Bray" Reply-To: "Jody Bray" To: dnsext-archive@ietf.org Subject: Re: OEM Windows XP, Adobe, & Symantec on $ale Now Date: Sat, 12 Nov 2005 13:00:27 +0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: DorianBoucher@ghgriggslaw.com Content-Type: multipart/mixed; boundary="--IDVCf82WSoD9XQR" X-Spam-Score: 0.3 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e Msmv ----IDVCf82WSoD9XQR Content-Type: text/html; Content-Transfer-Encoding: quoted-printable s
Opt-in Email Special Offer   = ;  unsubscribe me
= = <= /table>
SEARCH

Microsoft Window= s XP Professional *w/SP2*
Microsoft

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

=
=  <= /tr>
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
 = ;2 Creative Suite 2
 3 MS Office 2003 Pro
 4 Adobe Acrobat 7 Pro
 <= /td>5 Macromedia Flash 8
 = 6 Dreamweaver 8
 7= Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
 = ;10 Borland Architect 2005
&= nbsp; See more by this manufacturer
   Microsoft
   Macromedia
  Ado= be
  Customers also b= ought
   these other items...

<= /p>

Choose:<= /b>
=  <= input type=3Dimage alt=3DGo src=3Dhttp://g-images.amazon.com/images/G/01/s= earch-browse/go-button-software.gif value=3DGo border=3D0 name=3Dsubmit.di= splay-variation width=3D21 height=3D21>
<= /tr>
List Price:$299.00
Price:$49.99
Y= ou Save:$249.01 (80%)


Availability: Available for INSTANT download= !
Coupon Code: WI0EUNq
Platform: Windows XP

Sales Rank: #1
System requirements  |  Other Versions
Date Cou= pon Expires: December 31st, 2005
Aver= age Customer Review:3D"5 Based on 17862 reviews. Write a review.

Adobe Creative Suite 2 *P= remium*
Adob= e

Choose:
 

List Price:$1199.00
Price:$149.99
You Save:$1049.01 (95%)



= Availability: Available for INSTANT download!
Coupon Code: pNgL8Y
Platform: Windows XP

Sales Rank: #2=
System r= equirements  |  Other Vers= ions
Date Coupon Expires: Decembe= r 31st, 2005
Average Customer Review:= 3D"5 Based on 11445 reviews. Write a= review.

Microsoft Office 2003 *Professiona= l*
Microsoft=

Choose:
 

<= /tr>
List Price:$499.00
Price:$69.99
Y= ou Save:$429.01 (85%)


Availability: Available for INSTANT download= !
Coupon Code: d6c7HSN
Platform: Windows XP

Sales Rank: #3
System requirements  |  Other Versions
Date Cou= pon Expires: December 31st, 2005
Aver= age Customer Review:3D"5 Based on 1157 reviews. Write a review.

Adobe Acrob= at Professional V 7.0
Adobe=

=
Choose:
 

=

List Price:<= /b>$499.00
Price:$69.99
You Save:$429.01 (85%)



= Availability: Available for INSTANT download!
Coupon Code: huPlnBTY
Platform: Windows XP

Sales Rank: = #4
System= requirements  |  Other Ve= rsions
Date Coupon Expires: Decem= ber 31st, 2005
Average Customer Review:3D"5 Based on 116126 reviews. Writ= e a review.

----IDVCf82WSoD9XQR-- From NorahPelletier@bl-huaxiang.com Sun Nov 13 02:46:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbCZ8-0003Hs-LL for dnsext-archive@megatron.ietf.org; Sun, 13 Nov 2005 02:46:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18996 for ; Sun, 13 Nov 2005 02:45:46 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbCpn-0002QS-J9 for dnsext-archive@ietf.org; Sun, 13 Nov 2005 03:03:38 -0500 Received: from [61.254.13.102] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1EbCYv-0003xd-Ad for dnsext-archive@ietf.org; Sun, 13 Nov 2005 02:46:05 -0500 Received: from o56W@localhost by dKZD.int (8.11.6/8.11.6); Sun, 13 Nov 2005 01:59:56 -0300 Message-ID: From: "Kate Farris" Reply-To: "Kate Farris" To: dnsext-archive@ietf.org Subject: AutoCAD Special Deals today 0nly Date: Sun, 13 Nov 2005 03:53:56 -0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: NorahPelletier@bl-huaxiang.com Content-Type: multipart/mixed; boundary="--QU6HbD3gHflHdl6jy" X-Spam-Score: 3.6 (+++) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 eraQ ----QU6HbD3gHflHdl6jy Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 1
Opt-in Email Special Offer   = ;  unsubscribe me
SEARCH

TOP 10 NEW TITLES

=
= = = <= td width=3D4> 
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&n= bsp;2 Creative Suite 2
&= nbsp;3 MS Office 2003 Pro
 4 Adobe Acrobat 7 Pro
 5 Macromedia Flash 8
 6<= /td> Dreamweaver 8
 7 Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
 10 Borland Architect 2005
  See more by this manufact= urer
   Microsoft
  = Macromedia
 =   = Adobe
  Customers also bought
   <= font face=3Dverdana,arial,helvetica size=3D1> these other items...

Microsoft Windows XP Professional *w/SP2*
Microsoft

Choose:<= td width=3D135>
 

=
List Pr= ice:$299.00
Pric= e:$49.99
You Save:$249.01 (80%)



Availability: Available for INSTANT download!
Coup= on Code: wHIQcN
Platform: Windows XP

Sales Ra= nk: #1
System requirements  |  Other Versions
Date Coupon Expi= res: December 31st, 2005
Average Cust= omer Review:3D"5 Based on 171387 reviews. Write a review.

Adobe Creative Suite 2 *Premi= um*
Adobe=

Choose:
 

List Pr= ice:$1199.00
Pri= ce:$149.99
You Save:= $1049.01 (95%)

=

Availability: Available for INSTANT download!
C= oupon Code: JWme9
Platform: Windows XP

Sales = Rank: #2
System requirements  |  Other Versions
Date Coupon Ex= pires: December 31st, 2005
Average Cu= stomer Review:3D"5 Based on 1519 reviews. Write a review.

Microsoft Offi= ce 2003 *Professional*
Microsoft

Choose:<= /b>
 

=

List Price:$499.00
Price:$69.99
You Save:<= /td>$429.01 (= 85%)



Availability:<= /b> Available for INSTANT download!
Coupon Code: WG4qI
P= latform: Windows = XP

Sales Rank: #3
System requirements=   |  Other Versions
Date Coupon Expires: December 31st, 2005=
Average Customer Review:3D"5 Based= on 1944 reviews. Write a review.=

Adobe Acrobat Professional V 7.0
= Adobe

<= tr>
Choose:
=  

List Price:$499.00
Price:$69.99
You Save:$429.0= 1 (85%)

<= img border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/buttons/add-to= -cart-yellow-short.gif width=3D113 height=3D23>

Availabilit= y: Available for INSTANT download!
Coupon Code: ObvzesqF Platform: Wi= ndows XP

Sales Rank: #4
System requiremen= ts  |  Other Versions
Date Coupon Expires: December 31st= , 2005
Average Customer Review:3D"5 Based on 15637 reviews. Write a re= view.

----QU6HbD3gHflHdl6jy-- From marietjie@bestbuylocal.com Sun Nov 13 13:07:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbMGD-0005Mk-7A for dnsext-archive@megatron.ietf.org; Sun, 13 Nov 2005 13:07:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23922 for ; Sun, 13 Nov 2005 13:06:53 -0500 (EST) Received: from astrasbourg-251-1-49-163.w82-126.abo.wanadoo.fr ([82.126.222.163] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EbMX1-000471-0C for dnsext-archive@ietf.org; Sun, 13 Nov 2005 13:24:50 -0500 Message-ID: <000001c5e87c$5172e480$0100007f@localhost> From: "Tate Phillips" To: Subject: What IS OEM Software And Why Do You Care? Date: Sun, 13 Nov 2005 19:08:34 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5E87C.5172E480" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.7 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5E87C.5172E480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 38 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 38 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5E87C.5172E480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT down! load!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 37 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 3! 4 reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 40 reviews)

------=_NextPart_000_0001_01C5E87C.5172E480-- From owner-namedroppers@ops.ietf.org Sun Nov 13 13:13:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbMMS-0006xf-R9 for dnsext-archive@megatron.ietf.org; Sun, 13 Nov 2005 13:13:53 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24112 for ; Sun, 13 Nov 2005 13:13:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EbMGy-0003ss-Np for namedroppers-data@psg.com; Sun, 13 Nov 2005 18:08:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EbMGx-0003sV-KY for namedroppers@ops.ietf.org; Sun, 13 Nov 2005 18:08:12 +0000 Received: from cc730311-a.ENSCH1.OV.HOME.NL (cc730311-a.ensch1.ov.home.nl [82.75.151.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.schlyter.se (Postfix) with ESMTP id 567BB2D4E5; Sun, 13 Nov 2005 19:08:08 +0100 (CET) Date: Sun, 13 Nov 2005 19:08:03 +0100 From: Roy Arends X-X-Sender: roy@cc730311-a To: hardaker@tislabs.com cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ds-sha256-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Wes, On Fri, 11 Nov 2005 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the DNS Extensions Working Group of the IETF. > > Title : Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) > Author(s) : W. Hardaker > Filename : draft-ietf-dnsext-ds-sha256-00.txt > Pages : 7 > Date : 2005-11-11 > > This document defines the use of the SHA-256 digest type for creating > digests of DNSKEY Resource Records (RRs). These digests can then be > published in Delegation Signer (DS) resource records (RRs) by a > parent zone. Good work. I'd like to see this advanced asap. However, I'd like to see (something like) the following text added in section 4 as a motivation for supporting both digest types for two years, since that might be perceived as counter-intuititive: 4. Deployment Requirements If a validator does not support the SHA-256 digest type in an authenticated DS RRset, then the validator has no supported authentication path leading from the parent to the child. The resolver should treat this case as it would be the case of an authenticated NSEC RRset proving that no DS RRset exists, as described in RFC 4035, section 5.2. Therefore, deployments SHOULD publish both SHA-1 and SHA-256 based DS records for 2 years from the publication date of this RFC (XXX: RFC Editor: Please insert the calculated date here). 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 mexicaantje@acooper.com Mon Nov 14 04:42:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbarA-0003Zm-4B for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 04:42:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08644 for ; Mon, 14 Nov 2005 04:41:59 -0500 (EST) Received: from [59.188.175.119] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ebb89-0005aO-6R for dnsext-archive@ietf.org; Mon, 14 Nov 2005 05:00:06 -0500 Message-ID: <000001c5e8fe$f3d3ac00$0100007f@localhost> From: "Julian Phillips" To: Subject: Corel Draw Date: Mon, 14 Nov 2005 09:41:54 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5E8FE.F3D3AC00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5E8FE.F3D3AC00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 36 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 47 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 50 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5E8FE.F3D3AC00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES
!

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT downl! oad!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 47 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 43! reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 39 reviews)

------=_NextPart_000_0001_01C5E8FE.F3D3AC00-- From owner-namedroppers@ops.ietf.org Mon Nov 14 05:20:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbbRl-0000p9-VJ for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 05:20:22 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10049 for ; Mon, 14 Nov 2005 05:19:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EbbMK-000D2v-OB for namedroppers-data@psg.com; Mon, 14 Nov 2005 10:14:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EbbMJ-000D2V-7s for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 10:14:43 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 8631B33C44 for ; Mon, 14 Nov 2005 10:14:38 +0000 (GMT) Message-ID: <4378638F.1000303@algroup.co.uk> Date: Mon, 14 Nov 2005 10:14:39 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: DNSEXT WG Subject: Open NSEC3 Issues Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Later this week our issue tracking system for NSEC3 should go live. Assuming the WG is agreeable, I intended to direct its update emails to this list, rather than try to keep the list and the tracking system in sync manually. Is this OK with everyone? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 14 07:40:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbddQ-0007lb-3G for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 07:40:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17443 for ; Mon, 14 Nov 2005 07:40:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EbdZk-000K9P-AG for namedroppers-data@psg.com; Mon, 14 Nov 2005 12:36:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,UPPERCASE_25_50 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EbdZg-000K9A-Md for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 12:36:40 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jAECaUNb081508; Mon, 14 Nov 2005 13:36:33 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <4378638F.1000303@algroup.co.uk> References: <4378638F.1000303@algroup.co.uk> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: DNSEXT WG Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Open NSEC3 Issues Date: Mon, 14 Nov 2005 13:36:27 +0100 To: Ben Laurie X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > Assuming the WG is agreeable, I intended to direct its update > emails to this list, rather than try to keep the list and the > tracking system in sync manually. > > Is this OK with everyone? As long there is no flood of administrative e-mails this is fine; a good way to get work done. - --Olaf - ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDeITLtN/ca3YJIocRAg87AJ9ExaaJ9j8h0V7/wQrDSlvKSBi11QCgljXN eo/yveoEVeWnxzCP2SHjXdU= =WQRu -----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 14 07:47:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbdkX-000182-I0 for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 07:47:53 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17838 for ; Mon, 14 Nov 2005 07:47:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EbdiR-000KhG-PF for namedroppers-data@psg.com; Mon, 14 Nov 2005 12:45:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EbdiO-000Kgn-VF for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 12:45:41 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 5D84333C40; Mon, 14 Nov 2005 12:45:39 +0000 (GMT) Message-ID: <437886F4.9070601@algroup.co.uk> Date: Mon, 14 Nov 2005 12:45:40 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: DNSEXT WG Subject: Re: Open NSEC3 Issues References: <4378638F.1000303@algroup.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf M. Kolkman wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > >> >> Assuming the WG is agreeable, I intended to direct its update emails >> to this list, rather than try to keep the list and the tracking system >> in sync manually. >> >> Is this OK with everyone? > > > As long there is no flood of administrative e-mails this is fine; a good > way to get work done. There should be nothing other than ticket updates. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 14 09:33:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbfOp-0005IE-BU for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 09:33:35 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24474 for ; Mon, 14 Nov 2005 09:33:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EbfL9-0001KH-PI for namedroppers-data@psg.com; Mon, 14 Nov 2005 14:29:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EbfL7-0001K4-Sv for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 14:29:47 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAEETbli058915 for ; Mon, 14 Nov 2005 09:29:37 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id jAEETaCL058914 for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 09:29:36 -0500 (EST) (envelope-from namedroppers) Received: from [82.75.151.113] (helo=cc730311-a.ensch1.ov.home.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EbJNE-000EtJ-1b for namedroppers@ops.ietf.org; Sun, 13 Nov 2005 15:02:28 +0000 Received: from Administrator (helo=localhost) by cc730311-a.ensch1.ov.home.nl with local-esmtp (Exim 4.54) id IPWF3U-0002G4-M2; Sun, 13 Nov 2005 16:02:18 +0100 Date: Sun, 13 Nov 2005 16:02:14 +0100 From: Roy Arends X-X-Sender: Administrator@cc730311-a To: hardaker@tislabs.com cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ds-sha256-00.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ 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. ] Wes, On Fri, 11 Nov 2005 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the DNS Extensions Working Group of the IETF. > > Title : Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) > Author(s) : W. Hardaker > Filename : draft-ietf-dnsext-ds-sha256-00.txt > Pages : 7 > Date : 2005-11-11 > > This document defines the use of the SHA-256 digest type for creating > digests of DNSKEY Resource Records (RRs). These digests can then be > published in Delegation Signer (DS) resource records (RRs) by a > parent zone. Good work. I'd like to see this advanced asap. However, I'd like to see (something like) the following text added in section 4 as a motivation for supporting both digest types for two years: 4. Deployment Requirements If a validator does not support the SHA-256 digest type in an authenticated DS RRset, then the validator has no supported authentication path leading from the parent to the child. The resolver should treat this case as it would be the case of an authenticated NSEC RRset proving that no DS RRset exists, as described in RFC 4035, section 5.2. Therefore, deployments SHOULD publish both SHA-1 and SHA-256 based DS records for 2 years from the publication date of this RFC (XXX: RFC Editor: Please insert the calculated date here). 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 Mon Nov 14 09:34:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbfQ1-0005Mg-8M for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 09:34:49 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24562 for ; Mon, 14 Nov 2005 09:34:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EbfOX-0001XS-Ex for namedroppers-data@psg.com; Mon, 14 Nov 2005 14:33:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EbfOW-0001XD-2g for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 14:33:16 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAEEXAPG058931 for ; Mon, 14 Nov 2005 09:33:10 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20051114093206.02eb3a10@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 14 Nov 2005 09:33:12 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Advancing AAAA to Full standard ? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk About 2 years ago RFC3596 was published as Draft Standard. The chairs have received a question if it can be elevated to Full Standard. On the face of it RFC3596 meets all the criteria for advancement, it is implemented, deployed and used. If you have any reason to object that this document be advanced please state so on the mailing list before December 1'st 2005. In addition the chairs need at least 5 people to state support for this action. What is needed for advancement is a report from Working Group that this is a fully mature specification and is in use. Olafur & Olaf -- to unsubscribe send a message to namedroppers-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 14 09:39:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbfUZ-0006AN-ED for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 09:39:31 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24975 for ; Mon, 14 Nov 2005 09:38:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EbfSt-0001rL-Vu for namedroppers-data@psg.com; Mon, 14 Nov 2005 14:37:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM, NO_REAL_NAME autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EbfSr-0001qj-Nk for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 14:37:46 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAEEbcbM058969 for ; Mon, 14 Nov 2005 09:37:38 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id jAEEbbwe058968 for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 09:37:37 -0500 (EST) (envelope-from namedroppers) Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EZtcE-000LzS-UW; Wed, 09 Nov 2005 17:20:07 +0000 Received: from wds1.windom.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 09 Nov 2005 17:20:05 +0000 X-IronPort-AV: i="3.97,309,1125874800"; d="scan'208"; a="1400045:sNHT27615760" In-Reply-To: <43723634.9040906@algroup.co.uk> To: Ben Laurie Cc: namedroppers@ops.ietf.org, =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= , owner-namedroppers@ops.ietf.org Subject: Re: IETF-64 DNSEXT draft minutes MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 Message-ID: From: Geoffrey.Sisson@nominet.org.uk Date: Wed, 9 Nov 2005 17:20:03 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 11/09/2005 05:20:04 PM, Serialize complete at 11/09/2005 05:20:04 PM Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable [ 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. ] owner-namedroppers@ops.ietf.org wrote on 09-11-2005 17:47:32: > =D3lafur Gu=F0mundsson wrote: > > NSEC3 Report and Discussion > > There is an issue tracker available for NSEC3: > > http://nsec3.nominum.org.uk/ >=20 > I guess things to do with "name" in Latin are popular, but actually its > Nominet, and the URL is really: >=20 > http://dnssec.nominet.org.uk/nsec3 This will actually end up at: http://nsec3.nominet.org.uk/ Geoff -- to unsubscribe send a message to namedroppers-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 14 09:42:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbfXB-0007JT-RK for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 09:42:13 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25271 for ; Mon, 14 Nov 2005 09:41:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EbfVe-00028j-2z for namedroppers-data@psg.com; Mon, 14 Nov 2005 14:40:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EbfVb-000286-AW for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 14:40:35 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jAEEeHH18428; Mon, 14 Nov 2005 15:40:17 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jAEEeGSw035221; Mon, 14 Nov 2005 15:40:17 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511141440.jAEEeGSw035221@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair cc: namedroppers@ops.ietf.org Subject: Re: Advancing AAAA to Full standard ? In-reply-to: Your message of Mon, 14 Nov 2005 09:33:12 EST. <6.2.5.6.2.20051114093206.02eb3a10@ogud.com> Date: Mon, 14 Nov 2005 15:40:16 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In your previous mail you wrote: In addition the chairs need at least 5 people to state support for this action. => I support! What is needed for advancement is a report from Working Group that this is a fully mature specification and is in use. => TAHI has a test suite for DNS, IMHO they can give a list of certified (i.e., successfully tested) implementations. Thanks Francis.Dupont@enst-bretagne.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 14 09:54:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebfj6-0002pu-7m for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 09:54:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26380 for ; Mon, 14 Nov 2005 09:54:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ebfh2-00034z-63 for namedroppers-data@psg.com; Mon, 14 Nov 2005 14:52:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1Ebfh0-00034i-TD for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 14:52:23 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id D923926C0C0; Mon, 14 Nov 2005 15:52:21 +0100 (CET) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id C304C26C09C; Mon, 14 Nov 2005 15:52:20 +0100 (CET) Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id jAEEqKYa627838; Mon, 14 Nov 2005 15:52:20 +0100 (CET) Received: from kerkenna.nic.fr (localhost [127.0.0.1]) by kerkenna.nic.fr (8.13.3/8.13.3) with ESMTP id jAEEqKbv033944; Mon, 14 Nov 2005 15:52:20 +0100 (CET) (envelope-from souissi@kerkenna.nic.fr) Received: (from souissi@localhost) by kerkenna.nic.fr (8.13.3/8.13.3/Submit) id jAEEqJKS033943; Mon, 14 Nov 2005 15:52:19 +0100 (CET) (envelope-from souissi) Date: Mon, 14 Nov 2005 15:52:19 +0100 From: Mohsen Souissi To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= /DNSEXT co-chair Cc: namedroppers@ops.ietf.org Subject: Re: Advancing AAAA to Full standard ? Message-ID: <20051114145219.GB99793@kerkenna.nic.fr> References: <6.2.5.6.2.20051114093206.02eb3a10@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20051114093206.02eb3a10@ogud.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk As asked below, I believe RFC3596 is widely implemented and many implementations have been fully inter-operating for many years now in this matter and especially since it was published as DS. I fully support the action of the chairs which consists in moving forward RFC3596 to Full Standard. Mohsen. On 14 Nov, lafur Gumundsson /DNSEXT co-chair wrote: | | About 2 years ago RFC3596 was published as Draft Standard. | The chairs have received a question if it can be elevated to Full Standard. | | On the face of it RFC3596 meets all the criteria for advancement, | it is implemented, deployed and used. | | If you have any reason to object that this document be advanced please | state so on the mailing list before December 1'st 2005. | In addition the chairs need at least 5 people to state support | for this action. | | What is needed for advancement is a report from Working Group that this | is a fully mature specification and is in use. | | Olafur & Olaf -- to unsubscribe send a message to namedroppers-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 14 10:14:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebg2p-0003N4-5M for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 10:14:55 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28362 for ; Mon, 14 Nov 2005 10:14:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ebg0U-0004T6-Up for namedroppers-data@psg.com; Mon, 14 Nov 2005 15:12:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.52 (FreeBSD)) id 1Ebg0Q-0004Sa-UB for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 15:12:27 +0000 Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.13.4+Sun/8.13.4) with ESMTP id jAEFCJLX002071 (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO); Mon, 14 Nov 2005 16:12:20 +0100 (CET) Received: (from leinen@localhost) by diotima.switch.ch (8.13.4+Sun/8.13.4/Submit) id jAEFCI43002070; Mon, 14 Nov 2005 16:12:18 +0100 (CET) To: =?iso-8859-1?q?=D3lafur_Gu=F0mundsson_=2FDNSEXT_co-chair?= Cc: namedroppers@ops.ietf.org Subject: Re: Advancing AAAA to Full standard ? X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: <6.2.5.6.2.20051114093206.02eb3a10@ogud.com> =?iso-8859-1?q?=28=D3lafur_Gu=F0mundsson's?= message of "Mon, 14 Nov 2005 09:33:12 -0500") References: <6.2.5.6.2.20051114093206.02eb3a10@ogud.com> Date: Mon, 14 Nov 2005 16:12:18 +0100 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I support the RFC 3596's advancement to Full Standard. I have been using multiple RFC 3596 implementations every day for several years; in fact I think I use every aspect of it. My employer considers it an integral part of our network's DNS infrastructure, and our tools support it for the generation of forward and inverse zones, as well as for glue in the ccTLD registries that we operate. Regards, -- Simon Leinen. SWITCH -- to unsubscribe send a message to namedroppers-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 14 10:37:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbgOH-00084I-0z for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 10:37:05 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29619 for ; Mon, 14 Nov 2005 10:36:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EbgLu-0005vj-B5 for namedroppers-data@psg.com; Mon, 14 Nov 2005 15:34:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID,UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [208.17.35.58] (helo=cable.comcast.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EbgLs-0005vP-RU for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 15:34:37 +0000 Received: from ([10.20.62.12]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.14975939; Mon, 14 Nov 2005 10:34:08 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Nov 2005 10:34:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Advancing AAAA to Full standard ? Date: Mon, 14 Nov 2005 10:34:06 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302EB6430@PACDCEXCMB01.cable.comcast.com> Thread-Topic: Advancing AAAA to Full standard ? Thread-Index: AcXpKkzEx7NT7sb5QWa/7kzcfSwUfgABoE8g From: "Durand, Alain" To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT__co-chair?= , X-OriginalArrivalTime: 14 Nov 2005 15:34:07.0842 (UTC) FILETIME=[DA333C20:01C5E930] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > In addition the chairs need at least 5 people to state=20 > support for this action. I support this action. - Alain. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 14 10:37:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbgOI-00085N-Qm for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 10:37:06 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29622 for ; Mon, 14 Nov 2005 10:36:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EbgLg-0005ul-8N for namedroppers-data@psg.com; Mon, 14 Nov 2005 15:34:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EbgLe-0005uT-Hq for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 15:34:23 +0000 Received: from [10.31.32.115] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAEFYEFL059396; Mon, 14 Nov 2005 10:34:14 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.5.6.2.20051114093206.02eb3a10@ogud.com> References: <6.2.5.6.2.20051114093206.02eb3a10@ogud.com> Date: Mon, 14 Nov 2005 10:34:15 -0500 To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson_=2FDNSEXT__co=2Dchair?= From: Edward Lewis Subject: Re: Advancing AAAA to Full standard ? Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Shouldn't RFC 3596 require EDNS0? Looking at RFC 3226, A6 was stated to require=20 EDNS0 in section 2.2. This has always been in=20 the back of my mind. It's possible that the rationale in RFC 3226 is=20 wrong, that larger message sizes aren't=20 necessary. On the other hand, I wonder if=20 requiring it might make it possible to sneak=20 AAAA's into the root zone. Other than that, it seems to be mature, implemented and in some use. At 9:33 -0500 11/14/05, =D3lafur Gu=F0mundsson /DNSEXT co-chair wrote: >About 2 years ago RFC3596 was published as Draft Standard. >The chairs have received a question if it can be elevated to Full Standard. > >On the face of it RFC3596 meets all the criteria for advancement, >it is implemented, deployed and used. > >If you have any reason to object that this document be advanced please >state so on the mailing list before December 1'st 2005. >In addition the chairs need at least 5 people to state support >for this action. > >What is needed for advancement is a report from Working Group that this >is a fully mature specification and is in use. > > Olafur & Olaf > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis +1-571-434-5468 NeuStar True story: Only a routing "expert" would fly London->Minneapolis->Dallas->Minneapolis to get home from a conference. (Cities changed to protect his identity.) -- to unsubscribe send a message to namedroppers-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 14 10:40:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbgRt-0000MK-Qo for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 10:40:49 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29842 for ; Mon, 14 Nov 2005 10:40:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EbgQa-0006Hd-Gm for namedroppers-data@psg.com; Mon, 14 Nov 2005 15:39:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EbgQZ-0006HO-Hs for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 15:39:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jAEFdMr05536; Mon, 14 Nov 2005 17:39:22 +0200 Date: Mon, 14 Nov 2005 17:39:22 +0200 (EET) From: Pekka Savola To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair cc: namedroppers@ops.ietf.org Subject: Re: Advancing AAAA to Full standard ? In-Reply-To: <6.2.5.6.2.20051114093206.02eb3a10@ogud.com> Message-ID: References: <6.2.5.6.2.20051114093206.02eb3a10@ogud.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-1501005461-1131982762=:5456" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-1501005461-1131982762=:5456 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA29842 On Mon, 14 Nov 2005, =D3lafur Gu=F0mundsson /DNSEXT co-chair wrote: > On the face of it RFC3596 meets all the criteria for advancement, > it is implemented, deployed and used. I support this action, HOWEVER, the spec has IPv6 addressing=20 architecture as a normative reference; it cannot go to FS withou=20 addrarch going to full standard or applying for variance. So, basically this could be advanced when the v6 protocol bundle gets=20 advanced. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --1589707168-1501005461-1131982762=3D:5456-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: --1589707168-1501005461-1131982762=:5456-- From owner-namedroppers@ops.ietf.org Mon Nov 14 12:29:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebi8Y-0001fQ-U7 for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 12:29:01 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06961 for ; Mon, 14 Nov 2005 12:28:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ebi5Q-000C5f-7M for namedroppers-data@psg.com; Mon, 14 Nov 2005 17:25:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Ebi5N-000C5R-M9 for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 17:25:41 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0C1421142B for ; Mon, 14 Nov 2005 17:25:41 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Advancing AAAA to Full standard ? In-Reply-To: Your message of "Mon, 14 Nov 2005 10:34:15 EST." References: <6.2.5.6.2.20051114093206.02eb3a10@ogud.com> Date: Mon, 14 Nov 2005 17:25:41 +0000 Message-Id: <20051114172541.0C1421142B@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk i was considering making a process objection to the advancement of AAAA, but even though the process has been flawed, the results we'll get by advancing AAAA aren't worse than the ones we'd get by backtracking and then following the process. i refer specifically to the abandonment of A6. the decision to abandon A6 was made in a smoke filled room and then presented to the community as the new default unless sufficient cause was shown to reinstate the previous default (A6). lacking such sufficient cause, A6 was abandoned. the results have been catastrophic, and will only get worse as IPv6 is further deployed. we had one shining chance to use DNS as an identity and IPv6 addresses as locators, and that's been lost. most enterprise IPv6 deployment will be behind NAT, for the resulting economic reasons. the routing table will be every bit as pressured in an IPv6 world as it has been in an IPv4 world, or likely, far more pressured. but, even though our reasons for going to war were either outright lies or based on faulty intelligence or "sexed up" by interested politicians or even "not voted down" by folks who were afraid to be seen as "outside of the consensus position", the fact remains that we are at war, and we should win rather than lose or draw. AAAA will be a black mark on this working group's historical record. advance it please. -- to unsubscribe send a message to namedroppers-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 14 12:31:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbiAo-0001zf-BK for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 12:31:18 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07081 for ; Mon, 14 Nov 2005 12:30:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ebi6W-000CB7-T1 for namedroppers-data@psg.com; Mon, 14 Nov 2005 17:26:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INFO_TLD autolearn=no version=3.1.0 Received: from [206.190.36.78] (helo=smtp100.rog.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.52 (FreeBSD)) id 1Ebi6W-000CAm-6b for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 17:26:52 +0000 Received: (qmail 27110 invoked from network); 14 Nov 2005 17:26:51 -0000 Received: from unknown (HELO phlogiston.dydns.org) (a.sullivan@rogers.com@209.222.54.227 with login) by smtp100.rog.mail.re2.yahoo.com with SMTP; 14 Nov 2005 17:26:51 -0000 Received: by phlogiston.dydns.org (Postfix, from userid 1000) id 505D940B6; Mon, 14 Nov 2005 12:26:50 -0500 (EST) Date: Mon, 14 Nov 2005 12:26:50 -0500 From: Andrew Sullivan To: namedroppers@ops.ietf.org, dnssec-deployment@shinkuro.com Subject: Re: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM Message-ID: <20051114172650.GS15926@phlogiston.dyndns.org> Reply-To: Andrew Sullivan References: <4362A1E4.40505@connotech.com> <43664C8E.105@connotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43664C8E.105@connotech.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Oct 31, 2005 at 11:55:42AM -0500, Thierry Moreau wrote: > Having this discretion and the mandate to solve the trust anchor > key rollover problem, the DNSEXT wg should determine that the IPR > encumbered technology is *not* superior enough. If those who are > strict in their reluctance to study the > draft-moreau-dnsext-takrem-dns-00.txt are convinced that this is > the inescapable outcome of the wg activities, they merely decline > to participate in progress towards this determination. It appears this argument is subtly circular. It suggests that people who refuse to review a document on the basis of fear of contamination by IPR claims have a choice whether to read it. But that begs the question: the _whole point_ of not reading is precisely that one is concerned that the mere reading involves the loss of certain choices. Anyway, the way to determine whether the technology is superior enough for the use case is to define what the use case is, and we haven't done that yet; that effort is still underway, it seems to me. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +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 14 13:25:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebj1j-00085t-RW for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 13:25:59 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11581 for ; Mon, 14 Nov 2005 13:25:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ebiyb-000FHi-Pk for namedroppers-data@psg.com; Mon, 14 Nov 2005 18:22:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Ebiya-000FHX-Nd for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 18:22:44 +0000 Received: from [192.168.2.14] (ip68-105-211-64.tl.dl.cox.net [68.105.211.64]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id D6BA25691C; Mon, 14 Nov 2005 10:22:43 -0800 (PST) (envelope-from david.conrad@nominum.com) In-Reply-To: <20051114172541.0C1421142B@sa.vix.com> References: <6.2.5.6.2.20051114093206.02eb3a10@ogud.com> <20051114172541.0C1421142B@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <832D6C21-9859-4572-93E6-E5B2EEB7552D@nominum.com> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: David Conrad Subject: Flogging the A6 horse (was Re: Advancing AAAA to Full standard ?) Date: Mon, 14 Nov 2005 10:22:51 -0800 To: Paul Vixie X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul, On Nov 14, 2005, at 9:25 AM, Paul Vixie wrote: > i refer specifically to the abandonment of A6. the decision to > abandon A6 was > made in a smoke filled room and then presented to the community as > the new > default unless sufficient cause was shown to reinstate the previous > default > (A6). lacking such sufficient cause, A6 was abandoned. Yes, the way A6 was abandoned was unfortunate. The fact that it was abandoned wasn't. I don't see the relationship to AAAA however. > the results have been catastrophic, and will only get worse as IPv6 > is further > deployed. we had one shining chance to use DNS as an identity and > IPv6 > addresses as locators, and that's been lost. A6 was inherently flawed in a variety of ways (this isn't intended as criticism of the A6 authors, rather just an observation of what was discovered during implementation), the worst of which was that it would have introduced non-determinism in the lookup algorithm. Ick. However, there is absolutely nothing that stops using the DNS as the identifier and an IPv6 address as a locator and, in fact, there is much to argue for it (provider independence, site-wide transparent renumbering, site multi-homing, amenable to non-network topological and/or geo-political assignment, etc). The DNS could be used for the mapping between IPv6 identifier and locator _today_ (albeit a deployable DNSSEC would help), you don't need the weird half-step that was A6. "It's dead, Jim." Let it be. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 14 13:44:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbjJD-0003eq-I0 for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 13:44:04 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12882 for ; Mon, 14 Nov 2005 13:43:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EbjFn-000GI8-PZ for namedroppers-data@psg.com; Mon, 14 Nov 2005 18:40:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EbjFl-000GHv-Pp for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 18:40:30 +0000 Received: from [10.31.32.115] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAEIeCjW060245; Mon, 14 Nov 2005 13:40:15 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <832D6C21-9859-4572-93E6-E5B2EEB7552D@nominum.com> References: <6.2.5.6.2.20051114093206.02eb3a10@ogud.com> <20051114172541.0C1421142B@sa.vix.com> <832D6C21-9859-4572-93E6-E5B2EEB7552D@nominum.com> Date: Mon, 14 Nov 2005 13:37:22 -0500 To: David Conrad From: Edward Lewis Subject: Re: Flogging the A6 horse (was Re: Advancing AAAA to Full standard ?) Cc: Paul Vixie , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:22 -0800 11/14/05, David Conrad wrote: >Paul, > >On Nov 14, 2005, at 9:25 AM, Paul Vixie wrote: >> i refer specifically to the abandonment of A6. the decision to abandon A6 >> was >> made in a smoke filled room and then presented to the community as the new >> default unless sufficient cause was shown to reinstate the previous default >> (A6). lacking such sufficient cause, A6 was abandoned. > >Yes, the way A6 was abandoned was unfortunate. The fact that it was >abandoned wasn't. > >I don't see the relationship to AAAA however. Me too. <\aol> >> the results have been catastrophic, and will only get worse as IPv6 is >> further >> deployed. we had one shining chance to use DNS as an identity and IPv6 >> addresses as locators, and that's been lost. > >A6 was inherently flawed in a variety of ways (this isn't intended as >criticism of the A6 authors, rather just an observation of what was >discovered during implementation), the worst of which was that it would have >introduced non-determinism in the lookup algorithm. Ick. > >However, there is absolutely nothing that stops using the DNS as the >identifier and an IPv6 address as a locator and, in fact, there is much to >argue for it (provider independence, site-wide transparent renumbering, site >multi-homing, amenable to non-network topological and/or geo-political >assignment, etc). The DNS could be used for the mapping between IPv6 >identifier and locator _today_ (albeit a deployable DNSSEC would help), you >don't need the weird half-step that was A6. > >"It's dead, Jim." Let it be. Sometimes I think that it would be good to publish RFC's detailing things like this for the historical record and as lessons to the next generation. I was once disappointed in the loss of A6. It was neat, it appealed to the engineer/protocol geek in me. Kind of like flying cars. But it is against the basic tenet of a core infrastructural element, it is complex. My metric for the bit label was that I never once saw anyone ever, ever, stand up in front of more than 5 people and successfully work out an example by hand. If a human expert can't follow the algorithm, even for just a one-shot with no time limit, I can't expect two or more expert implementers to independently get the code right. Ok, maybe the bit label isn't A6, but they went hand-in-hand because of the arbitrary bit delegation boundry ideal. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-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 14 13:44:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbjJK-0003ff-7n for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 13:44:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12905 for ; Mon, 14 Nov 2005 13:43:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EbjFt-000GIg-Pd for namedroppers-data@psg.com; Mon, 14 Nov 2005 18:40:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EbjFs-000GIB-US for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 18:40:37 +0000 Received: from [10.31.32.115] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAEIeCjY060245; Mon, 14 Nov 2005 13:40:24 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <6.2.5.6.2.20051114093206.02eb3a10@ogud.com> Date: Mon, 14 Nov 2005 13:40:13 -0500 To: Pekka Savola From: Edward Lewis Subject: Re: Advancing AAAA to Full standard ? Cc: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson_=2FDNSEXT__co=2Dchair?= , namedroppers@ops.ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 17:39 +0200 11/14/05, Pekka Savola wrote: >On Mon, 14 Nov 2005, =D3lafur Gu=F0mundsson /DNSEXT co-chair wrote: >> On the face of it RFC3596 meets all the criteria for advancement, >> it is implemented, deployed and used. > >I support this action, HOWEVER, the spec has IPv6 addressing architecture= as a >normative reference; it cannot go to FS withou addrarch going to full stand= ard >or applying for variance. > >So, basically this could be advanced when the v6=20 >protocol bundle gets advanced. At that rate... =2E..or can we rewrite the document to remove the=20 reference. Make the AAAA record definition stand=20 on it's own, regardless of IPv6. I.e., it's a=20 128 bit address, not an IPv6 address. That's all=20 nomenclature, just trying to avoid IETF process=20 gridlock. Still - I would like to hear about whether we=20 ought to require EDNS0, recommending a minimum=20 acceptable response size. -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-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 14 14:02:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebjaz-00006O-0l for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 14:02:25 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14183 for ; Mon, 14 Nov 2005 14:01:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EbjZB-000HkB-0U for namedroppers-data@psg.com; Mon, 14 Nov 2005 19:00:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EbjZA-000Hjx-1I; Mon, 14 Nov 2005 19:00:32 +0000 To: Edward Lewis Cc: namedroppers@ops.ietf.org Reply-To: mankin@psg.com Subject: Re: Advancing AAAA to Full standard ? Date: Mon, 14 Nov 2005 11:00:32 -0800 From: Allison Mankin Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Ed, > ..or can we rewrite the document to remove the > reference. Or there can be a downref by using RFC 3967 procedure in the Last Call - it just asks the community to agree that AAAA going to Full Standard doesn't require the IPv6 architecture RFC to go beyond DS. IMO, the downref is technically reasonable. Asking the question in the Last Call is easy boilerplate. Allison -- to unsubscribe send a message to namedroppers-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 14 15:27:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebkuo-0001g4-HO for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 15:27:00 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21170 for ; Mon, 14 Nov 2005 15:26:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ebks4-000Mv9-IG for namedroppers-data@psg.com; Mon, 14 Nov 2005 20:24:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,UPPERCASE_25_50 autolearn=ham version=3.1.0 Received: from [208.31.42.42] (helo=xuxa.iecc.com) by psg.com with smtp (Exim 4.52 (FreeBSD)) id 1Ebks2-000Mu1-4e for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 20:24:06 +0000 Received: (qmail 28408 invoked by uid 100); 14 Nov 2005 20:24:03 -0000 Date: 14 Nov 2005 20:24:03 -0000 Message-ID: <20051114202403.28407.qmail@xuxa.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: Advancing AAAA to Full standard ? In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: Ed.Lewis@neustar.biz Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > It's possible that the rationale in RFC 3226 is wrong, that larger > message sizes aren't necessary. On the other hand, I wonder if > requiring [EDNS0] might make it possible to sneak AAAA's into the > root zone. Could you clarify "sneak" ? $ dig @e.root-servers.net fr. soa ; <<>> DiG 8.3 <<>> @e.root-servers.net fr. soa ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 12 ;; QUERY SECTION: ;; fr, type = SOA, class = IN ;; AUTHORITY SECTION: fr. 2D IN NS A.EXT.NIC.fr. fr. 2D IN NS A.NIC.fr. fr. 2D IN NS B.EXT.NIC.fr. fr. 2D IN NS B.NIC.fr. fr. 2D IN NS C.EXT.NIC.fr. fr. 2D IN NS C.NIC.fr. fr. 2D IN NS D.EXT.NIC.fr. fr. 2D IN NS E.EXT.NIC.fr. fr. 2D IN NS E.NIC.fr. ;; ADDITIONAL SECTION: A.EXT.NIC.fr. 2D IN A 193.51.208.14 A.NIC.fr. 2D IN A 192.93.0.1 B.EXT.NIC.fr. 2D IN A 192.228.90.21 B.NIC.fr. 2D IN A 192.93.0.4 B.NIC.fr. 2D IN AAAA 2001:660:3005:1::1:2 C.EXT.NIC.fr. 2D IN A 128.112.129.15 C.NIC.fr. 2D IN A 192.134.0.49 C.NIC.fr. 2D IN AAAA 2001:660:3006:1::1:1 D.EXT.NIC.fr. 2D IN A 204.152.184.85 D.EXT.NIC.fr. 2D IN AAAA 2001:4f8:0:2::8 E.EXT.NIC.fr. 2D IN A 193.176.144.6 E.NIC.fr. 2D IN A 194.57.253.1 ;; Total query time: 94 msec ;; FROM: xuxa.iecc.com to SERVER: e.root-servers.net 192.203.230.10 ;; WHEN: Mon Nov 14 15:20:23 2005 ;; MSG SIZE sent: 20 rcvd: 400 $ dig @e.root-servers.net coop. soa ; <<>> DiG 8.3 <<>> @e.root-servers.net coop. soa ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 8 ;; QUERY SECTION: ;; coop, type = SOA, class = IN ;; AUTHORITY SECTION: coop. 2D IN NS NS2.NIC.coop. coop. 2D IN NS NS3.NIC.coop. coop. 2D IN NS NS4.NIC.coop. coop. 2D IN NS NS5.NIC.coop. coop. 2D IN NS NS6.NIC.coop. coop. 2D IN NS NS1.NIC.coop. ;; ADDITIONAL SECTION: NS1.NIC.coop. 2D IN A 204.74.112.106 NS1.NIC.coop. 2D IN AAAA 2001:502:d399::106 NS2.NIC.coop. 2D IN A 204.74.113.106 NS3.NIC.coop. 2D IN A 199.7.66.106 NS4.NIC.coop. 2D IN A 199.7.67.106 NS4.NIC.coop. 2D IN AAAA 2001:502:100e::106 NS5.NIC.coop. 2D IN A 192.100.59.106 NS6.NIC.coop. 2D IN A 198.133.199.106 ;; Total query time: 98 msec ;; FROM: xuxa.iecc.com to SERVER: e.root-servers.net 192.203.230.10 ;; WHEN: Mon Nov 14 15:23:07 2005 ;; MSG SIZE sent: 22 rcvd: 286 -- to unsubscribe send a message to namedroppers-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 14 16:12:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eblch-0006iP-Cp for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 16:12:19 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28108 for ; Mon, 14 Nov 2005 16:11:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ebla2-0001C7-N8 for namedroppers-data@psg.com; Mon, 14 Nov 2005 21:09:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EblZz-0001Be-UJ for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 21:09:32 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Mon, 14 Nov 2005 16:09:30 -0500 id 005DC268.4378FD0A.00000393 In-Reply-To: <20051114202403.28407.qmail@xuxa.iecc.com> References: <20051114202403.28407.qmail@xuxa.iecc.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <58F96147-5047-4102-988E-63DEC8F5D287@verisignlabs.com> Cc: namedroppers@ops.ietf.org, Ed.Lewis@neustar.biz Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: Advancing AAAA to Full standard ? Date: Mon, 14 Nov 2005 16:09:29 -0500 To: John Levine X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Nov 14, 2005, at 3:24 PM, John Levine wrote: >> It's possible that the rationale in RFC 3226 is wrong, that larger >> message sizes aren't necessary. On the other hand, I wonder if >> requiring [EDNS0] might make it possible to sneak AAAA's into the >> root zone. > > Could you clarify "sneak" ? I presumed that Ed was referring to using AAAA records for the root servers themselves, where sizing is an issue, e.g., a AAAA record for b.root-servers.net. However, I must not have eaten my Wheaties(tm) this morning because I am failing to understand how mandating EDNS0 for AAAA records would even work at this late date. Would servers give back different answers if queried without EDNS? -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-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 14 16:34:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eblxt-0006xQ-GB for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 16:34:13 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02839 for ; Mon, 14 Nov 2005 16:33:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EbluE-0003E7-8l for namedroppers-data@psg.com; Mon, 14 Nov 2005 21:30:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [208.31.42.38] (helo=tom.iecc.com) by psg.com with smtp (Exim 4.52 (FreeBSD)) id 1EbluA-0003Db-L3 for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 21:30:23 +0000 Received: (qmail 14322 invoked from network); 14 Nov 2005 21:30:21 -0000 Received: (ofmipd 127.0.0.1); 14 Nov 2005 21:29:59 -0000 Date: 14 Nov 2005 16:30:21 -0500 Message-ID: From: "John R Levine" To: "David Blacka" Cc: namedroppers@ops.ietf.org, Ed.Lewis@neustar.biz Subject: Re: Advancing AAAA to Full standard ? In-Reply-To: <58F96147-5047-4102-988E-63DEC8F5D287@verisignlabs.com> References: <20051114202403.28407.qmail@xuxa.iecc.com> <58F96147-5047-4102-988E-63DEC8F5D287@verisignlabs.com> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I presumed that Ed was referring to using AAAA records for the root > servers themselves, where sizing is an issue, e.g., a AAAA record for > b.root-servers.net. Since resolvers typically have the addresses of the roots configured in a hints file, why is that an issue? I realize they should query and get an updated set of addresses, but so what? > However, I must not have eaten my Wheaties(tm) this morning because I > am failing to understand how mandating EDNS0 for AAAA records would > even work at this late date. Would servers give back different > answers if queried without EDNS? I suppose they might leave out some of the additional records to keep the response under 512 bytes, thereby adding a trickle of additional traffic. The response for the root with authority and additional records is currently 493 bytes, so it'd take additional queries to find AAAA records for them. Considering how what a tiny fraction of root traffic is this sort of root refresh query, do we care? Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "I dropped the toothpaste", said Tom, crestfallenly. -- to unsubscribe send a message to namedroppers-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 14 16:41:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebm4j-0000YE-Hr for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 16:41:17 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03338 for ; Mon, 14 Nov 2005 16:40:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ebm2u-00043c-Qy for namedroppers-data@psg.com; Mon, 14 Nov 2005 21:39:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Ebm2s-000430-F2 for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 21:39:22 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 76795677FA for ; Mon, 14 Nov 2005 21:39:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id jAELdH5Q015884 for ; Tue, 15 Nov 2005 08:39:17 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200511142139.jAELdH5Q015884@drugs.dv.isc.org> Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Advancing AAAA to Full standard ? In-reply-to: Your message of "Mon, 14 Nov 2005 16:09:29 CDT." <58F96147-5047-4102-988E-63DEC8F5D287@verisignlabs.com> Date: Tue, 15 Nov 2005 08:39:16 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I worried about advancing AAAA as it alone does not reflect the status of addresses assigned to a IPv6 node. IPv6 has both active and deprecated addresses and we don't have a way of reflecting these states in the DNS. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 14 17:37:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebmwx-000119-3I for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 17:37:19 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06662 for ; Mon, 14 Nov 2005 17:36:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ebmtg-00093H-Ir for namedroppers-data@psg.com; Mon, 14 Nov 2005 22:33:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,UPPERCASE_25_50 autolearn=ham version=3.1.0 Received: from [131.111.8.131] (helo=ppsw-1.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1Ebmtd-00092n-Ui for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 22:33:54 +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]:60682) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1EbmtM-0002Ix-5r (Exim 4.54) (return-path ); Mon, 14 Nov 2005 22:33:36 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1EbmtM-0004Q3-PY (Exim 4.53) (return-path ); Mon, 14 Nov 2005 22:33:36 +0000 Date: Mon, 14 Nov 2005 22:33:36 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Mark Andrews cc: namedroppers@ops.ietf.org Subject: Re: Advancing AAAA to Full standard ? In-Reply-To: <200511142139.jAELdH5Q015884@drugs.dv.isc.org> Message-ID: References: <200511142139.jAELdH5Q015884@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 15 Nov 2005, Mark Andrews wrote: > > IPv6 has both active and deprecated addresses and we don't > have a way of reflecting these states in the DNS. What's wrong with deleting the deprecated address RRs? Tony. -- f.a.n.finch http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. 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 14 17:53:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnCQ-0005nw-O6 for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 17:53:19 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07817 for ; Mon, 14 Nov 2005 17:52:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ebn6I-000AJ8-LU for namedroppers-data@psg.com; Mon, 14 Nov 2005 22:46:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, MIME_BASE64_NO_NAME,RCVD_IN_WHOIS_INVALID,UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [208.17.35.59] (helo=paoakoavas10.cable.comcast.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Ebn6H-000AIw-Mm for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 22:46:57 +0000 Received: from ([10.20.9.172]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.14901647; Mon, 14 Nov 2005 17:46:32 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Nov 2005 17:46:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: Re: Advancing AAAA to Full standard ? Date: Mon, 14 Nov 2005 17:46:31 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73C2F148@PACDCEXCMB01.cable.comcast.com> Thread-Topic: Advancing AAAA to Full standard ? Thread-Index: AcXpMvgHAS03tWMTRsK+8RJPSoSXIAAOkmk1 From: "Durand, Alain" To: , Cc: X-OriginalArrivalTime: 14 Nov 2005 22:46:32.0260 (UTC) FILETIME=[42474040:01C5E96D] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: base64 UGVra2EsDQoNClRoaXMgaXMgYSBnb29kIHBvaW50LCBzdGlsbCB0aGUgcmVxdWVzdHMgdG8gdGhl IElFU0cgdG8gYWR2YW5jZSBhbGwgdGhvc2Ugc3BlY3MgY2FuIGhhcHBlbiBzaW11bHRhbmVvdXNs eS4NCg0KICAgIC0gQWxhaW4uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IG93bmVyLW5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmcNClRvOiDDk2xhZnVyIEd1w7BtdW5kc3Nv biAvRE5TRVhUICBjby1jaGFpcg0KQ0M6IG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmcNClNlbnQ6 IE1vbiBOb3YgMTQgMTA6Mzk6MjIgMjAwNQ0KU3ViamVjdDogUmU6IEFkdmFuY2luZyBBQUFBIHRv IEZ1bGwgc3RhbmRhcmQgPyANCg0KT24gTW9uLCAxNCBOb3YgMjAwNSwgw5NsYWZ1ciBHdcOwbXVu ZHNzb24gL0ROU0VYVCAgY28tY2hhaXIgd3JvdGU6DQo+IE9uIHRoZSBmYWNlIG9mIGl0IFJGQzM1 OTYgbWVldHMgYWxsIHRoZSBjcml0ZXJpYSBmb3IgYWR2YW5jZW1lbnQsDQo+IGl0IGlzIGltcGxl bWVudGVkLCBkZXBsb3llZCBhbmQgdXNlZC4NCg0KSSBzdXBwb3J0IHRoaXMgYWN0aW9uLCBIT1dF VkVSLCB0aGUgc3BlYyBoYXMgSVB2NiBhZGRyZXNzaW5nIA0KYXJjaGl0ZWN0dXJlIGFzIGEgbm9y bWF0aXZlIHJlZmVyZW5jZTsgaXQgY2Fubm90IGdvIHRvIEZTIHdpdGhvdSANCmFkZHJhcmNoIGdv aW5nIHRvIGZ1bGwgc3RhbmRhcmQgb3IgYXBwbHlpbmcgZm9yIHZhcmlhbmNlLg0KDQpTbywgYmFz aWNhbGx5IHRoaXMgY291bGQgYmUgYWR2YW5jZWQgd2hlbiB0aGUgdjYgcHJvdG9jb2wgYnVuZGxl IGdldHMgDQphZHZhbmNlZC4NCg0KLS0gDQpQZWtrYSBTYXZvbGEgICAgICAgICAgICAgICAgICJZ b3UgZWFjaCBuYW1lIHlvdXJzZWx2ZXMga2luZywgeWV0IHRoZQ0KTmV0Y29yZSBPeSAgICAgICAg ICAgICAgICAgICAga2luZ2RvbSBibGVlZHMuIg0KU3lzdGVtcy4gTmV0d29ya3MuIFNlY3VyaXR5 LiAtLSBHZW9yZ2UgUi5SLiBNYXJ0aW46IEEgQ2xhc2ggb2YgS2luZ3MNCg== -- to unsubscribe send a message to namedroppers-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 14 18:02:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbnLI-0001kG-9U for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 18:02:28 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08561 for ; Mon, 14 Nov 2005 18:01:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EbnJK-000BgA-VV for namedroppers-data@psg.com; Mon, 14 Nov 2005 23:00:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EbnJK-000Bfz-B5 for namedroppers@ops.ietf.org; Mon, 14 Nov 2005 23:00:26 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 83189677F9 for ; Mon, 14 Nov 2005 23:00:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id jAEN0GBE017406; Tue, 15 Nov 2005 10:00:16 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200511142300.jAEN0GBE017406@drugs.dv.isc.org> To: Tony Finch Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Advancing AAAA to Full standard ? In-reply-to: Your message of "Mon, 14 Nov 2005 22:33:36 -0000." Date: Tue, 15 Nov 2005 10:00:16 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Tue, 15 Nov 2005, Mark Andrews wrote: > > > > IPv6 has both active and deprecated addresses and we don't > > have a way of reflecting these states in the DNS. > > What's wrong with deleting the deprecated address RRs? Well you can still send packets to and from these addresses. They are deprecated not gone. Being deprecated you don't want to use these for new sessions, if you can avoid doing so, but you still need to maintain the association between the name and the address. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 14 20:15:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbpQT-00023y-MC for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 20:15:57 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16264 for ; Mon, 14 Nov 2005 20:15:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EbpNZ-000Khl-OY for namedroppers-data@psg.com; Tue, 15 Nov 2005 01:12:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EbpNW-000KhK-P4 for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 01:12:55 +0000 Received: from [10.31.32.115] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAF1CdpN064031; Mon, 14 Nov 2005 20:12:40 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20051114202403.28407.qmail@xuxa.iecc.com> <58F96147-5047-4102-988E-63DEC8F5D287@verisignlabs.com> Date: Mon, 14 Nov 2005 20:12:43 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Advancing AAAA to Full standard ? Cc: Ed.Lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:30 -0500 11/14/05, John R Levine wrote: >Quoting David >> I presumed that Ed was referring to using AAAA records for the root >> servers themselves, where sizing is an issue, e.g., a AAAA record for >> b.root-servers.net. > >Since resolvers typically have the addresses of the roots configured in a >hints file, why is that an issue? I realize they should query and get an >updated set of addresses, but so what? Yeah, David is right. Yeah, there are AAAA's for delegations from the root. I've just been waiting for the root servers to start having AAAA's (and DNSSEC). So what? - Configured data goes stale. It's better to have them listed in the zone. >> However, I must not have eaten my Wheaties(tm) this morning because I >> am failing to understand how mandating EDNS0 for AAAA records would >> even work at this late date. Would servers give back different >> answers if queried without EDNS? > >I suppose they might leave out some of the additional records to keep the >response under 512 bytes, thereby adding a trickle of additional traffic. >The response for the root with authority and additional records is >currently 493 bytes, so it'd take additional queries to find AAAA records >for them. Considering how what a tiny fraction of root traffic is this >sort of root refresh query, do we care? One of the first commandments of the DNS protocol is to put the entire response for the root SOA, authority and additional in one packet. It's my understanding that the problem of getting AAAA's for the root servers is doing so while obeying that commandment. What would happen if we dropped that commandment? Would things still work? Would that get AAAA's into, okay, root-servers.net? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-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 14 20:57:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebq4C-0000QM-VQ for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 20:57:01 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20302 for ; Mon, 14 Nov 2005 20:56:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ebq27-000NSQ-9W for namedroppers-data@psg.com; Tue, 15 Nov 2005 01:54:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,UPPERCASE_25_50 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Ebq25-000NSD-KG for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 01:54:49 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id D6700677F9 for ; Tue, 15 Nov 2005 01:54:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id jAF1rmUe052192; Tue, 15 Nov 2005 12:54:01 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200511150154.jAF1rmUe052192@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Advancing AAAA to Full standard ? In-reply-to: Your message of "Mon, 14 Nov 2005 20:12:43 CDT." Date: Tue, 15 Nov 2005 12:53:48 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 16:30 -0500 11/14/05, John R Levine wrote: > >Quoting David > >> I presumed that Ed was referring to using AAAA records for the root > >> servers themselves, where sizing is an issue, e.g., a AAAA record for > >> b.root-servers.net. > > > >Since resolvers typically have the addresses of the roots configured in a > >hints file, why is that an issue? I realize they should query and get an > >updated set of addresses, but so what? > > Yeah, David is right. Yeah, there are AAAA's for delegations from > the root. I've just been waiting for the root servers to start > having AAAA's (and DNSSEC). > > So what? - Configured data goes stale. It's better to have them > listed in the zone. > > >> However, I must not have eaten my Wheaties(tm) this morning because I > >> am failing to understand how mandating EDNS0 for AAAA records would > >> even work at this late date. Would servers give back different > >> answers if queried without EDNS? > > > >I suppose they might leave out some of the additional records to keep the > >response under 512 bytes, thereby adding a trickle of additional traffic. > >The response for the root with authority and additional records is > >currently 493 bytes, so it'd take additional queries to find AAAA records > >for them. Considering how what a tiny fraction of root traffic is this > >sort of root refresh query, do we care? > > One of the first commandments of the DNS protocol is to put the > entire response for the root SOA, authority and additional in one > packet. It's my understanding that the problem of getting AAAA's for > the root servers is doing so while obeying that commandment. Actually the DNS protocol does not require this. Older versions of 'named' required this which is not the same thing. A resolver should be able to get any missing address records using the SBELT information. > What would happen if we dropped that commandment? Would things still > work? Would that get AAAA's into, okay, root-servers.net? Yes they would still work given that the servers can preferentually treat A additional records over AAAA additional records to help the broken systems. Note that the A records are all present but the AAAA records are not. [The local caching server has AAAA/A records for a number of the root servers pre-loaded.] ; <<>> DiG 8.3 <<>> ns . ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62036 ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15 ;; QUERY SECTION: ;; ., type = NS, class = IN ;; ANSWER SECTION: . 4d14m25s IN NS A.ROOT-SERVERS.NET. . 4d14m25s IN NS B.ROOT-SERVERS.NET. . 4d14m25s IN NS C.ROOT-SERVERS.NET. . 4d14m25s IN NS D.ROOT-SERVERS.NET. . 4d14m25s IN NS E.ROOT-SERVERS.NET. . 4d14m25s IN NS F.ROOT-SERVERS.NET. . 4d14m25s IN NS G.ROOT-SERVERS.NET. . 4d14m25s IN NS H.ROOT-SERVERS.NET. . 4d14m25s IN NS I.ROOT-SERVERS.NET. . 4d14m25s IN NS J.ROOT-SERVERS.NET. . 4d14m25s IN NS K.ROOT-SERVERS.NET. . 4d14m25s IN NS L.ROOT-SERVERS.NET. . 4d14m25s IN NS M.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 1d23h55m11s IN A 198.41.0.4 B.ROOT-SERVERS.NET. 1H IN A 192.228.79.201 C.ROOT-SERVERS.NET. 1d23h55m7s IN A 192.33.4.12 D.ROOT-SERVERS.NET. 1d23h55m4s IN A 128.8.10.90 E.ROOT-SERVERS.NET. 1d23h55m1s IN A 192.203.230.10 F.ROOT-SERVERS.NET. 1H IN A 192.5.5.241 G.ROOT-SERVERS.NET. 1d23h54m55s IN A 192.112.36.4 H.ROOT-SERVERS.NET. 1H IN A 128.63.2.53 I.ROOT-SERVERS.NET. 1d23h54m52s IN A 192.36.148.17 J.ROOT-SERVERS.NET. 1d23h54m47s IN A 192.58.128.30 K.ROOT-SERVERS.NET. 1H IN A 193.0.14.129 L.ROOT-SERVERS.NET. 1d23h54m44s IN A 198.32.64.12 M.ROOT-SERVERS.NET. 1H IN A 202.12.27.33 B.ROOT-SERVERS.NET. 1H IN AAAA 2001:478:65::53 F.ROOT-SERVERS.NET. 1H IN AAAA 2001:500::1035 ;; Total query time: 1 msec ;; FROM: drugs.dv.isc.org to SERVER: 127.0.0.1 ;; WHEN: Tue Nov 15 12:40:05 2005 ;; MSG SIZE sent: 17 rcvd: 492 Adding AAAA records for the roots while definitely causing the answer to exceed 512 bytes should not trigger fragmentation. ; <<>> DiG 8.3 <<>> ns . +dnssec ;; res options: init recurs defnam dnsrch dnssec ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63291 ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 19 ;; QUERY SECTION: ;; ., type = NS, class = IN ;; ANSWER SECTION: . 4d10m59s IN NS A.ROOT-SERVERS.NET. . 4d10m59s IN NS B.ROOT-SERVERS.NET. . 4d10m59s IN NS C.ROOT-SERVERS.NET. . 4d10m59s IN NS D.ROOT-SERVERS.NET. . 4d10m59s IN NS E.ROOT-SERVERS.NET. . 4d10m59s IN NS F.ROOT-SERVERS.NET. . 4d10m59s IN NS G.ROOT-SERVERS.NET. . 4d10m59s IN NS H.ROOT-SERVERS.NET. . 4d10m59s IN NS I.ROOT-SERVERS.NET. . 4d10m59s IN NS J.ROOT-SERVERS.NET. . 4d10m59s IN NS K.ROOT-SERVERS.NET. . 4d10m59s IN NS L.ROOT-SERVERS.NET. . 4d10m59s IN NS M.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 1d23h51m45s IN A 198.41.0.4 B.ROOT-SERVERS.NET. 1H IN A 192.228.79.201 C.ROOT-SERVERS.NET. 1d23h51m41s IN A 192.33.4.12 D.ROOT-SERVERS.NET. 1d23h51m38s IN A 128.8.10.90 E.ROOT-SERVERS.NET. 1d23h51m35s IN A 192.203.230.10 F.ROOT-SERVERS.NET. 1H IN A 192.5.5.241 G.ROOT-SERVERS.NET. 1d23h51m29s IN A 192.112.36.4 H.ROOT-SERVERS.NET. 1H IN A 128.63.2.53 I.ROOT-SERVERS.NET. 1d23h51m26s IN A 192.36.148.17 J.ROOT-SERVERS.NET. 1d23h51m21s IN A 192.58.128.30 K.ROOT-SERVERS.NET. 1H IN A 193.0.14.129 L.ROOT-SERVERS.NET. 1d23h51m18s IN A 198.32.64.12 M.ROOT-SERVERS.NET. 1H IN A 202.12.27.33 B.ROOT-SERVERS.NET. 1H IN AAAA 2001:478:65::53 F.ROOT-SERVERS.NET. 1H IN AAAA 2001:500::1035 H.ROOT-SERVERS.NET. 1H IN AAAA 2001:500:1::803f:235 K.ROOT-SERVERS.NET. 1H IN AAAA 2001:7fd::1 M.ROOT-SERVERS.NET. 1H IN AAAA 2001:dc3::35 ; EDNS: version: 0, udp=1460, flags=8000 ;; Total query time: 1 msec ;; FROM: drugs.dv.isc.org to SERVER: 127.0.0.1 ;; WHEN: Tue Nov 15 12:43:31 2005 ;; MSG SIZE sent: 28 rcvd: 587 A referral to the COM/NET servers already exceeds 512 bytes. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > 3 months to the next trip. I guess it's finally time to settle down and > find a grocery store. > > -- > to 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 14 21:56:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebr04-00013v-Lh for dnsext-archive@megatron.ietf.org; Mon, 14 Nov 2005 21:56:50 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23244 for ; Mon, 14 Nov 2005 21:56:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ebqx4-00017q-5K for namedroppers-data@psg.com; Tue, 15 Nov 2005 02:53:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Ebqx2-00017a-Eu for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 02:53:41 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id jAF2rZ7b030055; Tue, 15 Nov 2005 02:53:35 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id jAF2rXYf030052; Tue, 15 Nov 2005 02:53:33 GMT Date: Tue, 15 Nov 2005 02:53:33 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Cc: David Conrad , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: Flogging the A6 horse (was Re: Advancing AAAA to Full standard ?) Message-ID: <20051115025333.GD29731@vacation.karoshi.com.> References: <6.2.5.6.2.20051114093206.02eb3a10@ogud.com> <20051114172541.0C1421142B@sa.vix.com> <832D6C21-9859-4572-93E6-E5B2EEB7552D@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >"It's dead, Jim." Let it be. > > I was once disappointed in the loss of A6. It was neat, it appealed > to the engineer/protocol geek in me. Kind of like flying cars. But > it is against the basic tenet of a core infrastructural element, it > is complex. i -still- am pissed off that support for A6 is gone. > My metric for the bit label was that I never once saw anyone ever, > ever, stand up in front of more than 5 people and successfully work > out an example by hand. If a human expert can't follow the > algorithm, even for just a one-shot with no time limit, I can't > expect two or more expert implementers to independently get the code > right. Ha! i've seen it done on several occasions. get one of the swedes four or five shots down a fine single malt and they can do it... :) (ok, only slightly less complex than sendmail rulesets... :) > Ok, maybe the bit label isn't A6, but they went hand-in-hand because > of the arbitrary bit delegation boundry ideal. critical, core technology required to support variable length addresses. hanging in suspended animation until the world is ready for true advances. of course YMMV. > Edward Lewis +1-571-434-5468 --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 15 00:39:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbtXm-0001Af-0W for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 00:39:46 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01281 for ; Tue, 15 Nov 2005 00:39:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EbtU0-000Ait-Jz for namedroppers-data@psg.com; Tue, 15 Nov 2005 05:35:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EbtTz-000Aie-EM for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 05:35:51 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAF5Q6C9065618; Tue, 15 Nov 2005 00:26:08 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200511150154.jAF1rmUe052192@drugs.dv.isc.org> References: <200511150154.jAF1rmUe052192@drugs.dv.isc.org> Date: Tue, 15 Nov 2005 00:26:13 -0500 To: Mark Andrews From: Edward Lewis Subject: Re: Advancing AAAA to Full standard ? Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:53 +1100 11/15/05, Mark Andrews wrote: >> What would happen if we dropped that commandment? Would things still >> work? Would that get AAAA's into, okay, root-servers.net? > > Yes they would still work given that the servers can > preferentually treat A additional records over AAAA additional > records to help the broken systems. Note that the A > records are all present but the AAAA records are not. > [The local caching server has AAAA/A records for a number > of the root servers pre-loaded.] So, why don't we see AAAA's for the root servers? I lulled myself into believing it was the size constraint. Doesn't ($implementation=) BIND treat AAAA's as preferential? I ask because I am not sure what you mean by preferential treatment. Do you mean prefer to include A's over AAAA's? (As opposed to trying the AAAA before the A for the server.) > Adding AAAA records for the roots while definitely causing > the answer to exceed 512 bytes should not trigger fragmentation. > ... >;; ADDITIONAL SECTION: ... >B.ROOT-SERVERS.NET. 1H IN AAAA 2001:478:65::53 >F.ROOT-SERVERS.NET. 1H IN AAAA 2001:500::1035 >H.ROOT-SERVERS.NET. 1H IN AAAA 2001:500:1::803f:235 >K.ROOT-SERVERS.NET. 1H IN AAAA 2001:7fd::1 >M.ROOT-SERVERS.NET. 1H IN AAAA 2001:dc3::35 >; EDNS: version: 0, udp=1460, flags=8000 I don't see these records when querying... sh-2.05b$ for i in a b c d e f g h i j k l m; \ do dig $i.root-servers.net aaaa +short; \ done sh-2.05b$ It's late here, maybe I have a typo in my dig, but I can't find AAAA's for the roots. If there's no problem with AAAA's and message size, then I can see that EDNS0 is not an issue for AAAA's. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-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 15 01:01:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbtsN-0006iZ-OJ for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 01:01:03 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02410 for ; Tue, 15 Nov 2005 01:00:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ebtnu-000Chc-CH for namedroppers-data@psg.com; Tue, 15 Nov 2005 05:56:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Ebtnt-000Cgk-87 for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 05:56:25 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 58894677FA for ; Tue, 15 Nov 2005 05:56:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id jAF5uD3Q020616; Tue, 15 Nov 2005 16:56:14 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200511150556.jAF5uD3Q020616@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Advancing AAAA to Full standard ? In-reply-to: Your message of "Tue, 15 Nov 2005 00:26:13 CDT." Date: Tue, 15 Nov 2005 16:56:13 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 12:53 +1100 11/15/05, Mark Andrews wrote: > > >> What would happen if we dropped that commandment? Would things still > >> work? Would that get AAAA's into, okay, root-servers.net? > > > > Yes they would still work given that the servers can > > preferentually treat A additional records over AAAA additional > > records to help the broken systems. Note that the A > > records are all present but the AAAA records are not. > > [The local caching server has AAAA/A records for a number > > of the root servers pre-loaded.] > > So, why don't we see AAAA's for the root servers? I lulled myself > into believing it was the size constraint. > > Doesn't ($implementation=) BIND treat AAAA's as preferential? I ask > because I am not sure what you mean by preferential treatment. Do > you mean prefer to include A's over AAAA's? (As opposed to trying > the AAAA before the A for the server.) I mean prefer adding A records to the additional section over AAAA records. Most nameservers that make/accept queries over IPv6 also support EDNS. Note preferential treatment is a implementation specific behaviour. > > Adding AAAA records for the roots while definitely causing > > the answer to exceed 512 bytes should not trigger fragmentation. > > > ... > >;; ADDITIONAL SECTION: > ... > >B.ROOT-SERVERS.NET. 1H IN AAAA 2001:478:65::53 > >F.ROOT-SERVERS.NET. 1H IN AAAA 2001:500::1035 > >H.ROOT-SERVERS.NET. 1H IN AAAA 2001:500:1::803f:235 > >K.ROOT-SERVERS.NET. 1H IN AAAA 2001:7fd::1 > >M.ROOT-SERVERS.NET. 1H IN AAAA 2001:dc3::35 > >; EDNS: version: 0, udp=1460, flags=8000 > > I don't see these records when querying... > > sh-2.05b$ for i in a b c d e f g h i j k l m; \ > do dig $i.root-servers.net aaaa +short; \ > done > sh-2.05b$ > > It's late here, maybe I have a typo in my dig, but I can't find > AAAA's for the roots. http://www.root-servers.org/ will give you the IPv6 addresses of the root servers. It's easy enough to create zones for each of the root servers that has a IPv6 address to test IPv6 support. zone "f.root-servers.net" { type master; file "master/f.root-servers.net"; notify no; allow-query { localhost; }; }; master/f.root-servers.net: @ 3600 IN SOA drugs.dv.isc.org. marka.isc.org. 1 3600 1200 604800 3600 @ 3600 IN NS drugs.dv.isc.org. @ 3600 IN A 192.5.5.241 @ 3600 IN AAAA 2001:500::1035 > If there's no problem with AAAA's and message size, then I can see > that EDNS0 is not an issue for AAAA's. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > 3 months to the next trip. I guess it's finally time to settle down and > find a grocery store. -- 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 15 04:38:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbxGq-0006mF-JM for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 04:38:33 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13737 for ; Tue, 15 Nov 2005 04:37:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EbxDE-0002oF-G0 for namedroppers-data@psg.com; Tue, 15 Nov 2005 09:34:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [192.36.250.140] (helo=rasmus.kthnoc.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EbxDD-0002o1-Cq for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 09:34:47 +0000 Received: from localhost (localhost [127.0.0.1]) by rasmus.kthnoc.net (Postfix) with ESMTP id CC39ED5583; Tue, 15 Nov 2005 10:34:43 +0100 (CET) Date: Tue, 15 Nov 2005 09:14:08 +0100 From: =?UTF-8?Q?M=C3=A5ns_Nilsson?= To: bert hubert , Samuel Weiler Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEC explanation, comments? Message-ID: <19FFD18C5C2E4ABAF6461E8B@E3993D2B0BE66833664712A4> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========D5FFA6F6B0D1539E1C4B==========" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --==========D5FFA6F6B0D1539E1C4B========== Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On den 13 oktober 2005 23.32.33 +0200 bert hubert wrote: > I've queried for real .se delegations but short of asking here or > bothering the .se administrators nobody could point me to a real DS > record 'in the wild'. But I'm very interested. such records should appear any in SE time now; testing with signed delegations is to commence 2nd half November.=20 --=20 M=C3=A5ns Nilsson Systems Specialist +46 70 681 7204 cell KTHNOC +46 8 790 6518 office MN1334-RIPE I joined scientology at a garage sale!! --==========D5FFA6F6B0D1539E1C4B========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDeZjQ02/pMZDM1cURAm/AAJ9Olp0zP3bWe6lDkysmA3n9xHKylACdHX+z BRzLrftlkV/fR1Ss0Yd3YLQ= =FHRk -----END PGP SIGNATURE----- --==========D5FFA6F6B0D1539E1C4B==========-- -- to unsubscribe send a message to namedroppers-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 15 08:57:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec1JI-0006BY-35 for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 08:57:22 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25479 for ; Tue, 15 Nov 2005 08:56:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ec1FD-000Hh2-5A for namedroppers-data@psg.com; Tue, 15 Nov 2005 13:53:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1Ec1FC-000Hgp-2S for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 13:53:06 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jAFDqq601470; Tue, 15 Nov 2005 15:52:53 +0200 Date: Tue, 15 Nov 2005 15:52:52 +0200 (EET) From: Pekka Savola To: Edward Lewis cc: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson_=2FDNSEXT__co=2Dchair?= , namedroppers@ops.ietf.org Subject: Re: Advancing AAAA to Full standard ? In-Reply-To: Message-ID: References: <6.2.5.6.2.20051114093206.02eb3a10@ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 14 Nov 2005, Edward Lewis wrote: > Still - I would like to hear about whether we ought to require EDNS0, > recommending a minimum acceptable response size. We can't require it without a normative reference, and EDNS0 isn't full standard grade yet. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-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 15 08:57:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec1JJ-0006BZ-4F for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 08:57:24 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25485 for ; Tue, 15 Nov 2005 08:56:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ec1Hf-000Hs6-Gr for namedroppers-data@psg.com; Tue, 15 Nov 2005 13:55:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Ec1Hc-000Hqw-Vx for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 13:55:37 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jAFDtEga002018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Nov 2005 14:55:15 +0100 From: Simon Josefsson To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051115:roy@dnss.ec::zETKVbQ8jXOYI/Gl:4cmm X-Hashcash: 1:21:051115:namedroppers@ops.ietf.org::TNnTUJNXJBhXXOxx:2Yl6 Date: Tue, 15 Nov 2005 14:55:05 +0100 In-Reply-To: (Roy Arends's message of "Sat, 22 Oct 2005 19:59:02 +0200 (W. Europe Daylight Time)") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends writes: > On Sat, 22 Oct 2005, Simon Josefsson wrote: > >> Roy Arends writes: >> >>> There exist multiple base32 alphabets. The two mostly used are >>> "A-Z2-7" (examples in rfc3548) and "0-9A-V" (examples in rfc2938). >> >> We could update RFC 3548 to add an alternative base32 alphabet, to >> handle this problem. I have some other pending nits to that document, >> available from . > > That would be a good thing. I have submitted the draft, and it has been published (see below). Are there any base-* considerations that you need for NSEC3 that isn't in the document? Any other suggestions? If not, I'll ask the RFC Editor to publish it. Thanks, Simon > Title : The Base16, Base32, and Base64 Data Encodings > > This document describes the commonly used base 64, base 32, and base > 16 encoding schemes. It also discusses the use of line-feeds in > encoded data, use of padding in encoded data, use of non-alphabet > characters in encoded data, and use of different encoding alphabets. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-josefsson-rfc3548bis-00.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 15 09:07:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec1T0-0008Ji-58 for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 09:07:23 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26125 for ; Tue, 15 Nov 2005 09:06:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ec1QP-000IWS-SA for namedroppers-data@psg.com; Tue, 15 Nov 2005 14:04:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Ec1QP-000IWG-1O for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 14:04:41 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAFE4RsA067664; Tue, 15 Nov 2005 09:04:28 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200511150556.jAF5uD3Q020616@drugs.dv.isc.org> References: <200511150556.jAF5uD3Q020616@drugs.dv.isc.org> Date: Tue, 15 Nov 2005 09:04:29 -0500 To: Mark Andrews From: Edward Lewis Subject: Re: Advancing AAAA to Full standard ? Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:56 +1100 11/15/05, Mark Andrews wrote: > > http://www.root-servers.org/ will give you the IPv6 addresses > of the root servers. It's easy enough to create zones for > each of the root servers that has a IPv6 address to test > IPv6 support. > >zone "f.root-servers.net" { ... I appreciate the work around and the engineering coolness associated with it but when it comes to an operational environment configured data is to be avoided. Why, if message size isn't the issue, are there no AAAA resource records for the roots in DNS? I thought the issue was message size. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-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 15 09:13:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec1Yx-0001PY-Hx for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 09:13:31 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26416 for ; Tue, 15 Nov 2005 09:12:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ec1WL-000J0b-Tc for namedroppers-data@psg.com; Tue, 15 Nov 2005 14:10:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.169.16.30] (helo=exchangebe.corporate.telin.nl) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1Ec1WG-000J0I-8O for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 14:10:44 +0000 Received: from netinfo.corporate.telin.nl ([195.169.16.63]) by exchangebe.corporate.telin.nl with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Nov 2005 15:10:42 +0100 Date: Tue, 15 Nov 2005 15:10:42 +0100 (CET) From: Roy Arends X-X-Sender: roy@netinfo.corporate.telin.nl To: Simon Josefsson cc: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 15 Nov 2005 14:10:42.0507 (UTC) FILETIME=[5D3379B0:01C5E9EE] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 15 Nov 2005, Simon Josefsson wrote: > I have submitted the draft, and it has been published (see below). > > Are there any base-* considerations that you need for NSEC3 that isn't > in the document? Any other suggestions? If not, I'll ask the RFC > Editor to publish it. Not that I can think of, though I suggest to rewrite the ambiguous "zero bits are added" into "bits with value zero are added" (which appears twice in the document). Thanks, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 15 09:26:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec1lL-00054y-AC for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 09:26:19 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27297 for ; Tue, 15 Nov 2005 09:25:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ec1ht-000JwY-Vn for namedroppers-data@psg.com; Tue, 15 Nov 2005 14:22:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Ec1ht-000JwD-2h for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 14:22:45 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jAFEMekK005619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Nov 2005 15:22:41 +0100 From: Simon Josefsson To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051115:roy@dnss.ec::lFcoi0irPD/3/ESO:0lbE X-Hashcash: 1:21:051115:namedroppers@ops.ietf.org::8/p7xfSk6FIgRK7R:6OZp Date: Tue, 15 Nov 2005 15:22:32 +0100 In-Reply-To: (Roy Arends's message of "Tue, 15 Nov 2005 15:10:42 +0100 (CET)") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends writes: > On Tue, 15 Nov 2005, Simon Josefsson wrote: > >> I have submitted the draft, and it has been published (see below). >> >> Are there any base-* considerations that you need for NSEC3 that isn't >> in the document? Any other suggestions? If not, I'll ask the RFC >> Editor to publish it. > > Not that I can think of, though I suggest to rewrite the ambiguous > "zero bits are added" into "bits with value zero are added" (which > appears twice in the document). Fixed in my local copy, thanks. Btw, the live version can be tracked through: http://josefsson.org/base-encoding/ Regards, Simon -- to unsubscribe send a message to namedroppers-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 15 09:53:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec2BC-0005Ul-Ox for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 09:53:03 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28809 for ; Tue, 15 Nov 2005 09:52:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ec28k-000LqA-EL for namedroppers-data@psg.com; Tue, 15 Nov 2005 14:50:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Ec28j-000Lpx-DA for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 14:50:29 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id jAFEoK7b032750; Tue, 15 Nov 2005 14:50:20 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id jAFEoHBA032747; Tue, 15 Nov 2005 14:50:17 GMT Date: Tue, 15 Nov 2005 14:50:17 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Cc: Mark Andrews , namedroppers@ops.ietf.org Subject: Re: Advancing AAAA to Full standard ? Message-ID: <20051115145017.GE32533@vacation.karoshi.com.> References: <200511150556.jAF5uD3Q020616@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Nov 15, 2005 at 09:04:29AM -0500, Edward Lewis wrote: > At 16:56 +1100 11/15/05, Mark Andrews wrote: > > > > > http://www.root-servers.org/ will give you the IPv6 addresses > > of the root servers. It's easy enough to create zones for > > each of the root servers that has a IPv6 address to test > > IPv6 support. > > > >zone "f.root-servers.net" { > ... > > I appreciate the work around and the engineering coolness associated > with it but when it comes to an operational environment configured > data is to be avoided. Why, if message size isn't the issue, are > there no AAAA resource records for the roots in DNS? I thought the > issue was message size. message size is only one consideration. given the number of "legacy" IMRs running a variety of older software, consideration should be made for code that fails to comprend unknown RR types. or, we can just declare that such code is broken and we don't care if they stop working. (try that on for size ICANN!!!) > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > 3 months to the next trip. I guess it's finally time to settle down and > find a grocery store. > > -- > to 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 15 10:15:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec2Wo-0003IU-Eu for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 10:15:23 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29840 for ; Tue, 15 Nov 2005 10:14:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ec2Tm-000NON-0S for namedroppers-data@psg.com; Tue, 15 Nov 2005 15:12:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Ec2Ti-000NMt-Lb for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 15:12:10 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id CA6B133C1C; Tue, 15 Nov 2005 15:12:08 +0000 (GMT) Message-ID: <4379FACB.9070901@algroup.co.uk> Date: Tue, 15 Nov 2005 15:12:11 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Simon Josefsson CC: Roy Arends , namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Simon Josefsson wrote: > Roy Arends writes: > >> On Sat, 22 Oct 2005, Simon Josefsson wrote: >> >>> Roy Arends writes: >>> >>>> There exist multiple base32 alphabets. The two mostly used are >>>> "A-Z2-7" (examples in rfc3548) and "0-9A-V" (examples in rfc2938). >>> We could update RFC 3548 to add an alternative base32 alphabet, to >>> handle this problem. I have some other pending nits to that document, >>> available from . >> That would be a good thing. > > I have submitted the draft, and it has been published (see below). > > Are there any base-* considerations that you need for NSEC3 that isn't > in the document? Any other suggestions? If not, I'll ask the RFC > Editor to publish it. Yes, it should be case-blind. I was going to say that in the NSEC3 I-D, but far better if its in RFC3548bis. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 15 10:16:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec2Xn-0003UI-EA for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 10:16:23 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29866 for ; Tue, 15 Nov 2005 10:15:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ec2WX-000Naa-7X for namedroppers-data@psg.com; Tue, 15 Nov 2005 15:15:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Ec2WW-000NZL-E0 for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 15:15:04 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 52C6533C1C; Tue, 15 Nov 2005 15:15:00 +0000 (GMT) Message-ID: <4379FB76.5060706@algroup.co.uk> Date: Tue, 15 Nov 2005 15:15:02 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Roy Arends CC: Simon Josefsson , namedroppers@ops.ietf.org Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends wrote: > On Tue, 15 Nov 2005, Simon Josefsson wrote: > >> I have submitted the draft, and it has been published (see below). >> >> Are there any base-* considerations that you need for NSEC3 that isn't >> in the document? Any other suggestions? If not, I'll ask the RFC >> Editor to publish it. > > Not that I can think of, though I suggest to rewrite the ambiguous "zero > bits are added" into "bits with value zero are added" (which appears > twice in the document). Hmm. Can I be lazy and ask if it supports unpadded modes? If not, can it? -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 15 10:44:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec2yk-0003AF-0f for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 10:44:14 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01390 for ; Tue, 15 Nov 2005 10:43:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ec2wo-000Pff-PX for namedroppers-data@psg.com; Tue, 15 Nov 2005 15:42:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Ec2wl-000PeW-Gt for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 15:42:11 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id jAFFg1g6012086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Nov 2005 16:42:02 +0100 From: Simon Josefsson To: Ben Laurie Cc: namedroppers@ops.ietf.org, Roy Arends Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 References: <4379FB76.5060706@algroup.co.uk> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051115:ben@algroup.co.uk::W8r9J7G8xnDar7Sk:0GW X-Hashcash: 1:21:051115:namedroppers@ops.ietf.org::NAotL58/NJL27w1i:37mo X-Hashcash: 1:21:051115:roy@dnss.ec::hhrKsWBtxexosIiH:BjMN Date: Tue, 15 Nov 2005 16:41:52 +0100 In-Reply-To: <4379FB76.5060706@algroup.co.uk> (Ben Laurie's message of "Tue, 15 Nov 2005 15:15:02 +0000") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben Laurie writes: > Roy Arends wrote: >> On Tue, 15 Nov 2005, Simon Josefsson wrote: >> >>> I have submitted the draft, and it has been published (see below). >>> >>> Are there any base-* considerations that you need for NSEC3 that isn't >>> in the document? Any other suggestions? If not, I'll ask the RFC >>> Editor to publish it. >> Not that I can think of, though I suggest to rewrite the ambiguous >> "zero bits are added" into "bits with value zero are added" (which >> appears twice in the document). > > Hmm. Can I be lazy and ask if it supports unpadded modes? If not, can it? They aren't discussed. I need them in the SASL GS2-* mechanism as well (seems I ended up as co-author on that..), so adding a section on that seem appropriate. I have added it to the todo list. Thanks, Simon -- to unsubscribe send a message to namedroppers-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 15 10:52:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec371-0006CS-IZ for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 10:52:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02127 for ; Tue, 15 Nov 2005 10:52:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ec35X-0000Sr-1X for namedroppers-data@psg.com; Tue, 15 Nov 2005 15:51:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Ec35V-0000RI-PX for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 15:51:14 +0000 Received: from [10.31.32.115] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAFFp242068145; Tue, 15 Nov 2005 10:51:03 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20051115145017.GE32533@vacation.karoshi.com.> References: <200511150556.jAF5uD3Q020616@drugs.dv.isc.org> <20051115145017.GE32533@vacation.karoshi.com.> Date: Tue, 15 Nov 2005 10:51:04 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Advancing AAAA to Full standard ? Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 14:50 +0000 11/15/05, bmanning@vacation.karoshi.com wrote: > message size is only one consideration. given the number of > "legacy" IMRs running a variety of older software, consideration > should be made for code that fails to comprend unknown RR types. > or, we can just declare that such code is broken and we don't care > if they stop working. (try that on for size ICANN!!!) What's an IMR? I learned of IMP's in my History of the Internet course, but not IMR. ;) What is the problem if the AAAA is not understood? Is the implication that this software just stops working? The old software will likely also be unable to make use of an IPv6 address even if it recognized it. As someone said in the hallway last month, some bad ideas will cause "broken things to stop working." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-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 15 11:37:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec3oL-0006Gu-Fr for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 11:37:33 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06559 for ; Tue, 15 Nov 2005 11:36:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ec3lv-0003Yx-VC for namedroppers-data@psg.com; Tue, 15 Nov 2005 16:35:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Ec3lv-0003Yh-Bq for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 16:35:03 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id jAFGZ27b000803; Tue, 15 Nov 2005 16:35:02 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id jAFGZ177000799; Tue, 15 Nov 2005 16:35:01 GMT Date: Tue, 15 Nov 2005 16:35:01 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: Advancing AAAA to Full standard ? Message-ID: <20051115163501.GD621@vacation.karoshi.com.> References: <200511150556.jAF5uD3Q020616@drugs.dv.isc.org> <20051115145017.GE32533@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Nov 15, 2005 at 10:51:04AM -0500, Edward Lewis wrote: > At 14:50 +0000 11/15/05, bmanning@vacation.karoshi.com wrote: > > > message size is only one consideration. given the number of > > "legacy" IMRs running a variety of older software, consideration > > should be made for code that fails to comprend unknown RR types. > > or, we can just declare that such code is broken and we don't care > > if they stop working. (try that on for size ICANN!!!) > > What's an IMR? I learned of IMP's in my History of the Internet > course, but not IMR. ;) read the list archives... :) Iterative Mode Resolver ... or in depricated parlance, caching server > What is the problem if the AAAA is not understood? Is the > implication that this software just stops working? The old software > will likely also be unable to make use of an IPv6 address even if it > recognized it. perhaps the best examples are documented in an upcoming SAINT paper. the failures range from failure to continue processing to returning A data instead of the AAAA data. > As someone said in the hallway last month, some bad ideas will cause > "broken things to stop working." yup, but there is something to be said for stability. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > 3 months to the next trip. I guess it's finally time to settle down and > find a grocery store. > > -- > to 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 15 14:44:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec6j8-0004NL-V8 for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 14:44:25 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21820 for ; Tue, 15 Nov 2005 14:43:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ec6cp-000HQT-Do for namedroppers-data@psg.com; Tue, 15 Nov 2005 19:37:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Ec6co-000HPp-KP for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 19:37:50 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id ABEBB11426 for ; Tue, 15 Nov 2005 19:37:49 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Advancing AAAA to Full standard ? In-Reply-To: Your message of "Tue, 15 Nov 2005 15:52:52 +0200." References: <6.2.5.6.2.20051114093206.02eb3a10@ogud.com> Date: Tue, 15 Nov 2005 19:37:49 +0000 Message-Id: <20051115193749.ABEBB11426@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # EDNS0 isn't full standard grade yet. suggestions welcomed? -- to unsubscribe send a message to namedroppers-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 15 15:44:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7eo-0008J1-LR for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 15:44:00 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24922 for ; Tue, 15 Nov 2005 15:43:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ec7a8-000Q0V-7y for namedroppers-data@psg.com; Tue, 15 Nov 2005 20:39:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,UPPERCASE_25_50 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Ec7a5-000Q06-7e for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 20:39:05 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 0F7DF677F9 for ; Tue, 15 Nov 2005 20:39:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id jAFKcpnS018490; Wed, 16 Nov 2005 07:38:51 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200511152038.jAFKcpnS018490@drugs.dv.isc.org> To: bmanning@vacation.karoshi.com Cc: Edward Lewis , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Advancing AAAA to Full standard ? In-reply-to: Your message of "Tue, 15 Nov 2005 14:50:17 -0000." <20051115145017.GE32533@vacation.karoshi.com.> Date: Wed, 16 Nov 2005 07:38:51 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Tue, Nov 15, 2005 at 09:04:29AM -0500, Edward Lewis wrote: > > At 16:56 +1100 11/15/05, Mark Andrews wrote: > > > > > > > > http://www.root-servers.org/ will give you the IPv6 addresses > > > of the root servers. It's easy enough to create zones for > > > each of the root servers that has a IPv6 address to test > > > IPv6 support. > > > > > >zone "f.root-servers.net" { > > ... > > > > I appreciate the work around and the engineering coolness associated > > with it but when it comes to an operational environment configured > > data is to be avoided. Why, if message size isn't the issue, are > > there no AAAA resource records for the roots in DNS? I thought the > > issue was message size. > > message size is only one consideration. given the number of > "legacy" IMRs running a variety of older software, consideration > should be made for code that fails to comprend unknown RR types. > or, we can just declare that such code is broken and we don't care > if they stop working. (try that on for size ICANN!!!) You mean all those nameservers which will break when they recieve AAAA record in response to a ./NS query but also do not break when handed a referral to the COM/NET/SE/FR servers and whatever other TLD with nameservers answering on IPv6. AAAA has been it the wild for many years now. The only place in the DNS heirachy that it is not returned is with non-delegation answers from the root. ; <<>> DiG 8.3 <<>> soa com @a.root-servers.net ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15018 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 15 ;; QUERY SECTION: ;; com, type = SOA, class = IN ;; AUTHORITY SECTION: com. 2D IN NS A.GTLD-SERVERS.NET. com. 2D IN NS G.GTLD-SERVERS.NET. com. 2D IN NS H.GTLD-SERVERS.NET. com. 2D IN NS C.GTLD-SERVERS.NET. com. 2D IN NS I.GTLD-SERVERS.NET. com. 2D IN NS B.GTLD-SERVERS.NET. com. 2D IN NS D.GTLD-SERVERS.NET. com. 2D IN NS L.GTLD-SERVERS.NET. com. 2D IN NS F.GTLD-SERVERS.NET. com. 2D IN NS J.GTLD-SERVERS.NET. com. 2D IN NS K.GTLD-SERVERS.NET. com. 2D IN NS E.GTLD-SERVERS.NET. com. 2D IN NS M.GTLD-SERVERS.NET. ;; ADDITIONAL SECTION: A.GTLD-SERVERS.NET. 2D IN AAAA 2001:503:a83e::2:30 A.GTLD-SERVERS.NET. 2D IN A 192.5.6.30 G.GTLD-SERVERS.NET. 2D IN A 192.42.93.30 H.GTLD-SERVERS.NET. 2D IN A 192.54.112.30 C.GTLD-SERVERS.NET. 2D IN A 192.26.92.30 I.GTLD-SERVERS.NET. 2D IN A 192.43.172.30 B.GTLD-SERVERS.NET. 2D IN AAAA 2001:503:231d::2:30 B.GTLD-SERVERS.NET. 2D IN A 192.33.14.30 D.GTLD-SERVERS.NET. 2D IN A 192.31.80.30 L.GTLD-SERVERS.NET. 2D IN A 192.41.162.30 F.GTLD-SERVERS.NET. 2D IN A 192.35.51.30 J.GTLD-SERVERS.NET. 2D IN A 192.48.79.30 K.GTLD-SERVERS.NET. 2D IN A 192.52.178.30 E.GTLD-SERVERS.NET. 2D IN A 192.12.94.30 M.GTLD-SERVERS.NET. 2D IN A 192.55.83.30 ;; Total query time: 232 msec ;; FROM: drugs.dv.isc.org to SERVER: 198.41.0.4 ;; WHEN: Wed Nov 16 07:26:04 2005 ;; MSG SIZE sent: 21 rcvd: 509 > > > > -- > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > Edward Lewis +1-571-434-5468 > > NeuStar > > > > 3 months to the next trip. I guess it's finally time to settle down and > > find a grocery store. > > > > -- > > to 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 15 18:11:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec9xo-0000yt-Vz for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 18:11:45 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04354 for ; Tue, 15 Nov 2005 18:11:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1Ec9tA-000I0E-LN for namedroppers-data@psg.com; Tue, 15 Nov 2005 23:06:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06 autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1Ec9t9-000Hzu-Hb for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 23:06:55 +0000 Received: from [10.0.1.2] (unknown [192.0.35.62]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id ABD7356884; Tue, 15 Nov 2005 15:06:54 -0800 (PST) (envelope-from david.conrad@nominum.com) In-Reply-To: <20051115163501.GD621@vacation.karoshi.com.> References: <200511150556.jAF5uD3Q020616@drugs.dv.isc.org> <20051115145017.GE32533@vacation.karoshi.com.> <20051115163501.GD621@vacation.karoshi.com.> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <13035DDD-6DCB-4F17-9D42-BC8B810A621F@nominum.com> Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: Advancing AAAA to Full standard ? Date: Tue, 15 Nov 2005 10:13:21 -0800 To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bill, On Nov 15, 2005, at 8:35 AM, bmanning@vacation.karoshi.com wrote: >> As someone said in the hallway last month, some bad ideas will cause >> "broken things to stop working." > yup, but there is something to be said for stability. Seems to me there is a fairly binary choice: 0) Add to the root zone and risk breaking things. 1) Don't add to the root zone and get stuck in the eighties. I didn't particularly like the 80's myself, but I'm sure that's just me. It is too bad that the politics of the DNS world don't allow the existence of multiple DNS infrastructures implementing the same DNS content (e.g., a different set of root hints that reflected servers that supported , leaving the "classic" root hints pointing to servers that don't support ). Ah well, I'm sure the ISPs around the world will be happy when their customers call them asking why DNS answers are ... different. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From tpaigo@astec2.com Tue Nov 15 18:44:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcAT8-00031y-T6 for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 18:44:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07233 for ; Tue, 15 Nov 2005 18:43:32 -0500 (EST) Received: from cpe-70-123-183-171.stx.res.rr.com ([70.123.183.171] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EcAkQ-0000Du-Cw for dnsext-archive@ietf.org; Tue, 15 Nov 2005 19:02:00 -0500 Message-ID: <000001c5ea3d$6f3b7780$0100007f@localhost> From: "Jayson Thomas" To: Subject: Three Steps to the Software You Need at the Prices You Want Date: Tue, 15 Nov 2005 17:43:45 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5EA3D.6F3B7780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5EA3D.6F3B7780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5EA3D.6F3B7780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES
Norton Antivirus 2005

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT downlo! ad!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 34 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 42 ! reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 49 reviews)

------=_NextPart_000_0001_01C5EA3D.6F3B7780-- From owner-namedroppers@ops.ietf.org Tue Nov 15 18:58:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcAhO-0006D2-Ii for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 18:58:50 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08956 for ; Tue, 15 Nov 2005 18:58:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcAe6-000NVe-SY for namedroppers-data@psg.com; Tue, 15 Nov 2005 23:55:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EcAe5-000NVS-LS for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 23:55:25 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id jAFNtN7b002696; Tue, 15 Nov 2005 23:55:23 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id jAFNtMDe002693; Tue, 15 Nov 2005 23:55:22 GMT Date: Tue, 15 Nov 2005 23:55:22 +0000 From: bmanning@vacation.karoshi.com To: David Conrad Cc: bmanning@vacation.karoshi.com, Edward Lewis , namedroppers@ops.ietf.org Subject: Re: Advancing AAAA to Full standard ? Message-ID: <20051115235522.GB2519@vacation.karoshi.com.> References: <200511150556.jAF5uD3Q020616@drugs.dv.isc.org> <20051115145017.GE32533@vacation.karoshi.com.> <20051115163501.GD621@vacation.karoshi.com.> <13035DDD-6DCB-4F17-9D42-BC8B810A621F@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13035DDD-6DCB-4F17-9D42-BC8B810A621F@nominum.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Nov 15, 2005 at 10:13:21AM -0800, David Conrad wrote: > Bill, > > On Nov 15, 2005, at 8:35 AM, bmanning@vacation.karoshi.com wrote: > >>As someone said in the hallway last month, some bad ideas will cause > >>"broken things to stop working." > > yup, but there is something to be said for stability. > > Seems to me there is a fairly binary choice: > > 0) Add to the root zone and risk breaking things. > 1) Don't add to the root zone and get stuck in the > eighties. > > I didn't particularly like the 80's myself, but I'm sure that's just me. had to give up polyester and chest hair... the mores the pity. > It is too bad that the politics of the DNS world don't allow the > existence of multiple DNS infrastructures implementing the same DNS > content (e.g., a different set of root hints that reflected servers > that supported , leaving the "classic" root hints > pointing to servers that don't support ). Ah well, > I'm sure the ISPs around the world will be happy when their customers > call them asking why DNS answers are ... different. change invites disaster, to some anyway. the concerns, as i understand them are: how much damage and can any of it be pre-empted by education and upgrades? so the question becomes not so much binary by analog... yes, we add new technology, but at what cost? > Rgds, > -drc -- bill (who recommends you get a hair cut and a real job) -- to unsubscribe send a message to namedroppers-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 15 19:21:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcB3j-0005wy-TJ for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 19:21:58 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14006 for ; Tue, 15 Nov 2005 19:21:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcB1I-0000BG-0C for namedroppers-data@psg.com; Wed, 16 Nov 2005 00:19:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [208.31.42.42] (helo=xuxa.iecc.com) by psg.com with smtp (Exim 4.52 (FreeBSD)) id 1EcB1H-0000Ao-1o for namedroppers@ops.ietf.org; Wed, 16 Nov 2005 00:19:23 +0000 Received: (qmail 16573 invoked by uid 100); 16 Nov 2005 00:19:22 -0000 Date: 16 Nov 2005 00:19:22 -0000 Message-ID: <20051116001922.16572.qmail@xuxa.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: Advancing AAAA to Full standard ? In-Reply-To: <20051115193749.ABEBB11426@sa.vix.com> Organization: I.E.C.C., Trumansburg NY USA Cc: paul@vix.com Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ># EDNS0 isn't full standard grade yet. > >suggestions welcomed? I've seen plausible complaints saying that EDNS0 still causes operational problems because of the funky things that non-EDNS0 servers do when presented with a EDNS0 request. If you're lucky, they'll reject it, but some return odd responses, and some just ignore it, leading to a lot of potential extra traffic due to retries before falling back. I haven't tried it myself, so I'd be interested to hear what people's actual EDNS0 experience is. R's, 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 Tue Nov 15 20:11:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcBpf-0005bH-D9 for dnsext-archive@megatron.ietf.org; Tue, 15 Nov 2005 20:11:27 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16625 for ; Tue, 15 Nov 2005 20:10:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcBmX-0004ug-KL for namedroppers-data@psg.com; Wed, 16 Nov 2005 01:08:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EcBmW-0004uM-Vt for namedroppers@ops.ietf.org; Wed, 16 Nov 2005 01:08:13 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id F3B3B677F9 for ; Wed, 16 Nov 2005 01:08:11 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id jAG18677026442 for ; Wed, 16 Nov 2005 12:08:07 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200511160108.jAG18677026442@drugs.dv.isc.org> Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Advancing AAAA to Full standard ? In-reply-to: Your message of "16 Nov 2005 00:19:22 -0000." <20051116001922.16572.qmail@xuxa.iecc.com> Date: Wed, 16 Nov 2005 12:08:06 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ># EDNS0 isn't full standard grade yet. > > > >suggestions welcomed? > > I've seen plausible complaints saying that EDNS0 still causes > operational problems because of the funky things that non-EDNS0 > servers do when presented with a EDNS0 request. If you're lucky, > they'll reject it, but some return odd responses, and some just ignore > it, leading to a lot of potential extra traffic due to retries before > falling back. > > I haven't tried it myself, so I'd be interested to hear what people's > actual EDNS0 experience is. > > R's, > John EDNS is basically a non-issue these days. +70% of the worlds nameservers talk EDNS. Of the others the majority are RFC 1034 / RFC 1035 compliant and send a error code. There really is only a handful of servers that get this wrong these days though one major vendor decided to implement a 60 second holddown on sending error responses. The problem is with middleware that drops packets they can't completely decode. Note: most middleware now handles EDNS though some boxes block EDNS w/ DO set. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 16 01:39:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcGwc-0002VM-Qk for dnsext-archive@megatron.ietf.org; Wed, 16 Nov 2005 01:39:01 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03623 for ; Wed, 16 Nov 2005 01:38:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcGsY-000DF9-1G for namedroppers-data@psg.com; Wed, 16 Nov 2005 06:34:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcGsW-000DEo-Vz for namedroppers@ops.ietf.org; Wed, 16 Nov 2005 06:34:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jAG6YQt21113; Wed, 16 Nov 2005 08:34:27 +0200 Date: Wed, 16 Nov 2005 08:34:26 +0200 (EET) From: Pekka Savola To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: Advancing AAAA to Full standard ? In-Reply-To: <20051115193749.ABEBB11426@sa.vix.com> Message-ID: References: <6.2.5.6.2.20051114093206.02eb3a10@ogud.com> <20051115193749.ABEBB11426@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 15 Nov 2005, Paul Vixie wrote: > # EDNS0 isn't full standard grade yet. > > suggestions welcomed? Get it enabled by default on stub resolvers so we get some actual operational experience, and get it to Draft Standard first. If stub resolvers {can't,won't} turn it on by default, that's a pretty strong indication that something might not work as well as hoped. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-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 16 02:26:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcHgK-0005tC-AN for dnsext-archive@megatron.ietf.org; Wed, 16 Nov 2005 02:26:12 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05530 for ; Wed, 16 Nov 2005 02:25:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcHeN-000Jc6-7o for namedroppers-data@psg.com; Wed, 16 Nov 2005 07:24:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcHeM-000Jbc-C3 for namedroppers@ops.ietf.org; Wed, 16 Nov 2005 07:24:10 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jAG7NwS22401; Wed, 16 Nov 2005 09:23:58 +0200 Date: Wed, 16 Nov 2005 09:23:58 +0200 (EET) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: Advancing AAAA to Full standard ? In-Reply-To: Message-ID: References: <6.2.5.6.2.20051114093206.02eb3a10@ogud.com> <20051115193749.ABEBB11426@sa.vix.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-714541615-1132125838=:22363" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-714541615-1132125838=:22363 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA05530 On Wed, 16 Nov 2005, JINMEI Tatuya / =BF=C0=CC=C0=C3=A3=BA=C8 wrote: > >> Get it enabled by default on stub resolvers so we get some actual >> operational experience, and get it to Draft Standard first. > > I don't think we need to force stub resolvers to turn on EDNS0 by > default in order to advance the EDNS0 spec to Draft Standard. Today > many of recursive resolvers turn it on by default (there are at least > two different implementations), and I personally believe operational > experiences with these recursive resolvers should provide enough > information to decide whether it's matured for DS. Agreed, I was not clear enough: on stubs is not (IMHO) a strict=20 requirement for DS, but it's IMHO a requirement for Full Standard. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --1589707168-714541615-1132125838=3D:22363-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: --1589707168-714541615-1132125838=:22363-- From owner-namedroppers@ops.ietf.org Wed Nov 16 10:01:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcOnI-0004Il-Ef for dnsext-archive@megatron.ietf.org; Wed, 16 Nov 2005 10:01:52 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02300 for ; Wed, 16 Nov 2005 10:01:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcOjJ-0005ai-Bi for namedroppers-data@psg.com; Wed, 16 Nov 2005 14:57:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EcOjI-0005aP-8U for namedroppers@ops.ietf.org; Wed, 16 Nov 2005 14:57:44 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAGEvP4v074320; Wed, 16 Nov 2005 09:57:26 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200511160108.jAG18677026442@drugs.dv.isc.org> References: <200511160108.jAG18677026442@drugs.dv.isc.org> Date: Wed, 16 Nov 2005 09:57:30 -0500 To: Mark Andrews From: Edward Lewis Subject: EDNS0, was Re: Advancing AAAA to Full standard ? Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:08 +1100 11/16/05, Mark Andrews wrote: > EDNS is basically a non-issue these days. +70% of the > worlds nameservers talk EDNS. Of the others the majority > are RFC 1034 / RFC 1035 compliant and send a error code. With almost 1 out of 3 not talking EDNS0, I'd say it's an issue. ;) (Funny how you can twist statistics - IOW "if your two neighbors are speaking EDNS0, you are probably not.") But perhaps not an issue in the way you mean. > There really is only a handful of servers that get this > wrong these days though one major vendor decided to implement > a 60 second holddown on sending error responses. > > The problem is with middleware that drops packets they can't > completely decode. Note: most middleware now handles EDNS > though some boxes block EDNS w/ DO set. Well, moving EDNS0 (or rather the RFC that documents it) from Proposed to Draft (and then Full) won't wreck the world of code. Moving along the standards track on one hand is just an IETF procedural matter, and on the other hand is just an IETF procedural matter. Being a procedural matter, it doesn't change reality. It's good for the WG to begin to exercise this process, to give some weight to the work that has been done over the past decade. This is all about formally documenting what we've done, something a mature organization does. On the other hand, being a procedural matter, it's only as important as the weight given to the procedures. A lot of the IETF standards consuming world confuses RFC with standard (the IETF editor not highlighting the STD track on their home page isn't helping in this regard). Moreover, the difference between Proposed, Draft, and Full are not clear. Yes, they matter to the believers of the IETF, but the IETF apparently hasn't sold the consumers on the importance of the process. At least not well enough. One other thing I'll add. The thread started out on AAAA advancement to Full. Now we've spread to EDNS0. At some point the chairs ought to step back in and scope and time the work before we become a classroom full of unruly students wanting to reinvent everything all at once. So, let's focus on advancing one thing and publicizing the importance of the process, the reason for expending more resources to redocument what's already been done in both an RFC and in code. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-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 16 10:33:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcPHv-00032U-Bq for dnsext-archive@megatron.ietf.org; Wed, 16 Nov 2005 10:33:31 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03645 for ; Wed, 16 Nov 2005 10:32:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcPEQ-0007TL-Mz for namedroppers-data@psg.com; Wed, 16 Nov 2005 15:29:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EcPEP-0007T9-Ti for namedroppers@ops.ietf.org; Wed, 16 Nov 2005 15:29:54 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAGFTmTV074496 for ; Wed, 16 Nov 2005 10:29:48 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id jAGFTmur074495 for namedroppers@ops.ietf.org; Wed, 16 Nov 2005 10:29:48 -0500 (EST) (envelope-from namedroppers) Received: from [202.249.10.124] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcHrq-000Le1-4C for namedroppers@ops.ietf.org; Wed, 16 Nov 2005 07:38:06 +0000 Received: from impact.jinmei.org (unknown [3ffe:501:100f:1010:217e:36f4:7c93:c360]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 1C3B81521A; Wed, 16 Nov 2005 16:38:04 +0900 (JST) Date: Wed, 16 Nov 2005 16:37:47 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= /DNSEXT co-chair , namedroppers@ops.ietf.org Subject: Re: Advancing AAAA to Full standard ? In-Reply-To: <200511141440.jAEEeGSw035221@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] (I could not find the original message from the chair in my mail box, so I'm responding to this message) >>>>> On Mon, 14 Nov 2005 15:40:16 +0100, >>>>> Francis Dupont said: > In addition the chairs need at least 5 people to state support > for this action. > => I support! > What is needed for advancement is a report from Working Group that this > is a fully mature specification and is in use. I generally agree that the specification and implementations of AAAA are pretty mature. However, I believe we should note that there are also non-negligible numbers of implementations that do not process AAAA RRs correctly and cause troubles in the actual operation. RFC4074 describes some of such (authoritative server) implementations. We've also found some recursive servers/DNS proxies deployed in hotel Internet connectivity services do not handle AAAA correctly. I'm not sure whether the existence of these bad implementations can be a showstopper of this action, though. Perhaps advancing the spec to full standard can be a strong incentive for vendors to conform to the spec. But I'd like the community (= us) to be aware of the problems and then to decide the action. So my response to the proposed action is currently "support with a reservation". JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -- to unsubscribe send a message to namedroppers-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 16 10:37:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcPM0-0003Yl-Tm for dnsext-archive@megatron.ietf.org; Wed, 16 Nov 2005 10:37:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04234 for ; Wed, 16 Nov 2005 10:33:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcPDs-0007S5-Ky for namedroppers-data@psg.com; Wed, 16 Nov 2005 15:29:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EcPDr-0007RP-JF for namedroppers@ops.ietf.org; Wed, 16 Nov 2005 15:29:20 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAGFTCuK074480 for ; Wed, 16 Nov 2005 10:29:12 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id jAGFTC2I074479 for namedroppers@ops.ietf.org; Wed, 16 Nov 2005 10:29:12 -0500 (EST) (envelope-from namedroppers) Received: from [202.249.10.124] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcHat-000J9f-0C for namedroppers@ops.ietf.org; Wed, 16 Nov 2005 07:20:37 +0000 Received: from impact.jinmei.org (unknown [3ffe:501:100f:1010:217e:36f4:7c93:c360]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 1EB7F1525D; Wed, 16 Nov 2005 16:20:34 +0900 (JST) Date: Wed, 16 Nov 2005 16:20:17 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: Advancing AAAA to Full standard ? In-Reply-To: References: <6.2.5.6.2.20051114093206.02eb3a10@ogud.com> <20051115193749.ABEBB11426@sa.vix.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ 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 Wed, 16 Nov 2005 08:34:26 +0200 (EET), >>>>> Pekka Savola said: >> # EDNS0 isn't full standard grade yet. >> >> suggestions welcomed? > Get it enabled by default on stub resolvers so we get some actual > operational experience, and get it to Draft Standard first. I don't think we need to force stub resolvers to turn on EDNS0 by default in order to advance the EDNS0 spec to Draft Standard. Today many of recursive resolvers turn it on by default (there are at least two different implementations), and I personally believe operational experiences with these recursive resolvers should provide enough information to decide whether it's matured for DS. > If stub resolvers {can't,won't} turn it on by default, that's a pretty > strong indication that something might not work as well as hoped. In my understanding, stub resolvers simply don't have to turn it on by default, since they generally only get small responses (much smaller than 512 bytes). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -- to unsubscribe send a message to namedroppers-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 16 10:37:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcPM3-0003Yl-5L for dnsext-archive@megatron.ietf.org; Wed, 16 Nov 2005 10:37:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04007 for ; Wed, 16 Nov 2005 10:33:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcPE5-0007Si-Fw for namedroppers-data@psg.com; Wed, 16 Nov 2005 15:29:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EcPE4-0007ST-Lm for namedroppers@ops.ietf.org; Wed, 16 Nov 2005 15:29:33 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAGFTQHb074486 for ; Wed, 16 Nov 2005 10:29:26 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id jAGFTQ8V074485 for namedroppers@ops.ietf.org; Wed, 16 Nov 2005 10:29:26 -0500 (EST) (envelope-from namedroppers) Received: from [202.249.10.124] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EcHrq-000Le1-4C for namedroppers@ops.ietf.org; Wed, 16 Nov 2005 07:38:06 +0000 Received: from impact.jinmei.org (unknown [3ffe:501:100f:1010:217e:36f4:7c93:c360]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 1C3B81521A; Wed, 16 Nov 2005 16:38:04 +0900 (JST) Date: Wed, 16 Nov 2005 16:37:47 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= /DNSEXT co-chair , namedroppers@ops.ietf.org Subject: Re: Advancing AAAA to Full standard ? In-Reply-To: <200511141440.jAEEeGSw035221@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] (I could not find the original message from the chair in my mail box, so I'm responding to this message) >>>>> On Mon, 14 Nov 2005 15:40:16 +0100, >>>>> Francis Dupont said: > In addition the chairs need at least 5 people to state support > for this action. > => I support! > What is needed for advancement is a report from Working Group that this > is a fully mature specification and is in use. I generally agree that the specification and implementations of AAAA are pretty mature. However, I believe we should note that there are also non-negligible numbers of implementations that do not process AAAA RRs correctly and cause troubles in the actual operation. RFC4074 describes some of such (authoritative server) implementations. We've also found some recursive servers/DNS proxies deployed in hotel Internet connectivity services do not handle AAAA correctly. I'm not sure whether the existence of these bad implementations can be a showstopper of this action, though. Perhaps advancing the spec to full standard can be a strong incentive for vendors to conform to the spec. But I'd like the community (= us) to be aware of the problems and then to decide the action. So my response to the proposed action is currently "support with a reservation". JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -- to unsubscribe send a message to namedroppers-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 16 10:54:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcPcX-000819-ME for dnsext-archive@megatron.ietf.org; Wed, 16 Nov 2005 10:54:52 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05404 for ; Wed, 16 Nov 2005 10:54:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcPZe-0009Hl-2Y for namedroppers-data@psg.com; Wed, 16 Nov 2005 15:51:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EcPZa-0009HO-Ju for namedroppers@ops.ietf.org; Wed, 16 Nov 2005 15:51:47 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAGFpb8A074745 for ; Wed, 16 Nov 2005 10:51:37 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id jAGFpbxD074744 for namedroppers@ops.ietf.org; Wed, 16 Nov 2005 10:51:37 -0500 (EST) (envelope-from namedroppers) Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1Ec88x-00051s-U2 for namedroppers@ops.ietf.org; Tue, 15 Nov 2005 21:15:08 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id C9D1811D606; Tue, 15 Nov 2005 13:15:04 -0800 (PST) From: Wes Hardaker To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ds-sha256-00.txt Organization: Sparta References: Date: Tue, 15 Nov 2005 13:15:03 -0800 In-Reply-To: (Roy Arends's message of "Sun, 13 Nov 2005 16:02:14 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ 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 Sun, 13 Nov 2005 16:02:14 +0100, Roy Arends said: Roy> Good work. I'd like to see this advanced asap. Thanks, though the incentive came from Olafur and Olaf to be honest. They wanted someone to do it and I said I could have it done by the end of the plenary... (I submitted it shortly after the second one). Roy> However, I'd like to see (something like) the following text Roy> added in section 4 as a motivation for supporting both digest Roy> types for two years: Thats good looking starting text. I've added it and modified it slightly. Feed back appreciated: 4. Deployment Requirements If a validator does not support the SHA-256 digest type in an authenticated DS RR and no other RR exists in the DS RRset with a digest type that it supported, then the validator has no supported authentication path leading from the parent to the child. The resolver should treat this case as it would be the case of an authenticated NSEC RRset proving that no DS RRset exists, as described in [RFC4035], section 5.2. Because zone administrators can not control the deployment support of SHA-256 in deployed validators that may referencing any given zone, deployments SHOULD publish both SHA-1 and SHA-256 based DS records for 2 years from the publication date of this RFC (XXX: RFC Editor: Please insert the calculated date here). (I'm generally thinking that we should avoid document feature creep, and stick to the solid facts most of the time. Arguing for why this and why that can fill a document and most of the existing documents already cover this, so... But the above I think is very worth stating. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett -- to unsubscribe send a message to namedroppers-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 16 11:19:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcQ0O-0000cg-Vj for dnsext-archive@megatron.ietf.org; Wed, 16 Nov 2005 11:19:29 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07242 for ; Wed, 16 Nov 2005 11:18:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EcPxv-000B3F-Ns for namedroppers-data@psg.com; Wed, 16 Nov 2005 16:16:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1EcPxu-000B31-Sd for namedroppers@ops.ietf.org; Wed, 16 Nov 2005 16:16:55 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAGGGgkr074880; Wed, 16 Nov 2005 11:16:43 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 16 Nov 2005 11:16:47 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Advancing AAAA to Full standard ? Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:37 +0900 11/16/05, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >I generally agree that the specification and implementations of AAAA >are pretty mature. However, I believe we should note that there are >also non-negligible numbers of implementations that do not process >AAAA RRs correctly and cause troubles in the actual operation. The rules are set forth in RFC 2026 for standards elevation. In short: (4.1.2) A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. For the and (4.1.3) A specification for which significant implementation and successful operational experience has been obtained may be elevated to the Internet Standard level. An Internet Standard (which may simply be Neither says anything about "non-negligible numbers of implementations that do not process X correctly." This is rooted in the non-enforcement of IETF standards. I would say that AAAA's meet the Draft Standard criteria, excepting for the formal documentation of such. Not knowing first hand, I would say that the same holds true for Internet Standard. (Meaning, I don't do surveys of implementations.) I know that non-compliant implementations cause headaches. But the IETF only has purview over documents. Perhaps making the documents more worthwhile will drive the non-compliant implementations to be corrected, that needs an outreach effort from the IETF I think. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From EricaTyler@cencomp.com Wed Nov 16 11:32:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcQCj-0004gp-Jo for dnsext-archive@megatron.ietf.org; Wed, 16 Nov 2005 11:32:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08128 for ; Wed, 16 Nov 2005 11:31:38 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcQU6-0007fX-9u for dnsext-archive@ietf.org; Wed, 16 Nov 2005 11:50:14 -0500 Received: from 200165128180.user.veloxzone.com.br ([200.165.128.180]) by mx2.foretec.com with smtp (Exim 4.24) id 1EcQBb-0007EJ-HP for dnsext-archive@ietf.org; Wed, 16 Nov 2005 11:31:14 -0500 Received: from No3Q@localhost by Drs.int (8.11.6/8.11.6); Wed, 16 Nov 2005 22:06:01 +0500 Message-ID: From: "Kate Carmichael" Reply-To: "Kate Carmichael" To: dnsext-archive@ietf.org Subject: Finally, you can afford software by Adobe Windows & Adobe, Windows Date: Wed, 16 Nov 2005 13:00:01 -0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: EricaTyler@cencomp.com Content-Type: multipart/mixed; boundary="--Jfbv4rRBvZ9GB6VMxxls" X-Spam-Score: 0.3 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e 9G8a ----Jfbv4rRBvZ9GB6VMxxls Content-Type: text/html; Content-Transfer-Encoding: quoted-printable i
Opt-in Email Special Offer   = ;  unsubscribe me
= =
SEARCH

Microsoft Window= s XP Professional *w/SP2*
Microsoft

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

=
=  <= /tr>
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
 = ;2 Creative Suite 2
 3 MS Office 2003 Pro
 4 Adobe Acrobat 7 Pro
 <= /td>5 Macromedia Flash 8
 = 6 Dreamweaver 8
 7= Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
 = ;10 Borland Architect 2005
&= nbsp; See more by this manufacturer
   Microsoft
   Macromedia
  Ado= be
  Customers also b= ought
   these other items...

<= /p>

Choose:<= /b>
=  <= input type=3Dimage alt=3DGo src=3Dhttp://g-images.amazon.com/images/G/01/s= earch-browse/go-button-software.gif value=3DGo border=3D0 name=3Dsubmit.di= splay-variation width=3D21 height=3D21>
<= /tr>
List Price:$299.00
Price:$49.99
Y= ou Save:$249.01 (80%)


Availability: Available for INSTANT download= !
Coupon Code: p5qRSlk
Platform: Windows XP

Sales Rank: #1
System requirements  |  Other Versions
Date Cou= pon Expires: December 31st, 2005
Aver= age Customer Review:3D"5 Based on 11686 reviews. Write a review.

Adobe Creative Suite 2 *P= remium*
Adob= e

Choose:
 

List Price:$1199.00
Price:$149.99
You Save:$1049.01 (95%)



= Availability: Available for INSTANT download!
Coupon Code: c2AR0F
Platform: Windows XP

Sales Rank: #2=
System r= equirements  |  Other Vers= ions
Date Coupon Expires: Decembe= r 31st, 2005
Average Customer Review:= 3D"5 Based on 176254 reviews. Write = a review.

Microsoft Office 2003 *Profession= al*
Microsof= t

Choose:
 

<= /p><= /tr>
List Price:$499.00
Price:$69.99
Y= ou Save:$429.01 (85%)


Availability: Available for INSTANT download= !
Coupon Code: g9qxdDV
Platform: Windows XP

Sales Rank: #3
System requirements  |  Other Versions
Date Cou= pon Expires: December 31st, 2005
Aver= age Customer Review:3D"5 Based on 153227 reviews. Write a review.

Adobe Acro= bat Professional V 7.0
Adobe

Choose:
<= /td> 

List Price:<= /b>$499.00
Price:$69.99
You Save:$429.01 (85%)



= Availability: Available for INSTANT download!
Coupon Code: IuUKfj9
Platform: Windows XP

Sales Rank: #= 4
System = requirements  |  Other Ver= sions
Date Coupon Expires: Decemb= er 31st, 2005
Average Customer Review:3D"5 Based on 1342 reviews. Write a= review.

----Jfbv4rRBvZ9GB6VMxxls-- From EricaTyler@cencomp.com Wed Nov 16 11:33:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcQDh-0004qw-1S for dnsext-archive@megatron.ietf.org; Wed, 16 Nov 2005 11:33:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08203 for ; Wed, 16 Nov 2005 11:32:39 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcQV4-0007j1-VQ for dnsext-archive@ietf.org; Wed, 16 Nov 2005 11:51:16 -0500 Received: from [201.10.92.93] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1EcQDB-0007Xw-4t for dnsext-archive@ietf.org; Wed, 16 Nov 2005 11:32:44 -0500 Received: from No3Q@localhost by Drs.int (8.11.6/8.11.6); Wed, 16 Nov 2005 22:06:01 +0500 Message-ID: From: "Kate Carmichael" Reply-To: "Kate Carmichael" To: dnsext-archive@ietf.org Subject: Finally, you can afford software by Adobe Windows & Adobe, Windows Date: Wed, 16 Nov 2005 13:00:01 -0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: EricaTyler@cencomp.com Content-Type: multipart/mixed; boundary="--Jfbv4rRBvZ9GB6VMxxls" X-Spam-Score: 3.6 (+++) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e 9G8a ----Jfbv4rRBvZ9GB6VMxxls Content-Type: text/html; Content-Transfer-Encoding: quoted-printable i
Opt-in Email Special Offer   = ;  unsubscribe me
= =
SEARCH

Microsoft Window= s XP Professional *w/SP2*
Microsoft

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

=
=  <= /tr>
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
 = ;2 Creative Suite 2
 3 MS Office 2003 Pro
 4 Adobe Acrobat 7 Pro
 <= /td>5 Macromedia Flash 8
 = 6 Dreamweaver 8
 7= Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
 = ;10 Borland Architect 2005
&= nbsp; See more by this manufacturer
   Microsoft
   Macromedia
  Ado= be
  Customers also b= ought
   these other items...

<= /p>

Choose:<= /b>
=  <= input type=3Dimage alt=3DGo src=3Dhttp://g-images.amazon.com/images/G/01/s= earch-browse/go-button-software.gif value=3DGo border=3D0 name=3Dsubmit.di= splay-variation width=3D21 height=3D21>
<= /tr>
List Price:$299.00
Price:$49.99
Y= ou Save:$249.01 (80%)


Availability: Available for INSTANT download= !
Coupon Code: p5qRSlk
Platform: Windows XP

Sales Rank: #1
System requirements  |  Other Versions
Date Cou= pon Expires: December 31st, 2005
Aver= age Customer Review:3D"5 Based on 11686 reviews. Write a review.

Adobe Creative Suite 2 *P= remium*
Adob= e

Choose:
 

List Price:$1199.00
Price:$149.99
You Save:$1049.01 (95%)



= Availability: Available for INSTANT download!
Coupon Code: c2AR0F
Platform: Windows XP

Sales Rank: #2=
System r= equirements  |  Other Vers= ions
Date Coupon Expires: Decembe= r 31st, 2005
Average Customer Review:= 3D"5 Based on 176254 reviews. Write = a review.

Microsoft Office 2003 *Profession= al*
Microsof= t

Choose:
 

<= /p><= /tr>
List Price:$499.00
Price:$69.99
Y= ou Save:$429.01 (85%)


Availability: Available for INSTANT download= !
Coupon Code: g9qxdDV
Platform: Windows XP

Sales Rank: #3
System requirements  |  Other Versions
Date Cou= pon Expires: December 31st, 2005
Aver= age Customer Review:3D"5 Based on 153227 reviews. Write a review.

Adobe Acro= bat Professional V 7.0
Adobe

Choose:
<= /td> 

List Price:<= /b>$499.00
Price:$69.99
You Save:$429.01 (85%)



= Availability: Available for INSTANT download!
Coupon Code: IuUKfj9
Platform: Windows XP

Sales Rank: #= 4
System = requirements  |  Other Ver= sions
Date Coupon Expires: Decemb= er 31st, 2005
Average Customer Review:3D"5 Based on 1342 reviews. Write a= review.

----Jfbv4rRBvZ9GB6VMxxls-- From g.collum@19460.com Wed Nov 16 15:48:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcUCm-0003Mw-NT for dnsext-archive@megatron.ietf.org; Wed, 16 Nov 2005 15:48:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23312 for ; Wed, 16 Nov 2005 15:47:58 -0500 (EST) Received: from [201.30.83.147] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EcUU6-0008Pk-RM for dnsext-archive@ietf.org; Wed, 16 Nov 2005 16:06:37 -0500 Message-ID: <000001c5eaed$e4668580$0100007f@localhost> From: "Matthew Sanchez" To: Subject: Office 2003 Date: Wed, 16 Nov 2005 20:48:26 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5EAED.E4668580" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5EAED.E4668580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 33 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 36 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5EAED.E4668580 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES
Microsoft

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
   
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 39 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 32 review! s)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 46 reviews)

------=_NextPart_000_0001_01C5EAED.E4668580-- From owner-namedroppers@ops.ietf.org Wed Nov 16 18:19:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcWZ0-0004PI-MP for dnsext-archive@megatron.ietf.org; Wed, 16 Nov 2005 18:19:38 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06597 for ; Wed, 16 Nov 2005 18:19:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EcWUj-000A7S-Ii for namedroppers-data@psg.com; Wed, 16 Nov 2005 23:15:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,UPPERCASE_25_50 autolearn=ham version=3.1.0 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EcWUi-000A6C-Pk for namedroppers@ops.ietf.org; Wed, 16 Nov 2005 23:15:12 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id DA1D311D666; Wed, 16 Nov 2005 15:15:08 -0800 (PST) From: Wes Hardaker To: namedroppers@ops.ietf.org Subject: example DS record for SHA-256 Organization: Sparta Date: Wed, 16 Nov 2005 15:15:08 -0800 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Here's an example section for the recent sha-256 ID; feedback appreciated: (note: was TDB appendix A in -00; moved to Section 2.3 to match 4034 style) ---------------------------------------------------------------------- 2.3. Example DS Record Using SHA-256 The following is an example DSKEY and matching DS record. This DNSKEY record comes from the example DNSKEY/DS records found in section 5.4 of [RFC4034]. The DNSKEY record:: dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz fwJr1AYtsmx3TGkJaNXVbfi/ 2pHm822aJ5iI9BMzNXxeYCmZ DRD99WYwYqUSdjMmmAphXdvx egXd/M5+X7OrzKBaMbCVdFLU Uh6DhweJBjEVv5f2wwjM9Xzc nOf+EPbtG9DMBmADjFDc2w/r ljwvFw== ) ; key id = 60485 The resulting DS record covering the above DNSKEY record using a SHA- 256 digest: [RFC Editor: please replace XXX with the assigned digest type (likely 2):] dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C CEB1E3E0614B93C4F9E99B83 83F6A1E4469DA50A ) ---------------------------------------------------------------------- -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 16 23:58:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcbqX-0004MA-9G for dnsext-archive@megatron.ietf.org; Wed, 16 Nov 2005 23:58:05 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27280 for ; Wed, 16 Nov 2005 23:57:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ecbmv-0005qE-3Y for namedroppers-data@psg.com; Thu, 17 Nov 2005 04:54:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Ecbmu-0005q1-8U for namedroppers@ops.ietf.org; Thu, 17 Nov 2005 04:54:20 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAH4s8PO078590 for ; Wed, 16 Nov 2005 23:54:08 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20051116235002.04170e60@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 16 Nov 2005 23:54:17 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Re: I-D ACTION:draft-ietf-dnsext-ds-sha256-00.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk As this might have got lost among the many AAAA messages. Please read and comment if the approach is reasonable if the time values are acceptable Remember this Draft is going to attempt to get through the IETF in record time, last call will start once version 01 is issued later this week. Olafur At 16:15 15/11/2005, Wes Hardaker wrote: > >>>>> On Sun, 13 Nov 2005 16:02:14 +0100, Roy Arends > said: > >Thats good looking starting text. I've added it and modified it >slightly. Feed back appreciated: > > 4. Deployment Requirements > > If a validator does not support the SHA-256 digest type in an > authenticated DS RR and no other RR exists in the DS RRset with a > digest type that it supported, then the validator has no supported > authentication path leading from the parent to the child. The > resolver should treat this case as it would be the case of an > authenticated NSEC RRset proving that no DS RRset exists, as > described in [RFC4035], section 5.2. > > Because zone administrators can not control the deployment support of > SHA-256 in deployed validators that may referencing any given zone, > deployments SHOULD publish both SHA-1 and SHA-256 based DS records > for 2 years from the publication date of this RFC (XXX: RFC Editor: > Please insert the calculated date here). > > >(I'm generally thinking that we should avoid document feature creep, >and stick to the solid facts most of the time. Arguing for why this >and why that can fill a document and most of the existing documents >already cover this, so... But the above I think is very worth >stating. -- to unsubscribe send a message to namedroppers-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 17 00:12:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecc4K-0000Ax-Dj for dnsext-archive@megatron.ietf.org; Thu, 17 Nov 2005 00:12:20 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27878 for ; Thu, 17 Nov 2005 00:11:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ecc20-0006nR-HH for namedroppers-data@psg.com; Thu, 17 Nov 2005 05:09:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Ecc1z-0006nF-Rj for namedroppers@ops.ietf.org; Thu, 17 Nov 2005 05:09:55 +0000 Received: from [10.0.1.2] (unknown [192.0.35.62]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 2038C56884; Wed, 16 Nov 2005 21:09:54 -0800 (PST) (envelope-from david.conrad@nominum.com) In-Reply-To: <6.2.5.6.2.20051116235002.04170e60@ogud.com> References: <6.2.5.6.2.20051116235002.04170e60@ogud.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <5A99C738-12BC-4E51-B289-0F2F9A7788BA@nominum.com> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable From: David Conrad Subject: Re: I-D ACTION:draft-ietf-dnsext-ds-sha256-00.txt Date: Wed, 16 Nov 2005 21:10:08 -0800 To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT_co-chair?= X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On Nov 16, 2005, at 8:54 PM, =D3lafur Gu=F0mundsson /DNSEXT co-chair = wrote: >> Because zone administrators can not control the deployment =20 >> support of >> SHA-256 in deployed validators that may referencing any given =20 >> zone, >> deployments SHOULD publish both SHA-1 and SHA-256 based DS records >> for 2 years from the publication date of this RFC (XXX: RFC =20 >> Editor: >> Please insert the calculated date here). I remain unconvinced that supporting something for 2 years that has =20 had infinitesimal deployment to date by requiring people to deploy =20 something that they shouldn't use makes any sense at all. If you =20 want to kill SHA-1, kill it. Don't make it a zombie that will never =20 go away. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 17 03:09:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecepb-0007fb-IW for dnsext-archive@megatron.ietf.org; Thu, 17 Nov 2005 03:09:19 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05894 for ; Thu, 17 Nov 2005 03:08:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ecel7-000Hb2-JM for namedroppers-data@psg.com; Thu, 17 Nov 2005 08:04:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ecel6-000Hao-LN for namedroppers@ops.ietf.org; Thu, 17 Nov 2005 08:04:40 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id BBFF011D666; Thu, 17 Nov 2005 00:04:35 -0800 (PST) From: Wes Hardaker To: David Conrad Cc: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= /DNSEXT co-chair , namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ds-sha256-00.txt Organization: Sparta References: <6.2.5.6.2.20051116235002.04170e60@ogud.com> <5A99C738-12BC-4E51-B289-0F2F9A7788BA@nominum.com> Date: Thu, 17 Nov 2005 00:04:34 -0800 In-Reply-To: <5A99C738-12BC-4E51-B289-0F2F9A7788BA@nominum.com> (David Conrad's message of "Wed, 16 Nov 2005 21:10:08 -0800") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On Wed, 16 Nov 2005 21:10:08 -0800, David Conrad said: David> I remain unconvinced that supporting something for 2 years that has David> had infinitesimal deployment to date by requiring people to deploy David> something that they shouldn't use makes any sense at all. If you David> want to kill SHA-1, kill it. Don't make it a zombie that will never David> go away. There is a reason I listed it as a "SHOULD". I'm actually not sure it'll pass IESG review anyway. There are many who think than putting mandatory words in there for deployment is actually not possible. Maybe a lower-case should would be better? -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 17 05:56:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EchRb-0000ZX-Jy for dnsext-archive@megatron.ietf.org; Thu, 17 Nov 2005 05:56:43 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13913 for ; Thu, 17 Nov 2005 05:56:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EchNw-0001iM-CU for namedroppers-data@psg.com; Thu, 17 Nov 2005 10:52:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EchNv-0001iB-Ak for namedroppers@ops.ietf.org; Thu, 17 Nov 2005 10:52:55 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jAHAqV622930; Thu, 17 Nov 2005 12:52:35 +0200 Date: Thu, 17 Nov 2005 12:52:31 +0200 (EET) From: Pekka Savola To: Wes Hardaker cc: David Conrad , =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= /DNSEXT co-chair , namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ds-sha256-00.txt In-Reply-To: Message-ID: References: <6.2.5.6.2.20051116235002.04170e60@ogud.com> <5A99C738-12BC-4E51-B289-0F2F9A7788BA@nominum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 17 Nov 2005, Wes Hardaker wrote: > I'm actually not sure it'll pass IESG review anyway. There are many > who think than putting mandatory words in there for deployment is > actually not possible. Maybe a lower-case should would be better? Aye. The documents should be clear on whether such statement is a) an operational recommendation, or b) an implementation requirement. Typically, it can't be both. Using uppercase keywords for operational recommendation easily adds confusion with b), so it may be better to reword for clarity and/or use lowercase. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From hlailey@backtrend.com Thu Nov 17 07:48:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcjBh-0002p2-HA for dnsext-archive@megatron.ietf.org; Thu, 17 Nov 2005 07:48:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20207 for ; Thu, 17 Nov 2005 07:47:48 -0500 (EST) Received: from [82.148.17.146] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EcjTI-00009K-85 for dnsext-archive@ietf.org; Thu, 17 Nov 2005 08:06:37 -0500 Message-ID: <000001c5eb74$3a7e0c00$0100007f@localhost> From: "Ezra Carter" To: Subject: Windows XP Date: Thu, 17 Nov 2005 15:47:56 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5EB74.3A7E0C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.4 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5EB74.3A7E0C00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 48 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 43 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5EB74.3A7E0C00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download! !


Sales Rank: #1
Average Customer Review: 3D"5
(based on 48 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 32 re! views)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 34 reviews)

------=_NextPart_000_0001_01C5EB74.3A7E0C00-- From owner-namedroppers@ops.ietf.org Thu Nov 17 09:26:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EckiX-0001pP-FD for dnsext-archive@megatron.ietf.org; Thu, 17 Nov 2005 09:26:26 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26804 for ; Thu, 17 Nov 2005 09:25:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EckfB-000EV7-87 for namedroppers-data@psg.com; Thu, 17 Nov 2005 14:22:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EckfA-000EUs-48 for namedroppers@ops.ietf.org; Thu, 17 Nov 2005 14:22:56 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAHEMZYu091238; Thu, 17 Nov 2005 09:22:36 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <6.2.5.6.2.20051116235002.04170e60@ogud.com> <5A99C738-12BC-4E51-B289-0F2F9A7788BA@nominum.com> Date: Thu, 17 Nov 2005 09:22:34 -0500 To: Pekka Savola From: Edward Lewis Subject: Re: I-D ACTION:draft-ietf-dnsext-ds-sha256-00.txt Cc: Wes Hardaker , David Conrad , =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson_=2FDNSEXT_co=2Dchair?= , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:52 +0200 11/17/05, Pekka Savola wrote: >Aye. The documents should be clear on whether such statement is a) an >operational recommendation, or b) an implementation requirement. Typically, it >can't be both. Tangential to the topic but to reinforce this conundrum, I have been sitting through IPv6 discussions in the RIRs. They get tripped up confusing "protocol necessities" against "what the protocol designers think is the way this will work." To be specific, is a /48 something that every house should have because there is a protocol need for it, now or in the future, or is it a number that seems to be the easiest to manage? Whenever that comes up, the discussion bounces from operator practices to protocol engineering. It's becoming apparent to me that we (the DNS protocol WG) ought to just specify the components of the protocol and document the pros and cons of each element. When it comes to saying "use this element [say SHA-256]" leave that to an operations forum. Whether that is DNSOP or external to the IETF I won't recommend. But the only expertise we should count on in this WG is on protocol engineering. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-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 17 09:35:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eckrl-0003Ie-9w for dnsext-archive@megatron.ietf.org; Thu, 17 Nov 2005 09:35:57 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27379 for ; Thu, 17 Nov 2005 09:35:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eckpn-000FMC-3o for namedroppers-data@psg.com; Thu, 17 Nov 2005 14:33:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Eckpk-000FM0-I1 for namedroppers@ops.ietf.org; Thu, 17 Nov 2005 14:33:52 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id jAHEXlWZ016058; Thu, 17 Nov 2005 09:33:50 -0500 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id jAHEXVG3018200; Thu, 17 Nov 2005 09:33:31 -0500 (EST) From: "Scott Rose" To: "Wes Hardaker" , Subject: draft SHA-256 for DS RRs comments Date: Thu, 17 Nov 2005 09:33:31 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I just finished the draft and I have one comment on Section 3. I don't know if the wording "MUST perfer DS records with SHA-256..." is necessary. It is also rather vague for validator implementors - what happens when the SHA-256 DS RR is invalid, but there is a valid SHA-1? Is the chain still valid? I think the preference language isn't necessary (local policy :) ) since most developers know SHA-256 is stronger than SHA-1. Also, it might be helpful for readers to include a simple table in the IANA considerations section detailing the algorithms: VALUE Algorithm Status 0 Reserved - 1 SHA-1 MANDATORY(1) 2 SHA-256 MANDATORY 3-255 Unassigned - (1) SHA-1 is still mandatory to implement and deploy for a period following the publication of this draft to RFC status. This is necessary for a period of backwards compatibility until SHA-256 is more widely deployed. See section 4. ------------- Or something similar. The note may not be necessary. Scott **************************************** Scott Rose Adv. Network Tech. Div., NIST +1 301-975-8439 https://www-x.antd.nist.gov/dnssec/ **************************************** > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Wes Hardaker > Sent: Wednesday, November 16, 2005 6:15 PM > To: namedroppers@ops.ietf.org > Subject: example DS record for SHA-256 > > > > Here's an example section for the recent sha-256 ID; feedback > appreciated: > > (note: was TDB appendix A in -00; moved to Section 2.3 to match > 4034 style) > > ---------------------------------------------------------------------- > > 2.3. Example DS Record Using SHA-256 > > The following is an example DSKEY and matching DS record. This > DNSKEY record comes from the example DNSKEY/DS records found in > section 5.4 of [RFC4034]. > > The DNSKEY record:: > > dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz > fwJr1AYtsmx3TGkJaNXVbfi/ > 2pHm822aJ5iI9BMzNXxeYCmZ > DRD99WYwYqUSdjMmmAphXdvx > egXd/M5+X7OrzKBaMbCVdFLU > Uh6DhweJBjEVv5f2wwjM9Xzc > nOf+EPbtG9DMBmADjFDc2w/r > ljwvFw== > ) ; key id = 60485 > > The resulting DS record covering the above DNSKEY record using a SHA- > 256 digest: [RFC Editor: please replace XXX with the assigned digest > type (likely 2):] > > dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C > CEB1E3E0614B93C4F9E99B83 > 83F6A1E4469DA50A ) > > ---------------------------------------------------------------------- > > > -- > Wes Hardaker > Sparta, Inc. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 17 10:04:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EclJ4-0006BU-RG for dnsext-archive@megatron.ietf.org; Thu, 17 Nov 2005 10:04:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28970 for ; Thu, 17 Nov 2005 10:03:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EclGI-000HsC-AH for namedroppers-data@psg.com; Thu, 17 Nov 2005 15:01:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EclGH-000HrP-I4 for namedroppers@ops.ietf.org; Thu, 17 Nov 2005 15:01:17 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 0CD8811D666; Thu, 17 Nov 2005 07:01:16 -0800 (PST) From: Wes Hardaker To: Pekka Savola Cc: David Conrad , =?iso-8859-1?Q?=D3lafur_Gu?= =?iso-8859-1?Q?=F0mundsson?= /DNSEXT co-chair , namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ds-sha256-00.txt Organization: Sparta References: <6.2.5.6.2.20051116235002.04170e60@ogud.com> <5A99C738-12BC-4E51-B289-0F2F9A7788BA@nominum.com> Date: Thu, 17 Nov 2005 07:01:15 -0800 In-Reply-To: (Pekka Savola's message of "Thu, 17 Nov 2005 12:52:31 +0200 (EET)") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On Thu, 17 Nov 2005 12:52:31 +0200 (EET), Pekka Savola said: >> I'm actually not sure it'll pass IESG review anyway. There are many >> who think than putting mandatory words in there for deployment is >> actually not possible. Maybe a lower-case should would be better? Pekka> Aye. The documents should be clear on whether such statement Pekka> is a) an operational recommendation, or b) an implementation Pekka> requirement. Typically, it can't be both. I've changed the section title to "deployment considerations" and changed the "SHOULD" to a "should" which I think should alleviate the concerns. (?) -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 17 10:05:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EclKJ-0006vr-8o for dnsext-archive@megatron.ietf.org; Thu, 17 Nov 2005 10:05:27 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29018 for ; Thu, 17 Nov 2005 10:04:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EclIy-000I3Z-Vi for namedroppers-data@psg.com; Thu, 17 Nov 2005 15:04:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EclIy-000I3D-1K for namedroppers@ops.ietf.org; Thu, 17 Nov 2005 15:04:04 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAHF3svi091407; Thu, 17 Nov 2005 10:03:54 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20051117094203.02e88eb0@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 17 Nov 2005 10:03:57 -0500 To: Edward Lewis , Pekka Savola From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Obsoleting DS alg 1 (Was: Re: I-D ACTION:draft-ietf-dnsext-ds-sha256-00.txt) Cc: namedroppers@ops.ietf.org In-Reply-To: References: <6.2.5.6.2.20051116235002.04170e60@ogud.com> <5A99C738-12BC-4E51-B289-0F2F9A7788BA@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 09:22 17/11/2005, Edward Lewis wrote: >At 12:52 +0200 11/17/05, Pekka Savola wrote: > >>Aye. The documents should be clear on whether such statement is a) an >>operational recommendation, or b) an implementation requirement. >>Typically, it >>can't be both. > > >It's becoming apparent to me that we (the DNS protocol WG) ought to >just specify the components of the protocol and document the pros >and cons of each element. When it comes to saying "use this element >[say SHA-256]" leave that to an operations forum. Whether that is >DNSOP or external to the IETF I won't recommend. But the only >expertise we should count on in this WG is on protocol engineering. This is first of at least DS two algorithm rollovers we should get the procedure some thought and try to do the "correct" thing, so when the second one is performed we use the same procedure. The two rollovers are this one (SHA256) and the outcome selection of new generation of digest algorithm by NIST in about 5 year time frame. Protocol action: For existing DS alg=1 that is to be obsoleted what should the document say: A. It is obsoleted ? B. It is obsoleted in 2 or more years ? C. Should the not obsolete it ? D. other Operational guidance: 1. As it is harder update code in validators forcing but cheap to generate and distribute DS records, the cost for parents to list multiple DS is low. 2. On the other hand deployment is almost nil so forcing the issue may be a good thing. 3. As DS sets are small (compared to signatures) listing each trust anchor multiple times to help old implementations may be a good thing but only for a "limited" time. 4. Say nothing 5. Other option not listed above please make some statements about applicability of these options 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 aloperfido@arizona-excellence.com Thu Nov 17 15:24:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqJO-00036k-Vz for dnsext-archive@megatron.ietf.org; Thu, 17 Nov 2005 15:24:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18070 for ; Thu, 17 Nov 2005 15:24:15 -0500 (EST) Received: from c-71-197-154-208.hsd1.or.comcast.net ([71.197.154.208] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ecqb4-0007dh-Jd for dnsext-archive@ietf.org; Thu, 17 Nov 2005 15:43:08 -0500 Message-ID: <000001c5ebb3$fa3e7e00$0100007f@localhost> From: "Carson Price" To: Subject: cheap oem soft shipping //orldwide Date: Thu, 17 Nov 2005 12:24:30 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5EBB3.FA3E7E00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5EBB3.FA3E7E00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 44 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 37 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 35 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5EBB3.FA3E7E00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 38 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 37 reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 44 reviews)

------=_NextPart_000_0001_01C5EBB3.FA3E7E00-- From owner-namedroppers@ops.ietf.org Thu Nov 17 20:18:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcutK-0002ge-GD for dnsext-archive@megatron.ietf.org; Thu, 17 Nov 2005 20:18:14 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10220 for ; Thu, 17 Nov 2005 20:17:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ecurg-0003vz-Nm for namedroppers-data@psg.com; Fri, 18 Nov 2005 01:16:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ecurg-0003vn-4M for namedroppers@ops.ietf.org; Fri, 18 Nov 2005 01:16:32 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id jAI1C3x5027179 for ; Thu, 17 Nov 2005 20:12:03 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAZmaae1; Thu, 17 Nov 05 20:11:59 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id jAI1DsmU016927; Thu, 17 Nov 2005 20:13:54 -0500 (EST) Date: Thu, 17 Nov 2005 20:13:54 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Scott Rose cc: Wes Hardaker , namedroppers@ops.ietf.org Subject: Re: draft SHA-256 for DS RRs comments In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 17 Nov 2005, Scott Rose wrote: > I just finished the draft and I have one comment on Section 3. I don't know > if the wording "MUST perfer DS records with SHA-256..." is necessary. It is > also rather vague for validator implementors - what happens when the SHA-256 > DS RR is invalid, but there is a valid SHA-1? Is the chain still valid? I > think the preference language isn't necessary (local policy :) ) since most > developers know SHA-256 is stronger than SHA-1. I agree with Scott -- the entire "preference" paragraph (2nd paragraph of section 3) needs to come out. > Also, it might be helpful for readers to include a simple table in the IANA > considerations section detailing the algorithms: > > VALUE Algorithm Status > 0 Reserved - > 1 SHA-1 MANDATORY(1) > 2 SHA-256 MANDATORY > 3-255 Unassigned - > > (1) SHA-1 is still mandatory to implement and deploy for a period following > the publication of this draft to RFC status. This is necessary for a period > of backwards compatibility until SHA-256 is more widely deployed. See > section 4. I suggest changing this to "Both SHA-1 and SHA-256 are mandatory for resolvers to implement. Resolvers may wish to provide a configuration option to disable any given message digest algorithm. DS records should use SHA-256 and may use SHA-1, as discussed in section 4." -- 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 17 20:18:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecute-0002is-1V for dnsext-archive@megatron.ietf.org; Thu, 17 Nov 2005 20:18:34 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10223 for ; Thu, 17 Nov 2005 20:17:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ecuo1-0003jQ-Vg for namedroppers-data@psg.com; Fri, 18 Nov 2005 01:12:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ecuo0-0003jF-W6 for namedroppers@ops.ietf.org; Fri, 18 Nov 2005 01:12:45 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id jAI18GL5026699 for ; Thu, 17 Nov 2005 20:08:16 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAATbaGi0; Thu, 17 Nov 05 20:08:13 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id jAI1ADIR016826; Thu, 17 Nov 2005 20:10:13 -0500 (EST) Date: Thu, 17 Nov 2005 20:10:13 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ds-sha256-00.txt In-Reply-To: <6.2.5.6.2.20051116235002.04170e60@ogud.com> Message-ID: References: <6.2.5.6.2.20051116235002.04170e60@ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tislabs.com id jAI1ADIR016826 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On Wed, 16 Nov 2005, [iso-8859-1] =D3lafur[iso-8859-1] Gu=F0mundsson /DN= SEXT co-chair wrote: > Please read and comment > if the approach is reasonable > if the time values are acceptable I'd prefer to see a weaker recommendation, if any at all, per the last paragraph below. > > If a validator does not support the SHA-256 digest type in an > > authenticated DS RR and no other RR exists in the DS RRset with > > digest type that it supported, then the validator has no supported > > authentication path leading from the parent to the child. The > > resolver should treat this case as it would be the case of an > > authenticated NSEC RRset proving that no DS RRset exists, as > > described in [RFC4035], section 5.2. The above is correct, but 4035 is not completely clear on how to handle unknown algorithms, as is discussed in section 3.1 of draft-ietf-dnsext-dnssec-bis-updates-01. I think a reference to that section of bis-updates would be a good idea. Some have suggested that we should go ahead and push out bis-updates sooner rather than later, figuring it's useful as-is and we can always push a new document with more clarifications later. I support that -- I see no reason why the docs couldn't both advance quickly and together. > > Because zone administrators can not control the deployment support= of > > SHA-256 in deployed validators that may referencing any given zone= , > > deployments SHOULD publish both SHA-1 and SHA-256 based DS records > > for 2 years from the publication date of this RFC (XXX: RFC Editor= : > > Please insert the calculated date here). I want to see a weaker recommendation here, perhaps even no recommendation. "May want to considere publishing both for some time, while being aware of SHA-1's potential weaknesses". If any stronger recommendation is kept, then the security considerations section needs to point out that we're encouraging a door to be left open. -- 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 18 03:46:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed1t3-0002Nq-S4 for dnsext-archive@megatron.ietf.org; Fri, 18 Nov 2005 03:46:26 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01550 for ; Fri, 18 Nov 2005 03:45:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ed1ns-0006s5-1l for namedroppers-data@psg.com; Fri, 18 Nov 2005 08:41:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.169.16.30] (helo=exchangebe.corporate.telin.nl) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Ed1nm-0006rT-8i for namedroppers@ops.ietf.org; Fri, 18 Nov 2005 08:40:58 +0000 Received: from netinfo.corporate.telin.nl ([195.169.16.63]) by exchangebe.corporate.telin.nl with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Nov 2005 09:40:54 +0100 Date: Fri, 18 Nov 2005 09:40:53 +0100 (CET) From: Roy Arends X-X-Sender: roy@netinfo.corporate.telin.nl To: Samuel Weiler cc: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair , namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ds-sha256-00.txt In-Reply-To: Message-ID: References: <6.2.5.6.2.20051116235002.04170e60@ogud.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1446822128-830937687-1132303253=:5393" X-OriginalArrivalTime: 18 Nov 2005 08:40:54.0018 (UTC) FILETIME=[C994EE20:01C5EC1B] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1446822128-830937687-1132303253=:5393 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 17 Nov 2005, Samuel Weiler wrote: > On Wed, 16 Nov 2005, [iso-8859-1] =D3lafur[iso-8859-1] Gu=F0mundsson /DN= SEXT co-chair wrote: > >> Please read and comment >> if the approach is reasonable >> if the time values are acceptable > > I'd prefer to see a weaker recommendation, if any at all, per the last > paragraph below. > >>> If a validator does not support the SHA-256 digest type in an >>> authenticated DS RR and no other RR exists in the DS RRset with >>> digest type that it supported, then the validator has no supported >>> authentication path leading from the parent to the child. The >>> resolver should treat this case as it would be the case of an >>> authenticated NSEC RRset proving that no DS RRset exists, as >>> described in [RFC4035], section 5.2. > > The above is correct, but 4035 is not completely clear on how to > handle unknown algorithms, as is discussed in section 3.1 of > draft-ietf-dnsext-dnssec-bis-updates-01. I think a reference to that > section of bis-updates would be a good idea. Actually, when rfc4035 section 5.2 discusses unknown algorithms, it does=20 not specifically identify the signing algorithm. It reads "any of the=20 algorithms listed in an authenticated DS RRset". This definition, imho,=20 includes digest algorithms as well, which makes section 3.1 of bis-updates= =20 redundant, or at most a clarification of a text that might be perceived=20 as ambiguous, but definitly not an update. > Some have suggested that we should go ahead and push out bis-updates > sooner rather than later, figuring it's useful as-is and we can always > push a new document with more clarifications later. I support that -- > I see no reason why the docs couldn't both advance quickly and > together. I think, as per my explanation above, that new digest types and=20 bis-updates are orthogonal. I'd rather wait with bis-updates until we have= =20 more deployment experience. I do _not_ want to wait with sha-256, and I really do _not_ want to make=20 sha-256 dependent on bis-updates. Roy ---1446822128-830937687-1132303253=:5393-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From planner@avelinas.com Fri Nov 18 04:09:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed2Ev-0002ky-6S for dnsext-archive@megatron.ietf.org; Fri, 18 Nov 2005 04:09:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02823 for ; Fri, 18 Nov 2005 04:08:25 -0500 (EST) Received: from [217.67.119.10] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ed2Wh-0007yA-Vk for dnsext-archive@ietf.org; Fri, 18 Nov 2005 04:27:25 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Fri, 18 Nov 2005 12:08:49 +0300 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Fri, 18 Nov 2005 12:08:49 +0300 Message-ID: <000001c5ec1e$d06e7100$0100007f@localhost> From: "Drake Perez" To: Subject: Be the "biggest" out of all your friends Date: Fri, 18 Nov 2005 12:08:49 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5EC1E.D06E7100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5EC1E.D06E7100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! Name Patches Regular Now Steel Package 10 Patches $79.95 $49.95 Free shipping Silver Package 25 Patches $129.95 $99.95 Free shipping and exercise manual included Gold Package 40 Patches $189.95 $149.95 Free shipping and exercise manual included Platinum Package 65 Patches $259.95 $199.95 Free shipping and exercise manual included ------=_NextPart_000_0001_01C5EC1E.D06E7100 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

Name Patches Regular Now
Steel Package 10 Patches $79.95 $49.95 Free shipping
Silver Package 25 Patches $129.95 $99.95 Free shipping and exercise manual included
Gold Package 40 Patches $189.95 $149.95 Free shipping and exercise manual included
Platinum Package 65 Patches $259.95 $199.95 Free shipping and exercise manual included
------=_NextPart_000_0001_01C5EC1E.D06E7100-- From VilmaKerns@eezyled.com Fri Nov 18 04:21:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed2RI-0007gD-D9 for dnsext-archive@megatron.ietf.org; Fri, 18 Nov 2005 04:21:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03474; Fri, 18 Nov 2005 04:21:12 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed2j6-0008Nj-2x; Fri, 18 Nov 2005 04:40:12 -0500 Received: from ip.85.202.171.96.dyn.sub-11.broadband.voliacable.com ([85.202.171.96]) by mx2.foretec.com with smtp (Exim 4.24) id 1Ed2RC-0002dq-Ia; Fri, 18 Nov 2005 04:21:43 -0500 Received: from C4R@localhost by teR.int (8.11.6/8.11.6); Fri, 18 Nov 2005 05:58:09 -0400 Message-ID: From: "Jewell Dawson" Reply-To: "Jewell Dawson" To: droyer@ietf.org, rfc-editor@ietf.org, v6tc@ietf.org, dnsext-archive@ietf.org Subject: XP Pro Software titles available for Download Date: Fri, 18 Nov 2005 11:58:09 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: VilmaKerns@eezyled.com Content-Type: multipart/mixed; boundary="--772987723358744" X-Spam-Score: 0.2 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 xZN ----772987723358744 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable S
Opt-in Email Special Offer   = ;  unsubscribe me
----772987723358744-- From allsafe@3dstructures.com Fri Nov 18 10:07:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed7pa-0002j3-CQ for dnsext-archive@megatron.ietf.org; Fri, 18 Nov 2005 10:07:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22561 for ; Fri, 18 Nov 2005 10:06:38 -0500 (EST) Received: from [82.204.178.43] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ed87P-0002ww-5z for dnsext-archive@ietf.org; Fri, 18 Nov 2005 10:25:42 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Fri, 18 Nov 2005 18:06:58 +0300 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Fri, 18 Nov 2005 18:06:58 +0300 Message-ID: <000001c5ec50$e85ee880$0100007f@localhost> From: "Jay Edwards" To: Subject: Hey baby, found this site and wanted you to check it out firstNeed Software? Date: Fri, 18 Nov 2005 18:06:58 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5EC50.E85EE880" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.3 (++) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5EC50.E85EE880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! Name Patches Regular Now Steel Package 10 Patches $79.95 $49.95 Free shipping Silver Package 25 Patches $129.95 $99.95 Free shipping and exercise manual included Gold Package 40 Patches $189.95 $149.95 Free shipping and exercise manual included Platinum Package 65 Patches $259.95 $199.95 Free shipping and exercise manual included ------=_NextPart_000_0001_01C5EC50.E85EE880 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

SEARCH

TOP 10 NEW TITLES

=
<= td width=3D132> Dreamweaver 8=   Adobe
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&nb= sp;2 Creative Suite 2
&nb= sp;3 MS Office 2003 Pro
&= nbsp;4 Adobe Acrobat 7 Pro
 5 Macromedia Flash 8
 6
 7 Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
10 Borland Architect 2005
  See more by this manufacturer
   Microsoft
=    Macromedia
  
 = Customers also bought
   these = other items...

<= b class=3Dsans>Microsoft Windows XP Professional *w/SP2*
Microsoft

Choose:
<= a href=3Dhttp://buymoresoft.com/?B>  =

List Price:$299.00
Price:$49.99
You Save:= $249.01 (80%)



Availa= bility: Available for INSTANT download!
Coupon Code: yOOusw= OX
Platform: Windows XP

Sales Rank: #1
System requir= ements  |  Other Version= s
Date Coupon Expires: December 3= 1st, 2005
Average Customer Review: Based on 1311 reviews. Write a r= eview.

Adobe Creative Suite 2 *Premium*
= Adobe

Choose:
&= nbsp;

List Price:$1199.00
Price:$149.99
You Save:$1049= 01 (95%)

=

Availabili= ty: Available for INSTANT download!
Coupon Code: c0fO3lTN Platform: W= indows XP

Sales Rank: #2
System requiremen= ts  |  Other Versions
Date Coupon Expires: December 31st,= 2005
Average Customer Review:3D"5 Based on 17152 reviews. Write a revi= ew.

Microsoft Office 2003 *Professional*
Microsoft

Choose:
 

You Save:



Availability: Available for INSTANT dow= nload!
Coupon Code: JN5EcCv
Platform: Windows XP

Sales Rank: #3
System requirements  |  Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 174927 reviews. Write a review.

List Price:$499.00
Price:$69.99
$429.01 (85%)

Adobe Acrobat Professional V 7.0
Adobe

C= hoose:
 

<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 height=3D21 width=3D189><= tr>		 List Price:$499.00
Price:$69.99
You = Save:$429.01 (85%)

<= a href=3Dhttp://buymoresoft.com/?H>

Availability: Available for INSTANT download= !
Coupon Code: QAJ2x4
Platform: Windows XP

Sales Rank: #4
System requirements  |  Other Versions
Date = Coupon Expires: December 31st, 2005
A= verage Customer Review:3D"5 Based on 13845 reviews. Write a review.

Name Patches Regular Now
Steel Package 10 Patches $79.95 $49.95 Free shipping
Silver Package 25 Patches $129.95 $99.95 Free shipping and exercise manual included
Gold Package 40 Patches $189.95 $149.95 Free shipping and exercise manual included
Platinum Package 65 Patches $259.95 $199.95 Free shipping and exercise manual included
------=_NextPart_000_0001_01C5EC50.E85EE880-- From owner-namedroppers@ops.ietf.org Fri Nov 18 14:05:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdBXx-0001dQ-Vf for dnsext-archive@megatron.ietf.org; Fri, 18 Nov 2005 14:05:18 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04762 for ; Fri, 18 Nov 2005 14:04:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EdBPb-000I1g-3m for namedroppers-data@psg.com; Fri, 18 Nov 2005 18:56:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EdBPa-000I1U-43 for namedroppers@ops.ietf.org; Fri, 18 Nov 2005 18:56:38 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jAIIuW16073440 for ; Fri, 18 Nov 2005 19:56:32 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2--585828420" To: Namedroppers From: "Olaf M. Kolkman" Subject: Reinforcing the Review decision Date: Fri, 18 Nov 2005 19:56:34 +0100 X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2--585828420 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Dear Colleagues, During the Vancouver meeting the folk in the room consented with the proposal to only forward work to the IESG when we received minimum number of statements of thorough review. We would like re-iterate this proposal on the list and set the minimum number to five. That is: We will not forward work if during a working group last call not at least five people have gone on record that they thoroughly reviewed the most current version of an I-D (and there is rough consensus to forward the work). We would like to ask the working groups consent for this. Olaf and Olafur DNSEXT chairs. ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-2--585828420 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.1 (Darwin) Comment: This message is locally signed. iD8DBQFDfiPitN/ca3YJIocRAksXAJ9Unt5OfNVvnT1LI0qBuZoQ9wE9LwCghznF dpHYqJNTdIoDgKQWbHfKXwg= =HSCe -----END PGP SIGNATURE----- --Apple-Mail-2--585828420-- -- to unsubscribe send a message to namedroppers-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 18 16:56:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdEDJ-0005Dq-Ad for dnsext-archive@megatron.ietf.org; Fri, 18 Nov 2005 16:56:09 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13127 for ; Fri, 18 Nov 2005 16:55:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EdE9V-0003dI-Sd for namedroppers-data@psg.com; Fri, 18 Nov 2005 21:52:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EdE9T-0003cu-8r for namedroppers@ops.ietf.org; Fri, 18 Nov 2005 21:52:11 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 3C0BE11D666; Fri, 18 Nov 2005 13:52:08 -0800 (PST) From: Wes Hardaker To: Samuel Weiler Cc: Scott Rose , namedroppers@ops.ietf.org Subject: Re: draft SHA-256 for DS RRs comments Organization: Sparta References: Date: Fri, 18 Nov 2005 13:52:07 -0800 In-Reply-To: (Samuel Weiler's message of "Thu, 17 Nov 2005 20:13:54 -0500 (EST)") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On Thu, 17 Nov 2005 20:13:54 -0500 (EST), Samuel Weiler said: Samuel> I suggest changing this to "Both SHA-1 and SHA-256 are Samuel> mandatory for resolvers to implement. If you're going to go down the current road that looks like the path consensus want to take, I don't think you should say that SHA-1 is mandatory to implement. The new document should state that SHA-256 is mandatory but I'm not sure you should say that SHA-1 also is mandatory, unless you also state that this requirement doesn't come from this document but rather that you're just quoting the other RFC(s). Samuel> Resolvers may wish to provide a configuration option to Samuel> disable any given message digest algorithm. DS records should Samuel> use SHA-256 and may use SHA-1, as discussed in section 4." Interestingly enough, I actually didn't like the language in the document as well but had put it in based on input received from a few people. I generally don't think it's wise to dictate policy. I think the better choice is to specify what you must implement (which you indicated above) and potentially indicate what you must default to. Thus, I'd think something like the following text might be better: Validator implementations MUST implement the SHA-256 digest type. Validator implementations MUST be able to prefer SHA-256 digest types over SHA-1 digest types, and MUST do this by default. Validator implementations SHOULD provide configuration ability to specify the proper policy to use when selecting between whether to use SHA-256 and SHA-1 digest types when DS records of both types are available but only one can be used to securely validate a child's DNSKEY. -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Nov 18 16:57:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdEEX-0005KE-M7 for dnsext-archive@megatron.ietf.org; Fri, 18 Nov 2005 16:57:25 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13163 for ; Fri, 18 Nov 2005 16:56:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EdEAz-0003l0-SV for namedroppers-data@psg.com; Fri, 18 Nov 2005 21:53:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EdEAz-0003kp-ED for namedroppers@ops.ietf.org; Fri, 18 Nov 2005 21:53:45 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id D38AD11426 for ; Fri, 18 Nov 2005 21:53:44 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: Reinforcing the Review decision In-Reply-To: Your message of "Fri, 18 Nov 2005 19:56:34 +0100." References: Date: Fri, 18 Nov 2005 21:53:44 +0000 Message-Id: <20051118215344.D38AD11426@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # We would like to ask the working groups consent for this. "Aye." -- to unsubscribe send a message to namedroppers-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 18 16:57:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdEEs-0005Kw-2Q for dnsext-archive@megatron.ietf.org; Fri, 18 Nov 2005 16:57:46 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13183 for ; Fri, 18 Nov 2005 16:57:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EdEDa-00043o-Bn for namedroppers-data@psg.com; Fri, 18 Nov 2005 21:56:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EdEDX-00042l-TY for namedroppers@ops.ietf.org; Fri, 18 Nov 2005 21:56:24 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id C8AC211D666; Fri, 18 Nov 2005 13:56:20 -0800 (PST) From: Wes Hardaker To: "Scott Rose" Cc: Subject: Re: draft SHA-256 for DS RRs comments Organization: Sparta References: Date: Fri, 18 Nov 2005 13:56:20 -0800 In-Reply-To: (Scott Rose's message of "Thu, 17 Nov 2005 09:33:31 -0500") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On Thu, 17 Nov 2005 09:33:31 -0500, "Scott Rose" said: Scott> I just finished the draft and I have one comment on Section 3. Scott> I don't know if the wording "MUST perfer DS records with Scott> SHA-256..." is necessary. It is also rather vague for Scott> validator implementors - what happens when the SHA-256 DS RR is Scott> invalid, but there is a valid SHA-1? Is the chain still valid? Scott> I think the preference language isn't necessary (local policy Scott> :) ) since most developers know SHA-256 is stronger than SHA-1. See my response to Sam's message for a better answer to why that text is in there and a proposed replacement. However, in summary I agree that it should be configurable policy. However, I personally am not sure when I'd ever allow a SHA-256 digest to fail and I'd trust the SHA-1 digest instead. But that's my preference and I'm sure we could find someone that would state that's a necessary policy to hold. -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Nov 18 17:02:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdEJN-0006dm-Hz for dnsext-archive@megatron.ietf.org; Fri, 18 Nov 2005 17:02:26 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13374 for ; Fri, 18 Nov 2005 17:01:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EdEHS-0004Ul-FN for namedroppers-data@psg.com; Fri, 18 Nov 2005 22:00:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EdEHR-0004Ts-Pe for namedroppers@ops.ietf.org; Fri, 18 Nov 2005 22:00:25 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 8471D11D666; Fri, 18 Nov 2005 14:00:22 -0800 (PST) From: Wes Hardaker To: Roy Arends Cc: Samuel Weiler , =?iso-8859-1?Q?=D3lafur_Gu=F0mund?= =?iso-8859-1?Q?sson?= /DNSEXT co-chair , namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ds-sha256-00.txt Organization: Sparta References: <6.2.5.6.2.20051116235002.04170e60@ogud.com> Date: Fri, 18 Nov 2005 14:00:21 -0800 In-Reply-To: (Roy Arends's message of "Fri, 18 Nov 2005 09:40:53 +0100 (CET)") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On Fri, 18 Nov 2005 09:40:53 +0100 (CET), Roy Arends said: Roy> I do _not_ want to wait with sha-256, and I really do _not_ want to make Roy> sha-256 dependent on bis-updates. If I say "ditto" do I have to claim to be an AOL user, or is that solely reserved for "me too" responses. I've never been too clear on that. I don't think that a bis-update that includes a new mandatory algorithm is truly a good way to go forward, as it would require cycling at proposed. I'm not sure the rest of the bis-update thought would require that. -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Nov 18 17:09:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdEQ2-0007zE-A6 for dnsext-archive@megatron.ietf.org; Fri, 18 Nov 2005 17:09:18 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13714 for ; Fri, 18 Nov 2005 17:08:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EdEOC-0005MX-2p for namedroppers-data@psg.com; Fri, 18 Nov 2005 22:07:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EdEOB-0005MI-9t for namedroppers@ops.ietf.org; Fri, 18 Nov 2005 22:07:23 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 31CCD111 for ; Fri, 18 Nov 2005 17:07:22 -0500 (EST) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 849AC41B8 for ; Fri, 18 Nov 2005 17:07:21 -0500 (EST) Date: Fri, 18 Nov 2005 17:07:21 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Reinforcing the Review decision In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20051118220721.849AC41B8@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Fri, 18 Nov 2005 19:56:34 +0100, Olaf M Kolkman wrote: > > We will not forward work if during a working group last call not at > least five people have gone on record that they thoroughly reviewed > the most current version of an I-D (and there is rough consensus to > forward the work). > > We would like to ask the working groups consent for this. Aye. -- to unsubscribe send a message to namedroppers-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 18 17:10:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdER5-0008T3-Vp for dnsext-archive@megatron.ietf.org; Fri, 18 Nov 2005 17:10:24 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13758 for ; Fri, 18 Nov 2005 17:09:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EdENa-0005Iz-MA for namedroppers-data@psg.com; Fri, 18 Nov 2005 22:06:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [213.154.224.50] (helo=bartok.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EdENZ-0005Ic-Na for namedroppers@ops.ietf.org; Fri, 18 Nov 2005 22:06:46 +0000 Received: from bartok.nlnetlabs.nl (localhost.nlnetlabs.nl [127.0.0.1]) by bartok.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jAIM6gti086379; Fri, 18 Nov 2005 23:06:42 +0100 (CET) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200511182206.jAIM6gti086379@bartok.nlnetlabs.nl> To: "Olaf M. Kolkman" cc: Namedroppers Subject: Re: Reinforcing the Review decision In-reply-to: Your message of Fri, 18 Nov 2005 19:56:34 +0100. Date: Fri, 18 Nov 2005 23:06:42 +0100 From: Jaap Akkerhuis Sender: owner-namedroppers@ops.ietf.org Precedence: bulk We will not forward work if during a working group last call not at least five people have gone on record that they thoroughly reviewed the most current version of an I-D (and there is rough consensus to forward the work). We would like to ask the working groups consent for this. ACK. jaap -- to unsubscribe send a message to namedroppers-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 18 17:18:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdEYj-0001Se-K2 for dnsext-archive@megatron.ietf.org; Fri, 18 Nov 2005 17:18:17 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14071 for ; Fri, 18 Nov 2005 17:17:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EdEX5-0006Q1-7O for namedroppers-data@psg.com; Fri, 18 Nov 2005 22:16:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, INFO_TLD autolearn=no version=3.1.0 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EdEX4-0006Pn-Dd for namedroppers@ops.ietf.org; Fri, 18 Nov 2005 22:16:34 +0000 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1EdEX3-0001gU-Js for namedroppers@ops.ietf.org; Fri, 18 Nov 2005 17:16:33 -0500 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id 208A513744; Fri, 18 Nov 2005 17:16:32 -0500 (EST) Date: Fri, 18 Nov 2005 17:16:32 -0500 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: Reinforcing the Review decision Message-ID: <20051118221631.GE21289@libertyrms.info> Reply-To: Andrew Sullivan References: <20051118215344.D38AD11426@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051118215344.D38AD11426@sa.vix.com> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Nov 18, 2005 at 09:53:44PM +0000, Paul Vixie wrote: > # We would like to ask the working groups consent for this. > > "Aye." Me too. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +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 Fri Nov 18 17:31:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdElO-0004mk-AZ for dnsext-archive@megatron.ietf.org; Fri, 18 Nov 2005 17:31:22 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14673 for ; Fri, 18 Nov 2005 17:30:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EdEjD-0007aD-NW for namedroppers-data@psg.com; Fri, 18 Nov 2005 22:29:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EdEjC-0007a2-W3 for namedroppers@ops.ietf.org; Fri, 18 Nov 2005 22:29:07 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id jAIMSq1Z000406; Fri, 18 Nov 2005 17:28:56 -0500 Received: from gorilla ([129.6.220.8]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id jAIMSgbX024740; Fri, 18 Nov 2005 17:28:43 -0500 (EST) From: "Scott Rose" To: "Wes Hardaker" Cc: Subject: RE: draft SHA-256 for DS RRs comments Date: Fri, 18 Nov 2005 17:28:45 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Importance: Normal X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com] > Sent: Friday, November 18, 2005 1:56 PM > > However, in summary I agree that it should be configurable policy. > However, I personally am not sure when I'd ever allow a SHA-256 digest > to fail and I'd trust the SHA-1 digest instead. But that's my > preference and I'm sure we could find someone that would state that's > a necessary policy to hold. > That's the beauty of local policy :) Some folks might want any chain that works - if there is some problem with the SHA-256 DS RR, then try the SHA-1 DS and proceed if it works. If we want SHA-256 to be deployed quickly, then I agree that SHA-256 be the only mandatory to implement algo. And move SHA-1 to NOT RECOMMENDED or even obsolete it. Given the fact that upgrades could be slow (even with the 2010 date), obsoleting it now does not sound like a good idea to me. Scott > > -- > Wes Hardaker > Sparta, Inc. > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Nov 18 17:32:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdEm4-0005FV-Fv for dnsext-archive@megatron.ietf.org; Fri, 18 Nov 2005 17:32:04 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14728 for ; Fri, 18 Nov 2005 17:31:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EdEj8-0007Ze-Jg for namedroppers-data@psg.com; Fri, 18 Nov 2005 22:29:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EdEj7-0007ZJ-Oa for namedroppers@ops.ietf.org; Fri, 18 Nov 2005 22:29:02 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id jAIMSq1R000406 for ; Fri, 18 Nov 2005 17:28:53 -0500 Received: from gorilla ([129.6.220.8]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id jAIMSgbY024740 for ; Fri, 18 Nov 2005 17:28:45 -0500 (EST) From: "Scott Rose" To: "Namedroppers" Subject: RE: Reinforcing the Review decision Date: Fri, 18 Nov 2005 17:28:45 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Importance: Normal X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Olaf M. Kolkman > Sent: Friday, November 18, 2005 10:57 AM > > We will not forward work if during a working group last call not at > least five people have gone on record that they thoroughly reviewed > the most current version of an I-D (and there is rough consensus to > forward the work). > > We would like to ask the working groups consent for this. > I agree to this as well Scott > -- to unsubscribe send a message to namedroppers-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 18 18:14:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdFRa-0006pO-NU for dnsext-archive@megatron.ietf.org; Fri, 18 Nov 2005 18:14:58 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16557 for ; Fri, 18 Nov 2005 18:14:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EdFOC-000BH5-KT for namedroppers-data@psg.com; Fri, 18 Nov 2005 23:11:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EdFOC-000BGo-0i for namedroppers@ops.ietf.org; Fri, 18 Nov 2005 23:11:28 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 1AF6E677F9 for ; Fri, 18 Nov 2005 23:11:26 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id jAINBKSU053697 for ; Sat, 19 Nov 2005 10:11:22 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200511182311.jAINBKSU053697@drugs.dv.isc.org> Cc: Namedroppers From: Mark Andrews Subject: Re: Reinforcing the Review decision In-reply-to: Your message of "Fri, 18 Nov 2005 19:56:34 BST." Date: Sat, 19 Nov 2005 10:11:20 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Dear Colleagues, > > During the Vancouver meeting the folk in the room consented with the > proposal to only forward work to the IESG when we received minimum > number of statements of thorough review. > > We would like re-iterate this proposal on the list and set the > minimum number to five. > > That is: > > We will not forward work if during a working group last call not at > least five people have gone on record that they thoroughly reviewed > the most current version of an I-D (and there is rough consensus to > forward the work). > > We would like to ask the working groups consent for this. > > Olaf and Olafur > DNSEXT chairs. > > > > ----------------------------------------------------------- > Olaf M. Kolkman > NLnet Labs > http://www.nlnetlabs.nl/ Agreed. -- 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 18 18:29:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdFfh-0002H6-0y for dnsext-archive@megatron.ietf.org; Fri, 18 Nov 2005 18:29:33 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19151 for ; Fri, 18 Nov 2005 18:28:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EdFdY-000CcX-FR for namedroppers-data@psg.com; Fri, 18 Nov 2005 23:27:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EdFdX-000CcL-PI for namedroppers@ops.ietf.org; Fri, 18 Nov 2005 23:27:20 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id jAINRJ7b018353 for ; Fri, 18 Nov 2005 23:27:19 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id jAINRJ5I018350 for namedroppers@ops.ietf.org; Fri, 18 Nov 2005 23:27:19 GMT Date: Fri, 18 Nov 2005 23:27:19 +0000 From: bmanning@vacation.karoshi.com To: namedroppers@ops.ietf.org Subject: [Reinforcing the Review decision] Message-ID: <20051118232719.GA18068@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk ++ We would like to ask the working groups consent for this. bless. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Nov 18 19:17:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdGQN-0004Si-RM for dnsext-archive@megatron.ietf.org; Fri, 18 Nov 2005 19:17:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23962 for ; Fri, 18 Nov 2005 19:17:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EdGNc-000GJi-NJ for namedroppers-data@psg.com; Sat, 19 Nov 2005 00:14:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.151.192.200] (helo=sokol.elan.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EdGNa-000GJO-4U for namedroppers@ops.ietf.org; Sat, 19 Nov 2005 00:14:54 +0000 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id jAJ0Emmh027291; Fri, 18 Nov 2005 16:14:48 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id jAJ0EhJP027287; Fri, 18 Nov 2005 16:14:48 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 18 Nov 2005 16:14:43 -0800 (PST) From: "william(at)elan.net" To: "Olaf M. Kolkman" cc: Namedroppers Subject: Re: Reinforcing the Review decision In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk How are you going to get folks to review the proposal if they dont do it voluntarily as it is now and required number is not reached? On Fri, 18 Nov 2005, Olaf M. Kolkman wrote: > Dear Colleagues, > > During the Vancouver meeting the folk in the room consented with the proposal > to only forward work to the IESG when we received minimum number of > statements of thorough review. > > We would like re-iterate this proposal on the list and set the minimum number > to five. > > That is: > > We will not forward work if during a working group last call not at least > five people have gone on record that they thoroughly reviewed the most > current version of an I-D (and there is rough consensus to forward the work). > > We would like to ask the working groups consent for this. > > Olaf and Olafur > DNSEXT chairs. > > > > ----------------------------------------------------------- > 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 18 21:14:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdIF8-0006Wq-Gj for dnsext-archive@megatron.ietf.org; Fri, 18 Nov 2005 21:14:22 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29238 for ; Fri, 18 Nov 2005 21:13:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EdI8b-000Q0R-GU for namedroppers-data@psg.com; Sat, 19 Nov 2005 02:07:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EdI8b-000Q0G-0J for namedroppers@ops.ietf.org; Sat, 19 Nov 2005 02:07:33 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6EC9511426; Sat, 19 Nov 2005 02:07:32 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "william(at)elan.net" cc: "Olaf M. Kolkman" , Namedroppers Subject: Re: Reinforcing the Review decision In-Reply-To: Your message of "Fri, 18 Nov 2005 16:14:43 PST." References: Date: Sat, 19 Nov 2005 02:07:32 +0000 Message-Id: <20051119020732.6EC9511426@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # How are you going to get folks to review the proposal if they dont # do it voluntarily as it is now and required number is not reached? peer pressure. either the wg, or the authors, or the design team, or interested others, will tap on various shoulders, request, demand, bribe, cajole, or even threaten, to get enough reviewers to step forward. the ietf community and culture has many problems but this isn't one of them. if this rule goes into effect, then i predict immediate and positive results for the quality of this WG's output. -- to unsubscribe send a message to namedroppers-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 18 23:19:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdKCT-00012G-Sd for dnsext-archive@megatron.ietf.org; Fri, 18 Nov 2005 23:19:42 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04289 for ; Fri, 18 Nov 2005 23:19:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EdK8X-0008yB-4a for namedroppers-data@psg.com; Sat, 19 Nov 2005 04:15:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EdK8W-0008xg-8n for namedroppers@ops.ietf.org; Sat, 19 Nov 2005 04:15:36 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAJ4FDWr000293; Fri, 18 Nov 2005 23:15:13 -0500 (EST) (envelope-from ogud@ogud.com) Received: from localhost (ogud@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) with ESMTP id jAJ4FCYs000288; Fri, 18 Nov 2005 23:15:13 -0500 (EST) (envelope-from ogud@ogud.com) X-Authentication-Warning: mail.ogud.com: ogud owned process doing -bs Date: Fri, 18 Nov 2005 23:15:12 -0500 (EST) From: Olafur Gudmundsson To: Paul Vixie cc: "william(at)elan.net" , "Olaf M. Kolkman" , Namedroppers Subject: Re: Reinforcing the Review decision In-Reply-To: <20051119020732.6EC9511426@sa.vix.com> Message-ID: <20051118231334.M234@mail.ogud.com> References: <20051119020732.6EC9511426@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Killing the document is the ultimate threat, as Paul points out there are ways, including prodding people personally. In earnest if only 3 people care about a document is it worth writing in the first place ? Olafur On Sat, 19 Nov 2005, Paul Vixie wrote: > # How are you going to get folks to review the proposal if they dont > # do it voluntarily as it is now and required number is not reached? > > peer pressure. either the wg, or the authors, or the design team, or > interested others, will tap on various shoulders, request, demand, bribe, > cajole, or even threaten, to get enough reviewers to step forward. > > the ietf community and culture has many problems but this isn't one of > them. if this rule goes into effect, then i predict immediate and > positive results for the quality of this WG's output. > > -- > to 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 18 23:31:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdKNe-0003hH-F4 for dnsext-archive@megatron.ietf.org; Fri, 18 Nov 2005 23:31:14 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04859 for ; Fri, 18 Nov 2005 23:30:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EdKLe-000ADb-Vr for namedroppers-data@psg.com; Sat, 19 Nov 2005 04:29:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EdKLe-000ADN-0x for namedroppers@ops.ietf.org; Sat, 19 Nov 2005 04:29:10 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id jAJ4Ss7b019591; Sat, 19 Nov 2005 04:28:54 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id jAJ4SsNC019588; Sat, 19 Nov 2005 04:28:54 GMT Date: Sat, 19 Nov 2005 04:28:54 +0000 From: bmanning@vacation.karoshi.com To: Olafur Gudmundsson Cc: Paul Vixie , "william(at)elan.net" , "Olaf M. Kolkman" , Namedroppers Subject: Re: Reinforcing the Review decision Message-ID: <20051119042854.GA18897@vacation.karoshi.com.> References: <20051119020732.6EC9511426@sa.vix.com> <20051118231334.M234@mail.ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051118231334.M234@mail.ogud.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk if only a small group are interested, there is always the individual submission route... --bill On Fri, Nov 18, 2005 at 11:15:12PM -0500, Olafur Gudmundsson wrote: > > Killing the document is the ultimate threat, as Paul points out > there are ways, including prodding people personally. > > In earnest if only 3 people care about a document is it worth > writing in the first place ? > > Olafur > > On Sat, 19 Nov 2005, Paul Vixie wrote: > > ># How are you going to get folks to review the proposal if they dont > ># do it voluntarily as it is now and required number is not reached? > > > >peer pressure. either the wg, or the authors, or the design team, or > >interested others, will tap on various shoulders, request, demand, bribe, > >cajole, or even threaten, to get enough reviewers to step forward. > > > >the ietf community and culture has many problems but this isn't one of > >them. if this rule goes into effect, then i predict immediate and > >positive results for the quality of this WG's output. > > > >-- > >to 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: -- to unsubscribe send a message to namedroppers-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 19 11:26:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdVXt-0005v0-F1 for dnsext-archive@megatron.ietf.org; Sat, 19 Nov 2005 11:26:33 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05814 for ; Sat, 19 Nov 2005 11:25:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EdVTR-0005Mb-Ke for namedroppers-data@psg.com; Sat, 19 Nov 2005 16:21:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EdVTO-0005MK-Jv for namedroppers@ops.ietf.org; Sat, 19 Nov 2005 16:21:54 +0000 Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id C171933C3F; Sat, 19 Nov 2005 16:21:52 +0000 (GMT) Message-ID: <437F5128.1060805@algroup.co.uk> Date: Sat, 19 Nov 2005 16:22:00 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: Namedroppers Subject: Re: Reinforcing the Review decision References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf M. Kolkman wrote: > > > Dear Colleagues, > > During the Vancouver meeting the folk in the room consented with the > proposal to only forward work to the IESG when we received minimum > number of statements of thorough review. > > We would like re-iterate this proposal on the list and set the minimum > number to five. > > That is: > > We will not forward work if during a working group last call not at > least five people have gone on record that they thoroughly reviewed the > most current version of an I-D (and there is rough consensus to forward > the work). > > We would like to ask the working groups consent for this. Yep. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Nov 19 11:48:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdVsm-0001dV-17 for dnsext-archive@megatron.ietf.org; Sat, 19 Nov 2005 11:48:08 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06531 for ; Sat, 19 Nov 2005 11:47:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EdVqI-0006mY-5F for namedroppers-data@psg.com; Sat, 19 Nov 2005 16:45:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [64.233.182.198] (helo=nproxy.gmail.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EdVqH-0006mC-E5 for namedroppers@ops.ietf.org; Sat, 19 Nov 2005 16:45:33 +0000 Received: by nproxy.gmail.com with SMTP id o25so26892nfa for ; Sat, 19 Nov 2005 08:45:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=R1wJ/V3/U8veCdA8ORJBwtuzth1onkdRLFgosslvZCDEVSUSJjo6llSj8I9mgXSVNZpl3ElT83VwwGhXWqBZB8mFG0uxdeAS3OyAVjoNMJiJovl96fnxQChVk4DRJ4sb3KLYo+4WTfGTHOj5ycdjrE5L56M5N7UxQE0gvVEbjAw= Received: by 10.49.5.19 with SMTP id h19mr95121nfi; Sat, 19 Nov 2005 08:45:31 -0800 (PST) Received: by 10.48.108.11 with HTTP; Sat, 19 Nov 2005 08:45:31 -0800 (PST) Message-ID: <487354f10511190845n2271c89ct@mail.gmail.com> Date: Sat, 19 Nov 2005 17:45:31 +0100 From: Robert Martin-Legene To: Namedroppers Subject: Re: Reinforcing the Review decision In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > We would like to ask the working groups consent for this. This is reasonable. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From anthean@alexdullinger.com Sat Nov 19 13:36:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdXZr-0007oU-Ur for dnsext-archive@megatron.ietf.org; Sat, 19 Nov 2005 13:36:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10827 for ; Sat, 19 Nov 2005 13:36:08 -0500 (EST) Received: from [80.90.116.8] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EdXrx-0000EM-E6 for dnsext-archive@ietf.org; Sat, 19 Nov 2005 13:55:26 -0500 Message-ID: <000001c5ed37$4a921900$0100007f@localhost> From: "Chase Allen" To: Subject: Hey buddy, whats up Date: Sat, 19 Nov 2005 21:36:41 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5ED37.4A921900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.6 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5ED37.4A921900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 39 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 47 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5ED37.4A921900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 50 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 41 reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 36 reviews)

------=_NextPart_000_0001_01C5ED37.4A921900-- From owner-namedroppers@ops.ietf.org Sat Nov 19 22:16:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edfgx-0000fN-Eo for dnsext-archive@megatron.ietf.org; Sat, 19 Nov 2005 22:16:35 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27945 for ; Sat, 19 Nov 2005 22:15:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Edfbr-000G6l-2j for namedroppers-data@psg.com; Sun, 20 Nov 2005 03:11:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Edfbp-000G6X-U0 for namedroppers@ops.ietf.org; Sun, 20 Nov 2005 03:11:18 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jAK3AhS6006885; Sat, 19 Nov 2005 22:10:44 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20051119042854.GA18897@vacation.karoshi.com.> References: <20051119020732.6EC9511426@sa.vix.com> <20051118231334.M234@mail.ogud.com> <20051119042854.GA18897@vacation.karoshi.com.> Date: Sat, 19 Nov 2005 22:10:49 -0500 To: bmanning@vacation.karoshi.com From: Edward Lewis Subject: Re: Reinforcing the Review decision Cc: Olafur Gudmundsson , Paul Vixie , "william(at)elan.net" , "Olaf M. Kolkman" , Namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The individual submission ploy would likely not work in this case - i.e., work that fails to attract the interest of a WG won't be easily accepted by the IESG (and the IETF in general). At least not work in the sense that folks generally want something to be standardized. Informational and Experimental submissions may fly, though, I'll give you that, but not standards track. Unless one individual can convince the IESG that the DNS working groups are all washed up on a topic. Keep in mind is that there's a difference between engineering and document management. If one person wants to implement a service that is only of interest to them, there's absolutely no stopping them. If it's code they want, there's no one stopping them in doing it themselves or arranging a business arrangement with a DNS implementer. (No, I'm not going to put in a plug here for anyone.) But the IETF is all about interoperability. If interoperability of some feature is important, you will get people willing to work on a document. The IETF stamp of approval should be reserved for that. I think that sometimes we get caught up in document process self-importance. Documents are not the important thing, nor are theoretic ideals. What's important is providing a service to our community, i.e., collaboration on fundamental ideas and solving real problems. Inter-area review is important, that's why IETF's are held in one large center three times a year. Getting an idea into an RFC isn't the goal. The IETF is an arena that thrives on innovation and innovative ideas. But ultimately the ideas that survive are those that benefit the non-IETF community. I believe that this is the reason why Internet Drafts expire after 6 months - meritorious pipe dreams are noble but unimportant and we have to accept that. So, I also agree that only ideas of widespread voluntary-as-far-as-the-IETF-goes should survive within a working group. Admittance of an idea is not like getting tenure - the idea should be de-admitted once it falls from interest. At 4:28 +0000 11/19/05, bmanning@vacation.karoshi.com wrote: >if only a small group are interested, there is always the individual >submission route... > >--bill > > >On Fri, Nov 18, 2005 at 11:15:12PM -0500, Olafur Gudmundsson wrote: >> >> Killing the document is the ultimate threat, as Paul points out >> there are ways, including prodding people personally. >> >> In earnest if only 3 people care about a document is it worth >> writing in the first place ? >> >> Olafur >> >> On Sat, 19 Nov 2005, Paul Vixie wrote: >> >> ># How are you going to get folks to review the proposal if they dont >> ># do it voluntarily as it is now and required number is not reached? >> > >> >peer pressure. either the wg, or the authors, or the design team, or >> >interested others, will tap on various shoulders, request, demand, bribe, >> >cajole, or even threaten, to get enough reviewers to step forward. >> > >> >the ietf community and culture has many problems but this isn't one of >> >them. if this rule goes into effect, then i predict immediate and >> >positive results for the quality of this WG's output. >> > >> >-- >> >to 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: > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-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 19 22:25:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdfpT-00020k-6l for dnsext-archive@megatron.ietf.org; Sat, 19 Nov 2005 22:25:23 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28133 for ; Sat, 19 Nov 2005 22:24:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Edfnw-000Gqj-PP for namedroppers-data@psg.com; Sun, 20 Nov 2005 03:23:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Edfnt-000GqO-7u for namedroppers@ops.ietf.org; Sun, 20 Nov 2005 03:23:45 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C5A4A11426 for ; Sun, 20 Nov 2005 03:23:44 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: Reinforcing the Review decision In-Reply-To: Your message of "Sat, 19 Nov 2005 22:10:49 EST." References: <20051119020732.6EC9511426@sa.vix.com> <20051118231334.M234@mail.ogud.com> <20051119042854.GA18897@vacation.karoshi.com.> Date: Sun, 20 Nov 2005 03:23:44 +0000 Message-Id: <20051120032344.C5A4A11426@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # Informational and Experimental submissions may fly, though, I'll give # you that, but not standards track. i'm still waiting for an answer as to "in what way has experimental status and being unwelcome on the standards track injured the SRV RR" ? the standards track has two powers. one is to focus the energy of ietf on a somewhat-more-disciplined result than just "write a bunch of rfc's and hope for the best". the other is to inform industry as to which rfc's are generally considered necessary-to-implement. neither of those powers are necessary, or as it turns out, sufficient for a technology to become popular. if the WG doesn't care, then the IESG won't care. experimental status is enough to enable an open source implementation, and in some cases (like SRV) to also enable proprietary implementations, and if those implementations become popular then the experimentalness of the rfc status won't matter, and the ietf will have functioned as a secretary and not as a forum. -- to unsubscribe send a message to namedroppers-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 20 06:58:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdnqH-0008Hs-3z for dnsext-archive@megatron.ietf.org; Sun, 20 Nov 2005 06:58:45 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14554 for ; Sun, 20 Nov 2005 06:58:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Ednkp-000GbQ-KT for namedroppers-data@psg.com; Sun, 20 Nov 2005 11:53:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.151.192.200] (helo=sokol.elan.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Ednkm-000Gb7-48 for namedroppers@ops.ietf.org; Sun, 20 Nov 2005 11:53:04 +0000 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id jAKBp1iL022073; Sun, 20 Nov 2005 03:51:02 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id jAKBp10W022070; Sun, 20 Nov 2005 03:51:01 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sun, 20 Nov 2005 03:51:01 -0800 (PST) From: "william(at)elan.net" To: Scott Rose cc: namedroppers@ops.ietf.org Subject: Re: draft SHA-256 for DS RRs comments In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Since I was not present at recent hash related government sponsored meetings can I get a confirmation that SHA256 is considered to be sufficiently secure and is now recommended where SHA1 previously was to be used? Also will the new hash algorithm be developed and if so when should we expect it? Will it be 160-bit or at minimum 256-bit like SHA256? On Thu, 17 Nov 2005, Scott Rose wrote: > I just finished the draft and I have one comment on Section 3. I don't know > if the wording "MUST perfer DS records with SHA-256..." is necessary. It is > also rather vague for validator implementors - what happens when the SHA-256 > DS RR is invalid, but there is a valid SHA-1? Is the chain still valid? I > think the preference language isn't necessary (local policy :) ) since most > developers know SHA-256 is stronger than SHA-1. > > Also, it might be helpful for readers to include a simple table in the IANA > considerations section detailing the algorithms: > > VALUE Algorithm Status > 0 Reserved - > 1 SHA-1 MANDATORY(1) > 2 SHA-256 MANDATORY > 3-255 Unassigned - > > (1) SHA-1 is still mandatory to implement and deploy for a period following > the publication of this draft to RFC status. This is necessary for a period > of backwards compatibility until SHA-256 is more widely deployed. See > section 4. > > ------------- > Or something similar. The note may not be necessary. > > Scott > **************************************** > Scott Rose > Adv. Network Tech. Div., NIST > +1 301-975-8439 > > https://www-x.antd.nist.gov/dnssec/ > **************************************** -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Nov 20 11:38:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdsD5-000442-Ng for dnsext-archive@megatron.ietf.org; Sun, 20 Nov 2005 11:38:36 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29668 for ; Sun, 20 Nov 2005 11:37:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eds9E-0003ic-7q for namedroppers-data@psg.com; Sun, 20 Nov 2005 16:34:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Eds9D-0003iR-Cy for namedroppers@ops.ietf.org; Sun, 20 Nov 2005 16:34:35 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id jAKGYE7b031589; Sun, 20 Nov 2005 16:34:14 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id jAKGYDDl031586; Sun, 20 Nov 2005 16:34:13 GMT Date: Sun, 20 Nov 2005 16:34:13 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Cc: bmanning@vacation.karoshi.com, Olafur Gudmundsson , Paul Vixie , "william(at)elan.net" , "Olaf M. Kolkman" , Namedroppers Subject: Re: Reinforcing the Review decision Message-ID: <20051120163413.GC22414@vacation.karoshi.com.> References: <20051119020732.6EC9511426@sa.vix.com> <20051118231334.M234@mail.ogud.com> <20051119042854.GA18897@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, Nov 19, 2005 at 10:10:49PM -0500, Edward Lewis wrote: > The individual submission ploy would likely not work in this case - > i.e., work that fails to attract the interest of a WG won't be easily > accepted by the IESG (and the IETF in general). At least not work in > the sense that folks generally want something to be standardized. true enough. > Informational and Experimental submissions may fly, though, I'll give > you that, but not standards track. Unless one individual can > convince the IESG that the DNS working groups are all washed up on a > topic. in fact, they -SHOULD- fly. > But the IETF is all about interoperability. If interoperability of > some feature is important, you will get people willing to work on a > document. The IETF stamp of approval should be reserved for that. er... the IETF doesn't do "interoperability"... it may demand that implementations are interoperable, but it does "do" that work. > I think that sometimes we get caught up in document process > self-importance. Documents are not the important thing, nor are > theoretic ideals. what -IS- important is documenting choices and options. what was tried and why. > What's important is providing a service to our > community, i.e., collaboration on fundamental ideas and solving real > problems. Inter-area review is important, that's why IETF's are held > in one large center three times a year. Getting an idea into an RFC > isn't the goal. RFC == Request For Comments ... getting ideas into a persistant, available, public archive is critical. even bad ideas, false leads, and dead ends deserve to be documented ... if only to show others WHY we ended up where we did. (this is where I REALLY disagree w/ the current IETF chair on his quest to expunge this type of material from the RFC archives.) > The IETF is an arena that thrives on innovation and innovative ideas. > But ultimately the ideas that survive are those that benefit the > non-IETF community. I believe that this is the reason why Internet > Drafts expire after 6 months - meritorious pipe dreams are noble but > unimportant and we have to accept that. IDs are "supposed" to be ephemeral places to draft ideas. If the ideas are explored further, via implementation or other means, then IMHO, they are deserving of persistant documentation, e.g RFC status. The IETF got bogged down in Vendors insistance that RFCs were all of equal weight... hence the attempts to classify RFCs into catagories. ... which fails. So now there are serious attemtps to recast IDs as persistant documents... a sad commentary on the documentation process. > So, I also agree that only ideas of widespread > voluntary-as-far-as-the-IETF-goes should survive within a working > group. Admittance of an idea is not like getting tenure - the idea > should be de-admitted once it falls from interest. i want a persistant archive of everything... even the goofy. but for WG acceptance, i'm comfortable w/ the bar we are setting for ourselves. i'm in favor of indivual submission and getting RFC status for that kind of work, if only as experimental or informational. > At 4:28 +0000 11/19/05, bmanning@vacation.karoshi.com wrote: > >if only a small group are interested, there is always the individual > >submission route... > > > >--bill > > > > > >On Fri, Nov 18, 2005 at 11:15:12PM -0500, Olafur Gudmundsson wrote: > >> > >> Killing the document is the ultimate threat, as Paul points out > >> there are ways, including prodding people personally. > >> > >> In earnest if only 3 people care about a document is it worth > >> writing in the first place ? > >> > >> Olafur > >> > >> On Sat, 19 Nov 2005, Paul Vixie wrote: > >> > >> ># How are you going to get folks to review the proposal if they dont > >> ># do it voluntarily as it is now and required number is not reached? > >> > > >> >peer pressure. either the wg, or the authors, or the design team, or > >> >interested others, will tap on various shoulders, request, demand, > >> bribe, > >> >cajole, or even threaten, to get enough reviewers to step forward. > >> > > >> >the ietf community and culture has many problems but this isn't one of > >> >them. if this rule goes into effect, then i predict immediate and > >> >positive results for the quality of this WG's output. > >> > > >> >-- > >> >to 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: > > > >-- > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with > >the word 'unsubscribe' in a single line as the message text body. > >archive: > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > 3 months to the next trip. I guess it's finally time to settle down and > find a grocery store. -- to unsubscribe send a message to namedroppers-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 21 08:10:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeBQn-0007Ok-7l for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 08:10:01 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28733 for ; Mon, 21 Nov 2005 08:09:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeBKp-000I48-Qy for namedroppers-data@psg.com; Mon, 21 Nov 2005 13:03:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeBKp-000I3s-32 for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 13:03:51 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jALD3flb093505; Mon, 21 Nov 2005 08:03:44 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20051120163413.GC22414@vacation.karoshi.com.> References: <20051119020732.6EC9511426@sa.vix.com> <20051118231334.M234@mail.ogud.com> <20051119042854.GA18897@vacation.karoshi.com.> <20051120163413.GC22414@vacation.karoshi.com.> Date: Mon, 21 Nov 2005 08:03:10 -0500 To: Namedroppers From: Edward Lewis Subject: Re: Reinforcing the Review decision Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:34 +0000 11/20/05, bmanning@vacation.karoshi.com wrote: > > er... the IETF doesn't do "interoperability"... it may demand > that implementations are interoperable, but it does "do" that > work. What I meant is that interoperability is what it best talks about. > what -IS- important is documenting choices and options. what was > tried and why. That would separate the IETF, an engineering organization, from a standards body, wouldn't it? > RFC == Request For Comments ... getting ideas into a persistant, > available, public archive is critical. even bad ideas, false leads, > and dead ends deserve to be documented ... if only to show others WHY > we ended up where we did. That is what I feel too. But, like what NAT and split brain DNS have done to end-to-end uniqueness and coherency, time may have passed by the notion of the RFCs being what just that. I think that's as much a fault of the IETF (lack of education/outreach) as the vendor community (wants easy to consume standards). > i want a persistant archive of everything... even the goofy. You would, Bill, you would. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-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 21 09:46:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeCwO-0006u1-3U for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 09:46:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05196 for ; Mon, 21 Nov 2005 09:46:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeCte-000OaP-HT for namedroppers-data@psg.com; Mon, 21 Nov 2005 14:43:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeCtd-000Oa9-Ks for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 14:43:53 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jALEhnog037543; Mon, 21 Nov 2005 15:43:49 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: References: <20051119020732.6EC9511426@sa.vix.com> <20051118231334.M234@mail.ogud.com> <20051119042854.GA18897@vacation.karoshi.com.> <20051120163413.GC22414@vacation.karoshi.com.> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-23--341794238" Message-Id: <09EE6B1D-2846-4CC4-BA11-E70E13F1614F@NLnetLabs.nl> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Reinforcing the Review decision Date: Mon, 21 Nov 2005 15:43:48 +0100 To: Edward Lewis X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-23--341794238 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Thorough workgroup review adds credibility to the standards track document; how the community distinguishes between standards track and informational/experimental is somewhat out of scope for this list isn't it? Not wearing a hat. --Olaf --Apple-Mail-23--341794238 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.1 (Darwin) Comment: This message is locally signed. iD8DBQFDgd0ktN/ca3YJIocRAh0EAKD6CKxF2toOP9c7bA6IhjrVUBCuhgCfWre9 BUzsNp4md6aghoJpvvFJL3Y= =66B2 -----END PGP SIGNATURE----- --Apple-Mail-23--341794238-- -- to unsubscribe send a message to namedroppers-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 21 10:01:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeDB1-0000tw-9W for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 10:01:51 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05941 for ; Mon, 21 Nov 2005 10:01:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeD8n-000Pvi-VX for namedroppers-data@psg.com; Mon, 21 Nov 2005 14:59:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeD8n-000PvN-2X for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 14:59:33 +0000 Received: from [10.31.32.103] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jALExNwH095180; Mon, 21 Nov 2005 09:59:23 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <09EE6B1D-2846-4CC4-BA11-E70E13F1614F@NLnetLabs.nl> References: <20051119020732.6EC9511426@sa.vix.com> <20051118231334.M234@mail.ogud.com> <20051119042854.GA18897@vacation.karoshi.com.> <20051120163413.GC22414@vacation.karoshi.com.> <09EE6B1D-2846-4CC4-BA11-E70E13F1614F@NLnetLabs.nl> Date: Mon, 21 Nov 2005 09:59:25 -0500 To: "Olaf M. Kolkman" From: Edward Lewis Subject: Re: Reinforcing the Review decision Cc: Edward Lewis , Namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:43 +0100 11/21/05, Olaf M. Kolkman wrote: >Thorough workgroup review adds credibility to the standards track document; >how the community distinguishes between standards track and informational/ >experimental is somewhat out of scope for this list isn't it? > >Not wearing a hat. Hatless and balding-ly, I'd say that it is a consideration for the proposal. Given that it seems to me that the current state of the IESG is to take any remotely DNS related document and pass it by the DNS working groups. In some cases, if the working groups decide to not take the topic up, my assumption is that the IESG will refuse to pass the document. Of course, one can always try to bypass the IESG and go to the RFC Editor - but the editor will ask the IESG for an opinion. If the editor is satisfied that it's not an IETF matter, the document goes on the backburner queue. (The queue of documents handled when there's nothing else to do. I've heard it from the editor - that non-IETF/IESG documents are handled when there's no IETF work to do.) Given that the editor takes so long to handle IETF documents, being on the backburner queue essentially kills a document. What that all means is, if it is correct, that if an idea fails to meet the bar we set with this proposal, then the idea will never be recorded in an RFC in our careers. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From fareymist@autohausdogan.com Mon Nov 21 10:17:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeDQS-0004IQ-EH for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 10:17:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07111 for ; Mon, 21 Nov 2005 10:17:08 -0500 (EST) Received: from [81.195.116.202] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EeDis-0005xB-Es for dnsext-archive@ietf.org; Mon, 21 Nov 2005 10:36:51 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Mon, 21 Nov 2005 18:15:59 +0300 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Mon, 21 Nov 2005 18:15:59 +0300 Message-ID: <000001c5eead$8d75fd00$0100007f@localhost> From: "Nathaniel Price" To: Subject: Last chance to supercharge your performance! Date: Mon, 21 Nov 2005 18:15:59 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5EEAD.8D75FD00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5EEAD.8D75FD00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! Name Patches Regular Now Steel Package 10 Patches $79.95 $49.95 Free shipping Silver Package 25 Patches $129.95 $99.95 Free shipping and exercise manual included Gold Package 40 Patches $189.95 $149.95 Free shipping and exercise manual included Platinum Package 65 Patches $259.95 $199.95 Free shipping and exercise manual included ------=_NextPart_000_0001_01C5EEAD.8D75FD00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

Name Patches Regular Now
Steel Package 10 Patches $79.95 $49.95 Free shipping
Silver Package 25 Patches $129.95 $99.95 Free shipping and exercise manual included
Gold Package 40 Patches $189.95 $149.95 Free shipping and exercise manual included
Platinum Package 65 Patches $259.95 $199.95 Free shipping and exercise manual included
------=_NextPart_000_0001_01C5EEAD.8D75FD00-- From owner-namedroppers@ops.ietf.org Mon Nov 21 10:38:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeDkS-0008Vv-OF for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 10:38:28 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09550 for ; Mon, 21 Nov 2005 10:37:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeDhT-0002Mm-5E for namedroppers-data@psg.com; Mon, 21 Nov 2005 15:35:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, INFO_TLD autolearn=no version=3.1.0 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeDhQ-0002MC-DW for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 15:35:20 +0000 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1EeDhP-0004ty-Iw for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 10:35:19 -0500 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id 5C3C813744; Mon, 21 Nov 2005 10:35:16 -0500 (EST) Date: Mon, 21 Nov 2005 10:35:16 -0500 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: Reinforcing the Review decision Message-ID: <20051121153516.GE12036@libertyrms.info> Reply-To: Andrew Sullivan References: <20051119020732.6EC9511426@sa.vix.com> <20051118231334.M234@mail.ogud.com> <20051119042854.GA18897@vacation.karoshi.com.> <20051120163413.GC22414@vacation.karoshi.com.> <09EE6B1D-2846-4CC4-BA11-E70E13F1614F@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Nov 21, 2005 at 09:59:25AM -0500, Edward Lewis wrote: > there's nothing else to do. I've heard it from the editor - that > non-IETF/IESG documents are handled when there's no IETF work to do.) > Given that the editor takes so long to handle IETF documents, being > on the backburner queue essentially kills a document. To be fair, what we heard in a report in Vancouver is that there are plans currently in implementation to try to make the queue move at least as fast as the input. So one could argue that this problem is scheduled to be corrected. But in any case. . . > What that all means is, if it is correct, that if an idea fails to > meet the bar we set with this proposal, then the idea will never be > recorded in an RFC in our careers. . . .even if that's true, it's not an objection. I'd argue that the answer to sub-optimal performance in one area of a system is surely not to bodge up some other part of the system to avoid the problem, in such a way that the bodged portion of the system thereby does not work as planned. I think that such a description is apt for "everything goes through the WG, because if it doesn't, it won't get any attention." As others have already pointed out, if we can't get at least 5 people to review a document, in what sense can it be called a product of the "group"? A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +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 21 10:41:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeDnR-00010W-Dw for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 10:41:33 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09787 for ; Mon, 21 Nov 2005 10:40:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeDlf-0002f7-Dq for namedroppers-data@psg.com; Mon, 21 Nov 2005 15:39:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeDle-0002es-Dx for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 15:39:42 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jALFdd3O038241; Mon, 21 Nov 2005 16:39:39 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: References: <20051119020732.6EC9511426@sa.vix.com> <20051118231334.M234@mail.ogud.com> <20051119042854.GA18897@vacation.karoshi.com.> <20051120163413.GC22414@vacation.karoshi.com.> <09EE6B1D-2846-4CC4-BA11-E70E13F1614F@NLnetLabs.nl> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-25--338449471" Message-Id: <70859ED7-3F31-4D0E-BFB9-DBF94B2E86F4@NLnetLabs.nl> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Reinforcing the Review decision Date: Mon, 21 Nov 2005 16:39:32 +0100 To: Edward Lewis X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-25--338449471 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Nov 21, 2005, at 15:59 , Edward Lewis wrote: > Given that it seems to me that the current state of the IESG is to > take any remotely DNS related document and pass it by the DNS > working groups. In some cases, if the working groups decide to not > take the topic up, my assumption is that the IESG will refuse to > pass the document. I zoom in on "pass it by": If documents that are outside of our charter need review then the IESG, or the relevant working groups will seek to get that review, or in other words "pass it by" for review. Personally I commit to provide this sort of review (so now and then) and I sincerely hope that there are more persons that are willing to make this sort of commitment. We are now talking about review of DNSEXT working group documents. That is where we have our specific responsibility. peer-namedropper, --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-25--338449471 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.1 (Darwin) Comment: This message is locally signed. iD8DBQFDgeo5tN/ca3YJIocRAhj3AKDWEyg4x+4xmFoRJDXTo6epmuCimwCgpFUf ziuzSaQwu3jVWkIkZKouSrw= =oZBJ -----END PGP SIGNATURE----- --Apple-Mail-25--338449471-- -- to unsubscribe send a message to namedroppers-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 21 11:33:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeEc8-0004r7-6P for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 11:33:56 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12861 for ; Mon, 21 Nov 2005 11:33:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeEZH-0005rD-Sv for namedroppers-data@psg.com; Mon, 21 Nov 2005 16:30:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeEZE-0005qn-A9 for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 16:30:56 +0000 Received: from [10.31.32.103] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jALGUjhP095567; Mon, 21 Nov 2005 11:30:46 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <70859ED7-3F31-4D0E-BFB9-DBF94B2E86F4@NLnetLabs.nl> References: <20051119020732.6EC9511426@sa.vix.com> <20051118231334.M234@mail.ogud.com> <20051119042854.GA18897@vacation.karoshi.com.> <20051120163413.GC22414@vacation.karoshi.com.> <09EE6B1D-2846-4CC4-BA11-E70E13F1614F@NLnetLabs.nl> <70859ED7-3F31-4D0E-BFB9-DBF94B2E86F4@NLnetLabs.nl> Date: Mon, 21 Nov 2005 11:30:49 -0500 To: "Olaf M. Kolkman" From: Edward Lewis Subject: Re: Reinforcing the Review decision Cc: Edward Lewis , Namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:39 +0100 11/21/05, Olaf M. Kolkman wrote: >it by" for review. Personally I commit to provide this sort of review (so now >and then) and I sincerely hope that there are more persons that are willing >to make this sort of commitment. > >We are now talking about review of DNSEXT working group documents. That is >where we have our specific responsibility. > >peer-namedropper, Dear peer gynt, Let's say bert.secret-wg.org decides that it is a good idea to put in a txt record at the apex of the zone that discloses the location of the next event Bert will attend and implements this. Further, a draft is submitted, intended to ask for a new RR type "NXTEVT" to be used by all domains to state where they will next be represented and that this record SHOULD(2119) be included in all NS responses for the domain name. You can bet that this would be "passed by" the DNSEXT WG and it would get thumbs down. (Special processing, etc.) This idea would never get to RFC with these rules. However, this doesn't bar the proposer going ahead anyway and hack into an open source name server and put in this record. There's nothing stopping this from being published under the "bad ideas" link of the Secret WG web site. This kind of goofy idea, which Bill would like to see documented, would never make it to the RFC stage. What a shame - imagine all that useless energy unwasted. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-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 21 13:36:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGX1-0000FN-Hs for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 13:36:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20989 for ; Mon, 21 Nov 2005 13:36:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeGT6-000E5c-8R for namedroppers-data@psg.com; Mon, 21 Nov 2005 18:32:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeGT5-000E5O-Ie for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 18:32:43 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id jALIWg7b004935 for ; Mon, 21 Nov 2005 18:32:42 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id jALIWgEr004932 for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 18:32:42 GMT Date: Mon, 21 Nov 2005 18:32:42 +0000 From: bmanning@vacation.karoshi.com To: namedroppers@ops.ietf.org Subject: "orphaned" RRsets & DNSSEC Message-ID: <20051121183242.GM4433@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk So... Hokay... DNSSEC is a fine and useful BOS ... but there is this little nagging problem that is bugging me. One of the lemas is that zones are signed, which leaves the small problem of validating glue. others have argued that the proper response is to insist on all glue be removed by excising all the "out of baliwick" data - forcing servers to being the zone. nice idea, but will take a -LONG- time to gain operational traction. So in the mean time, we have signed zones w/ "orphaned" RRsets. Is there any reason why we can't validate the NS records, perhaps using the same general techniques as would be used for incremental signing? --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 21 13:49:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeGjh-00046g-UV for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 13:49:54 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23040 for ; Mon, 21 Nov 2005 13:49:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeGhb-000F58-Oz for namedroppers-data@psg.com; Mon, 21 Nov 2005 18:47:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeGha-000F4n-Ut for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 18:47:43 +0000 Received: from [10.31.32.103] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id jALIlUCC098717; Mon, 21 Nov 2005 13:47:31 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20051121183242.GM4433@vacation.karoshi.com.> References: <20051121183242.GM4433@vacation.karoshi.com.> Date: Mon, 21 Nov 2005 13:47:35 -0500 To: bmanning@vacation.karoshi.com From: Edward Lewis Subject: Re: "orphaned" RRsets & DNSSEC Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 18:32 +0000 11/21/05, bmanning@vacation.karoshi.com wrote: >So... Hokay... > > DNSSEC is a fine and useful BOS ... but there is this little nagging >problem that is bugging me. One of the lemas is that zones are signed, which >leaves the small problem of validating glue. others have argued that the >proper response is to insist on all glue be removed by excising all the >"out of baliwick" data - forcing servers to being the zone. nice idea, but >will take a -LONG- time to gain operational traction. So in the mean time, >we have signed zones w/ "orphaned" RRsets. > > Is there any reason why we can't validate the NS records, perhaps >using the same general techniques as would be used for incremental signing? I'm not clear on the question. Are you asking why the parent doesn't sign the cutpoint NS RRset? Are you calling the NS RRSets part of the glue? (I've always thought the glue to be the address records pertaining to the cutpoints and not the NS sets.) One of the basic tenets of DNSSEC is to have the authority on a RRset be the sole provider of authentication meta-data, i.e., the signature. I've always liked the model of "let the NXT record note the presence of an NS set and have that signed" as proof that a cut point was granted by the parent without making a statement about the "Left Hand Side" of the NS data. Only the child signs the NS RRsets, the appropriate authority signs the address records that appear as glue. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-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 21 14:08:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeH1X-0001GG-CV for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 14:08:23 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24618 for ; Mon, 21 Nov 2005 14:07:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeGzL-000GPt-SC for namedroppers-data@psg.com; Mon, 21 Nov 2005 19:06:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeGzH-000GOs-6O for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 19:05:59 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id CA8CD11425 for ; Mon, 21 Nov 2005 19:05:58 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: "orphaned" RRsets & DNSSEC In-Reply-To: Your message of "Mon, 21 Nov 2005 18:32:42 GMT." <20051121183242.GM4433@vacation.karoshi.com.> References: <20051121183242.GM4433@vacation.karoshi.com.> Date: Mon, 21 Nov 2005 19:05:58 +0000 Message-Id: <20051121190558.CA8CD11425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # DNSSEC is a fine and useful BOS ... but there is this little nagging # problem that is bugging me. One of the lemas is that zones are signed, # which leaves the small problem of validating glue. others have argued that # the proper response is to insist on all glue be removed by excising all the # "out of baliwick" data - forcing servers to being the zone. nice idea, but # will take a -LONG- time to gain operational traction. So in the mean time, # we have signed zones w/ "orphaned" RRsets. dnssec only signs authority data. glue is (by definition) not authority data. the way glue is protected is that if you follow a delegation using supplied glue and the server you reach isn't signing its data with the key the parent's DS gave you, you know that the glue is evil and you can discard it, signal an error, try the next glue, refetch the glue from the apparent real nameservers for the enclosing zones of the glue, or treat the zone as "in failure", according to (drum roll, please) "local policy". this leads directly to the problem masataka pointed out ten years ago, where if all of FOO.NET's nameservers are under FOO.COM, and vice versa, there's a reasonable chance of both zones becoming unreachable. DNSSEC does not create that problem, it's inherited from DNS. DNSSEC doesn't even make it any worse. # Is there any reason why we can't validate the NS records, perhaps # using the same general techniques as would be used for incremental signing? yes. because we have to stop adding requirements some day. let's start now? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 21 14:17:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeHAp-00032x-0o for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 14:17:55 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25583 for ; Mon, 21 Nov 2005 14:17:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeH7v-000H4a-GS for namedroppers-data@psg.com; Mon, 21 Nov 2005 19:14:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeH7u-000H4P-MT for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 19:14:54 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 2EB2E11D666; Mon, 21 Nov 2005 11:14:53 -0800 (PST) From: Wes Hardaker To: "william(at)elan.net" Cc: Scott Rose , namedroppers@ops.ietf.org Subject: Re: draft SHA-256 for DS RRs comments Organization: Sparta References: Date: Mon, 21 Nov 2005 11:14:52 -0800 In-Reply-To: (william elan net's message of "Sun, 20 Nov 2005 03:51:01 -0800 (PST)") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On Sun, 20 Nov 2005 03:51:01 -0800 (PST), "william(at)elan.net" said: william> Also will the new hash algorithm be developed and if so when william> should we expect it? Will it be 160-bit or at minimum 256-bit william> like SHA256? There is already a internet-draft (draft-ietf-dnsext-ds-sha256-00.txt) that describes this and specifies a full 256 bit length. -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 21 14:22:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeHFX-0004E5-DS for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 14:22:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26352 for ; Mon, 21 Nov 2005 14:22:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeHDr-000HYi-8N for namedroppers-data@psg.com; Mon, 21 Nov 2005 19:21:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeHDq-000HYX-Q3 for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 19:21:02 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 5AFA911D666; Mon, 21 Nov 2005 11:21:01 -0800 (PST) From: Wes Hardaker To: namedroppers@ops.ietf.org Subject: sha256 requirement consensus estimate Organization: Sparta Date: Mon, 21 Nov 2005 11:21:00 -0800 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Based on the recent conversations, I think that: 1) rough consensus is that deployment requirements shouldn't be included at all. Policy with respect to preference should also not be included (I liked my replacement text saying it had to be configurable and have a default to prefer 256, but no one responded to that so that certainly doesn't meet consensus). 2) We should specify that SHA-256 MUST be supported. 3) I actually think that there is more people leaning toward including a statement saying that SHA-1 be declared obsolete in the document. This is the statement that is most on the line and I'm not sure whether or not there is enough support behind it to include it. Opinions? -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 21 15:16:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeI5j-0001X5-Ph for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 15:16:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03843 for ; Mon, 21 Nov 2005 15:16:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeI4G-000LDR-Ov for namedroppers-data@psg.com; Mon, 21 Nov 2005 20:15:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeI4G-000LDG-9z for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 20:15:12 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id jALKFB7b005441; Mon, 21 Nov 2005 20:15:11 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id jALKFASn005438; Mon, 21 Nov 2005 20:15:10 GMT Date: Mon, 21 Nov 2005 20:15:10 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: "orphaned" RRsets & DNSSEC Message-ID: <20051121201510.GD5146@vacation.karoshi.com.> References: <20051121183242.GM4433@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Nov 21, 2005 at 01:47:35PM -0500, Edward Lewis wrote: > At 18:32 +0000 11/21/05, bmanning@vacation.karoshi.com wrote: > >So... Hokay... > > > > DNSSEC is a fine and useful BOS ... but there is this little nagging > >problem that is bugging me. One of the lemas is that zones are signed, > >which > >leaves the small problem of validating glue. others have argued that the > >proper response is to insist on all glue be removed by excising all the > >"out of baliwick" data - forcing servers to being the zone. nice idea, but > >will take a -LONG- time to gain operational traction. So in the mean time, > >we have signed zones w/ "orphaned" RRsets. > > > > Is there any reason why we can't validate the NS records, perhaps > >using the same general techniques as would be used for incremental signing? > > I'm not clear on the question. Are you asking why the parent doesn't > sign the cutpoint NS RRset? Are you calling the NS RRSets part of > the glue? (I've always thought the glue to be the address records > pertaining to the cutpoints and not the NS sets.) the NS RRset and the associated PTR records ... > One of the basic tenets of DNSSEC is to have the authority on a RRset > be the sole provider of authentication meta-data, i.e., the signature. yes. > I've always liked the model of "let the NXT record note the presence > of an NS set and have that signed" as proof that a cut point was > granted by the parent without making a statement about the "Left Hand > Side" of the NS data. Only the child signs the NS RRsets, the > appropriate authority signs the address records that appear as glue. that gets me partly where i want to go... :) > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > 3 months to the next trip. I guess it's finally time to settle down and > find a grocery store. -- to unsubscribe send a message to namedroppers-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 21 15:17:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeI68-0001c1-Lz for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 15:17:08 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03880 for ; Mon, 21 Nov 2005 15:16:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeI2F-000L6K-Uy for namedroppers-data@psg.com; Mon, 21 Nov 2005 20:13:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeI2F-000L64-38 for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 20:13:07 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id jALKD67b005419; Mon, 21 Nov 2005 20:13:06 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id jALKD6SW005416; Mon, 21 Nov 2005 20:13:06 GMT Date: Mon, 21 Nov 2005 20:13:06 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: "orphaned" RRsets & DNSSEC Message-ID: <20051121201306.GC5146@vacation.karoshi.com.> References: <20051121183242.GM4433@vacation.karoshi.com.> <20051121190558.CA8CD11425@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051121190558.CA8CD11425@sa.vix.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Nov 21, 2005 at 07:05:58PM +0000, Paul Vixie wrote: > # DNSSEC is a fine and useful BOS ... but there is this little nagging > # problem that is bugging me. One of the lemas is that zones are signed, > # which leaves the small problem of validating glue. others have argued that > # the proper response is to insist on all glue be removed by excising all the > # "out of baliwick" data - forcing servers to being the zone. nice idea, but > # will take a -LONG- time to gain operational traction. So in the mean time, > # we have signed zones w/ "orphaned" RRsets. > > dnssec only signs authority data. glue is (by definition) not authority data. not authority data for the zone in question. it is authority data for some part of the heirarchy tho... > the way glue is protected is that if you follow a delegation using supplied > glue and the server you reach isn't signing its data with the key the parent's > DS gave you, you know that the glue is evil and you can discard it, signal an > error, try the next glue, refetch the glue from the apparent real nameservers > for the enclosing zones of the glue, or treat the zone as "in failure", > according to (drum roll, please) "local policy". yes, yes... the presumption of fully signed heirarchy and/or locally maintained TA's... Is that -ALL- there is for choice? > this leads directly to the problem masataka pointed out ten years ago, where > if all of FOO.NET's nameservers are under FOO.COM, and vice versa, there's a > reasonable chance of both zones becoming unreachable. DNSSEC does not create > that problem, it's inherited from DNS. DNSSEC doesn't even make it any worse. well, DNSSEC doesn't make it better. and in the presence of actual application validation attempts, it couldbe much worse. > # Is there any reason why we can't validate the NS records, perhaps > # using the same general techniques as would be used for incremental signing? > > yes. because we have to stop adding requirements some day. let's start now? er... because we have to stop is not, IMHO, a credible reason. or are you sugestting that this is such a fundamental change, that we would have to scrap what has been done to add/integrate this spiffy chromed hood ornement to the DNSSEC funny car? or, are you concerned that DNSSEC will never gain adoption as long as there are suggested changed, modifications, additions, tweeks, etc. being proposed? Kind of like the DNS will never gain adoption until people stop trying to add, change, modify or tweek it? --bill > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-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 21 15:44:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeIWe-0000Z1-8q for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 15:44:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06402 for ; Mon, 21 Nov 2005 15:43:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeIUK-000MqG-SX for namedroppers-data@psg.com; Mon, 21 Nov 2005 20:42:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeIUK-000Mpu-AE for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 20:42:08 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E6F9611425 for ; Mon, 21 Nov 2005 20:42:07 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: "orphaned" RRsets & DNSSEC In-Reply-To: Your message of "Mon, 21 Nov 2005 20:13:06 GMT." <20051121201306.GC5146@vacation.karoshi.com.> References: <20051121183242.GM4433@vacation.karoshi.com.> <20051121190558.CA8CD11425@sa.vix.com> <20051121201306.GC5146@vacation.karoshi.com.> Date: Mon, 21 Nov 2005 20:42:07 +0000 Message-Id: <20051121204207.E6F9611425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # > dnssec only signs authority data. glue is (by definition) not authority # > data. # # not authority data for the zone in question. it is authority # data for some part of the heirarchy tho... in principle, then, a referring server could fetch, validate, and transmit the covering RRSIGs for any out-of-bailiwick glue it wants to hand out? # > according to (drum roll, please) "local policy". # # yes, yes... the presumption of fully signed heirarchy and/or locally # maintained TA's... Is that -ALL- there is for choice? the decision was made about a decade ago to force trust to follow delegation. while it'd be a nicer security market if anybody could sign anybody else's key, that's not what we ended up deciding. # > because we have to stop adding requirements some day. let's start now? # # er... because we have to stop is not, IMHO, a credible reason. if you think endless design and redesign and requirement change is credible, then i want some of whatever funding YOU'RE smoking. (mine isn't like that.) # or are you sugestting that this is such a fundamental change, that # we would have to scrap what has been done to add/integrate this # spiffy chromed hood ornement to the DNSSEC funny car? # # or, are you concerned that DNSSEC will never gain adoption as long # as there are suggested changed, modifications, additions, tweeks, # etc. being proposed? Kind of like the DNS will never gain adoption # until people stop trying to add, change, modify or tweek it? i'm suggesting that we have to call it deployable, and deploy it, and then we can go right on changing it. just like was done with dns, which was a total trainwreck when deployed, by today's lofty standards. -- to unsubscribe send a message to namedroppers-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 21 16:14:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeIzq-0003BY-9S for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 16:14:42 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13036 for ; Mon, 21 Nov 2005 16:14:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeIxW-000PVF-Rp for namedroppers-data@psg.com; Mon, 21 Nov 2005 21:12:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.54 (FreeBSD)) id 1EeIxV-000PUr-Ve for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 21:12:18 +0000 Received: (qmail 20610 invoked from network); 21 Nov 2005 21:41:32 -0000 Received: from yahoobb219001188003.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.3) by necom830.hpcl.titech.ac.jp with SMTP; 21 Nov 2005 21:41:32 -0000 Message-ID: <43823830.30406@necom830.hpcl.titech.ac.jp> Date: Tue, 22 Nov 2005 06:12:16 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: "orphaned" RRsets & DNSSEC References: <20051121183242.GM4433@vacation.karoshi.com.> <20051121190558.CA8CD11425@sa.vix.com> <20051121201306.GC5146@vacation.karoshi.com.> <20051121204207.E6F9611425@sa.vix.com> In-Reply-To: <20051121204207.E6F9611425@sa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > # > dnssec only signs authority data. glue is (by definition) not authority > # > data. > # > # not authority data for the zone in question. it is authority > # data for some part of the heirarchy tho... > > in principle, then, a referring server could fetch, validate, and transmit > the covering RRSIGs for any out-of-bailiwick glue it wants to hand out? The solution, as I said 10(?) years ago, is to add tags to glues in cache. Glues in cache should be tagged with parent zones of the referral points (though it is better to tag with referred zones, it involves modification to zone file format, XFER protocols etc.). The cached glues should not be used to answer normal reply. Cached glues should be used for cached referral if tags match the referring zones. There is nothing DNSSEC specific. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 21 16:14:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeJ05-0003N9-1d for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 16:14:57 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13077 for ; Mon, 21 Nov 2005 16:14:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeIxM-000PUA-9p for namedroppers-data@psg.com; Mon, 21 Nov 2005 21:12:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeIxL-000PTn-AN for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 21:12:07 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO0012A6; 21 Nov 2005 16:16:51 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 21 Nov 2005 16:16:46 -0500 Received: from connotech.com (209.71.204.109) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG0012A4; 21 Nov 2005 16:16:39 -0500 Message-ID: <43824006.4030308@connotech.com> Date: Mon, 21 Nov 2005 16:45:42 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org CC: ogud@ogud.com Subject: Turning off and turning on DNSSEC for a zone Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit To the DNSEXT working group: This post follows on an observation by Olafur (made during the IETF-64 DNSEXT wg session) that DNSSEC might be turned off and on for a zone, perhaps with emphasis on islands of trust. I think the question might be broken down in sub-questions related to a) the parent zone status, and b) the effect of turning off DNSSEC on child zones. a) the parent zone status Parent DNSSEC-aware Change the status reported by the parent zone from secure to insecure (and then reverse) ... no trust anchor key issue. Parent DNSSEC-oblivious (or root zone) Zone status from secure to indeterminate (and then reverse) ... with TAKREM as a TAK-rollover mechanism, going back from indeterminate to secure is supported (perhaps with the inconvenience that turning DNSSEC back on consumes a pre-announced trust anchor key if the key lifetime is handled in one of the three mechanisms explained in another post on the namedroppers list today) b) the effect of turning off DNSSEC on child zones Child DNSSEC-oblivious Child zone status going from insecure to indeterminate (and then reverse) ... no trust anchor key issue Child DNSSEC-aware, not a trust anchor key Child zone status going from secure to indeterminate (and then reverse) ... no trust anchor key issue Child DNSSEC-aware, child zone trust anchor key managed with TAKREM (e.g. the child zone became DNSSEC-aware before its parent and resolvers still contain the related configuration data, or e.g. the child zone has a trust anchor key configuration in a "private trust" arrangement) Child zone status staying secure, from normal delegation to trusted anchor key (and then reverse) ... supported by TAKREM Hope it helps ... -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 21 16:14:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeJ07-0003Qx-PY for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 16:14:59 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13083 for ; Mon, 21 Nov 2005 16:14:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeIxN-000PUQ-Ks for namedroppers-data@psg.com; Mon, 21 Nov 2005 21:12:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EeIxN-000PUD-0r for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 21:12:09 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO0012A7; 21 Nov 2005 16:16:52 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 21 Nov 2005 16:16:46 -0500 Received: from connotech.com (209.71.204.109) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG0012A5; 21 Nov 2005 16:16:45 -0500 Message-ID: <4382400B.5000606@connotech.com> Date: Mon, 21 Nov 2005 16:45:47 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org CC: Mike.StJohns@nominum.com Subject: The lifetime of a Trust Anchor Key Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit To the DNSEXT working group: This post is in answer of a question asked during the IETF-64 DNSEXT wg session, about the lifetime of DNSKEY records for trust anchor keys. Indeed, there is no notion of "lifetime" for a trust anchor key in the current DNSSEC protocols. In the TAKREM for DNSSEC presentations, I erroneously assumed that a DNSKEY TTL value, and/or RRSIG validity period would carry a DNSKEY lifetime information, while in fact the TTL information is for cached data handling and the RRSIG validity period applies to every DNSKEY in the RRset. There is perhaps an broader issue of prevention of replay attacks based on re-introducing and old signature key somewhere in the DNSSEC architecture. For secure DNS delegations, the verifications that should be made by a parent zone before signing a DS record should prevent such replay attacks. The replay attack threat is more acute for trust anchor keys because there is no parental oversight of the current valid key(s). For DNSSEC trust anchor keys rolled over with the TAKREM proposal, I see three alternatives: A validity period might be introduced to (a revised definition of) the SDDA record format. This would affix an explicit lifetime to a trust anchor key. The DNS resolver might assume that a trust anchor key record is expired when it disappeared from a zone's DNSKEY RRset *AND* a new valid trust anchor key has been detected. The revoked bit from the Mike St-Johns proposal (draft-ietf-dnsext-trustupdate-timers-01.txt) can be used as an indication that a trust anchor key has been revoked. With any of these solution avenues, there is an implicit requirement for the DNS resolver to remember the expired status of past trust anchor keys, at least to the extent that the DNS resolver local policy is to protect itself against Trust Anchor Key replay attacks. The details should be worked on later since the DNSEXT wg attention is currently focused on trust anchor key management requirements. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 21 16:17:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeJ2w-0005zS-PR for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 16:17:58 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13404 for ; Mon, 21 Nov 2005 16:17:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeJ0f-000Puo-31 for namedroppers-data@psg.com; Mon, 21 Nov 2005 21:15:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeJ0c-000PuT-O3 for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 21:15:30 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id jALLFU7b006319; Mon, 21 Nov 2005 21:15:30 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id jALLFUkY006316; Mon, 21 Nov 2005 21:15:30 GMT Date: Mon, 21 Nov 2005 21:15:30 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: "orphaned" RRsets & DNSSEC Message-ID: <20051121211530.GI5146@vacation.karoshi.com.> References: <20051121183242.GM4433@vacation.karoshi.com.> <20051121190558.CA8CD11425@sa.vix.com> <20051121201306.GC5146@vacation.karoshi.com.> <20051121204207.E6F9611425@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051121204207.E6F9611425@sa.vix.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Nov 21, 2005 at 08:42:07PM +0000, Paul Vixie wrote: > # > dnssec only signs authority data. glue is (by definition) not authority > # > data. > # > # not authority data for the zone in question. it is authority > # data for some part of the heirarchy tho... > > in principle, then, a referring server could fetch, validate, and transmit > the covering RRSIGs for any out-of-bailiwick glue it wants to hand out? if such out-of-baliwick glue was in part of a signed heirarchy itself -AND- the local system attempting the validation had associated Trust Anchors for those parts of the signed heirarchy... > # > according to (drum roll, please) "local policy". > # > # yes, yes... the presumption of fully signed heirarchy and/or locally > # maintained TA's... Is that -ALL- there is for choice? > > the decision was made about a decade ago to force trust to follow delegation. > while it'd be a nicer security market if anybody could sign anybody else's key, > that's not what we ended up deciding. so for the dnssec trust model, self-signed or third-party signatures are not to be used/trusted. but does this lema preclude the existance of such signatures? > # > because we have to stop adding requirements some day. let's start now? > # > # er... because we have to stop is not, IMHO, a credible reason. > > if you think endless design and redesign and requirement change is credible, > then i want some of whatever funding YOU'RE smoking. (mine isn't like that.) dns (and dnssec) have been inthe process of "endless design and redesign" since their inception. i'm not asking for anything more than status quo. if you -WANT- the kind of funding that supports and encourages research (where its ok to have novel ideas that may not fly in the commercial world) then that kind of funding is there... but there are downsides... as is true w/ nearly all funding models. > i'm suggesting that we have to call it deployable, and deploy it, and then we > can go right on changing it. just like was done with dns, which was a total > trainwreck when deployed, by today's lofty standards. dns was never frozen while it was being deployed. and i suspect dnssec won't be either. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From BarbaraDodson@boulderfulfillment.com Mon Nov 21 16:56:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeJeJ-0005D7-6e; Mon, 21 Nov 2005 16:56:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17304; Mon, 21 Nov 2005 16:55:53 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeJwo-0004AO-EO; Mon, 21 Nov 2005 17:15:40 -0500 Received: from 179250192.rjo.virtua.com.br ([200.179.250.192]) by mx2.foretec.com with smtp (Exim 4.24) id 1EeJeF-0000lA-9Y; Mon, 21 Nov 2005 16:56:28 -0500 Received: from Tywb@localhost by cEg.int (8.11.6/8.11.6); Mon, 21 Nov 2005 20:51:03 -0500 Message-ID: From: "Anne Owens" Reply-To: "Anne Owens" To: dn@ietf.org Subject: Over 80% Savings on ALL best-selling Office XP titles Date: Tue, 22 Nov 2005 07:48:03 +0600 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: BarbaraDodson@boulderfulfillment.com Content-Type: multipart/mixed; boundary="--rn9ouSEZhYz8grgZ5G" X-Spam-Score: 0.2 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 D5c2 ----rn9ouSEZhYz8grgZ5G Content-Type: text/html; Content-Transfer-Encoding: quoted-printable C
Opt-in Email Special Offer   = ;  unsubscribe me
=
SEARCH

TOP 10 NEW TITLES

=
<= td width=3D132> Dreamweaver 8=   Adobe
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&nb= sp;2 Creative Suite 2
&nb= sp;3 MS Office 2003 Pro
&= nbsp;4 Adobe Acrobat 7 Pro
 5 Macromedia Flash 8
 6
 7 Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
10 Borland Architect 2005
  See more by this manufacturer
   Microsoft
=    Macromedia
  
 = Customers also bought
   these = other items...

<= b class=3Dsans>Microsoft Windows XP Professional *w/SP2*
Microsoft

Choose:
<= a href=3Dhttp://onlythisoem.com/?u>  =

List Price:$299.00
Price:$49.99
You Save:= $249.01 (80%)



Availa= bility: Available for INSTANT download!
Coupon Code: qEHZ50=
Platform: = Windows XP

Sales Rank: #1
System requirem= ents  |  Other Versions<= /a>
Date Coupon Expires: December 31s= t, 2005
Average Customer Review:3D"5 Based on 14346 reviews. Write a rev= iew.

Adobe Creative Suite 2 *Premium*
= Adobe

Choose:
&= nbsp;

List Price:$1199.00
Price:$149.99
You Save:$1049= 01 (95%)

=

Availabili= ty: Available for INSTANT download!
Coupon Code: k2V68AMQU<= br> Platform: = Windows XP

Sales Rank: #2
System requireme= nts  |  Other Versions
Date Coupon Expires: December 31st= , 2005
Average Customer Review:3D"5 Based on 11688 reviews. Write a rev= iew.

Microsoft Office 2003 *Professional*
Microsoft

Choose:<= td width=3D126>
 

You Save:



Availability: Available for INSTANT dow= nload!
Coupon Code: DSlWkm5s
Platform: Windows XP

Sales Rank: #3
System requirements  |  Other Versions
<= b>Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 126658 reviews. Write a review.

List Price:$499.00
Price:$69.99
$429.01 (85%)
----rn9ouSEZhYz8grgZ5G-- From owner-namedroppers@ops.ietf.org Mon Nov 21 16:58:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeJg0-0005hF-FW for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 16:58:16 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17557 for ; Mon, 21 Nov 2005 16:57:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeJct-0002fe-Nc for namedroppers-data@psg.com; Mon, 21 Nov 2005 21:55:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeJcq-0002eV-Rk for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 21:55:01 +0000 Received: from [10.31.32.103] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id jALLsq8g001333; Mon, 21 Nov 2005 16:54:53 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20051121211530.GI5146@vacation.karoshi.com.> References: <20051121183242.GM4433@vacation.karoshi.com.> <20051121190558.CA8CD11425@sa.vix.com> <20051121201306.GC5146@vacation.karoshi.com.> <20051121204207.E6F9611425@sa.vix.com> <20051121211530.GI5146@vacation.karoshi.com.> Date: Mon, 21 Nov 2005 16:54:55 -0500 To: bmanning@vacation.karoshi.com From: Edward Lewis Subject: Re: "orphaned" RRsets & DNSSEC Cc: Paul Vixie , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Since we can't have a good argument unless we know we are arguing about: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 GLUE RECORDS If the name server host for a particular domain is itself inside the domain, then a 'glue' record will be needed. A glue record is an A (address) RR that specifies the address of the server. Glue records are only needed in the server delegating the domain, not in the domain itself. If for example the name server for domain SRI.COM was KL.SRI.COM, then the NS record would look like this, but you will also need to have the following A record. Also, RFC 1034, 4.2.1 to learn. To fix this problem, a zone contains "glue" RRs which are not part of the authoritative data, and are address RRs for the servers. And so on. Glue records are address records, not NS records, not PTR records. Maybe you want to change design assumptions after the cows have come home to roost, but don't go changing terminology - it just annoys the pigs. At 21:15 +0000 11/21/05, bmanning@vacation.karoshi.com wrote: > so for the dnssec trust model, self-signed or third-party >signatures are > not to be used/trusted. but does this lemma preclude the existance of > such signatures? We really tried to make a general purpose trust model work. We really, really tried hard. There was even a US DARPA research task to study this called FMESHD. The fact is that no one has been able to find an approach that isn't an open door to a denial of service attack. Maybe there is one, but no one has found it. In a nutshell, having one key signed by another, and then vice versa is a nice little infinite verification loop. 'Course, we could treat loops like CNAME does. But an implementation would have to also put an arbitrary cap on chasing extended signature chains. It's a mess, yes, and it was pushed aside as a neat little idea that was operationally not feasible. You should have seen the early cartoons and diagrams of "up tree validation" and the others. I remember trying to demonstrate it with a bag of paper clips, showing how it made the root of the DNS tree just another arbitrary starting point. (Too bad we didn't document those goofy ideas, huh?) I would say that the presence of third party signatures (I used to call them non-germane signatures) is a problem for naive code bases that may try to track them down into a dark alley. > dns was never frozen while it was being deployed. and i suspect dnssec > won't be either. I don't think that is a safe assumption. DNS was deployed in an era of no oversight. The Internet didn't matter to anyone outside the club of engineers that worked on it. Now that the Internet matters to daily life (I would stop short of saying it is essential) DNS and DNSSEC will seem frozen or glacial. Note the speed with which the root zone has taken up DNSSEC. Policy dudes don't like shifting sands, they will put in concrete barriers to stop "erosion." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-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 21 18:08:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeKm5-0004su-Pz for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 18:08:38 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24488 for ; Mon, 21 Nov 2005 18:07:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeKhX-0007gz-OP for namedroppers-data@psg.com; Mon, 21 Nov 2005 23:03:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeKhV-0007gc-9q for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 23:03:53 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id D742311425 for ; Mon, 21 Nov 2005 23:03:52 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: "orphaned" RRsets & DNSSEC In-Reply-To: Your message of "Mon, 21 Nov 2005 21:15:30 GMT." <20051121211530.GI5146@vacation.karoshi.com.> References: <20051121183242.GM4433@vacation.karoshi.com.> <20051121190558.CA8CD11425@sa.vix.com> <20051121201306.GC5146@vacation.karoshi.com.> <20051121204207.E6F9611425@sa.vix.com> <20051121211530.GI5146@vacation.karoshi.com.> Date: Mon, 21 Nov 2005 23:03:52 +0000 Message-Id: <20051121230352.D742311425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # dns was never frozen while it was being deployed. and i suspect # dnssec won't be either. at some point dns stopped invalidating its installed base, as dnssec must do. -- to unsubscribe send a message to namedroppers-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 21 18:20:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeKxw-00017N-NZ for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 18:20:52 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25727 for ; Mon, 21 Nov 2005 18:20:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeKuh-0008uM-T0 for namedroppers-data@psg.com; Mon, 21 Nov 2005 23:17:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeKuh-0008uA-Cm for namedroppers@ops.ietf.org; Mon, 21 Nov 2005 23:17:31 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id B7A25677F6 for ; Mon, 21 Nov 2005 23:17:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id jALNHDYf035158; Tue, 22 Nov 2005 10:17:14 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200511212317.jALNHDYf035158@drugs.dv.isc.org> To: Edward Lewis Cc: bmanning@vacation.karoshi.com, Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: "orphaned" RRsets & DNSSEC In-reply-to: Your message of "Mon, 21 Nov 2005 16:54:55 CDT." Date: Tue, 22 Nov 2005 10:17:13 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I was talking about this in the halls at Vancouver. My idea was to have a GLUESIG to cover delegating NS and address records. This would cover the gap we currently have in that not all data entered into a signed zone can be cryptographically verified when it is received. This would prevent resolvers being lead astray by being given forged NS / A / AAAA RRsets. The model would be verify before following rather than follow and hope that you get something that can be validated. Not having this is not a show stopper, but it is something we should work on fixing. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 21 19:42:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeMEi-0006Nq-RD for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 19:42:16 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10091 for ; Mon, 21 Nov 2005 19:41:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeMAV-000F2V-2X for namedroppers-data@psg.com; Tue, 22 Nov 2005 00:37:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeMAU-000F2H-BW for namedroppers@ops.ietf.org; Tue, 22 Nov 2005 00:37:54 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 95906677F9 for ; Tue, 22 Nov 2005 00:37:53 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id jAM0bkZS036443; Tue, 22 Nov 2005 11:37:47 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200511220037.jAM0bkZS036443@drugs.dv.isc.org> To: bmanning@vacation.karoshi.com Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: "orphaned" RRsets & DNSSEC In-reply-to: Your message of "Mon, 21 Nov 2005 18:32:42 -0000." <20051121183242.GM4433@vacation.karoshi.com.> Date: Tue, 22 Nov 2005 11:37:46 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > So... Hokay... > > DNSSEC is a fine and useful BOS ... but there is this little nagging > problem that is bugging me. One of the lemas is that zones are signed, which > > leaves the small problem of validating glue. others have argued that the > proper response is to insist on all glue be removed by excising all the > "out of baliwick" data - forcing servers to being the zone. nice idea, but > will take a -LONG- time to gain operational traction. So in the mean time, > we have signed zones w/ "orphaned" RRsets. Removing "out of baliwick" data will actually increase the amount of glue required not remove it. One could constuct a DNS such that there was no glue other than the SBELT needed to get to the roots. The servers for the TLD would live in a undelegated part of the root zone. The servers for the childen of a TLD would live in a undelegated part of the TLD zone. etc. > Is there any reason why we can't validate the NS records, perhaps > using the same general techniques as would be used for incremental signing? > > --bill > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 21 20:04:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeMaR-0005wF-Li for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 20:04:43 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11941 for ; Mon, 21 Nov 2005 20:04:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeMXu-000GvE-Kq for namedroppers-data@psg.com; Tue, 22 Nov 2005 01:02:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeMXs-000Guq-0t for namedroppers@ops.ietf.org; Tue, 22 Nov 2005 01:02:04 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 120D3677F9 for ; Tue, 22 Nov 2005 01:02: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.13.4/8.13.1) with ESMTP id jAM11nwR045807; Tue, 22 Nov 2005 12:01:50 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200511220101.jAM11nwR045807@drugs.dv.isc.org> To: Edward Lewis Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: "orphaned" RRsets & DNSSEC In-reply-to: Your message of "Mon, 21 Nov 2005 13:47:35 CDT." Date: Tue, 22 Nov 2005 12:01:49 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 18:32 +0000 11/21/05, bmanning@vacation.karoshi.com wrote: > >So... Hokay... > > > > DNSSEC is a fine and useful BOS ... but there is this little nagging > >problem that is bugging me. One of the lemas is that zones are signed, whic > h > >leaves the small problem of validating glue. others have argued that the > >proper response is to insist on all glue be removed by excising all the > >"out of baliwick" data - forcing servers to being the zone. nice idea, but > >will take a -LONG- time to gain operational traction. So in the mean time, > >we have signed zones w/ "orphaned" RRsets. > > > > Is there any reason why we can't validate the NS records, perhaps > >using the same general techniques as would be used for incremental signing? > > I'm not clear on the question. Are you asking why the parent doesn't > sign the cutpoint NS RRset? Are you calling the NS RRSets part of > the glue? (I've always thought the glue to be the address records > pertaining to the cutpoints and not the NS sets.) > > One of the basic tenets of DNSSEC is to have the authority on a RRset > be the sole provider of authentication meta-data, i.e., the signature. Early on in the development of DNSSEC we made a decision not to sign the glue and delegation records. We could do this because signing them was not strictly needed to prevent bogus data being returned from a signed child zone. If I was asked to make the same decision today in the presence of wide spead DoS attacks and spoofed traffic I have made choice to protect the resolver from going down the rathole, i.e. sign the delegation and glue. The attackers have got better so the defences need to be better. > I've always liked the model of "let the NXT record note the presence > of an NS set and have that signed" as proof that a cut point was > granted by the parent without making a statement about the "Left Hand > Side" of the NS data. Only the child signs the NS RRsets, the > appropriate authority signs the address records that appear as glue. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > 3 months to the next trip. I guess it's finally time to settle down and > find a grocery store. > > -- > to 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 sarah.bagshaw@augesoluciones.com Mon Nov 21 21:13:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeNfB-0006dD-E8 for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 21:13:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19695 for ; Mon, 21 Nov 2005 21:13:01 -0500 (EST) Received: from pool-68-161-167-232.ny325.east.verizon.net ([68.161.167.232] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EeNxj-0007Oz-Ps for dnsext-archive@ietf.org; Mon, 21 Nov 2005 21:32:52 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Mon, 21 Nov 2005 21:13:30 -0500 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Mon, 21 Nov 2005 21:13:30 -0500 Message-ID: <000001c5ef09$41f13c80$0100007f@localhost> From: "Ezekiel Evans" To: Subject: Hey bro, check out the huge sale these guys are offering Date: Mon, 21 Nov 2005 21:13:30 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5EF09.41F13C80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.3 (+++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5EF09.41F13C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.tomasto.com/pt/?46&cyasp ------=_NextPart_000_0001_01C5EF09.41F13C80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C5EF09.41F13C80-- From owner-namedroppers@ops.ietf.org Mon Nov 21 21:47:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeOBz-0001rz-Mb for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 21:47:36 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23096 for ; Mon, 21 Nov 2005 21:46:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeO8O-000NJL-Tp for namedroppers-data@psg.com; Tue, 22 Nov 2005 02:43:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeO8O-000NJ7-0G for namedroppers@ops.ietf.org; Tue, 22 Nov 2005 02:43:52 +0000 Received: from [10.31.32.103] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id jAM2hcxV002501; Mon, 21 Nov 2005 21:43:39 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200511212317.jALNHDYf035158@drugs.dv.isc.org> References: <200511212317.jALNHDYf035158@drugs.dv.isc.org> Date: Mon, 21 Nov 2005 21:43:44 -0500 To: Mark Andrews From: Edward Lewis Subject: Re: "orphaned" RRsets & DNSSEC Cc: Edward Lewis , bmanning@vacation.karoshi.com, Paul Vixie , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I have a hard time seeing this as needed. Assuming the parent and child are signed, a referral from the parent to the child would have a signed DS set, an unsigned NS set, and unsigned glue records. Assuming the glue is faked, the DS set provides the protection as no key is found matching any DS record. Signing the glue doesn't make it harder to substitute it. All I can see you'd save in verifying glue before following a referral is a query to a server that won't give you verifiable data. You lose time, not much more. However, if you do verify all referrals, you lose the same or less time more often. It's possible that I am missing the point, but I don't see how signing the glue helps. At 10:17 +1100 11/22/05, Mark Andrews wrote: > I was talking about this in the halls at Vancouver. > > My idea was to have a GLUESIG to cover delegating NS and > address records. This would cover the gap we currently > have in that not all data entered into a signed zone can > be cryptographically verified when it is received. > > This would prevent resolvers being lead astray by being > given forged NS / A / AAAA RRsets. The model would be > verify before following rather than follow and hope that > you get something that can be validated. > > Not having this is not a show stopper, but it is something > we should work on fixing. > > Mark >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-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 21 22:29:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeOqy-0000OY-LS for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 22:29:56 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26957 for ; Mon, 21 Nov 2005 22:29:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeOlP-0000HX-NW for namedroppers-data@psg.com; Tue, 22 Nov 2005 03:24:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeOlP-0000HJ-3O for namedroppers@ops.ietf.org; Tue, 22 Nov 2005 03:24:11 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id E4B72677F9 for ; Tue, 22 Nov 2005 03:24:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id jAM3NvUD082774; Tue, 22 Nov 2005 14:23:58 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200511220323.jAM3NvUD082774@drugs.dv.isc.org> To: Edward Lewis Cc: bmanning@vacation.karoshi.com, Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: "orphaned" RRsets & DNSSEC In-reply-to: Your message of "Mon, 21 Nov 2005 21:43:44 CDT." Date: Tue, 22 Nov 2005 14:23:57 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I have a hard time seeing this as needed. > > Assuming the parent and child are signed, a referral from the parent > to the child would have a signed DS set, an unsigned NS set, and > unsigned glue records. Assuming the glue is faked, the DS set > provides the protection as no key is found matching any DS record. > > Signing the glue doesn't make it harder to substitute it. > > All I can see you'd save in verifying glue before following a > referral is a query to a server that won't give you verifiable data. > You lose time, not much more. However, if you do verify all > referrals, you lose the same or less time more often. > > It's possible that I am missing the point, but I don't see how > signing the glue helps. I prevents the resolver following a bogus referrals in the first place. It allows resolvers to free resources sooner rather than later. While it is impossible to survive a MiM attacks it is possible to survive injected response attacks by waiting for later responses from the real servers. The sooner one can do this the less resources that need to be tied up to allow for recovery from the attack. Note a cleverly defined attack could have a valid DS/DNSKEY chain but everything else could be invalid. Mark > At 10:17 +1100 11/22/05, Mark Andrews wrote: > > I was talking about this in the halls at Vancouver. > > > > My idea was to have a GLUESIG to cover delegating NS and > > address records. This would cover the gap we currently > > have in that not all data entered into a signed zone can > > be cryptographically verified when it is received. > > > > This would prevent resolvers being lead astray by being > > given forged NS / A / AAAA RRsets. The model would be > > verify before following rather than follow and hope that > > you get something that can be validated. > > > > Not having this is not a show stopper, but it is something > > we should work on fixing. > > > > Mark > >-- > >Mark Andrews, ISC > >1 Seymour St., Dundas Valley, NSW 2117, Australia > >PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > > > >-- > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with > >the word 'unsubscribe' in a single line as the message text body. > >archive: > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > 3 months to the next trip. I guess it's finally time to settle down and > find a grocery store. -- 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 21 22:45:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeP6M-0007JU-Kg for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 22:45:50 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28305 for ; Mon, 21 Nov 2005 22:45:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeP3P-0001Tc-St for namedroppers-data@psg.com; Tue, 22 Nov 2005 03:42:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeP3N-0001TL-AK for namedroppers@ops.ietf.org; Tue, 22 Nov 2005 03:42:45 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id jAM3gXxg002697; Mon, 21 Nov 2005 22:42:34 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200511220323.jAM3NvUD082774@drugs.dv.isc.org> References: <200511220323.jAM3NvUD082774@drugs.dv.isc.org> Date: Mon, 21 Nov 2005 22:42:38 -0500 To: Mark Andrews From: Edward Lewis Subject: Re: "orphaned" RRsets & DNSSEC Cc: Edward Lewis , bmanning@vacation.karoshi.com, Paul Vixie , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 14:23 +1100 11/22/05, Mark Andrews wrote: > It prevents the resolver following a bogus referrals in the > first place. It allows resolvers to free resources sooner > rather than later. It only helps if you do the crypto operations as you go? Every referral? If so, here's why I have a hard time being convinced that it is worth the effort. Assuming the number of queries that get attacked is 1% (probably high), then 100% of the time you are eating resources to find the 1% of the times you sense an attack. When you sense an attack, you save one round of queries by not sending anything to the duping servers. Is the 100% of query overhead worth the savings? > While it is impossible to survive a MiM attacks it is possible > to survive injected response attacks by waiting for later > responses from the real servers. The sooner one can do this > the less resources that need to be tied up to allow for > recovery from the attack. It is always true that the sooner you can free resources used for fruitless work, the better. The trouble is, as always, determining when an effort is fruitless. (That's like having "perfect future knowledge" when playing a game.) > Note a cleverly defined attack could have a valid DS/DNSKEY > chain but everything else could be invalid. For some value of "cleverly defined" of course. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-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 21 22:59:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EePJi-0004zf-OB for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 22:59:41 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29680 for ; Mon, 21 Nov 2005 22:59:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EePGf-0002VZ-Mf for namedroppers-data@psg.com; Tue, 22 Nov 2005 03:56:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EePGf-0002VM-6Y for namedroppers@ops.ietf.org; Tue, 22 Nov 2005 03:56:29 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 8D4A8677F9 for ; Tue, 22 Nov 2005 03:56:28 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id jAM3uJPK096647; Tue, 22 Nov 2005 14:56:20 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200511220356.jAM3uJPK096647@drugs.dv.isc.org> To: Edward Lewis Cc: bmanning@vacation.karoshi.com, Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: "orphaned" RRsets & DNSSEC In-reply-to: Your message of "Mon, 21 Nov 2005 22:42:38 CDT." Date: Tue, 22 Nov 2005 14:56:19 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 14:23 +1100 11/22/05, Mark Andrews wrote: > > > It prevents the resolver following a bogus referrals in the > > first place. It allows resolvers to free resources sooner > > rather than later. > > It only helps if you do the crypto operations as you go? Yes. > Every referral? Every referral from a secure zone. Just in time for the addresses. It also helps provide some additional assurance when going from a secure zone to a unsecure zone. > If so, here's why I have a hard time being convinced that it is worth > the effort. > > Assuming the number of queries that get attacked is 1% (probably > high), then 100% of the time you are eating resources to find the 1% > of the times you sense an attack. When you sense an attack, you save > one round of queries by not sending anything to the duping servers. > Is the 100% of query overhead worth the savings? You save many queries when under attack. Mark > > While it is impossible to survive a MiM attacks it is possible > > to survive injected response attacks by waiting for later > > responses from the real servers. The sooner one can do this > > the less resources that need to be tied up to allow for > > recovery from the attack. > > It is always true that the sooner you can free resources used for > fruitless work, the better. The trouble is, as always, determining > when an effort is fruitless. (That's like having "perfect future > knowledge" when playing a game.) > > > Note a cleverly defined attack could have a valid DS/DNSKEY > > chain but everything else could be invalid. > > For some value of "cleverly defined" of course. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > 3 months to the next trip. I guess it's finally time to settle down and > find a grocery store. -- 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 21 23:14:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EePY5-0002PZ-PA for dnsext-archive@megatron.ietf.org; Mon, 21 Nov 2005 23:14:29 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01011 for ; Mon, 21 Nov 2005 23:13:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EePUd-0003Qm-8o for namedroppers-data@psg.com; Tue, 22 Nov 2005 04:10:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EePUc-0003Qb-R2 for namedroppers@ops.ietf.org; Tue, 22 Nov 2005 04:10:54 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6397911425 for ; Tue, 22 Nov 2005 04:10:54 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: "orphaned" RRsets & DNSSEC In-Reply-To: Your message of "Tue, 22 Nov 2005 14:56:19 +1100." <200511220356.jAM3uJPK096647@drugs.dv.isc.org> References: <200511220356.jAM3uJPK096647@drugs.dv.isc.org> Date: Tue, 22 Nov 2005 04:10:54 +0000 Message-Id: <20051122041054.6397911425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # You save many queries when under attack. i believe that ken orr's work demonstrates conclusively that if there are parallel databases, at least one of them will be wrong most of the time. -- to unsubscribe send a message to namedroppers-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 22 10:58:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeaX4-0007hV-5e for dnsext-archive@megatron.ietf.org; Tue, 22 Nov 2005 10:58:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04496 for ; Tue, 22 Nov 2005 10:57:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeaST-000Jrm-E2 for namedroppers-data@psg.com; Tue, 22 Nov 2005 15:53:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeaSS-000JrJ-K6 for namedroppers@ops.ietf.org; Tue, 22 Nov 2005 15:53:24 +0000 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EeaSN-0003wX-Sh; Tue, 22 Nov 2005 10:53:19 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard Reply-to: iesg@ietf.org CC: Message-Id: Date: Tue, 22 Nov 2005 10:53:19 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has received a request from the DNS Extensions WG to consider the following documents: - 'Minimally Covering NSEC Records and DNSSEC On-line Signing ' as a Proposed Standard - 'Derivation of DNS Name Predecessor and Successor ' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-12-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-online-signing-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-name-p-s-01.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From lynnl@basilford.com Tue Nov 22 12:05:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebaU-0007JG-D8 for dnsext-archive@megatron.ietf.org; Tue, 22 Nov 2005 12:05:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12881 for ; Tue, 22 Nov 2005 12:05:07 -0500 (EST) Received: from ppp9-135.pppoe.mtu-net.ru ([81.195.9.135] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eebt6-0006Mh-Mu for dnsext-archive@ietf.org; Tue, 22 Nov 2005 12:25:05 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Tue, 22 Nov 2005 20:05:23 +0300 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Tue, 22 Nov 2005 20:05:23 +0300 Message-ID: <000001c5ef85$93d7a800$0100007f@localhost> From: "Emmanuel James" To: Subject: Make her worship you! Date: Tue, 22 Nov 2005 20:05:23 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5EF85.93D7A800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.7 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5EF85.93D7A800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.tomasto.com/pt/?46&cyasp ------=_NextPart_000_0001_01C5EF85.93D7A800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C5EF85.93D7A800-- From owner-namedroppers@ops.ietf.org Tue Nov 22 12:27:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eebvs-0004n0-8J for dnsext-archive@megatron.ietf.org; Tue, 22 Nov 2005 12:27:52 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15959 for ; Tue, 22 Nov 2005 12:27:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eebsr-000PZa-R8 for namedroppers-data@psg.com; Tue, 22 Nov 2005 17:24:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, INFO_TLD autolearn=no version=3.1.0 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eebsq-000PZP-Vh for namedroppers@ops.ietf.org; Tue, 22 Nov 2005 17:24:45 +0000 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1Eebsq-00037u-7F for namedroppers@ops.ietf.org; Tue, 22 Nov 2005 12:24:44 -0500 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id 43F9E13744; Tue, 22 Nov 2005 12:24:40 -0500 (EST) Date: Tue, 22 Nov 2005 12:24:40 -0500 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: sha256 requirement consensus estimate Message-ID: <20051122172439.GK2178@libertyrms.info> Reply-To: Andrew Sullivan References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I have reviewed the document, and have some comments on the most recent mail. On Mon, Nov 21, 2005 at 11:21:00AM -0800, Wes Hardaker wrote: > 1) rough consensus is that deployment requirements shouldn't be > included at all. Policy with respect to preference should also not > be included (I liked my replacement text saying it had to be > configurable and have a default to prefer 256, but no one responded > to that so that certainly doesn't meet consensus). I agree with this in principle, but I like the proposal requiring at least the ability to prefer 256. It strikes me as a good balance between including operational requirements (bad) and specifying minimal functionality (good). > 2) We should specify that SHA-256 MUST be supported. Yes. > 3) I actually think that there is more people leaning toward including > a statement saying that SHA-1 be declared obsolete in the > document. This is the statement that is most on the line and I'm > not sure whether or not there is enough support behind it to > include it. Opinions? I think that including the "configurable to prefer 256" fits with this; I also think that obsoleting it is stepping over the operational requirements line. There may well be circumstances under which SHA-1 is preferable when 256 isn't feasible or something, and I don't think we have enough operations experience yet to know whether that's the case. Other than that, and the (more perceptive) comments others have already made, I think this document should be ready pretty soon. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +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 22 16:31:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eefjj-0002TR-9n for dnsext-archive@megatron.ietf.org; Tue, 22 Nov 2005 16:31:35 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14949 for ; Tue, 22 Nov 2005 16:30:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eefff-000Goz-Os for namedroppers-data@psg.com; Tue, 22 Nov 2005 21:27:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eeffe-000Goi-S8 for namedroppers@ops.ietf.org; Tue, 22 Nov 2005 21:27:23 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO001505; 22 Nov 2005 16:33:04 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 22 Nov 2005 16:32:51 -0500 Received: from connotech.com (209.71.204.101) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG001504; 22 Nov 2005 16:32:41 -0500 Message-ID: <4383950A.4040501@connotech.com> Date: Tue, 22 Nov 2005 17:00:42 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Trust anchor key IPR issues within existing DNS operations business model Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear IETF DNSEXT wg participants: This post addresses the IPR issue with respect to trust anchor key management for IETF purposes. The current business model for DNS is registration fees paid by registrants to registrars covering retail value of name registration. DNSSEC is a value-added service for DNSSEC-aware registrants who will pay some extra money for the registrar (and/or registry) to maintain a secure delegation to the registrant's zone. Part of the registration fees is passed at the wholesale level represented by the registries, and then some money goes to ICANN. As far as I can browse, the ICANN documents seem silent about the registry right to charge extra fees for secure delegations, but for IETF purposes, it is reasonable to use this assumption. For IETF purposes, it can be assumed that an IPR holder for a trust anchor key management scheme would behave rationally (in the economic sense) in shaping licensing arrangements along the current business model with the assumed secure delegation addenda explained in the above paragraph. Thus, the IPR licensing fees would be included in DNS registration fees, no explicitly visible impact for the masses of second level domain owners who are the target of secure delegation service offering. It can be argued that the DNS registration fees already include compensation for proprietary systems. This is hinted by the Verisign financial statements for proprietary protocols between registrars and registries (reference: search the Verisign financial statements for the word "proprietary"), and by some of the patent applications assigned to Verisign in the US patent office database. Trust anchor key management has server-side procedures and resolver-side procedures. The other participants are thus DNS resolver software users, developers, and vendors. It would not be rational for an IPR holder to impose licensing requirements to users beyond embedded provisions in software licenses for proprietary DNS resolver software. So, proprietary DNS resolver software vendors might be the target of IPR holder greediness. Again, this is without explicit visible impact to the masses, because proprietary software customers are already paying for software licenses. I.e. for software distributed without restriction on multiple copy usage, it would be unrealistic for an IPR holder to expect licensing revenues based end-user license count. So, a rational behavior from the part of IPR holder would hide the IPR licensing mechanisms from the mass market participant categories that are the second level domain owners and DNS resolver software users. This is simply so because the existing business models (and institutional framework) for Internet DNS operations has been worked out quite well, in economic terms. Furthermore, still for IETF purposes, it can be argued that an IPR holder would behave rationally in negotiating licensing fees, simply because the Internet DNS is a de-facto monopoly (i.e. there is no more a global X.25, SNA, or IPX network where trust anchor key IPR would allow a competitive advantage over Internet). I believe the above observations could have been made by some other (moderately educated and knowledgeable) participants. I.e. someone who can take a broader view on protocol engineering that encompasses Internet governance, business strategy, economics, and IPR management. I was assisted in these aspect by many fascinating documents which I omit to refer for sake of brevity. If the above observations facilitates the DNSEXT wg study of competing proposals for DNS trust anchor key management, so much the better. Finally, the current IPR holder of the TAKREM for DNSSEC proposal is my privately owned company. This may not be the case in the future, so the above description of a rational economic behavior is not a commitment from my part. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 22 17:41:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EegpK-0003Bf-0b for dnsext-archive@megatron.ietf.org; Tue, 22 Nov 2005 17:41:26 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23047 for ; Tue, 22 Nov 2005 17:40:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eegmd-000LUj-Hb for namedroppers-data@psg.com; Tue, 22 Nov 2005 22:38:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Eegmc-000LUX-Fe for namedroppers@ops.ietf.org; Tue, 22 Nov 2005 22:38:38 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id F0C38568CD; Tue, 22 Nov 2005 14:38:35 -0800 (PST) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.0.10.2.20051122170937.0365f810@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Tue, 22 Nov 2005 17:39:21 -0500 To: Thierry Moreau , namedroppers@ops.ietf.org From: Mike StJohns Subject: Re: Trust anchor key IPR issues within existing DNS operations business model In-Reply-To: <4383950A.4040501@connotech.com> References: <4383950A.4040501@connotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I would normally just leave this one alone, but .... At 05:00 PM 11/22/2005, Thierry Moreau wrote: >The current business model for DNS is registration fees paid by >registrants to registrars covering retail value of name >registration. Yes. And from registrars to registries for the wholesale value. > DNSSEC is a value-added service for DNSSEC-aware >registrants who will pay some extra money for the registrar >(and/or registry) to maintain a secure delegation to the >registrant's zone. No. This is an assumption and a bad one at that. There is no evidence either way on whether or not a registry will charge additional fees to sign a delegation. It's possible that there may be some "high-assurance" domains that charge additional monies for a higher quality delegation (similar to the certificate model), but if .COM/.NET etc go secure I would anticipate no additional fee in the long run (with maybe some fees in the short run). > Part of the registration fees is passed at the >wholesale level represented by the registries, and then some >money goes to ICANN. As far as I can browse, the ICANN documents >seem silent about the registry right to charge extra fees for >secure delegations, but for IETF purposes, it is reasonable to >use this assumption. See above. >For IETF purposes, it can be assumed that an IPR holder for a >trust anchor key management scheme would behave rationally (in >the economic sense) in shaping licensing arrangements along the >current business model with the assumed secure delegation addenda >explained in the above paragraph. Thus, the IPR licensing fees >would be included in DNS registration fees, no explicitly visible >impact for the masses of second level domain owners who are the >target of secure delegation service offering. This paragraph betrays a complete lack of understanding of the difference between DNS software which might incorporate the use of such technology (including specifically the clients and servers) and some registry which is signing delegations. In the "ideal" DNSSEC model, there is only one trust point (with multiple trust anchors) (e.g. the root) and that trust point actually exists outside the current registry model as none of the registrations in the root done through a registrar, but through ICANN actions. And the IPR for trust anchor has nothing at all to do with secure delegations so I'm not sure why it's even being brought up here. >It can be argued that the DNS registration fees already include >compensation for proprietary systems. This is hinted by the >Verisign financial statements for proprietary protocols between >registrars and registries (reference: search the Verisign >financial statements for the word "proprietary"), and by some of >the patent applications assigned to Verisign in the US patent >office database. No, actually it can't. Verisign and other registries have implemented internal procedures. On the balance sheet this comes under "overhead". The registrant isn't paying verisign for the use of the proprietary system, but for the registration - how Verisign chooses to implement the registration is its own business. DNS registration fees include compensation for all costs of doing business plus their profit (hopefully :-) ). >Trust anchor key management has server-side procedures and >resolver-side procedures. The other participants are thus DNS >resolver software users, developers, and vendors. It would not be >rational for an IPR holder to impose licensing requirements to >users beyond embedded provisions in software licenses for >proprietary DNS resolver software. If what you're saying is that the only way to extract money out of the end-user (e.g. guy on a computer at home) is to impose a fee on the software he uses I believe that's the normal approach to technology IPR licensing. >So, proprietary DNS resolver >software vendors might be the target of IPR holder greediness. >Again, this is without explicit visible impact to the masses, Except for additional cost to them when the software vendor passes on the IPR cost. >because proprietary software customers are already paying for >software licenses. I.e. for software distributed without >restriction on multiple copy usage, it would be unrealistic for >an IPR holder to expect licensing revenues based end-user license >count. Naive assumption at best. Self-serving mis-statement at worst. Again, this is the normal IPR licensing model. Go have a talk with a lawyer. >So, a rational behavior from the part of IPR holder would hide >the IPR licensing mechanisms from the mass market participant >categories that are the second level domain owners and DNS >resolver software users. This is simply so because the existing >business models (and institutional framework) for Internet DNS >operations has been worked out quite well, in economic terms. At this point - I'm going back into ignore mode. My opinion is that this document is pretty much a commercial for the individual's IPR masquerading as a semi-engineering analysis. As such, it's inappropriate for this mailing list. >Furthermore, still for IETF purposes, it can be argued that an >IPR holder would behave rationally in negotiating licensing fees, >simply because the Internet DNS is a de-facto monopoly (i.e. >there is no more a global X.25, SNA, or IPX network where trust >anchor key IPR would allow a competitive advantage over >Internet). > >I believe the above observations could have been made by some >other (moderately educated and knowledgeable) participants. I.e. >someone who can take a broader view on protocol engineering that >encompasses Internet governance, business strategy, economics, >and IPR management. I was assisted in these aspect by many >fascinating documents which I omit to refer for sake of brevity. > >If the above observations facilitates the DNSEXT wg study of >competing proposals for DNS trust anchor key management, so much >the better. > >Finally, the current IPR holder of the TAKREM for DNSSEC proposal >is my privately owned company. This may not be the case in the >future, so the above description of a rational economic behavior >is not a commitment from my part. > >Regards, > >-- > >- Thierry Moreau > >CONNOTECH Experts-conseils inc. >9130 Place de Montgolfier >Montreal, Qc >Canada H2M 2A1 > >Tel.: (514)385-5691 >Fax: (514)385-5900 > >web site: http://www.connotech.com >e-mail: thierry.moreau@connotech.com > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-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 22 18:51:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EehvG-0002aQ-51 for dnsext-archive@megatron.ietf.org; Tue, 22 Nov 2005 18:51:40 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00079 for ; Tue, 22 Nov 2005 18:50:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EehsN-0000c3-05 for namedroppers-data@psg.com; Tue, 22 Nov 2005 23:48:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EehsM-0000bq-AY for namedroppers@ops.ietf.org; Tue, 22 Nov 2005 23:48:38 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id D7F49C2DAA; Tue, 22 Nov 2005 23:48:36 +0000 (GMT) Date: Tue, 22 Nov 2005 23:48:34 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Thierry Moreau , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: Trust anchor key IPR issues within existing DNS operations business model Message-ID: In-Reply-To: <4383950A.4040501@connotech.com> References: <4383950A.4040501@connotech.com> X-Mailer: Mulberry/4.0.4 (Win32) 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 Content-Transfer-Encoding: 7bit --On 22 November 2005 17:00 -0500 Thierry Moreau wrote: > For IETF purposes, it can be assumed that an IPR holder for a > trust anchor key management scheme would behave rationally The IETF should assume no such thing, not least as rationality appears not to be a particular objective concept when it comes to IPR; we should not be attempting to reinvent IETF IPR policy in DNSEXT. At least one rational behaviour for IPR holders (FOC licensing) remains open. I don't think it's worth spending too many recycled electronics on this issue here, but I'll point out you seem to assume the IPR user here is an ICANN registrar. In fact, it's a software vendor, whose customer may be an ICANN registrar, may be a ccTLD, or may be an end registrant. Why it would be to these guys advantage to use an IPR-encumbered trust anchor scheme is beyond me. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 23 01:40:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeoJC-0004ee-9K for dnsext-archive@megatron.ietf.org; Wed, 23 Nov 2005 01:40:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17521 for ; Wed, 23 Nov 2005 01:40:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeoE7-0001S0-Nr for namedroppers-data@psg.com; Wed, 23 Nov 2005 06:35:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.151.192.200] (helo=sokol.elan.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeoE7-0001Rl-4C for namedroppers@ops.ietf.org; Wed, 23 Nov 2005 06:35:31 +0000 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id jAN6ZUZd017187 for ; Tue, 22 Nov 2005 22:35:30 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id jAN6ZUN5017184 for ; Tue, 22 Nov 2005 22:35:30 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 22 Nov 2005 22:35:30 -0800 (PST) From: "william(at)elan.net" To: namedroppers@ops.ietf.org Subject: Re: Trust anchor key IPR issues within existing DNS operations business model In-Reply-To: <7.0.0.10.2.20051122170937.0365f810@nominum.com> Message-ID: References: <4383950A.4040501@connotech.com> <7.0.0.10.2.20051122170937.0365f810@nominum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Could somebody please point me to the draft (or section of it or some other document or presentation) that explains trust anchor issues. I would prefer to see some neutral document, i.e. not written by proponent for particular solution. -- William Leibzon Elan Networks william@elan.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 23 03:31:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeq28-0001AN-Hi for dnsext-archive@megatron.ietf.org; Wed, 23 Nov 2005 03:31:16 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27211 for ; Wed, 23 Nov 2005 03:30:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eepwk-000A9e-Qs for namedroppers-data@psg.com; Wed, 23 Nov 2005 08:25:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Eepwj-000A9C-Oq for namedroppers@ops.ietf.org; Wed, 23 Nov 2005 08:25:42 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jAN8PDT5035888; Wed, 23 Nov 2005 09:25:14 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: References: <4383950A.4040501@connotech.com> <7.0.0.10.2.20051122170937.0365f810@nominum.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-9--191708077" Message-Id: <0EF1267E-B99A-4681-BBD8-F0793C68DB75@NLnetLabs.nl> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Trust anchor key IPR issues within existing DNS operations business model Date: Wed, 23 Nov 2005 09:25:14 +0100 To: "william(at)elan.net" X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-9--191708077 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Nov 23, 2005, at 07:35 , william(at)elan.net wrote: > > Could somebody please point me to the draft (or section of it or > some other document or presentation) that explains trust anchor > issues. > I would prefer to see some neutral document, i.e. not written by > proponent for particular solution. Would what we try to do with getting requirements (see: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01564.html ) satisfy your needs. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-9--191708077 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.1 (Darwin) Comment: This message is locally signed. iD8DBQFDhCdqtN/ca3YJIocRAvswAKDxEzs4t/WNtigZt2TC1s9df2tafgCcCeHr vDseerdyTxGTax5Bl1s9foI= =eBea -----END PGP SIGNATURE----- --Apple-Mail-9--191708077-- -- to unsubscribe send a message to namedroppers-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 23 08:58:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eev92-0004fw-Qy for dnsext-archive@megatron.ietf.org; Wed, 23 Nov 2005 08:58:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03513 for ; Wed, 23 Nov 2005 08:58:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eev52-000AxD-4F for namedroppers-data@psg.com; Wed, 23 Nov 2005 13:54:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Eev50-000Awp-VV for namedroppers@ops.ietf.org; Wed, 23 Nov 2005 13:54:35 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id jANDsN1q010539; Wed, 23 Nov 2005 08:54:24 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <4383950A.4040501@connotech.com> References: <4383950A.4040501@connotech.com> Date: Wed, 23 Nov 2005 08:54:26 -0500 To: Thierry Moreau From: Edward Lewis Subject: Re: Trust anchor key IPR issues within existing DNS operations business model Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:00 -0500 11/22/05, Thierry Moreau wrote: >The current business model for DNS is registration fees paid by >registrants to registrars covering retail value of name >registration. DNSSEC is a value-added service for DNSSEC-aware >registrants who will pay some extra money for the registrar >(and/or registry) to maintain a secure delegation to the >registrant's zone. Part of the registration fees is passed at the >wholesale level represented by the registries, and then some >money goes to ICANN. As far as I can browse, the ICANN documents >seem silent about the registry right to charge extra fees for >secure delegations, but for IETF purposes, it is reasonable to >use this assumption. From my perpective, the above isn't a good reflection of reality. ICANN does not have purview over many or most registries (I haven't counted, so I won't make a definitive statement). I.e., looking at ICANN's environment isn't sufficient. Also, from what I've learned, heard, discussed, I wouldn't count on there being any or many registrants willing to pay "some extra money...to maintain a secure delegation." >For IETF purposes, it can be assumed that an IPR holder for a >trust anchor key management scheme would behave rationally (in >the economic sense) in shaping licensing arrangements along the >current business model with the assumed secure delegation addenda >explained in the above paragraph. Thus, the IPR licensing fees >would be included in DNS registration fees, no explicitly visible >impact for the masses of second level domain owners who are the >target of secure delegation service offering. This being an engineering forum, you would need to define what behaving rationally in an economic sense means in the above paragraph, or at least provide a reference to a document that does so. However, by this time I can't justify volunteering any more review on this. Even if I were to take the time to thoroughly understand the issue, it seems that the proposal is built upon a world view that I see as wrong. Count me as someone that is not interested in pursuing this proposal. ... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-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 23 10:03:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eew9b-0004jv-D5 for dnsext-archive@megatron.ietf.org; Wed, 23 Nov 2005 10:03:23 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12313 for ; Wed, 23 Nov 2005 10:02:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eew6W-000FTf-SQ for namedroppers-data@psg.com; Wed, 23 Nov 2005 15:00:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, INFO_TLD autolearn=no version=3.1.0 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eew6W-000FTR-3I for namedroppers@ops.ietf.org; Wed, 23 Nov 2005 15:00:12 +0000 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1Eew6V-0000EU-4z for namedroppers@ops.ietf.org; Wed, 23 Nov 2005 10:00:11 -0500 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id BD6B813744; Wed, 23 Nov 2005 10:00:06 -0500 (EST) Date: Wed, 23 Nov 2005 10:00:06 -0500 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: Trust anchor key IPR issues within existing DNS operations business model Message-ID: <20051123150006.GC23525@libertyrms.info> Reply-To: Andrew Sullivan References: <4383950A.4040501@connotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Nov 23, 2005 at 08:54:26AM -0500, Edward Lewis wrote: > Also, from what I've learned, heard, discussed, I wouldn't count on > there being any or many registrants willing to pay "some extra > money...to maintain a secure delegation." In addition, I'll be completely astonished if most registrars in the ICANN world are even slightly interested in DNSSEC if the registry charges a service fee for it. The ICANN registry market doesn't seem to work that way. (Other registries may be a different matter, of course.) A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +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 bmarosi@8newyork.com Wed Nov 23 10:17:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EewMk-0004gZ-TZ for dnsext-archive@megatron.ietf.org; Wed, 23 Nov 2005 10:17:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14082 for ; Wed, 23 Nov 2005 10:16:18 -0500 (EST) Received: from [193.255.251.39] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eewfc-0007fp-GK for dnsext-archive@ietf.org; Wed, 23 Nov 2005 10:36:29 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Wed, 23 Nov 2005 17:16:44 +0200 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Wed, 23 Nov 2005 17:16:44 +0200 Message-ID: <000001c5f03f$d1990700$0100007f@localhost> From: "Kameron Flores" To: Subject: Hey buddy, whats up Date: Wed, 23 Nov 2005 17:16:44 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F03F.D1990700" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.3 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F03F.D1990700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.tomasto.com/pt/?46&cyasp ------=_NextPart_000_0001_01C5F03F.D1990700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C5F03F.D1990700-- From owner-namedroppers@ops.ietf.org Wed Nov 23 12:45:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeygL-00058l-S7 for dnsext-archive@megatron.ietf.org; Wed, 23 Nov 2005 12:45:22 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02683 for ; Wed, 23 Nov 2005 12:44:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EeycL-0001Fi-1R for namedroppers-data@psg.com; Wed, 23 Nov 2005 17:41:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EeycK-0001FU-8O for namedroppers@ops.ietf.org; Wed, 23 Nov 2005 17:41:12 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id jANHf6Zf011514 for ; Wed, 23 Nov 2005 12:41:06 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id jANHf6ds011513 for namedroppers@ops.ietf.org; Wed, 23 Nov 2005 12:41:06 -0500 (EST) (envelope-from namedroppers) Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.54 (FreeBSD)) id 1Edks8-00081H-It for namedroppers@ops.ietf.org; Sun, 20 Nov 2005 08:48:29 +0000 Received: from gihm3.apnic.net (dhcp24.potaroo.net [203.10.60.24]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAK8mHXt065186; Sun, 20 Nov 2005 19:48:18 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051120194746.02acbc48@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sun, 20 Nov 2005 19:48:06 +1100 To: "Olaf M. Kolkman" From: Geoff Huston Subject: Re: Reinforcing the Review decision Cc: Namedroppers In-Reply-To: <200511182206.jAIM6gti086379@bartok.nlnetlabs.nl> References: <200511182206.jAIM6gti086379@bartok.nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] At 09:06 AM 19/11/2005, Jaap Akkerhuis wrote: > > We will not forward work if during a working group last call not at > least five people have gone on record that they thoroughly reviewed > the most current version of an I-D (and there is rough consensus to > forward the work). > > We would like to ask the working groups consent for this. aye Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From NorahBrandt@angitechsolutions.com Thu Nov 24 08:20:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfH1D-0006Ms-5b for dnsext-archive@megatron.ietf.org; Thu, 24 Nov 2005 08:20:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28731 for ; Thu, 24 Nov 2005 08:19:26 -0500 (EST) Received: from [84.119.43.112] (helo=fr-col-c3-01-084119043112.chello.fr ident=hyqwtsud) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EfHKF-00059t-B2 for dnsext-archive@ietf.org; Thu, 24 Nov 2005 08:39:48 -0500 Received: from EIzZ@localhost by 5wHq.int (8.11.6/8.11.6); Thu, 24 Nov 2005 17:48:25 +0400 Message-ID: From: "Gina Gillis" Reply-To: "Gina Gillis" To: dnsext-archive@ietf.org Subject: MS Office XP Pro $49.95 Symantec Date: Thu, 24 Nov 2005 08:57:25 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: NorahBrandt@angitechsolutions.com Content-Type: multipart/mixed; boundary="--LWZN59vNAvxzFcrLn" X-Spam-Score: 0.2 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 6xP ----LWZN59vNAvxzFcrLn Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Y
Opt-in Email Special Offer   = ;  unsubscribe me

=
<= td width=3D5 bgcolor=3D#000080>
SEARCH

TOP 10 NEW TITLES

=
<= td width=3D132> Adobe Acrobat 7 Pro<= td width=3D8>  these other items...
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&= nbsp;2 Creative Suite 2
 3 MS Office 2003 Pro
 4
 5<= /td> Macromedia Flash 8
 6 Dreamweaver 8
 7 Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
 10 Borland Architect 2= 005
  See more by t= his manufacturer
  Microsoft
   Macromedia
   Adobe
  Customers also bought
  

Microsoft Windows XP Profes= sional *w/SP2*
Microsoft

Choose:
<= /a> =
=



Availability: Available for INSTAN= T download!
Coupon Code: J1FrVvwP8
Platform: Windows XP

Sales Rank: #1
System requirements  |  Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 13183 review= s. Write a review.

List Price:$299.00
Price:$49.99
= You Save:$249.01 (80%)

Adobe Creative Suite 2 *Premium*
Adobe

Choose:
 

$1049.01 (95= %)
List Price:$1199.00
Price:$149.99=
You Save:



Availability: Available for INSTANT download!
Coupon Code: pR1vsL
P= latform: Windows = XP

Sales Rank: #2
System requirements  |  Other Versions
Date Coupon Expires: December 31st, 20= 05
Average Customer Review:3D"5 B= ased on 16676 reviews. Write a revie= w.

Microsoft Office 2003 *Professional*=
Microsoft

Choose:<= td width=3D126>
 

= $69.99
List Price:$499.00<= /span>
Price:
You Save:$429.01 (85%)



Availability: Available for = INSTANT download!
Coupon Code: vtmjAqQ
Platform: Windows XP

= Sales Rank: #3
System requirements  |  = Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 17848 re= views. Write a review.

<= p>Adobe Acrobat Professional V 7.0
Adobe

= Choose:
 <= /td>

List Price:= $499.00
Price:$69.99
You Save:$429.01 (85= %)



Availability: Available for INSTANT download!
Coupon Code: ttuwOLv9
Platform: Window= s XP

Sales Rank: #4
System requirements<= /a>  |  Other Versions=
Date Coupon Expires: December 31st, = 2005
Average Customer Review:3D"5= Based on 17916 reviews. Write a rev= iew.

=
----LWZN59vNAvxzFcrLn-- From 3a528dbe.58ca57fc@apotheke-dumrese.com Thu Nov 24 09:50:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfIQl-0007IM-Ro for dnsext-archive@megatron.ietf.org; Thu, 24 Nov 2005 09:50:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10547 for ; Thu, 24 Nov 2005 09:49:55 -0500 (EST) Received: from [85.196.211.117] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EfIjo-0000na-Dq for dnsext-archive@ietf.org; Thu, 24 Nov 2005 10:10:19 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Thu, 24 Nov 2005 16:50:20 +0200 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Thu, 24 Nov 2005 16:50:20 +0200 Message-ID: <000001c5f105$2eaac080$0100007f@localhost> From: "Ashton Powell" <3a528dbe.58ca57fc@apotheke-dumrese.com> To: Subject: Hey bro, found this site Date: Thu, 24 Nov 2005 16:50:20 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F105.2EAAC080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.3 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F105.2EAAC080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.mogohp.com/pt/?46&wyskd ------=_NextPart_000_0001_01C5F105.2EAAC080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C5F105.2EAAC080-- From owner-namedroppers@ops.ietf.org Thu Nov 24 14:39:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfMwd-0001xi-Oa for dnsext-archive@megatron.ietf.org; Thu, 24 Nov 2005 14:39:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16063 for ; Thu, 24 Nov 2005 14:39:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfMq9-000KiE-V0 for namedroppers-data@psg.com; Thu, 24 Nov 2005 19:33:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY autolearn=ham version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfMq6-000Khg-L2 for namedroppers@ops.ietf.org; Thu, 24 Nov 2005 19:33:03 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO0017F5; 24 Nov 2005 14:38:38 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 24 Nov 2005 14:38:24 -0500 Received: from connotech.com (209.71.204.102) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG0017F4; 24 Nov 2005 14:38:15 -0500 Message-ID: <43861D3A.306@connotech.com> Date: Thu, 24 Nov 2005 15:06:18 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: DNSSEC deployment , namedroppers@ops.ietf.org Subject: Hands-off DNS root zone security proposal Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all: The political aspects of signing the DNS root zone seem to be recurring with little indication that some progress in this direction can be made in a predictable time. Echoes from a recent centr meeting (i.e. an association of ccTLD registries, at http://www.centr.org) indicate that "There seems to be a need for a Trust Anchor Distribution mechanism with which one can distribute multiple trust-anchors (e.g. those of TLDs) without the need for the mechanism itself to rely on [the DNS root] trust anchor." (- Olaf M. Kolkman). The present proposal is inspired from an approach has been taken by the ICAO (International Civil Aviation Authority) for their "PKI for Machine Readable Travel Documents [i.e. electronic passports]" (which bears little relation to the IETF PKI given the amount of simplification they did in the PKI model). Basically, the overseeing organization (ICAO as a treaty organization / ICANN as a domain manager overseeing TLDs) merely collects public key information from its constituency ("member states" for ICAO / TLD managers for ICANN), puts it together in a computer file, and makes it available to the public (ICAO Public Key Directory / ICANN "TLD TAK-i file" explained below). No digital signature by the overseeing organization, hence little mixed signals about the overseeing organization operational liability implied by a "digital signature." Those interested in the institutional paperwork and MoUs can look at http://www.icao.int/icao/en/atb/fal/mrtd/tagmrtd16/Tagmrtd16_026_ en.pdf. Important third parties will be interested in reading the computer file for configuring signature verification systems (for ICAO, airlines for passenger identification at boarding time / for ICANN, DNS resolver software developers and vendors for embedding trust anchor key material in software release initial configuration). In the case of ICANN, it is operationally more difficult (i.e. unrealistic) to update the configuration in signature verification systems (i.e. fielded resolver software) than in the case of ICAO member states (i.e. border control equipment) and airlines (boarding control systems). Accordingly, the present proposal assumes a clear separation of Trust Anchor Key initialization (TAK-i) from Trust Anchor Key rollover (TAK-r). The TLD TAK-i file maintained by ICANN would thus be concerned only with TAK-i related public data. Accordingly, the update operations on the TLD TAK-i file would be limited to: o adding TAK-i related public data for a TLD that will support DNSSEC, o updates in the case of TLD redelegation incidents, i.e. when a TLD is redelegated and the TAK-i private data counterpart does not follow the redelagation. The above is intended to be independent of a specific TAK-i and TAK-r solution. Nonetheless, the TAKREM for DNS (draft-moreau-dnsext-takrem-dns-00.txt) is indeed well suited to the present proposal, notably: o TAKREM meets the required separation of TAK-i from TAK-r, o TAKREM allows the preparation of TAK-i public data well in advance of the decision to make a TLD DNSSEC-aware, o the TAK-i private data counterpart is easily transferred from one organization to its successor in the case of a mutually agreed TLD redelegation. So, the above is presented as a path to DNSSEC deployment without full support of DNSSEC in root zone management. Perhaps the institutional arrangement can be described as "the root zone provisioning by ICANN is augmented with the collection of Trust Anchor Key public information from TLDs but the root zone DNS operation is not modified." So it is hands-off, i.e. no hands-on handling of private key material by ICANN or root zone operator. Hope it can be useful. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 24 14:58:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfNEt-0000aM-Tu for dnsext-archive@megatron.ietf.org; Thu, 24 Nov 2005 14:58:40 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18284 for ; Thu, 24 Nov 2005 14:57:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfN9u-000MGJ-A1 for namedroppers-data@psg.com; Thu, 24 Nov 2005 19:53:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EfN9t-000MFz-B9 for namedroppers@ops.ietf.org; Thu, 24 Nov 2005 19:53:29 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jAOJrM0t047698; Thu, 24 Nov 2005 20:53:23 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3--64027194" Message-Id: Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: [dnssec-deployment] Hands-off DNS root zone security proposal Date: Thu, 24 Nov 2005 20:53:15 +0100 To: Thierry Moreau X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-3--64027194 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit > > The political aspects of signing the DNS root zone seem to be > recurring with little indication that some progress in this > direction can be made in a predictable time. > Before we get endless threads: The political aspects of signing the root are more out than in scope for namedroppers. Thanks, --Olaf Kolkman DNSEXT Co Chair. ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-3--64027194 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.1 (Darwin) Comment: This message is locally signed. iD8DBQFDhhowtN/ca3YJIocRApMHAJ9KyGe6M49LzayD8939tE76+H2LsQCg6nts P0Z8tbdQFHi/w5rsoW3mgz0= =+Iwd -----END PGP SIGNATURE----- --Apple-Mail-3--64027194-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From jorgensencmj@aurapressing.com Thu Nov 24 16:15:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfORg-0002it-9I for dnsext-archive@megatron.ietf.org; Thu, 24 Nov 2005 16:15:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25646 for ; Thu, 24 Nov 2005 16:15:14 -0500 (EST) Received: from [213.236.151.28] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EfOkk-0007ls-E2 for dnsext-archive@ietf.org; Thu, 24 Nov 2005 16:35:39 -0500 Received: from [205.248.102.79] (port=25 helo=mailc.microsoft.com) by mailc.microsoft.com with smtp for bg@microsoft.com; Thu, 24 Nov 2005 22:15:37 +0100 Received: from [32.97.182.141] (port=25 helo=e1.ny.us.ibm.com) by e1.ny.us.ibm.com with smtp for bg@ibm.com; Thu, 24 Nov 2005 22:15:37 +0100 Message-ID: <000001c5f13a$ffaf4180$0100007f@localhost> From: "Zane Bryant" To: Subject: The Industries leading enhancement product, now on sale! Date: Thu, 24 Nov 2005 22:15:37 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F13A.FFAF4180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.4 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F13A.FFAF4180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing- no more ripoffs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere! A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results. Millions of men are taking advantage of this revolutionary new product - Don't be left behind! As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself! Here's the link to check out! http://www.kinel.net/pt/?46&idqjx ------=_NextPart_000_0001_01C5F13A.FFAF4180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally the real thing - no more tip-offs! Enhancment Patches are hot right now, VERY hot! Unfortunately, most are cheap imitiations and do very little to increase your size and stamina. Well this is the real thing, not an imitation! One of the very originals, the absolutely strongest Patch available, anywhere!

A top team of British scientists and medical doctors have worked to develop the state-of-the-art Pen1s Enlargment Patch delivery system which automatically increases pen1s size up to 3-4 full inches. The patches are the easiest and most effective way to increase your size. You won't have to take pills, get under the knife to perform expensive and very painful surgery, use any pumps or other devices. No one will ever find out that you are using our product. Just apply one patch on your body and wear it for 3 days and you will start noticing dramatic results.

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

As an added incentive, they are offering huge discount specials right now, check out the site to see for yourself!

Here's the link to check out!

NamePatchesRegularNow
Steel Package10 Patches$79.95$49.95Free shipping
Silver Package25 Patches$129.95$99.95Free shipping and exercise manual included
Gold Package40 Patches$189.95$149.95Free shipping and exercise manual included
Platinum Package65 Patches$259.95$199.95Free shipping and exercise manual included
------=_NextPart_000_0001_01C5F13A.FFAF4180-- From owner-namedroppers@ops.ietf.org Thu Nov 24 20:22:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfSIW-0004cu-V3 for dnsext-archive@megatron.ietf.org; Thu, 24 Nov 2005 20:22:45 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21979 for ; Thu, 24 Nov 2005 20:22:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfSEQ-000Nsl-Jn for namedroppers-data@psg.com; Fri, 25 Nov 2005 01:18:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfSEP-000NsX-SZ for namedroppers@ops.ietf.org; Fri, 25 Nov 2005 01:18:30 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id jAP1Dw7s028622 for ; Thu, 24 Nov 2005 20:13:58 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA7yaG33; Thu, 24 Nov 05 20:13:53 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id jAP1FrQp025817; Thu, 24 Nov 2005 20:15:59 -0500 (EST) Date: Thu, 24 Nov 2005 20:15:52 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Peter Koch cc: IETF DNSEXT WG Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-trans-02.txt In-Reply-To: Message-ID: References: <200502242137.j1OLbqU02800@grimsvotn.TechFak.Uni-Bielefeld.DE> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I've partially reviewed trans-03. I don't think the doc is ready for WGLC. Overall recommendation: I have concerns about the wisdom of a partial typecode rollover (especially of DS, with it's oh-so-funky only-RR-not-in-the-child semantics), which is what this doc recommends. I'm OK with pushing this doc forward as a historical record, but it needs to be clearly noted (in the abstract, intro, and section 3) that the recommendation was current as of date XXX (~1 year ago), not the date of publication. Numerous editorial comments have been sent to the editors. Here are some slightly more substantive ones: ---- 2.2.3 I don't necessarily assume that the NSEC RR type won't change -- I think algorithm number signaling might be used with or without a RR type code change. Perhaps that means we should duplicate this section. Or just suggest that these signaling mechanisms might be mixed-and-matched. ---- 2.2.3.2 and 2.2.4.2 As I wrote in February, I see no need to split the algorithm number or digest algorithm number space -- we could specifcy NSEC v. NSEC3 on a per-number basis rather than saying "numbers above X are for NSEC3". On Mon, 28 Feb 2005, Samuel Weiler wrote: > I also noticed that 2.2.3.2 suggests splitting the algorithm space > with each version of DNSSEC. As David Blacka's experiments draft > suggests, there might be more efficient ways to do this, and blindly > allocating half of the algorithm numbers at each versioning sounds > very limiting. -- 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 NitaFitch@nutrablue.com Thu Nov 24 21:10:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfT2v-00059U-05 for dnsext-archive@megatron.ietf.org; Thu, 24 Nov 2005 21:10:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25662; Thu, 24 Nov 2005 21:09:59 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfTM4-0001Eo-QB; Thu, 24 Nov 2005 21:30:29 -0500 Received: from cpe-66-65-231-156.nycap.res.rr.com ([66.65.231.156]) by mx2.foretec.com with smtp (Exim 4.24) id 1EfT98-0007uB-1t; Thu, 24 Nov 2005 21:17:06 -0500 Received: from sodk@localhost by 2XT.int (8.11.6/8.11.6); Thu, 24 Nov 2005 21:45:56 -0500 Message-ID: <0maKskL41yEmTj0paB0BkE@micimn.com> From: "Lloyd Moreland" Reply-To: "Lloyd Moreland" To: droyer@ietf.org, rfc-editor@ietf.org, v6tc@ietf.org, dnsext-archive@ietf.org Subject: Huge $avings on ALL best-selling Symantec titles Date: Fri, 25 Nov 2005 05:44:56 +0300 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: NitaFitch@nutrablue.com Content-Type: multipart/mixed; boundary="--4756685614152249" X-Spam-Score: 3.7 (+++) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 rQbW ----4756685614152249 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 2
Opt-in Email Special Offer   = ;  unsubscribe me

=
<= td width=3D5 bgcolor=3D#000080>
SEARCH

=

TOP 10 NEW TITLES

=
<= td width=3D132> Adobe Acrobat 7 Pro<= td width=3D8>  these other items...
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&= nbsp;2 Creative Suite 2
 3 MS Office 2003 Pro
 4
 5<= /td> Macromedia Flash 8
 6 Dreamweaver 8
 7 Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
 10 Borland Architect 2= 005
  See more by t= his manufacturer
  Microsoft
   Macromedia
   Adobe
  Customers also bought
  

Microsoft Windows XP Profes= sional *w/SP2*
Microsoft

Choose:
<= /a> =
=



Availability: Available for INSTAN= T download!
Coupon Code: aIzqnJ
Platform: Windows XP

Sales Rank: #1
System requirements  |  Other Versions Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 1462 reviews. Write a review.

List Price:$299.00
Price:$49.99
= You Save:$249.01 (80%)
=

Adobe Crea= tive Suite 2 *Premium*
Adobe

Choose:=
 



Availability: Available for INST= ANT download!
Coupon Code: QAGlKlB
Platform: Windows XP

Sales Rank: #2
System requirements  |  Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 15215 review= s. Write a review.

List Price:$1199.00
Price:$149.99
You Save:$1049.01 (95%)

Microsoft Office 2003 *Professional*
Microsoft

Choose:
 

<= b>List Price:=
$499.00
Price:$69.99
You Save:= $429.01 (85%)



Availability: Available for INSTANT download! Coupon Code: 2Qqx0oq
Platform: Windows XP

= Sales Rank: #3
System requirements  |  Other Versions
Dat= e Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 116993 reviews. Write a review.

= Adobe Acrobat Professional V 7.0
Adobe

C= hoose:
 
=

You Save:



Availability: Available for INSTANT do= wnload!
Coupon Code: X25HApSn
Platform: Windows XP

Sales Rank: #4
System requirements  |  Other Versions Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 15519 reviews. Write a review.

=

List Price:$499.00
Price:$69.99
$429.01 (85%)
----4756685614152249-- From owner-namedroppers@ops.ietf.org Fri Nov 25 04:41:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efa4m-00012d-Vf for dnsext-archive@megatron.ietf.org; Fri, 25 Nov 2005 04:41:05 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02829 for ; Fri, 25 Nov 2005 04:40:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Efa0R-000D9L-B3 for namedroppers-data@psg.com; Fri, 25 Nov 2005 09:36:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Efa0Q-000D98-D6 for namedroppers@ops.ietf.org; Fri, 25 Nov 2005 09:36:34 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 976AE33C40; Fri, 25 Nov 2005 09:36:32 +0000 (GMT) Message-ID: <4386DB21.5080509@algroup.co.uk> Date: Fri, 25 Nov 2005 09:36:33 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: iesg@ietf.org CC: IETF-Announce , namedroppers@ops.ietf.org Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG wrote: > The IESG has received a request from the DNS Extensions WG to consider the > following documents: > > - 'Minimally Covering NSEC Records and DNSSEC On-line Signing ' > as a Proposed Standard According to RFC 2026 one of the criteria for Proposed Standard is "appears to enjoy enough community interest to be considered valuable". I do not believe we have seen evidence of this for this I-D. Indeed, we have only seen statements that this will _not_ be deployed. I propose that this should be downgraded to Experimental. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Nov 25 04:54:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfaHd-00041M-24 for dnsext-archive@megatron.ietf.org; Fri, 25 Nov 2005 04:54:21 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04413 for ; Fri, 25 Nov 2005 04:53:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfaEf-000EUE-9g for namedroppers-data@psg.com; Fri, 25 Nov 2005 09:51:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.169.16.30] (helo=exchangebe.corporate.telin.nl) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfaEZ-000ERo-MK for namedroppers@ops.ietf.org; Fri, 25 Nov 2005 09:51:11 +0000 Received: from netinfo.corporate.telin.nl ([195.169.16.63]) by exchangebe.corporate.telin.nl with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Nov 2005 10:51:09 +0100 Date: Fri, 25 Nov 2005 10:51:09 +0100 (CET) From: Roy Arends X-X-Sender: roy@netinfo.corporate.telin.nl To: Ben Laurie cc: iesg@ietf.org, IETF-Announce , namedroppers@ops.ietf.org Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard In-Reply-To: <4386DB21.5080509@algroup.co.uk> Message-ID: References: <4386DB21.5080509@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 25 Nov 2005 09:51:09.0811 (UTC) FILETIME=[C3482430:01C5F1A5] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 25 Nov 2005, Ben Laurie wrote: > The IESG wrote: >> The IESG has received a request from the DNS Extensions WG to consider the >> following documents: >> >> - 'Minimally Covering NSEC Records and DNSSEC On-line Signing ' >> as a Proposed Standard > > According to RFC 2026 one of the criteria for Proposed Standard is > "appears to enjoy enough community interest to be considered valuable". > I do not believe we have seen evidence of this for this I-D. Indeed, we > have only seen statements that this will _not_ be deployed. > > I propose that this should be downgraded to Experimental. I concur 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 25 09:20:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfeR7-0005by-Tr for dnsext-archive@megatron.ietf.org; Fri, 25 Nov 2005 09:20:26 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00177 for ; Fri, 25 Nov 2005 09:19:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfeN3-000BOD-Q9 for namedroppers-data@psg.com; Fri, 25 Nov 2005 14:16:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EfeN3-000BLD-0v for namedroppers@ops.ietf.org; Fri, 25 Nov 2005 14:16:13 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO0019C7; 25 Nov 2005 09:16:43 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 25 Nov 2005 09:16:03 -0500 Received: from connotech.com (209.71.204.111) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG0019C6; 25 Nov 2005 09:15:59 -0500 Message-ID: <4387249C.1010600@connotech.com> Date: Fri, 25 Nov 2005 09:50:04 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie CC: iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard References: <4386DB21.5080509@algroup.co.uk> In-Reply-To: <4386DB21.5080509@algroup.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ben Laurie wrote: > The IESG wrote: > >>The IESG has received a request from the DNS Extensions WG to consider the >>following documents: >> >>- 'Minimally Covering NSEC Records and DNSSEC On-line Signing ' >> as a Proposed Standard > > > According to RFC 2026 one of the criteria for Proposed Standard is > "appears to enjoy enough community interest to be considered valuable". > I do not believe we have seen evidence of this for this I-D. Indeed, we > have only seen statements that this will _not_ be deployed. > > I propose that this should be downgraded to Experimental. > > Cheers, > > Ben. > I concur -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Nov 25 10:06:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eff9o-0006jH-NX for dnsext-archive@megatron.ietf.org; Fri, 25 Nov 2005 10:06:36 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05246 for ; Fri, 25 Nov 2005 10:05:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eff5p-000FQl-AK for namedroppers-data@psg.com; Fri, 25 Nov 2005 15:02:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Eff5o-000FQY-4Y for namedroppers@ops.ietf.org; Fri, 25 Nov 2005 15:02:28 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jAPF1x55059088; Fri, 25 Nov 2005 16:01:59 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <4386DB21.5080509@algroup.co.uk> References: <4386DB21.5080509@algroup.co.uk> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-19-4895660" Message-Id: Cc: iesg@ietf.org, Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard Date: Fri, 25 Nov 2005 16:01:58 +0100 To: Ben Laurie X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-19-4895660 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit > According to RFC 2026 one of the criteria for Proposed Standard is > "appears to enjoy enough community interest to be considered > valuable". > I do not believe we have seen evidence of this for this I-D. > Indeed, we > have only seen statements that this will _not_ be deployed. > > I propose that this should be downgraded to Experimental. Gentlemen, We started gauging what the status needed to be in Paris (see http://tools.ietf.org/wg/dnsext/minutes?item=minutes63.html where at least one stakeholder in the enumeration business showed interest) Then these issues have been raised specifically during last call: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/ msg01100.html and again in: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/ msg01241.html In other words I think the working group passed this decision point. Personally I do not care either way, Experimental or Proposed, but I do care not having to revisit old decisions. Thanks, --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-19-4895660 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.1 (Darwin) Comment: This message is locally signed. iD8DBQFDhydmtN/ca3YJIocRArxHAKCsU4s0S1GF1nSSZ6JeOcyeXObT8gCgk5fj bukl5EH4Eck0fJA8fUk3CvM= =UuVE -----END PGP SIGNATURE----- --Apple-Mail-19-4895660-- -- to unsubscribe send a message to namedroppers-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 25 10:15:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EffIR-00027A-Dm for dnsext-archive@megatron.ietf.org; Fri, 25 Nov 2005 10:15:31 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06311 for ; Fri, 25 Nov 2005 10:14:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EffFY-000GLs-PI for namedroppers-data@psg.com; Fri, 25 Nov 2005 15:12:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EffFX-000GLe-HM for namedroppers@ops.ietf.org; Fri, 25 Nov 2005 15:12:31 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id F092633C3F; Fri, 25 Nov 2005 15:12:29 +0000 (GMT) Message-ID: <438729DE.8030500@algroup.co.uk> Date: Fri, 25 Nov 2005 15:12:30 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: iesg@ietf.org, Namedroppers Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard References: <4386DB21.5080509@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf M. Kolkman wrote: >> According to RFC 2026 one of the criteria for Proposed Standard is >> "appears to enjoy enough community interest to be considered valuable". >> I do not believe we have seen evidence of this for this I-D. Indeed, we >> have only seen statements that this will _not_ be deployed. >> >> I propose that this should be downgraded to Experimental. > > > Gentlemen, > > We started gauging what the status needed to be in Paris (see > http://tools.ietf.org/wg/dnsext/minutes?item=minutes63.html where at least > one stakeholder in the enumeration business showed interest) > > Then these issues have been raised specifically during last call: > http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01100.html > and again in: > http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01241.html > > > In other words I think the working group passed this decision point. > > Personally I do not care either way, Experimental or Proposed, but I do > care not having to revisit old decisions. But ... what those documents appear to say is that you intend to go for Experimental, then for some unknown reason you changed your mind at the last moment. So, if any decision was made at all (which is far from clear) it was for Experimental. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Nov 25 10:43:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Effjr-0004ZP-VW for dnsext-archive@megatron.ietf.org; Fri, 25 Nov 2005 10:43:52 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09821 for ; Fri, 25 Nov 2005 10:43:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Effgv-000JCb-C5 for namedroppers-data@psg.com; Fri, 25 Nov 2005 15:40:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Effgu-000JCP-3E for namedroppers@ops.ietf.org; Fri, 25 Nov 2005 15:40:48 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jAPFeVjh059496; Fri, 25 Nov 2005 16:40:31 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <438729DE.8030500@algroup.co.uk> References: <4386DB21.5080509@algroup.co.uk> <438729DE.8030500@algroup.co.uk> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-25-7207366" Message-Id: <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> Cc: iesg@ietf.org, Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard Date: Fri, 25 Nov 2005 16:40:29 +0100 To: Ben Laurie X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-25-7207366 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Ben argued: > But ... what those documents appear to say is that you intend to go > for > Experimental, then for some unknown reason you changed your mind at > the > last moment. Yep, with explanation and all, in the open for anybody to see, to question or to comment. There was no feedback and it is not that I didn't wait for it before pushing the document to the IESG. The working groups consensus as I read it is that the working group thinks that online-signing needs to update 4034/4045 and that it is best to do that by moving the doc on the standards track. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-25-7207366 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.1 (Darwin) Comment: This message is locally signed. iD8DBQFDhzButN/ca3YJIocRAgmJAKCBjdbSrwEUWkmHx/GDjJVThJmVuwCeMinZ najjRfz1x0ugb6uWdoYCfZk= =uMcu -----END PGP SIGNATURE----- --Apple-Mail-25-7207366-- -- to unsubscribe send a message to namedroppers-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 25 11:06:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efg5I-0006Nj-R3 for dnsext-archive@megatron.ietf.org; Fri, 25 Nov 2005 11:06:00 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12143 for ; Fri, 25 Nov 2005 11:05:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Efg2a-000Lfk-Eq for namedroppers-data@psg.com; Fri, 25 Nov 2005 16:03:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Efg2Z-000LfT-NG for namedroppers@ops.ietf.org; Fri, 25 Nov 2005 16:03:11 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO0019DE; 25 Nov 2005 11:03:42 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 25 Nov 2005 11:03:25 -0500 Received: from connotech.com (209.71.204.124) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG0019DD; 25 Nov 2005 11:03:19 -0500 Message-ID: <43873DC4.7040206@connotech.com> Date: Fri, 25 Nov 2005 11:37:24 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: Ben Laurie , iesg@ietf.org, Namedroppers Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard References: <4386DB21.5080509@algroup.co.uk> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf M. Kolkman wrote: >> According to RFC 2026 one of the criteria for Proposed Standard is >> "appears to enjoy enough community interest to be considered valuable". >> I do not believe we have seen evidence of this for this I-D. Indeed, we >> have only seen statements that this will _not_ be deployed. >> >> I propose that this should be downgraded to Experimental. > > > > Gentlemen, > > We started gauging what the status needed to be in Paris [...] > > In other words I think the working group passed this decision point. > > Personally I do not care either way, Experimental or Proposed, but I do > care > not having to revisit old decisions. > Isn't a last call a process step to get a feedback from a broader audience than the wg itself? If such is the case, count me as an outsider of IETF DNSEXT who got a chance to review this only at the last call step! Isn't a last call a last chance to double check for minor glitches or misunderstanding in the wg procedures, or whatever last minute check might discover? In this instance, I think the Experimental or Proposed status is still a relevant issue. The Experimental (or Informational) status announces to the reader that the foremost protocol features for privacy protection of authenticated denial of existence lies elsewhere, i.e. more efficient/accurate documentation of engineering decisions. I would respectfully request the wg chairs to take this view into perspective while handling the wg decision process. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Nov 25 11:40:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efgd0-0002wG-QP for dnsext-archive@megatron.ietf.org; Fri, 25 Nov 2005 11:40:50 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15799 for ; Fri, 25 Nov 2005 11:40:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfgZo-000Om4-8Q for namedroppers-data@psg.com; Fri, 25 Nov 2005 16:37:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EfgZn-000Olt-DK for namedroppers@ops.ietf.org; Fri, 25 Nov 2005 16:37:31 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jAPGbL4Z060071; Fri, 25 Nov 2005 17:37:21 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <43873DC4.7040206@connotech.com> References: <4386DB21.5080509@algroup.co.uk> <43873DC4.7040206@connotech.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-27-10613388" Message-Id: <532ECFCA-5038-429C-A9CF-76B1E886AB6E@NLnetLabs.nl> Cc: Ben Laurie , iesg@ietf.org, Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard Date: Fri, 25 Nov 2005 17:37:15 +0100 To: Thierry Moreau X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-27-10613388 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit > Isn't a last call a process step to get a feedback from a broader > audience than the wg itself? If such is the case, count me as an > outsider of IETF DNSEXT who got a chance to review this only at the > last call step! Yep correct. But I am trying to argue that we, the working group, of which I consider Ben and Roy active and valuable participants did not provide this feedback when it was asked for. I am arguing that this was an explicit item during the last call and that we reached consensus decision. I also argue that there have at least one proponent for this technique on record (Paris minutes). > Isn't a last call a last chance to double check for minor glitches > or misunderstanding in the wg procedures, or whatever last minute > check might discover? Yes, but see above, I argue we are revisiting decisions. > > In this instance, I think the Experimental or Proposed status is > still a relevant issue. The Experimental (or Informational) status > announces to the reader that the foremost protocol features for > privacy protection of authenticated denial of existence lies > elsewhere, i.e. more efficient/accurate documentation of > engineering decisions. I would respectfully request the wg chairs > to take this view into perspective while handling the wg decision > process. We do not yet have a protocol feature for privacy protection of authenticated denial of existence. Seriously, we do not know if there is a skeleton in that particular NSEC3 closet. I personally hope there is not, but we might find unsolvable technical problems in the forthcoming workshops, we might even get somebody arguing for experimental status during IETF last call :-). If you think there should be some text that explicitly does not exclude other mechanisms to be deployed on the standards track than I think that is a fine addition to the document. It is a new concern that has not been brought up yet. Send text. I probably regret writing multiple mails on the subject during one day. I'll try to stay away from the keyboard :-) Have a nice weekend, --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-27-10613388 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.1 (Darwin) Comment: This message is locally signed. iD8DBQFDhz3AtN/ca3YJIocRAtymAKDpG8t1OEjjDy1SZi8EIjuqlGTHnwCguj2/ qWbEmv13J1ebDhNO1fPRBks= =Y0c9 -----END PGP SIGNATURE----- --Apple-Mail-27-10613388-- -- to unsubscribe send a message to namedroppers-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 25 18:47:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfnI1-0006lS-4V for dnsext-archive@megatron.ietf.org; Fri, 25 Nov 2005 18:47:37 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03853 for ; Fri, 25 Nov 2005 18:46:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfnBL-000H5k-GO for namedroppers-data@psg.com; Fri, 25 Nov 2005 23:40:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EfnBJ-000H5D-00 for namedroppers@ops.ietf.org; Fri, 25 Nov 2005 23:40:41 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 421BA11425 for ; Fri, 25 Nov 2005 23:40:40 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard In-Reply-To: Your message of "Fri, 25 Nov 2005 16:40:29 +0100." <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> References: <4386DB21.5080509@algroup.co.uk> <438729DE.8030500@algroup.co.uk> <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> Date: Fri, 25 Nov 2005 23:40:40 +0000 Message-Id: <20051125234040.421BA11425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # The working groups consensus as I read it is that the working group thinks # that online-signing needs to update 4034/4045 and that it is best to do # that by moving the doc on the standards track. i wasn't in paris, but i concur with this position. -- to unsubscribe send a message to namedroppers-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 26 07:36:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfzHo-0006If-2K for dnsext-archive@megatron.ietf.org; Sat, 26 Nov 2005 07:36:12 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05132 for ; Sat, 26 Nov 2005 07:35:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfzCH-000MLl-Bl for namedroppers-data@psg.com; Sat, 26 Nov 2005 12:30:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EfzCG-000MLL-HE for namedroppers@ops.ietf.org; Sat, 26 Nov 2005 12:30:28 +0000 Received: from cc730311-a.ENSCH1.OV.HOME.NL (cc730311-a.ensch1.ov.home.nl [82.75.151.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.schlyter.se (Postfix) with ESMTP id 5F1F22D493; Sat, 26 Nov 2005 13:30:20 +0100 (CET) Date: Sat, 26 Nov 2005 13:30:13 +0100 From: Roy Arends X-X-Sender: roy@cc730311-a To: "Olaf M. Kolkman" cc: Ben Laurie , iesg@ietf.org, Namedroppers Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard In-Reply-To: <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> Message-ID: References: <4386DB21.5080509@algroup.co.uk> <438729DE.8030500@algroup.co.uk> <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 25 Nov 2005, Olaf M. Kolkman wrote: > The working groups consensus as I read it is that the working group > thinks that online-signing needs to update 4034/4045 and that it is > best to do that by moving the doc on the standards track. Since this update is so incredibly minimal, how about adding this 'update' to the bis-updates document of the same author, and publish online signing as informational, since it does not require fundamental protocol change, but just implementation info. This way, consensus is not violated. Otherwise it looks to me that online signing is minimally updating 4034 and 4035 for the sole purpose of reaching proposed standard. 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 Sat Nov 26 07:39:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfzLM-00077z-11 for dnsext-archive@megatron.ietf.org; Sat, 26 Nov 2005 07:39:52 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05511 for ; Sat, 26 Nov 2005 07:39:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EfzIk-000N7w-G3 for namedroppers-data@psg.com; Sat, 26 Nov 2005 12:37:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EfzIj-000N7j-RE for namedroppers@ops.ietf.org; Sat, 26 Nov 2005 12:37:10 +0000 Received: from cc730311-a.ENSCH1.OV.HOME.NL (cc730311-a.ensch1.ov.home.nl [82.75.151.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.schlyter.se (Postfix) with ESMTP id 03B232D493; Sat, 26 Nov 2005 13:37:06 +0100 (CET) Date: Sat, 26 Nov 2005 13:37:04 +0100 From: Roy Arends X-X-Sender: roy@cc730311-a To: "Olaf M. Kolkman" cc: Thierry Moreau , Ben Laurie , iesg@ietf.org, Namedroppers Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard In-Reply-To: <532ECFCA-5038-429C-A9CF-76B1E886AB6E@NLnetLabs.nl> Message-ID: References: <4386DB21.5080509@algroup.co.uk> <43873DC4.7040206@connotech.com> <532ECFCA-5038-429C-A9CF-76B1E886AB6E@NLnetLabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 25 Nov 2005, Olaf M. Kolkman wrote: > But I am trying to argue that we, the working group, of which I > consider Ben and Roy active and valuable participants did not provide > this feedback when it was asked for. It is asked for now ! I'm acting now ! 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 Sat Nov 26 09:27:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg11Y-00086U-Rl for dnsext-archive@megatron.ietf.org; Sat, 26 Nov 2005 09:27:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15774 for ; Sat, 26 Nov 2005 09:26:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eg0x9-0009jl-8R for namedroppers-data@psg.com; Sat, 26 Nov 2005 14:22:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eg0x7-0009ja-MC for namedroppers@ops.ietf.org; Sat, 26 Nov 2005 14:22:58 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jAQEMZr26735; Sat, 26 Nov 2005 16:22:36 +0200 Date: Sat, 26 Nov 2005 16:22:35 +0200 (EET) From: Pekka Savola To: iesg@ietf.org cc: dhcwg@ietf.org, namedroppers@ops.ietf.org, ietf@ietf.org Subject: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard] In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, I'll break out the most substantial comments in separate messages.. On Mon, 14 Nov 2005, The IESG wrote: > The IESG has received a request from the Dynamic Host Configuration WG to > consider the following documents: > > - 'A DNS RR for Encoding DHCP Information (DHCID RR) ' > as a Proposed Standard > - 'Resolution of FQDN Conflicts among DHCP Clients ' > as a Proposed Standard > - 'The DHCP Client FQDN Option ' > as a Proposed Standard > - 'The DHCPv6 Client FQDN Option ' > as a Proposed Standard I have only one major comment on DHCID on its use of MD5 as a glued-in hash-function. The rest of the comments are rather straightforward. substantial ---------- In order to avoid exposing potentially sensitive identifying information, the data stored is the result of a one-way MD5 [5] hash computation. The hash includes information from the DHCP client's REQUEST message as well as the domain name itself, so that the data stored in the DHCID RR will be dependent on both the client identification used in the DHCP protocol interaction and the domain name. This means that the DHCID RDATA will vary if a single client is associated over time with more than one name. This makes it difficult to 'track' a client as it is associated with various domain names. The MD5 hash algorithm has been shown to be weaker than the SHA-1 algorithm; it could therefore be argued that SHA-1 is a better choice. However, SHA-1 is significantly slower than MD5. A successful attack of MD5's weakness does not reveal the original data that was used to generate the signature, but rather provides a new set of input data that will produce the same signature. Because we are using the MD5 hash to conceal the original data, the fact that an attacker could produce a different plaintext resulting in the same MD5 output is not significant concern. ==> while the informatione exposure of someone cracking the MD5 hash is not too huge, I believe it is unacceptable to design new protocols without the capability to switch the hash function as need be. This could be achieved for example by reserving one additional byte from the start of the DHCID record to designate the hash function used. If you don't bother to define your own registry (for all of me, you could include MD5 there as well, but at least include SHA1 and preferably also SHA-256), you could possibly re-use http://www.iana.org/assignments/ds-rr-types or something like that. That way, we can introduce new hash functions in a backward compatible manner later on, with no need to revamp the protocol. If we don't do this, we'll need to define DHCID2, DHCID3, .. etc. records further down in the future (w/ different hash functions) and make DHCP co-exist with all of them. That's bound to cause a lot of protocol complexity, and I don't think we want to go there. ... New DHCID RR type codes are tentatively assigned after the specification for the associated type code, published as an Internet Draft, has received expert review by a designated expert. The final assignment of DHCID RR type codes is through Standards Action, as defined in RFC 2434 [6]. ==> this new RR type code assignment procedure seems to be underspecified. Is there actually harm in just doing this through expert review, and giving the expert guidance that at least an I-D must be published? If so, you could reword this like: New DHCID RR type codes are assigned through Standards Action or Expert Review as defined in RFC2434 [6]. The expert should require sufficient public specification of the new type code. .. in any case, please use existing RFC2434 mechanism unless you're absolutely sure those won't fit your needs. semi-editorial -------------- Conflicts can arise if multiple DHCP clients wish to use the same DNS name. To resolve such conflicts, "Resolution of DNS Name Conflicts" [1] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients using them. ==> conflicts also occur when multiple nodes use the same FQDN while only a part of them uses DHCP. So, the above applicability could be reworded, e.g., like follows: Conflicts can arise if multiple nodes wish to use the same DNS name. To resolve such conflicts when the nodes are using DHCP, "Resolution of DNS Name Conflicts" [1] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients using them. 3.5. Examples ==> I'd also have liked to see an example of DHCPv6 DHCID generation. editorial --------- A DHCP server allocating the IPv4 address 10.0.0.1 to a client with Ethernet MAC address 01:02:03:04:05:06 using domain name "client.example.com" uses the client's link-layer address to identify the client. ==> you should probably use RFC3330 documentation prefix here instead of 10/8. To resolve such conflicts, "Resolution of DNS Name Conflicts" [1] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. ==> no refs in the abstract A set of procedures to allow DHCP [7] clients and servers to automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed in "Resolution of DNS Name Conflicts" [1]. ==> also refer DHCPv6 here, please -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-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 26 13:12:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg4X4-0002EA-3u for dnsext-archive@megatron.ietf.org; Sat, 26 Nov 2005 13:12:18 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11324 for ; Sat, 26 Nov 2005 13:11:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eg4S1-0007lu-KI for namedroppers-data@psg.com; Sat, 26 Nov 2005 18:07:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Eg4S0-0007lh-H6 for namedroppers@ops.ietf.org; Sat, 26 Nov 2005 18:07:04 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jAQI6O4c078212; Sat, 26 Nov 2005 19:06:24 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: References: <4386DB21.5080509@algroup.co.uk> <438729DE.8030500@algroup.co.uk> <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-41-102361080" Message-Id: Cc: Ben Laurie , iesg@ietf.org, Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard Date: Sat, 26 Nov 2005 19:06:23 +0100 To: Roy Arends X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-41-102361080 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit > > Otherwise it looks to me that online signing is minimally updating > 4034 > and 4035 for the sole purpose of reaching proposed standard. > It is clear where we are: You argue to revert the groups conscious decision on this. Its up to the IESG to push back if they agree with you. As said, if you want the problem you want to address is that "Online signing should explicitly say that it is not expected to be the exclusive solution in this problem space" then that is something you can fix with text. Send text. If the paraphrase of the problem is not correct then please explain what the actual problem is. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-41-102361080 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.1 (Darwin) Comment: This message is locally signed. iD8DBQFDiKQftN/ca3YJIocRAgq1AKDT2wRbDb5A1qdrxOKUc+7XrgPURwCdFooz dWmZTIXh6/OE0mSoIIdIBok= =IR3w -----END PGP SIGNATURE----- --Apple-Mail-41-102361080-- -- to unsubscribe send a message to namedroppers-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 26 14:13:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg5Uh-0001hp-3P for dnsext-archive@megatron.ietf.org; Sat, 26 Nov 2005 14:13:55 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16841 for ; Sat, 26 Nov 2005 14:13:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eg5Rb-000Egy-Ku for namedroppers-data@psg.com; Sat, 26 Nov 2005 19:10:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eg5Ra-000Egc-Cy for namedroppers@ops.ietf.org; Sat, 26 Nov 2005 19:10:43 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jAQJAG332528; Sat, 26 Nov 2005 21:10:16 +0200 Date: Sat, 26 Nov 2005 21:10:16 +0200 (EET) From: Pekka Savola To: Ted Lemon cc: iesg@ietf.org, dhcwg@ietf.org, namedroppers@ops.ietf.org, ietf@ietf.org Subject: Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard] In-Reply-To: <200511261243.21694.mellon@fugue.com> Message-ID: References: <200511261243.21694.mellon@fugue.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, 26 Nov 2005, Ted Lemon wrote: > Making a hash function interchangeable in DHCID makes the conflict detection > algorithm hugely more complicated, and possibly not workable at all. Think > about how that would work. AFAICS, it shouldn't be all that complicated as long as the implementations [checking for conflicts] support all the algorithms used at the site, right? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-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 26 14:14:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg5VX-0001xw-Ab for dnsext-archive@megatron.ietf.org; Sat, 26 Nov 2005 14:14:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16948 for ; Sat, 26 Nov 2005 14:14:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eg5UD-000F0H-Bo for namedroppers-data@psg.com; Sat, 26 Nov 2005 19:13:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Eg5UC-000Ezs-96 for namedroppers@ops.ietf.org; Sat, 26 Nov 2005 19:13:24 +0000 Received: from cc730311-a.ENSCH1.OV.HOME.NL (cc730311-a.ensch1.ov.home.nl [82.75.151.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.schlyter.se (Postfix) with ESMTP id A43332D493; Sat, 26 Nov 2005 20:13:21 +0100 (CET) Date: Sat, 26 Nov 2005 20:13:15 +0100 From: Roy Arends X-X-Sender: roy@cc730311-a To: "Olaf M. Kolkman" cc: Ben Laurie , iesg@ietf.org, Namedroppers Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard In-Reply-To: Message-ID: References: <4386DB21.5080509@algroup.co.uk> <438729DE.8030500@algroup.co.uk> <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, 26 Nov 2005, Olaf M. Kolkman wrote: > > Otherwise it looks to me that online signing is minimally updating > > 4034 > > and 4035 for the sole purpose of reaching proposed standard. > > > > It is clear where we are: You argue to revert the groups conscious > decision on this. Its up to the IESG to push back if they agree with > you. Olaf, I proposed a solution that does _NOT_ violate the groups 'conscious' decision on this: "Since this update is so incredibly minimal, how about adding this 'update' to the bis-updates document of the same author, and publish online signing as informational, since it does not require fundamental protocol change, but just implementation info. This way, consensus is not violated." > As said, if you want the problem you want to address is that "Online > signing should explicitly say that it is not expected to be the > exclusive solution in this problem space" then that is something you > can fix with text. Where did this come from ? > Send text. If the paraphrase of the problem is > not correct then please explain what the actual problem is. See above. 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 Sat Nov 26 19:55:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgApI-0001g9-RX for dnsext-archive@megatron.ietf.org; Sat, 26 Nov 2005 19:55:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11439 for ; Sat, 26 Nov 2005 19:54:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgAjg-0009A1-Nt for namedroppers-data@psg.com; Sun, 27 Nov 2005 00:49:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgAje-00099h-2m for namedroppers@ops.ietf.org; Sun, 27 Nov 2005 00:49:42 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id jAR0jBN4004934 for ; Sat, 26 Nov 2005 19:45:11 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAN0aOOj; Sat, 26 Nov 05 19:45:08 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id jAR0ksJl020481; Sat, 26 Nov 2005 19:46:55 -0500 (EST) Date: Sat, 26 Nov 2005 19:46:54 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Roy Arends cc: "Olaf M. Kolkman" , Ben Laurie , iesg@ietf.org, Namedroppers Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard In-Reply-To: Message-ID: References: <4386DB21.5080509@algroup.co.uk> <438729DE.8030500@algroup.co.uk> <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I don't understand what the real issue is here. I saw Ben claim that we haven't seen evidence of community interest. And I'm hearing speculation that this document claims to update 4034 and 4035 just to justify it being on the standards track. These sound like different concerns and leave me wondering if there's some other underlying issue. Do you want this off the standards track as a way to discourage people from doing it? Do you want to see DNSEXT publishing fewer standards track documents generally? In the past, DNSEXT has not hesitated to publish tiny protocol changes as standards track documents, even when we knew they'd be included in (or even obsoleted by) other documents in the near future: see 3445, 3655, 3658, 3755, 3757, and 3845, all of which are now obsolete. Is there some reason why we should now be hesitant to push out minor changes in the standards track? -- 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 Sun Nov 27 06:16:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgKW0-0005fi-L8 for dnsext-archive@megatron.ietf.org; Sun, 27 Nov 2005 06:16:16 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29735 for ; Sun, 27 Nov 2005 06:15:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgKRl-000JjI-Fm for namedroppers-data@psg.com; Sun, 27 Nov 2005 11:11:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgKRi-000Jiv-0W for namedroppers@ops.ietf.org; Sun, 27 Nov 2005 11:11:50 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id C14D433C3F; Sun, 27 Nov 2005 11:11:47 +0000 (GMT) Message-ID: <43899477.5090103@algroup.co.uk> Date: Sun, 27 Nov 2005 11:11:51 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Samuel Weiler CC: Roy Arends , "Olaf M. Kolkman" , iesg@ietf.org, Namedroppers Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard References: <4386DB21.5080509@algroup.co.uk> <438729DE.8030500@algroup.co.uk> <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Samuel Weiler wrote: > I don't understand what the real issue is here. I saw Ben claim that > we haven't seen evidence of community interest. And I'm hearing > speculation that this document claims to update 4034 and 4035 just to > justify it being on the standards track. These sound like different > concerns and leave me wondering if there's some other underlying > issue. Do you want this off the standards track as a way to > discourage people from doing it? Do you want to see DNSEXT publishing > fewer standards track documents generally? > > In the past, DNSEXT has not hesitated to publish tiny protocol changes > as standards track documents, even when we knew they'd be included in > (or even obsoleted by) other documents in the near future: see 3445, > 3655, 3658, 3755, 3757, and 3845, all of which are now obsolete. Is > there some reason why we should now be hesitant to push out minor > changes in the standards track? Firstly, online signing is not a minor change - it completely violates one of the fundamental principles of DNSSEC: no online keys. The only reason we have NSEC (and hence the problems with it) in the first place is in order to conform with this principle. Secondly, the reason I objected was because I re-read RFC 2026 and realised that we did not appear to be conforming to it. The past behaviour of the WG w.r.t. 2026 strikes me as a red herring. Thirdly, I don't agree that 6.3 implies that the I-D should be on the standards track - what it says is that a replacement for an established standard has to follow the whole process, rather than jumping the queue, which seems an entirely unrelated circumstance to me. Fourthly, it is a WG item to fix the problems with NSEC. Until it was brought up in this thread I would not have even considered that anyone would stoop so low as to claim that once online signing is on the standards track then that obligation has been discharged. But it seems that this is a possibility in at least some people's minds, and since I do not agree that online signing is a viable fix, I feel I must also object on those grounds. I do agree with Olaf that these concerns would have been better brought up earlier in the process, but it seems my attention was elsewhere. I apologise. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From MelanieCourtney@aluglaver.com Sun Nov 27 07:54:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgM3X-0001Sn-FJ; Sun, 27 Nov 2005 07:54:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09818; Sun, 27 Nov 2005 07:54:15 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgMNB-0002Rj-Bh; Sun, 27 Nov 2005 08:15:19 -0500 Received: from f111207.upc-f.chello.nl ([80.56.111.207]) by mx2.foretec.com with smtp (Exim 4.24) id 1EgM3L-0005gR-Cy; Sun, 27 Nov 2005 07:54:53 -0500 Received: from QdbN@localhost by eTQ.int (8.11.6/8.11.6); Sun, 27 Nov 2005 15:56:40 -0100 Message-ID: From: "Diane Bridges" Reply-To: "Diane Bridges" To: dn@ietf.org Subject: Windows XP Pro $49.95, Office 2003 $69.95 Win XP Date: Sun, 27 Nov 2005 14:49:40 -0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: MelanieCourtney@aluglaver.com Content-Type: multipart/mixed; boundary="--mzKugy3aEMgYz37mbdV" X-Spam-Score: 0.3 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 KrVg ----mzKugy3aEMgYz37mbdV Content-Type: text/html; Content-Transfer-Encoding: quoted-printable b
Opt-in Email Special Offer   = ;  unsubscribe me
<= td width=3D5 bgcolor=3D#000080>
SEARCH

TOP 10 NEW TITLES

=
<= td width=3D132> Adobe Acrobat 7 Pro<= td width=3D8>  these other items...
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&= nbsp;2 Creative Suite 2
 3 MS Office 2003 Pro
 4
 5<= /td> Macromedia Flash 8
 6 Dreamweaver 8
 7 Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
 10 Borland Architect 2= 005
  See more by t= his manufacturer
  Microsoft
   Macromedia
   Adobe
  Customers also bought
  

Microsoft Windows XP Profes= sional *w/SP2*
Microsoft

Choose:
<= /a> =
=



Availability: Available for INSTAN= T download!
Coupon Code: S13Kjr9b0
Platform: Windows XP

Sales Rank: #1
System requirements  |  Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 1348 reviews= Write a review.

List Price:$299.00
Price:$49.99
= You Save:$249.01 (80%)

Adobe Creative Suite 2 *Premium*
Adobe

Choose:
 

$1049.01 (95= %)
List Price:$1199.00
Price:$149.99=
You Save:



Availability: Available for INSTANT download!
Coupon Code: hBEa3v
P= latform: Windows = XP

Sales Rank: #2
System requirements  |  Other Versions
Date Coupon Expires: December 31st, 20= 05
Average Customer Review:3D"5 B= ased on 1253 reviews. Write a review= .

Microsoft Office 2003 *Professional*<= br> Microsoft

Choose:
 

= $69.99
List Price:$499.00<= /span>
Price:
You Save:$429.01 (85%)



Availability: Available for = INSTANT download!
Coupon Code: 0TAGx5
Platform: Windows XP

<= span class=3Dtiny>Sales Rank: #3
System requirements  |  Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 123514 revi= ews. Write a review.

=

= Adobe Acrobat Professional V 7.0
Adobe

Choose:
 

List Price:= $499.00
Price:$69.99
You Save:$429.01 (85= %)



Availability: Available for INSTANT download!
Coupon Code: aufNPChP
Platform: Window= s XP

Sales Rank: #4
System requirements<= /a>  |  Other Versions=
Date Coupon Expires: December 31st, = 2005
Average Customer Review:3D"5= Based on 1323 reviews. Write a revi= ew.

<= /td>
----mzKugy3aEMgYz37mbdV-- From owner-namedroppers@ops.ietf.org Sun Nov 27 09:45:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgNmi-0005up-3J for dnsext-archive@megatron.ietf.org; Sun, 27 Nov 2005 09:45:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22419 for ; Sun, 27 Nov 2005 09:44:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgNhj-0005Ak-BB for namedroppers-data@psg.com; Sun, 27 Nov 2005 14:40:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgNhi-0005AK-CP for namedroppers@ops.ietf.org; Sun, 27 Nov 2005 14:40:34 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jAREeFtI086313; Sun, 27 Nov 2005 15:40:15 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <43899477.5090103@algroup.co.uk> References: <4386DB21.5080509@algroup.co.uk> <438729DE.8030500@algroup.co.uk> <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> <43899477.5090103@algroup.co.uk> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-44-176392920" Message-Id: Cc: iesg@ietf.org, Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard Date: Sun, 27 Nov 2005 15:40:15 +0100 To: Ben Laurie X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-44-176392920 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Ben, My position on the first 3 points is that the working group did discuss these concerns and made a decision and I do not think we should be revising these unless there is a new problem that we ought to address. > Fourthly, it is a WG item to fix the problems with NSEC. Until it was > brought up in this thread I would not have even considered that anyone > would stoop so low as to claim that once online signing is on the > standards track then that obligation has been discharged. But it seems > that this is a possibility in at least some people's minds, and > since I > do not agree that online signing is a viable fix, I feel I must also > object on those grounds. I wouldn't have considered such low stoop as well but somebody expressed that fear while I was trying to understand what new problem was needed to be addressed. This particular beast is something we can easily address by asking the working group if there is consensus that NSEC3 is to appear on standards track once the work is done. It is my strong opinion that the work is to appear on the std-track and that if std-track would not be the target we should not even consider working on it. If you want we can do a formal call for consensus on this point. That would clear the air and we can move on (and focus on real work). --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-44-176392920 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.1 (Darwin) Comment: This message is locally signed. iD8DBQFDicVPtN/ca3YJIocRAlH2AKDxpaU/vavYsEnnfGGDzhvK8eRcOACeM5s5 HBur7DraYw8CwUeHPq1yAsI= =ZFrI -----END PGP SIGNATURE----- --Apple-Mail-44-176392920-- -- to unsubscribe send a message to namedroppers-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 27 10:09:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgO9h-0001MY-3d for dnsext-archive@megatron.ietf.org; Sun, 27 Nov 2005 10:09:29 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24552 for ; Sun, 27 Nov 2005 10:08:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgO7t-0006jW-Of for namedroppers-data@psg.com; Sun, 27 Nov 2005 15:07:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgO7s-0006jJ-Tk for namedroppers@ops.ietf.org; Sun, 27 Nov 2005 15:07:37 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 4128833C1C; Sun, 27 Nov 2005 15:07:35 +0000 (GMT) Message-ID: <4389CBBB.7010706@algroup.co.uk> Date: Sun, 27 Nov 2005 15:07:39 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: iesg@ietf.org, Namedroppers Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard References: <4386DB21.5080509@algroup.co.uk> <438729DE.8030500@algroup.co.uk> <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> <43899477.5090103@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf M. Kolkman wrote: > > Ben, > > My position on the first 3 points is that the working group did discuss > these concerns and made a decision and I do not think we should be > revising these unless there is a new problem that we ought to address. > >> Fourthly, it is a WG item to fix the problems with NSEC. Until it was >> brought up in this thread I would not have even considered that anyone >> would stoop so low as to claim that once online signing is on the >> standards track then that obligation has been discharged. But it seems >> that this is a possibility in at least some people's minds, and since I >> do not agree that online signing is a viable fix, I feel I must also >> object on those grounds. > > I wouldn't have considered such low stoop as well but somebody expressed > that fear while I was trying to understand what new problem was needed > to be addressed. This particular beast is something we can easily > address by asking the working group if there is consensus that NSEC3 is > to appear on standards track once the work is done. > > It is my strong opinion that the work is to appear on the std-track and > that if std-track would not be the target we should not even consider > working on it. If you want we can do a formal call for consensus on this > point. That would clear the air and we can move on (and focus on real > work). Since the other three points are all process issues, I'm more than happy to allow the IESG to do whatever is appropriate. It seems to me that clearing the air would be a good plan, but I think the consensus we are seeking is that online signing is not adequate to solve the problems with NSEC, rather than that NSEC3 will follow any particular path (which would presuppose the outcome of the process). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Nov 27 11:28:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgPO3-0006UR-Bd for dnsext-archive@megatron.ietf.org; Sun, 27 Nov 2005 11:28:23 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02791 for ; Sun, 27 Nov 2005 11:27:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgPKK-000BgN-46 for namedroppers-data@psg.com; Sun, 27 Nov 2005 16:24:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgPKJ-000Bfs-G9 for namedroppers@ops.ietf.org; Sun, 27 Nov 2005 16:24:31 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id jARGK1TQ001565 for ; Sun, 27 Nov 2005 11:20:01 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAMCaWcd; Sun, 27 Nov 05 11:19:57 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id jARGLnkZ013022; Sun, 27 Nov 2005 11:21:49 -0500 (EST) Date: Sun, 27 Nov 2005 11:21:48 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Ben Laurie cc: Roy Arends , "Olaf M. Kolkman" , iesg@ietf.org, Namedroppers Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard In-Reply-To: <43899477.5090103@algroup.co.uk> Message-ID: References: <4386DB21.5080509@algroup.co.uk> <438729DE.8030500@algroup.co.uk> <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> <43899477.5090103@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Thanks for the response. I'm glad to know that I was hearing completely different things. Ben> Firstly, online signing is not a minor change - it completely Ben> violates one of the fundamental principles of DNSSEC: ... Roy> Since this update is so incredibly minimal, ... ... Roy> Otherwise it looks to me that online signing is minimally Roy> updating 4034 and 4035 for the sole purpose of reaching Roy> proposed standard. To be clear, I think this doc should be marked as "updating" 4034 and 4035 because it explicitly allows (or even encourages) doing things that 4034 and 4035 explicitly forbid. That doesn't necessarily argue for standards track, though I suspect that putting it on the standards track will help avoid future down-reference issues. -- 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 Sun Nov 27 11:31:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgPQo-000786-U1 for dnsext-archive@megatron.ietf.org; Sun, 27 Nov 2005 11:31:14 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03248 for ; Sun, 27 Nov 2005 11:30:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgPPH-000C7m-EP for namedroppers-data@psg.com; Sun, 27 Nov 2005 16:29:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgPPG-000C7a-S2 for namedroppers@ops.ietf.org; Sun, 27 Nov 2005 16:29:39 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id jARGP8Iv001942 for ; Sun, 27 Nov 2005 11:25:08 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA9PaOYd; Sun, 27 Nov 05 11:25:05 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id jARGR0wV013120; Sun, 27 Nov 2005 11:27:00 -0500 (EST) Date: Sun, 27 Nov 2005 11:26:59 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Roy Arends cc: "Olaf M. Kolkman" , Ben Laurie , iesg@ietf.org, Namedroppers Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard In-Reply-To: Message-ID: References: <4386DB21.5080509@algroup.co.uk> <438729DE.8030500@algroup.co.uk> <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, 26 Nov 2005, Roy Arends wrote: > ... the bis-updates document of the same author... As a technicality... While I am one of the editors of both documents, they do have different editorial TEAMS: I worked with Johan Ihren on the epsilon document, and Rob Austein and I are editting bis-updates (he's been working on the next revision). One might still argue that both documents share the same author: the DNSEXT working group. -- 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 Sun Nov 27 11:54:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgPnL-0002XX-6k for dnsext-archive@megatron.ietf.org; Sun, 27 Nov 2005 11:54:31 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05337 for ; Sun, 27 Nov 2005 11:53:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgPky-000Dz7-L1 for namedroppers-data@psg.com; Sun, 27 Nov 2005 16:52:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgPky-000Dyw-2T for namedroppers@ops.ietf.org; Sun, 27 Nov 2005 16:52:04 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id jARGlXjs004617 for ; Sun, 27 Nov 2005 11:47:33 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAFxaW4i; Sun, 27 Nov 05 11:47:11 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id jARGmpJZ013675; Sun, 27 Nov 2005 11:48:51 -0500 (EST) Date: Sun, 27 Nov 2005 11:48:51 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Wes Hardaker cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ds-sha256-00.txt In-Reply-To: Message-ID: References: <6.2.5.6.2.20051116235002.04170e60@ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 18 Nov 2005, Wes Hardaker wrote: > I don't think that a bis-update that includes a new mandatory > algorithm is truly a good way to go forward, as it would require > cycling at proposed. I'm not sure the rest of the bis-update thought > would require that. It sounds like we may be talking about different things: I'm not talking about adding this new digest algorithm to bis-updates. I'm suggesting that the ds-sha256 doc refer to the discussion in bis-updates of handling unknown digest algorithms. I made that suggestion because the proposed text I was writing about (the section 4 text you proposed on 15 November) referred to a section of 4035 that doesn't adequately discuss unknown _digest_ algorithms. Another option, and one which avoids a reference to bis-updates, is to include text in ds-sha256 similar to what's in bis-updates section 3.2 -- make this doc, in addition to defining a new digest algorithm, explicitly tell resolvers what to do when they see an unknown (or unsupported/disabled) one. -- 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 Sun Nov 27 13:10:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgQz3-00072p-JA for dnsext-archive@megatron.ietf.org; Sun, 27 Nov 2005 13:10:43 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12116 for ; Sun, 27 Nov 2005 13:09:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgQwZ-000Jn3-Cp for namedroppers-data@psg.com; Sun, 27 Nov 2005 18:08:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgQwY-000JmT-Sc for namedroppers@ops.ietf.org; Sun, 27 Nov 2005 18:08:06 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 80AB911425 for ; Sun, 27 Nov 2005 18:08:04 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard In-Reply-To: Your message of "Sun, 27 Nov 2005 11:11:51 GMT." <43899477.5090103@algroup.co.uk> References: <4386DB21.5080509@algroup.co.uk> <438729DE.8030500@algroup.co.uk> <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> <43899477.5090103@algroup.co.uk> Date: Sun, 27 Nov 2005 18:08:04 +0000 Message-Id: <20051127180804.80AB911425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # Firstly, online signing is not a minor change - it completely violates # one of the fundamental principles of DNSSEC: no online keys. what? where's THAT documented? you mean BIND9 should not have an online key it can use to re-sign the changed parts of a zone after each update? (if we're RFC-incompatible, we'll surely be wanting to remove that feature?) # The only reason we have NSEC (and hence the problems with it) in the first # place is in order to conform with this principle. um, no. we have NSEC to prevent MiTM from injecting false negatives. NSEC has nothing to do with online signing or online keys per se. # Secondly, ... # # Thirdly, ... # # Fourthly, it is a WG item to fix the problems with NSEC. Until it was # brought up in this thread I would not have even considered that anyone would # stoop so low as to claim that once online signing is on the standards track # then that obligation has been discharged. But it seems that this is a # possibility in at least some people's minds, and since I do not agree that # online signing is a viable fix, I feel I must also object on those grounds. i think i agree with you that white lies does not discharge the WG's responsibility to make NSEC fit the needs of the current WG, but it's still a change to a standards-track document and thus has to be on the same track. even if it's optional for responders, it has to be mandatory for initiators. -- to unsubscribe send a message to namedroppers-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 27 13:15:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgR3Y-0007lA-DO for dnsext-archive@megatron.ietf.org; Sun, 27 Nov 2005 13:15:20 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12660 for ; Sun, 27 Nov 2005 13:14:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgR21-000KJ3-IF for namedroppers-data@psg.com; Sun, 27 Nov 2005 18:13:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.169.16.30] (helo=exchangebe.corporate.telin.nl) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgR20-000KIp-SN for namedroppers@ops.ietf.org; Sun, 27 Nov 2005 18:13:45 +0000 Received: from netinfo.corporate.telin.nl ([195.169.16.63]) by exchangebe.corporate.telin.nl with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 Nov 2005 19:13:43 +0100 Date: Sun, 27 Nov 2005 19:13:43 +0100 (CET) From: Roy Arends X-X-Sender: roy@netinfo.corporate.telin.nl To: Samuel Weiler cc: Ben Laurie , "Olaf M. Kolkman" , iesg@ietf.org, Namedroppers Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard In-Reply-To: Message-ID: References: <4386DB21.5080509@algroup.co.uk> <438729DE.8030500@algroup.co.uk> <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> <43899477.5090103@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 27 Nov 2005 18:13:43.0166 (UTC) FILETIME=[4CE879E0:01C5F37E] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 27 Nov 2005, Samuel Weiler wrote: > Thanks for the response. Oh, you're welcome Sam. > I'm glad to know that I was hearing completely different things. Are you hearing things ? :) > Ben> Firstly, online signing is not a minor change - it completely > Ben> violates one of the fundamental principles of DNSSEC: ... > > Roy> Since this update is so incredibly minimal, ... > ... > Roy> Otherwise it looks to me that online signing is minimally > Roy> updating 4034 and 4035 for the sole purpose of reaching > Roy> proposed standard. Don't get confused now Sam, Ben and I do not disagree, but merely talking about different things. With the 'minimal update' I meant the small change in text in 4034 and 4035 that currently, for some reason, keeps online-signing from being informational or even experimental. With 'not a minor change' Ben was not referring to the update in text in 4034/4035, but about the violation of one of the fundamental principles of DNSSEC: no keys online. > To be clear, I think this doc should be marked as "updating" 4034 and > 4035 because it explicitly allows (or even encourages) doing things > that 4034 and 4035 explicitly forbid. That doesn't necessarily argue > for standards track, though I suspect that putting it on the standards > track will help avoid future down-reference issues. That is why I argue to have this update put in the bis-updates. That way, online signing can be informational. If you can't agree with this, then it is obvious: online signing is minimally updating 4034 and 4035 for the sole purpose of reaching proposed standard. 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 ccarrasco@atkapta.com Sun Nov 27 14:51:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgSYD-0005is-Ej for dnsext-archive@megatron.ietf.org; Sun, 27 Nov 2005 14:51:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21668 for ; Sun, 27 Nov 2005 14:50:21 -0500 (EST) Received: from ppp4-93.pppoe.mtu-net.ru ([81.195.4.93] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EgSrV-0007K5-VY for dnsext-archive@ietf.org; Sun, 27 Nov 2005 15:11:28 -0500 Message-ID: <000001c5f38a$670f0080$0100007f@localhost> From: "Keegan Harris" To: Subject: cheap oem soft shipping //orldwide Date: Sun, 27 Nov 2005 22:50:34 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F38A.670F0080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F38A.670F0080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 34 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 44 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5F38A.670F0080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 46 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 35 revie! ws)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 37 reviews)

------=_NextPart_000_0001_01C5F38A.670F0080-- From owner-namedroppers@ops.ietf.org Sun Nov 27 15:23:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgT37-0001o1-DS for dnsext-archive@megatron.ietf.org; Sun, 27 Nov 2005 15:23:01 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24492 for ; Sun, 27 Nov 2005 15:22:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgT06-0003EJ-QI for namedroppers-data@psg.com; Sun, 27 Nov 2005 20:19:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgT06-0003E6-Aa for namedroppers@ops.ietf.org; Sun, 27 Nov 2005 20:19:54 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id CA28411425 for ; Sun, 27 Nov 2005 20:19:53 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard In-Reply-To: Your message of "Sun, 27 Nov 2005 19:13:43 +0100." References: <4386DB21.5080509@algroup.co.uk> <438729DE.8030500@algroup.co.uk> <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> <43899477.5090103@algroup.co.uk> Date: Sun, 27 Nov 2005 20:19:53 +0000 Message-Id: <20051127201953.CA28411425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # ... With the 'minimal update' I meant the small change in text in 4034 and # 4035 that currently, for some reason, keeps online-signing from being # informational or even experimental. when 4034/4035 went to iesg, it was known that this section would be wrong, but what wasn't known was the exact way in which it was wrong or could be made right. therefore it was planned that this rule would be relaxed. the document which relaxes it has to be on the same track as 4034/4035. # With 'not a minor change' Ben was not referring to the update in text in # 4034/4035, but about the violation of one of the fundamental principles of # DNSSEC: no keys online. i completely disagree that this is a fundamental principle, or any other kind of principle, of DNSSEC (or DNSSEC-bis). some zones have keys online, at the discretion of the zone operator. perhaps you mean "DNSSEC shall not *require* keys to be online" in which case i'd agree. but as seen on this thread and elsewhere/previously, the language has to be very exact. # > To be clear, I think this doc should be marked as "updating" 4034 and 4035 # > because it explicitly allows (or even encourages) doing things that 4034 # > and 4035 explicitly forbid. That doesn't necessarily argue for standards # > track, though I suspect that putting it on the standards track will help # > avoid future down-reference issues. i disagree. it does necessarily argue for "same track as 4034/4035". # That is why I argue to have this update put in the bis-updates. # That way, online signing can be informational. # # If you can't agree with this, then it is obvious: online signing is # minimally updating 4034 and 4035 for the sole purpose of reaching proposed # standard. i cannot agree with ANY of this. it won't work, AND it's not the plan we agreed to when we forwarded 4034/4035 to the IESG knowing that this section was wrong and would need to be changed. -- to unsubscribe send a message to namedroppers-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 27 16:25:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgU1K-0003YS-U9 for dnsext-archive@megatron.ietf.org; Sun, 27 Nov 2005 16:25:17 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29913 for ; Sun, 27 Nov 2005 16:24:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgTwP-0008B3-O9 for namedroppers-data@psg.com; Sun, 27 Nov 2005 21:20:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgTwP-0008Aq-17 for namedroppers@ops.ietf.org; Sun, 27 Nov 2005 21:20:09 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 68EDD33C1C; Sun, 27 Nov 2005 21:20:07 +0000 (GMT) Message-ID: <438A230B.4020007@algroup.co.uk> Date: Sun, 27 Nov 2005 21:20:11 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Paul Vixie CC: Namedroppers Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard References: <4386DB21.5080509@algroup.co.uk> <438729DE.8030500@algroup.co.uk> <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> <43899477.5090103@algroup.co.uk> <20051127201953.CA28411425@sa.vix.com> In-Reply-To: <20051127201953.CA28411425@sa.vix.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > # With 'not a minor change' Ben was not referring to the update in text in > # 4034/4035, but about the violation of one of the fundamental principles of > # DNSSEC: no keys online. > > i completely disagree that this is a fundamental principle, or any other kind > of principle, of DNSSEC (or DNSSEC-bis). some zones have keys online, at the > discretion of the zone operator. perhaps you mean "DNSSEC shall not *require* > keys to be online" in which case i'd agree. but as seen on this thread and > elsewhere/previously, the language has to be very exact. Good point, and I totally agree. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Nov 27 16:41:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgUHT-0005mH-Lb for dnsext-archive@megatron.ietf.org; Sun, 27 Nov 2005 16:41:55 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00917 for ; Sun, 27 Nov 2005 16:41:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgUFO-0009ua-U1 for namedroppers-data@psg.com; Sun, 27 Nov 2005 21:39:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgUFO-0009uP-FT for namedroppers@ops.ietf.org; Sun, 27 Nov 2005 21:39:46 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id E3667E6034 for ; Sun, 27 Nov 2005 21:39:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id jARLcwtZ042367; Mon, 28 Nov 2005 08:39:01 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200511272139.jARLcwtZ042367@drugs.dv.isc.org> To: Ben Laurie Cc: Samuel Weiler , Roy Arends , "Olaf M. Kolkman" , iesg@ietf.org, Namedroppers From: Mark Andrews Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard In-reply-to: Your message of "Sun, 27 Nov 2005 11:11:51 -0000." <43899477.5090103@algroup.co.uk> Date: Mon, 28 Nov 2005 08:38:58 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Firstly, online signing is not a minor change - it completely violates > one of the fundamental principles of DNSSEC: no online keys. The only > reason we have NSEC (and hence the problems with it) in the first place > is in order to conform with this principle. No. Online signing was always a choice. Simple secure dynamic update requires keys to be online. One just needs to weigh the risks vs the advantages. This is a choice. You can continue to use standard NSEC and have offline signing. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Nov 27 17:50:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgVMF-0006xx-46 for dnsext-archive@megatron.ietf.org; Sun, 27 Nov 2005 17:50:55 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06267 for ; Sun, 27 Nov 2005 17:50:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgVJD-000Fqc-RB for namedroppers-data@psg.com; Sun, 27 Nov 2005 22:47:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.169.16.30] (helo=exchangebe.corporate.telin.nl) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgVJD-000FqF-6b for namedroppers@ops.ietf.org; Sun, 27 Nov 2005 22:47:47 +0000 Received: from netinfo.corporate.telin.nl ([195.169.16.63]) by exchangebe.corporate.telin.nl with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 Nov 2005 23:47:45 +0100 Date: Sun, 27 Nov 2005 23:47:45 +0100 (CET) From: Roy Arends X-X-Sender: roy@netinfo.corporate.telin.nl To: Namedroppers Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard In-Reply-To: <20051127201953.CA28411425@sa.vix.com> Message-ID: References: <4386DB21.5080509@algroup.co.uk> <438729DE.8030500@algroup.co.uk> <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> <43899477.5090103@algroup.co.uk> <20051127201953.CA28411425@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 27 Nov 2005 22:47:45.0076 (UTC) FILETIME=[950CD740:01C5F3A4] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 27 Nov 2005, Paul Vixie wrote: > # ... With the 'minimal update' I meant the small change in text in 4034 and > # 4035 that currently, for some reason, keeps online-signing from being > # informational or even experimental. > > when 4034/4035 went to iesg, it was known that this section would be wrong, It was known ? By whom ? Pointers ? > but what wasn't known was the exact way in which it was wrong or could be > made right. therefore it was planned that this rule would be relaxed. It was planned ? By whom ? Pointers ? > the document which relaxes it has to be on the same track as 4034/4035. Sure. This can be the bis-updates document, no ? > # That is why I argue to have this update put in the bis-updates. > # That way, online signing can be informational. > # > # If you can't agree with this, then it is obvious: online signing is > # minimally updating 4034 and 4035 for the sole purpose of reaching proposed > # standard. > > i cannot agree with ANY of this. it won't work, AND it's not the plan we > agreed to when we forwarded 4034/4035 to the IESG knowing that this section > was wrong and would need to be changed. Which we ? Who did agree with what plan ? Pointers ? I should get out more. I'm obviously missing most of the fun :) 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 subscriptions@afashawaii.com Sun Nov 27 23:14:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgaPL-0006tL-7P for dnsext-archive@megatron.ietf.org; Sun, 27 Nov 2005 23:14:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03589 for ; Sun, 27 Nov 2005 23:13:42 -0500 (EST) Received: from ws-84-138.burnet.ru ([212.0.84.138] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Egaj8-000484-1a for dnsext-archive@ietf.org; Sun, 27 Nov 2005 23:34:55 -0500 Message-ID: <000001c5f3d0$fb03bb00$0100007f@localhost> From: "Elijah Allen" To: Subject: Software At Low Pr1ce Date: Mon, 28 Nov 2005 12:21:09 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F3D0.FB03BB00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.5 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F3D0.FB03BB00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 50 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 32 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 44 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5F3D0.FB03BB00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download! !


Sales Rank: #1
Average Customer Review: 3D"5
(based on 42 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 34 re! views)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 37 reviews)

------=_NextPart_000_0001_01C5F3D0.FB03BB00-- From owner-namedroppers@ops.ietf.org Mon Nov 28 01:14:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgcHW-0000rH-2F for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 01:14:30 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15136 for ; Mon, 28 Nov 2005 01:13:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgcDc-0000fE-EG for namedroppers-data@psg.com; Mon, 28 Nov 2005 06:10:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgcDb-0000f3-WE for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 06:10:28 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0ED6311457 for ; Mon, 28 Nov 2005 06:10:27 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard In-Reply-To: Your message of "Sun, 27 Nov 2005 23:47:45 +0100." References: <4386DB21.5080509@algroup.co.uk> <438729DE.8030500@algroup.co.uk> <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> <43899477.5090103@algroup.co.uk> <20051127201953.CA28411425@sa.vix.com> Date: Mon, 28 Nov 2005 06:10:27 +0000 Message-Id: <20051128061027.0ED6311457@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # It was known ? By whom ? Pointers ? by all of the folks who were then working on the white lies problem. # It was planned ? By whom ? Pointers ? by the editing team and WG chairs. it might even be in the minutes. # > the document which relaxes it has to be on the same track as 4034/4035. # # Sure. This can be the bis-updates document, no ? if we wanted to pointlessly mislead the readers of the historical record into believing that the text of document A wasn't really standards track but the text of document B was even though it's the same text, we could do that. but we won't stoop that low, will we? # I should get out more. I'm obviously missing most of the fun :) yes. -- to unsubscribe send a message to namedroppers-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 28 02:49:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egdlg-0001Al-NI for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 02:49:45 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25039 for ; Mon, 28 Nov 2005 02:49:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgdiA-00090a-QH for namedroppers-data@psg.com; Mon, 28 Nov 2005 07:46:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.169.16.30] (helo=exchangebe.corporate.telin.nl) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgdiA-00090P-4C for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 07:46:06 +0000 Received: from netinfo.corporate.telin.nl ([195.169.16.63]) by exchangebe.corporate.telin.nl with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Nov 2005 08:46:03 +0100 Date: Mon, 28 Nov 2005 08:46:03 +0100 (CET) From: Roy Arends X-X-Sender: roy@netinfo.corporate.telin.nl To: Paul Vixie cc: Namedroppers Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard In-Reply-To: <20051128061027.0ED6311457@sa.vix.com> Message-ID: References: <4386DB21.5080509@algroup.co.uk> <438729DE.8030500@algroup.co.uk> <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> <43899477.5090103@algroup.co.uk> <20051127201953.CA28411425@sa.vix.com> <20051128061027.0ED6311457@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 28 Nov 2005 07:46:03.0224 (UTC) FILETIME=[C83F1D80:01C5F3EF] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 28 Nov 2005, Paul Vixie wrote: > # It was known ? By whom ? Pointers ? > > by all of the folks who were then working on the white lies problem. I was one of them. It wasn't known by me. > # It was planned ? By whom ? Pointers ? > > by the editing team and WG chairs. it might even be in the minutes. I was one of them. It wasn't known by me. Couldn't find it in the minutes. WG chairs ? Olafur, Olaf ? If you would be so nice and point me to a general record of this plan? > # > the document which relaxes it has to be on the same track as 4034/4035. > # > # Sure. This can be the bis-updates document, no ? > > if we wanted to pointlessly mislead the readers of the historical record into > believing that the text of document A wasn't really standards track but the > text of document B was even though it's the same text, we could do that. but > we won't stoop that low, will we? This is not right Paul. I'm not trying to mislead the readers of the historical record into believing anything. What I'm trying to do is to protect the reader of the standards track from a false sense of security. Online signing is, in general, a really bad idea. What I find horrendesly disturbing is when a few TLD's were interested in for instance Opt-In, we fought against FUD, held workshops, invested in code, held discussions, wrote drafts etc, etc. It did not help. It was burried faster then you can spell IETF. Your reasoning is naive if you think that some 'won't stoop that low'. And yet, when one TLD shows interest in this terribly bad idea of online signing, it is tombstoned in Proposed Standard. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 28 03:54:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egem7-0005NC-KG for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 03:54:15 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02059 for ; Mon, 28 Nov 2005 03:53:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Egeix-000EWZ-Vb for namedroppers-data@psg.com; Mon, 28 Nov 2005 08:50:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Egeix-000EWG-C2 for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 08:50:59 +0000 Received: from staff.nominet.org.uk ([213.248.199.129]) by mx3.nominet.org.uk with ESMTP; 28 Nov 2005 08:50:57 +0000 X-IronPort-AV: i="3.97,384,1125874800"; d="scan'208"; a="1963453:sNHT26865908" Received: (from geoff@localhost) by staff.nominet.org.uk (8.12.9/8.12.9) id jAS8ouSh025462; Mon, 28 Nov 2005 08:50:56 GMT Date: Mon, 28 Nov 2005 08:50:56 GMT From: Geoffrey Sisson Message-Id: <200511280850.jAS8ouSh025462@staff.nominet.org.uk> To: iesg@ietf.org Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard Cc: namedroppers@ops.ietf.org In-Reply-To: <4386DB21.5080509@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 25 November 2005, Ben Laurie wrote: > According to RFC 2026 one of the criteria for Proposed Standard is > "appears to enjoy enough community interest to be considered valuable". > I do not believe we have seen evidence of this for this I-D. Indeed, we > have only seen statements that this will _not_ be deployed. > > I propose that this should be downgraded to Experimental. I'm reluctant to say this work does not "enjoy enough community interest to be considered valuable". Online signing represents a distinct set of trade-offs relative to NSEC3 (and friends): online signing keys may be more exposed, and online signing DNSSEC name servers may be more vulnerable to DoS; however, less zone information is leaked (no more than without DNSSEC) and the threat of offline attacks is eliminated. While online signing may or may not suitable for deployment by large TLDs, I suspect there will be interest in using this technique for zones further down in the DNS tree -- e.g. organisations with a greater need for privacy or secrecy of zone data -- particularly if good implementations (say, ASICS-based, HSM-based online signing DNSSEC name server appliances) become available. So in this case I would caution against gauging "community interest" by the interest of dnsext WG participants to use this technique themselves. While root server operators, TLDs and RIRs are well represented in the WG, the potential users of online signing probably are not. Geoff -- to unsubscribe send a message to namedroppers-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 28 05:37:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EggNs-0007VS-4w for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 05:37:20 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13373 for ; Mon, 28 Nov 2005 05:36:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EggK7-000NM4-4V for namedroppers-data@psg.com; Mon, 28 Nov 2005 10:33:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.169.16.30] (helo=exchangebe.corporate.telin.nl) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EggK6-000NLs-IK for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 10:33:26 +0000 Received: from netinfo.corporate.telin.nl ([195.169.16.63]) by exchangebe.corporate.telin.nl with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Nov 2005 11:33:24 +0100 Date: Mon, 28 Nov 2005 11:33:24 +0100 (CET) From: Roy Arends X-X-Sender: roy@netinfo.corporate.telin.nl To: Namedroppers Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard In-Reply-To: Message-ID: References: <4386DB21.5080509@algroup.co.uk> <438729DE.8030500@algroup.co.uk> <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> <43899477.5090103@algroup.co.uk> <20051127201953.CA28411425@sa.vix.com> <20051128061027.0ED6311457@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 28 Nov 2005 10:33:24.0229 (UTC) FILETIME=[2926E350:01C5F407] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 28 Nov 2005, Roy Arends wrote: > Online signing is, in general, a really bad idea. Okay, after a lot of private conversations with different folks in the wg, I'm less convinced online signing is, in general, a really bad idea. Since I reached the limit of 1 post per day, I'll let the subject rest. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 28 06:00:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eggkj-0003yM-HW for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 06:00:59 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16206 for ; Mon, 28 Nov 2005 06:00:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EggiO-000Pc4-Ig for namedroppers-data@psg.com; Mon, 28 Nov 2005 10:58:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EggiN-000Pbm-OS for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 10:58:32 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 55F7933C1C; Mon, 28 Nov 2005 10:58:30 +0000 (GMT) Message-ID: <438AE2DB.1090005@algroup.co.uk> Date: Mon, 28 Nov 2005 10:58:35 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Paul Vixie CC: Namedroppers Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard References: <4386DB21.5080509@algroup.co.uk> <438729DE.8030500@algroup.co.uk> <58A308E6-D845-463B-A2D5-ED442613861B@NLnetLabs.nl> <43899477.5090103@algroup.co.uk> <20051127180804.80AB911425@sa.vix.com> In-Reply-To: <20051127180804.80AB911425@sa.vix.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > # Firstly, online signing is not a minor change - it completely violates > # one of the fundamental principles of DNSSEC: no online keys. > > what? where's THAT documented? you mean BIND9 should not have an online > key it can use to re-sign the changed parts of a zone after each update? > (if we're RFC-incompatible, we'll surely be wanting to remove that feature?) OK, what I mean is that it should be possible to do DNSSEC without online keys, rather than that online keys are completely banned. RFC 4033, 3.1 "Note that the private keys used to sign zone data must be kept secure and should be stored offline when practical." > # The only reason we have NSEC (and hence the problems with it) in the first > # place is in order to conform with this principle. > > um, no. we have NSEC to prevent MiTM from injecting false negatives. NSEC > has nothing to do with online signing or online keys per se. NSEC works the way it does so you can prove negatives without having to sign dynamically. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 28 06:23:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egh6M-0007kA-Ai for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 06:23:18 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18638 for ; Mon, 28 Nov 2005 06:22:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Egh4T-0001i6-Q5 for namedroppers-data@psg.com; Mon, 28 Nov 2005 11:21:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Egh4T-0001hp-6E for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 11:21:21 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id B227433C40; Mon, 28 Nov 2005 11:21:19 +0000 (GMT) Message-ID: <438AE834.9060605@algroup.co.uk> Date: Mon, 28 Nov 2005 11:21:24 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: DNSEXT WG CC: Russ Housley Subject: Updated key-distribution I-D X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit After discussion with Russ Housley on how to do X.509 the way I want it, I've updated my key distribution I-D. http://www.links.org/dnssec/draft-laurie-dnssec-key-distribution-01.html Does the WG want to adopt this? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 28 07:25:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egi50-0003c0-Fw for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 07:25:58 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26173 for ; Mon, 28 Nov 2005 07:25:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Egi1k-0006ds-FN for namedroppers-data@psg.com; Mon, 28 Nov 2005 12:22:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Egi1j-0006dM-LU for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 12:22:35 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id jASCMWB2021549 for ; Mon, 28 Nov 2005 13:22:32 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <438AE834.9060605@algroup.co.uk> References: <438AE834.9060605@algroup.co.uk> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-57-254525849" Message-Id: <706D4642-06CE-487B-A8DB-37A1FED4FB85@NLnetLabs.nl> Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Updated key-distribution I-D Date: Mon, 28 Nov 2005 13:22:28 +0100 To: Namedroppers X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-57-254525849 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Nov 28, 2005, at 12:21 , Ben Laurie wrote: > After discussion with Russ Housley on how to do X.509 the way I > want it, > I've updated my key distribution I-D. > > http://www.links.org/dnssec/draft-laurie-dnssec-key- > distribution-01.html > > Does the WG want to adopt this? Hi Ben, Thanks for offering this to the working group. In order not to have 3 working group documents for addressing the distribution/maintenance problems I propose that we wait for the requirements document and assess if your document fits (a significant part of) the requirements before we take this on. In the mean time I would urge the working group to review this document and provide feedback on its content and merit. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-57-254525849 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.1 (Darwin) Comment: This message is locally signed. iD8DBQFDivaEtN/ca3YJIocRAp4lAJwNFK71/Y3eoqsMPTOvr1sE5tWSBACeIfGj lf40R5AwYnv4IyDvHS0MeHc= =1SSf -----END PGP SIGNATURE----- --Apple-Mail-57-254525849-- -- to unsubscribe send a message to namedroppers-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 28 09:19:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egjr9-0006V3-AC for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 09:19:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10419 for ; Mon, 28 Nov 2005 09:19:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgjnH-000G8D-RJ for namedroppers-data@psg.com; Mon, 28 Nov 2005 14:15:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgjnH-000G7x-3B for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 14:15:47 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id jASEFOAX058134; Mon, 28 Nov 2005 09:15:25 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200511280850.jAS8ouSh025462@staff.nominet.org.uk> References: <200511280850.jAS8ouSh025462@staff.nominet.org.uk> Date: Mon, 28 Nov 2005 09:15:37 -0500 To: Geoffrey Sisson From: Edward Lewis Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard Cc: iesg@ietf.org, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 8:50 +0000 11/28/05, Geoffrey Sisson wrote: >While online signing may or may not suitable for deployment by large >TLDs, I suspect there will be interest in using this technique for >zones further down in the DNS tree -- e.g. organisations with a greater >need for privacy or secrecy of zone data -- particularly if good >implementations (say, ASICS-based, HSM-based online signing DNSSEC >name server appliances) become available. Well said. Participants need to balance their views of the problem space with other views of the problem space. >So in this case I would caution against gauging "community interest" by >the interest of dnsext WG participants to use this technique >themselves. While root server operators, TLDs and RIRs are well >represented in the WG, the potential users of online signing probably >are not. This is what bothers me about the process we follow and the importance we put on it. Until the IETF can guarantee that all involved parties make comments, the IETF has to treat all of it's "decisions" as partial results. I.e., although consensus is "achieved", it is never carved in stone. All hope is not lost, partial results are better than none, but remember to put them in their place. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-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 28 10:35:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egl1y-0000Jg-JB for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 10:35:02 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20478 for ; Mon, 28 Nov 2005 10:34:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Egkxc-000MUB-MC for namedroppers-data@psg.com; Mon, 28 Nov 2005 15:30:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Egkxb-000MTo-HT for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 15:30:31 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id D9C8C11457 for ; Mon, 28 Nov 2005 15:30:30 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard In-Reply-To: Your message of "Mon, 28 Nov 2005 09:15:37 EST." References: <200511280850.jAS8ouSh025462@staff.nominet.org.uk> Date: Mon, 28 Nov 2005 15:30:30 +0000 Message-Id: <20051128153030.D9C8C11457@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # >..., I suspect there will be interest in using this technique for # >zones further down in the DNS tree -- ... i'm worried that my most important comment on this thread was buried too deep in the message where i said it, so let me try again. in order to preserve or provide the white-lies capability to zone owners who find it desireable and sufficient, we MUST put the technology on the standards track. it has to be mandatory-to-implement for any requestor who wants to be "DNSSEC compliant". responders don't have to use it, but if a responder wants to use it, then all or virtually all requestors must grok it. there's no way to do that if 4034/4035 is a proposed standard and white lies is informational or experimental or a best current practice. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 28 10:58:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EglOn-00061P-KH for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 10:58:37 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23592 for ; Mon, 28 Nov 2005 10:57:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EglMa-000PC5-Pr for namedroppers-data@psg.com; Mon, 28 Nov 2005 15:56:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EglMa-000PBq-3b for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 15:56:20 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id jASFttaY060490; Mon, 28 Nov 2005 10:55:56 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 28 Nov 2005 10:52:08 -0500 To: iesg@ietf.org From: Edward Lewis Subject: editorial comment on DNSEXT WG's Minimally Covering Cc: IETF-Announce , , The IESG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:53 -0500 11/22/05, The IESG wrote: >The IESG has received a request from the DNS Extensions WG to consider the >following documents: > >- 'Minimally Covering NSEC Records and DNSSEC On-line Signing ' > as a Proposed Standard ... >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-online-signing-00.txt In this document, in section 2, there is this line: ).com 3600 IN NSEC +.com ( RRSIG NSEC ) The line should read \).com 3600 IN NSEC \+.com ( RRSIG NSEC ) Using the escape characters as defined in RFC 1035. A minor point - but the documentation of DNS records ought to continue to follow this syntax. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From NitaStephenson@wifiguards.com Mon Nov 28 11:27:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EglqF-0003qm-GW for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 11:27:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26804; Mon, 28 Nov 2005 11:26:13 -0500 (EST) Received: from n20z146l173.broadband.ctm.net ([202.86.146.173]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EgmA4-0003WI-T6; Mon, 28 Nov 2005 11:47:32 -0500 Received: from EkRZ@localhost by aM4.int (8.11.6/8.11.6); Mon, 28 Nov 2005 19:13:28 -0200 Message-ID: From: "Scot Rifkin" Reply-To: "Scot Rifkin" To: droyer@ietf.org, rfc-editor@ietf.org, v6tc@ietf.org, dnsext-archive@ietf.org Subject: Re: OEM Symantec, Windows XP, & Systemworks on $ale Now Date: Mon, 28 Nov 2005 23:06:28 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: NitaStephenson@wifiguards.com Content-Type: multipart/mixed; boundary="--pychlj8dQxxKE95" X-Spam-Score: 0.2 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 HeN3 ----pychlj8dQxxKE95 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable i
Opt-in Email Special Offer   = ;  unsubscribe me
<= td width=3D5 bgcolor=3D#000080>
SEARCH

TOP 10 NEW TITLES

=
<= td width=3D132> Adobe Acrobat 7 Pro<= td width=3D8>  these other items...
<= p align=3Dcenter>  ON SALE NOW!

 = ;1 Windows XP Pro SP2
&= nbsp;2 Creative Suite 2
 3 MS Office 2003 Pro
 4
 5<= /td> Macromedia Flash 8
 6 Dreamweaver 8
 7 Norton Sysworks 2005
 8 Adobe GoLive CS2
 9 Adobe Illustrator CS2
 10 Borland Architect 2= 005
  See more by t= his manufacturer
  Microsoft
   Macromedia
   Adobe
  Customers also bought
  

Microsoft Windows XP Profes= sional *w/SP2*
Microsoft

Choose:
<= /a> =
=



Availability: Available for INSTAN= T download!
Coupon Code: smCopjaUr
Platform: Windows XP

Sales Rank: #1
System requirements  |  Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 1783 reviews= Write a review.

List Price:$299.00
Price:$49.99
= You Save:$249.01 (80%)

Adobe Creative Suite 2 *Premium*
Adobe

Choose:
 

$1049.01 (95= %)
List Price:$1199.00
Price:$149.99=
You Save:



Availability: Available for INSTANT download!
Coupon Code: MhsYDu
P= latform: Windows = XP

Sales Rank: #2
System requirements  |  Other Versions
Date Coupon Expires: December 31st, 20= 05
Average Customer Review:3D"5 B= ased on 1218 reviews. Write a review= .

Microsoft Office 2003 *Professional*<= br> Microsoft

Choose:
 

= $69.99
List Price:$499.00<= /span>
Price:
You Save:$429.01 (85%)



Availability: Available for = INSTANT download!
Coupon Code: fN9Lp
Platform: Windows XP

Sales Rank: #3
System requirements  |  Other Versions
Date Coupon Expires: December 31st, 2005
Average Customer Review:3D"5 Based on 12273 revie= ws. Write a review.

<= /font>

<= b class=3Dsans>Adobe Acrobat Professional V 7.0
Adobe

Choose:
 

List Price:= $499.00
Price:$69.99
You Save:$429.01 (85= %)



Availability: Available for INSTANT download!
Coupon Code: kblGyDtep
<= b>Platform: Windo= ws XP

Sales Rank: #4
System requirements=   |  Other Versions
Date Coupon Expires: December 31st,= 2005
Average Customer Review:3D"5 Based on 1316 reviews. Write a rev= iew.

=
----pychlj8dQxxKE95-- From owner-namedroppers@ops.ietf.org Mon Nov 28 13:04:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgnMa-00068m-O1 for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 13:04:28 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10653 for ; Mon, 28 Nov 2005 13:03:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgnHi-0008ty-3i for namedroppers-data@psg.com; Mon, 28 Nov 2005 17:59:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgnHh-0008tl-GQ for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 17:59:25 +0000 Received: from vpn-38.vpn.nominum.com (vpn-38.vpn.nominum.com [128.177.199.38]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id CAA93568D9; Mon, 28 Nov 2005 09:59:24 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) From: Ted Lemon Organization: Nominum, Inc. To: "Steven M. Bellovin" Subject: Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard] Date: Mon, 28 Nov 2005 11:59:20 -0600 User-Agent: KMail/1.8.3 Cc: Pekka Savola , dhcwg@ietf.org, ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org References: <20051128164925.5F05B3C0135@berkshire.machshav.com> In-Reply-To: <20051128164925.5F05B3C0135@berkshire.machshav.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511281159.20874.Ted.Lemon@nominum.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday 28 November 2005 10:49, Steven M. Bellovin wrote: > I confess that I don't see the problem. The problem is that in order to do what Pekka is proposing, we have to make a substantial change to the protocol. This creates two problems: first, it means that this protocol, which is in wide use, has been in wide use for more than five years, the standard for which has been under development for ten years, will probably take another year to make standard, for this change alone. As it has many times before. This is a major language tweak, and will require substantial review. Second, it renders implementations substantially more complicated, and creates a knob that administrators need to understand whether and how to turn, where no knob is needed. Additional knobs that aren't needed have a net negative impact on overall system security - the overall impact of the proposed change will be to reduce, not enhance security. I support the changes suggested by Havard that simply reduce the security claims being made here. I do not support making any substantive changes to the protocol at this point - to do so will simply delay it longer, and will not add any value. The only reason I can think of for not using MD5 is that at some point people might want to be able to avoid having an MD5 implementation on their device because MD5 is generally deprecated. I don't think this is a practical concern - MD5 implementations are with us for the long haul, deprecated or not. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 28 13:19:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgnbX-0001xH-KQ for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 13:19:55 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13042 for ; Mon, 28 Nov 2005 13:19:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgnXn-000AIr-4s for namedroppers-data@psg.com; Mon, 28 Nov 2005 18:16:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgnXm-000AIg-J4 for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 18:16:02 +0000 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EgnXl-0008CO-0n; Mon, 28 Nov 2005 13:16:01 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'HMAC SHA TSIG Algorithm Identifiers' to Proposed Standard Reply-to: iesg@ietf.org CC: Message-Id: Date: Mon, 28 Nov 2005 13:16:01 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has received a request from the DNS Extensions WG to consider the following document: - 'HMAC SHA TSIG Algorithm Identifiers ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-12-12. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-sha-05.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 28 13:20:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egnbl-00024o-Op for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 13:20:09 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13177 for ; Mon, 28 Nov 2005 13:19:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgnZT-000ASM-MC for namedroppers-data@psg.com; Mon, 28 Nov 2005 18:17:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgnZS-000AS4-F3 for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 18:17:47 +0000 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EgnZR-0008Vk-06; Mon, 28 Nov 2005 13:17:45 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'The Role of Wildcards in the Domain Name System' to Proposed Standard Reply-to: iesg@ietf.org CC: Message-Id: Date: Mon, 28 Nov 2005 13:17:45 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has received a request from the DNS Extensions WG to consider the following document: - 'The Role of Wildcards in the Domain Name System ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-12-12. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-09.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 28 13:29:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egnkt-0005UY-If for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 13:29:35 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15890 for ; Mon, 28 Nov 2005 13:28:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Egni2-000BOy-Sd for namedroppers-data@psg.com; Mon, 28 Nov 2005 18:26:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Egni2-000BOh-8Z for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 18:26:38 +0000 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1Egni0-0007XE-53; Mon, 28 Nov 2005 13:26:36 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , dnsext mailing list , dnsext chair , dnsext chair Subject: Protocol Action: 'Storing Certificates in the Domain Name System (DNS)' to Proposed Standard Message-Id: Date: Mon, 28 Nov 2005 13:26:36 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has approved the following document: - 'Storing Certificates in the Domain Name System (DNS) ' as a Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-09.txt Technical Summary This document describes how to store cryptographic public keys in RR records. It updates RFC2538 by clarifying the format and handling of OpenPGP public keys, clarifying representation issues, aligning the document with DNSSECbis terminology and clarifying how owner names need to be (re)constructed for specific types of public keys. Working Group Summary This document is a work item of the DNSEXT WG. For IESG review it may be useful to know that the document Editor clearly documented the editorial history of the document on: http://josefsson.org/rfc2538bis/ Protocol Quality RFC2538 has been implemented. Some of the problems discovered during implementation of RFC2538 have been addressed in this document. It was the intention of the working group to also supply an interoperability report so that this document could advance RFC2538 up the standards track. Unfortunately the WG could not draft volunteers. It is the intention that this document obsoletes 2538 and that the specification remains at proposed standard. Note that some of the examples in this document do not coply with RFC 3330. Those examples were taken verbatim from RFC 2538 and have been maintained for consistency. This document was reviewed for the IESG by Margaret Wasserman. -- to unsubscribe send a message to namedroppers-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 28 16:23:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgqSn-0007mE-0I for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 16:23:05 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16074 for ; Mon, 28 Nov 2005 16:22:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgqP3-0001ew-EA for namedroppers-data@psg.com; Mon, 28 Nov 2005 21:19:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgqP2-0001eW-B4 for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 21:19:12 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id jASLJ3xa062579 for ; Mon, 28 Nov 2005 16:19:03 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id jASLJ2JB062578 for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 16:19:03 -0500 (EST) (envelope-from namedroppers) Received: from [147.28.0.16] (helo=machshav.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eg3Lr-0000qS-68 for namedroppers@ops.ietf.org; Sat, 26 Nov 2005 16:56:39 +0000 Received: by machshav.com (Postfix, from userid 512) id D221FFB286; Sat, 26 Nov 2005 11:56:38 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 40BC4FB27D; Sat, 26 Nov 2005 11:56:37 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id EB1463BFFBD; Sat, 26 Nov 2005 11:56:35 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Pekka Savola Cc: iesg@ietf.org, dhcwg@ietf.org, ietf@ietf.org, namedroppers@ops.ietf.org Subject: Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard] In-Reply-To: Your message of "Sat, 26 Nov 2005 16:22:35 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 26 Nov 2005 11:56:35 -0500 Message-Id: <20051126165635.EB1463BFFBD@berkshire.machshav.com> X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ 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. ] In message , Pekka Savola writes: >Hi, > >I'll break out the most substantial comments in separate messages.. > >On Mon, 14 Nov 2005, The IESG wrote: >> The IESG has received a request from the Dynamic Host Configuration WG to >> consider the following documents: >> >> - 'A DNS RR for Encoding DHCP Information (DHCID RR) ' >> as a Proposed Standard >> - 'Resolution of FQDN Conflicts among DHCP Clients ' >> as a Proposed Standard >> - 'The DHCP Client FQDN Option ' >> as a Proposed Standard >> - 'The DHCPv6 Client FQDN Option ' >> as a Proposed Standard > >I have only one major comment on DHCID on its use of MD5 as a >glued-in hash-function. The rest of the comments are rather >straightforward. > >substantial >---------- > > In order to avoid exposing potentially sensitive identifying > information, the data stored is the result of a one-way MD5 [5] hash > computation. The hash includes information from the DHCP client's > REQUEST message as well as the domain name itself, so that the data > stored in the DHCID RR will be dependent on both the client > identification used in the DHCP protocol interaction and the domain > name. This means that the DHCID RDATA will vary if a single client > is associated over time with more than one name. This makes it > difficult to 'track' a client as it is associated with various domain > names. > > The MD5 hash algorithm has been shown to be weaker than the SHA-1 > algorithm; it could therefore be argued that SHA-1 is a better > choice. However, SHA-1 is significantly slower than MD5. A > successful attack of MD5's weakness does not reveal the original data > that was used to generate the signature, but rather provides a new > set of input data that will produce the same signature. Because we > are using the MD5 hash to conceal the original data, the fact that an > attacker could produce a different plaintext resulting in the same > MD5 output is not significant concern. > >==> while the informatione exposure of someone cracking the MD5 hash >is not too huge, I believe it is unacceptable to design new protocols >without the capability to switch the hash function as need be. This >could be achieved for example by reserving one additional byte from >the start of the DHCID record to designate the hash function used. >If you don't bother to define your own registry (for all of me, you >could include MD5 there as well, but at least include SHA1 and >preferably also SHA-256), you could possibly re-use >http://www.iana.org/assignments/ds-rr-types or something like that. > >That way, we can introduce new hash functions in a backward compatible >manner later on, with no need to revamp the protocol. > >If we don't do this, we'll need to define DHCID2, DHCID3, .. etc. >records further down in the future (w/ different hash functions) and >make DHCP co-exist with all of them. That's bound to cause a lot of >protocol complexity, and I don't think we want to go there. I agree with this comment. The draft is wrong -- it asserts that a "successful attack of MD5's weakness does not reveal the original data". That's an overassumption -- we have no idea what such an attack would yield, since no such attack currently exists. More generally... The currently-known attacks on MD5 are collision attacks: it's possible to generate two inputs that produce the same hash value. This scenario requires a preimage attack; none are known. It would not surprise me if someone were to develop one, but until that happens we can't speculate on its properties. There are, however, some reasons for concern. One of the options defined, the DHCPv4 Client Identifier, probably doesn't have much entropy. For example, a suggestion in RFC 2132 says to use the ARP hardware type code and MAC address. There's exactly one interesting hardware type code for most users, and the high-order 3 bytes of the MAC address are the manufacturer's ID, not many of which are actually used. Given that this is an 8-byte input string and that MD5 has an 8-byte output, it is plausible that comparatively few input strings hash to any given output. If several of the input bytes are fixed, or at least constrained, there may be only one. For that matter, that assumption alone may lead to a successful attack on MD5. In fact, the Security Considerations section should analyze the (non-trivial) probability of a brute-force attack. Again, consider the Client Identifier, which is likely 8 bytes long. 2 are fixed, and hence irrelevant. According to today's copy of http://standards.ieee.org/regauth/oui/oui.txt there are 8786 manufacturer IDs, or slightly more than 8 bits. Effectively, though, it's less, since the usage is very non-uniform. Even if is uniform, though, that field plus the unit identifier only total slightly over 32 bits -- well within anyone's capabilities. Most of this analysis applies to the other two options as well. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb -- to unsubscribe send a message to namedroppers-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 28 16:23:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgqSm-0007m8-Fr for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 16:23:05 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16065 for ; Mon, 28 Nov 2005 16:22:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgqQW-0001qx-CR for namedroppers-data@psg.com; Mon, 28 Nov 2005 21:20:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgqQV-0001qM-IR for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 21:20:44 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id jASLKZ7v062662 for ; Mon, 28 Nov 2005 16:20:35 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id jASLKZwY062661 for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 16:20:35 -0500 (EST) (envelope-from namedroppers) Received: from [69.25.196.178] (helo=carter-zimmerman.mit.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgUtu-000Dbu-Tc for namedroppers@ops.ietf.org; Sun, 27 Nov 2005 22:21:39 +0000 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 512CBE0073; Sun, 27 Nov 2005 17:21:31 -0500 (EST) To: "Steven M. Bellovin" Cc: Pekka Savola , dhcwg@ietf.org, namedroppers@ops.ietf.org, iesg@ietf.org, ietf@ietf.org Subject: Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard] References: <20051126165635.EB1463BFFBD@berkshire.machshav.com> From: Sam Hartman Date: Sun, 27 Nov 2005 17:21:31 -0500 In-Reply-To: <20051126165635.EB1463BFFBD@berkshire.machshav.com> (Steven M. Bellovin's message of "Sat, 26 Nov 2005 11:56:35 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ 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. ] >>>>> "Steven" == Steven M Bellovin writes: I'm currently writing a discuss on the md5 issue. At a minimum you will need to specify the complexity in order to deal with changing hash algorithms. Steven> More generally... The currently-known attacks on MD5 are Steven> collision attacks: it's possible to generate two inputs Steven> that produce the same hash value. This scenario requires Steven> a preimage attack; none are known. It would not surprise Steven> me if someone were to develop one, but until that happens Steven> we can't speculate on its properties. There are, however, Actually, no, it's worse than that. A preimage attack is sufficient to break this. However you cannot reduce a break of this system to a preimage attack. We actually know very little about how much information hash functions leak. We can prove an uppor bound on this given the assumption that they are one-way. If they leak too much information then they are not one-way and we can find preimages. However I don't think we can say much more than that. we can treat a hash function as a random oracle and under that assumption it does not leak information. The random oracle assumption is much stronger than collision resistance. Collision resistance can certainly be reduced to random oracle. So, saying that you can find collisions actually is a very strong strike against the use of a particular hash function as a random oracle. I am not happy with a protocol whose security depends on treating md5 as a random oracle. --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 28 16:23:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgqSm-0007mD-VT for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 16:23:05 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16066 for ; Mon, 28 Nov 2005 16:22:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgqQz-0001xg-7w for namedroppers-data@psg.com; Mon, 28 Nov 2005 21:21:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgqQy-0001xD-82 for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 21:21:12 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id jASLL3us062698 for ; Mon, 28 Nov 2005 16:21:03 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id jASLL3Ol062697 for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 16:21:03 -0500 (EST) (envelope-from namedroppers) Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgYgQ-00090E-1Y for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 02:23:58 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 27 Nov 2005 18:23:58 -0800 X-IronPort-AV: i="3.97,383,1125903600"; d="scan'208"; a="678753195:sNHT31534792" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAS2NreS024871; Sun, 27 Nov 2005 18:23:54 -0800 (PST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 27 Nov 2005 21:23:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard] Date: Sun, 27 Nov 2005 21:23:52 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21E70EAC@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard] Thread-Index: AcXyvVB/7m+9A2S8RMqkLb2qZICidABAv94w From: "Bernie Volz \(volz\)" To: "Pekka Savola" , "Ted Lemon" Cc: , , , X-OriginalArrivalTime: 28 Nov 2005 02:23:53.0334 (UTC) FILETIME=[C6BBF960:01C5F3C2] X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable [ 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. ] This would, as Ted indicates, greatly complicate the entire update sequence. The current update sequence (see draft-ietf-dhc-ddns-resolution-10.txt), never does a query of the RRs in the server. Therefore, either we'd have to do a query first to obtain the DHCID RR and extract the algorithm so we can do the comparison, or we'd have to try each of the algorithms in a DNS update operation. Neither of these is particularily pleasant (especially considering that things can change between DNS operations). And, if not all implementations support all algorithms, you'd have real interop problems. And, what's the benefit? It isn't like this information is hyper sensitive (come on, IPv6 uses the mac address in the link identifier -- yes, I know about RFC 3041). While MD5 could be compromised, you can't necessarily get back the mac address that was used to generate the value. Yet, we also have to remember that we're dealing with a 48-bit *INPUT* in many cases for the DHCID -- the mac address. A brute force attack is not out of the question if you really wanted to get the data (and given the well known 24-bit OID values, you could probably cut down the bruce force attack to make it very reasonable whatever scheme we used). If a client identifier or DUID is used, this does likely mean more bits but most client identifiers and DUIDs are based on mac addresses. So, let's be realistic here and not unnecessarily complicate matters for no real benefit. If there is a strong argument to improve the security of this information, we can debate whether SHA1 or SHA-256 be used for the start. But, I for one don't see the need. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Pekka Savola > Sent: Saturday, November 26, 2005 2:10 PM > To: Ted Lemon > Cc: dhcwg@ietf.org; ietf@ietf.org; iesg@ietf.org;=20 > namedroppers@ops.ietf.org > Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:=20 > 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed=20 > Standard] >=20 > On Sat, 26 Nov 2005, Ted Lemon wrote: > > Making a hash function interchangeable in DHCID makes the=20 > conflict detection > > algorithm hugely more complicated, and possibly not=20 > workable at all. Think > > about how that would work. >=20 > AFAICS, it shouldn't be all that complicated as long as the=20 > implementations [checking for conflicts] support all the algorithms=20 > used at the site, right? >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 28 16:23:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgqSp-0007nV-7d for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 16:23:07 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16102 for ; Mon, 28 Nov 2005 16:22:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgqPa-0001ih-2B for namedroppers-data@psg.com; Mon, 28 Nov 2005 21:19:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgqPZ-0001iB-9r for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 21:19:45 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id jASLJaSS062594 for ; Mon, 28 Nov 2005 16:19:36 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id jASLJak8062593 for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 16:19:36 -0500 (EST) (envelope-from namedroppers) Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eg519-000Bj2-8T for namedroppers@ops.ietf.org; Sat, 26 Nov 2005 18:43:23 +0000 Received: from [192.168.1.104] (adsl-65-64-51-112.dsl.tulsok.swbell.net [65.64.51.112]) by toccata.fugue.com (Postfix) with ESMTP id 785EA1B205E; Sat, 26 Nov 2005 11:43:22 -0700 (MST) From: Ted Lemon Organization: Diamond Mountain To: Pekka Savola Subject: Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard] Date: Sat, 26 Nov 2005 12:43:21 -0600 User-Agent: KMail/1.8.3 Cc: iesg@ietf.org, dhcwg@ietf.org, namedroppers@ops.ietf.org, ietf@ietf.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511261243.21694.mellon@fugue.com> X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ 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. ] Making a hash function interchangeable in DHCID makes the conflict detection algorithm hugely more complicated, and possibly not workable at all. Think about how that would work. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 28 16:23:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgqSt-0007pI-4T for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 16:23:11 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16139 for ; Mon, 28 Nov 2005 16:22:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgqQD-0001oB-F1 for namedroppers-data@psg.com; Mon, 28 Nov 2005 21:20:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgqQC-0001nl-L6 for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 21:20:25 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id jASLKHtZ062627 for ; Mon, 28 Nov 2005 16:20:17 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id jASLKGAp062626 for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 16:20:17 -0500 (EST) (envelope-from namedroppers) Received: from [69.25.196.178] (helo=carter-zimmerman.mit.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgUtu-000Dbu-Tc for namedroppers@ops.ietf.org; Sun, 27 Nov 2005 22:21:39 +0000 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 512CBE0073; Sun, 27 Nov 2005 17:21:31 -0500 (EST) To: "Steven M. Bellovin" Cc: Pekka Savola , dhcwg@ietf.org, namedroppers@ops.ietf.org, iesg@ietf.org, ietf@ietf.org Subject: Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard] References: <20051126165635.EB1463BFFBD@berkshire.machshav.com> From: Sam Hartman Date: Sun, 27 Nov 2005 17:21:31 -0500 In-Reply-To: <20051126165635.EB1463BFFBD@berkshire.machshav.com> (Steven M. Bellovin's message of "Sat, 26 Nov 2005 11:56:35 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ 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. ] >>>>> "Steven" == Steven M Bellovin writes: I'm currently writing a discuss on the md5 issue. At a minimum you will need to specify the complexity in order to deal with changing hash algorithms. Steven> More generally... The currently-known attacks on MD5 are Steven> collision attacks: it's possible to generate two inputs Steven> that produce the same hash value. This scenario requires Steven> a preimage attack; none are known. It would not surprise Steven> me if someone were to develop one, but until that happens Steven> we can't speculate on its properties. There are, however, Actually, no, it's worse than that. A preimage attack is sufficient to break this. However you cannot reduce a break of this system to a preimage attack. We actually know very little about how much information hash functions leak. We can prove an uppor bound on this given the assumption that they are one-way. If they leak too much information then they are not one-way and we can find preimages. However I don't think we can say much more than that. we can treat a hash function as a random oracle and under that assumption it does not leak information. The random oracle assumption is much stronger than collision resistance. Collision resistance can certainly be reduced to random oracle. So, saying that you can find collisions actually is a very strong strike against the use of a particular hash function as a random oracle. I am not happy with a protocol whose security depends on treating md5 as a random oracle. --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 28 16:24:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgqTn-00005Y-6f for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 16:24:07 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16787 for ; Mon, 28 Nov 2005 16:23:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgqSI-0002DL-Pp for namedroppers-data@psg.com; Mon, 28 Nov 2005 21:22:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgqSH-0002Ci-BT for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 21:22:33 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id jASLMPN0062715 for ; Mon, 28 Nov 2005 16:22:25 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id jASLMPfI062714 for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 16:22:25 -0500 (EST) (envelope-from namedroppers) Received: from [147.28.0.16] (helo=machshav.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgmC1-00041F-K1 for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 16:49:29 +0000 Received: by machshav.com (Postfix, from userid 512) id 6AC9FFB286; Mon, 28 Nov 2005 11:49:29 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5F902FB281; Mon, 28 Nov 2005 11:49:28 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 5F05B3C0135; Mon, 28 Nov 2005 11:49:25 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Ted Lemon Cc: Pekka Savola , dhcwg@ietf.org, ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard] In-Reply-To: (Your message of "Sat, 26 Nov 2005 12:43:21 CST.") <200511261243.21694.mellon@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Nov 2005 11:49:25 -0500 Message-Id: <20051128164925.5F05B3C0135@berkshire.machshav.com> X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ 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. ] In message <200511261243.21694.mellon@fugue.com>, Ted Lemon writes: >Making a hash function interchangeable in DHCID makes the conflict detection >algorithm hugely more complicated, and possibly not workable at all. Think >about how that would work. > I confess that I don't see the problem. The updater would do a DNS query for DHCID RRs; it would be given all of the stored records. The updater would then use local policy -- that is, an ordered list of preferred hash functions -- until it found one that was in the response. That one would be used. If no locally-known hash functions are in the list, it should behave as if there were no DHCID records present for that name. DNSSEC could protect against downgrade attacks. (Speaking of which -- were I still AD, I'd ding this document for an inadequate Security Considerations section -- apart from the lack of discussion of brute force attacks, you should cite 3833 for DNS attacks and explain what the risks are if someone can crack the hash function by any means, including brute force or eavesdropping on the wire or (perhaps) a misbehaving updater.) If you don't agree, I'd strongly suggest using SHA-256 instead of MD5. Yes, it's more expensive, but I doubt that that's a major hit on overall system performance here. It would also be useful to include in the document some discussion of upgrade strategy -- how would we ever switch to a new hash function? That's non-trivial even for protocols designed for agility, as Eric Rescorla and I have shown. No matter how it's done, this one is among the very hardest, since DNS servers would have to supply DHCID records for several hashes for a number of years. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb -- to unsubscribe send a message to namedroppers-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 28 16:25:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgqVL-0000m3-12 for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 16:25:43 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17286 for ; Mon, 28 Nov 2005 16:24:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgqT4-0002Kp-MF for namedroppers-data@psg.com; Mon, 28 Nov 2005 21:23:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgqT3-0002Jg-Ht for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 21:23:22 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id jASLN5fQ062732 for ; Mon, 28 Nov 2005 16:23:05 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id jASLN5Hl062731 for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 16:23:05 -0500 (EST) (envelope-from namedroppers) Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Egplj-000MhE-PI for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 20:38:35 +0000 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id jASKc7Kv016755; Mon, 28 Nov 2005 12:38:07 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 12:38:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Choice of crypto, was resolution etc, Date: Mon, 28 Nov 2005 12:38:06 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD377C2598@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: Choice of crypto, was resolution etc, Thread-Index: AcX0PDtUTWSAyqcEQNS+zSJuJkRGFwAENTiA From: "Hallam-Baker, Phillip" To: "Steven M. Bellovin" , "Ted Lemon" Cc: , , , "Pekka Savola" , X-OriginalArrivalTime: 28 Nov 2005 20:38:07.0394 (UTC) FILETIME=[A39A8020:01C5F45B] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] I don't always agree with Steve but I think he has made a good case on several occasions against the traditional 'menu choices' approach to crypto algorithms. The mere ability to specify a different algorithm ID is not sufficient to provide an upgrade path. Unless both the sender and receiver know which algorithm to expect the ability to specify different algorithms can result in a situation where the security of the system is the security of the weakest of the algorithms on offer rather than the strongest. The strength of the cryptographic algorithm is only one factor in determining the security of the system, in most cases the least important. We still have no confirmed cases of a criminal exploit based on the known insecurity of 40bit SSL or WEP. MD5 is much more secure than either of them. It is important to understand the difference between the preferred cryptographic algorithm and an acceptable one. At this point there is no hash algorithm that is entirely satisfactory. SHA 256 is the nearest to being acceptable but the design of SHA 256 is based on SHA-1 which has issues. >From a security point of view the weaknesses in the hash algorithms are like finding that the floor in your wood framed house drops 3 inches over a 12ft span. The problem is not the roll to the floor, its what the roll might indicate about what is under the floor (possibly termites). The actual compromise known in MD5, SHA-1 and related algorithms are only of immediate concern to a handful of applications. The criteria we demand of hash algorithms are exceptionally conservative.=20 There are realy two sets of recommendations that are needed for crypto algorithms: 1) Algorithms recommended for use in new applications 2) Algorithms that are acceptable for use in legacy applications without concern And then there are: 3) Algorithms that are acceptable for use in legacy applications after careful analysis of the specif use 4) Algorithms that should be avoided at all costs. For example, RSA 2048 would be in the first category, RSA 1024 and SHA1 in the second, DES and MD5 in the third, RSA 512 would be in the fourth. I think that in general there should only be one or at most two algorithms recommended for a certain type of operation. The performance differences between SHA1 and SHA256 are so marginal that I don't think they should be accepted as cause for allowing an algorithm option. I have in the past been very much opposed to ECC but the current level of backing for ECC and 'SuiteB' crypto from the NSA does come with some powerful arguments. There is certainly a sharp drop off in performance of RSA above 2048 bits. There are IPR issues but these may well solve themselves within an acceptable time frame (no patent lasts forever). Phill > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On=20 > Behalf Of Steven M. Bellovin > Sent: Monday, November 28, 2005 11:49 AM > To: Ted Lemon > Cc: iesg@ietf.org; dhcwg@ietf.org; namedroppers@ops.ietf.org;=20 > Pekka Savola; ietf@ietf.org > Subject: Re: DHCID and the use of MD5 [Re: Last Call:=20 > 'Resolution of FQDNConflicts among DHCP Clients' to Proposed=20 > Standard]=20 >=20 > In message <200511261243.21694.mellon@fugue.com>, Ted Lemon writes: > >Making a hash function interchangeable in DHCID makes the=20 > conflict detection=20 > >algorithm hugely more complicated, and possibly not workable=20 > at all. Think=20 > >about how that would work. > > > I confess that I don't see the problem. The updater would do=20 > a DNS query for DHCID RRs; it would be given all of the=20 > stored records. The updater would then use local policy --=20 > that is, an ordered list of preferred hash functions -- until=20 > it found one that was in the response. That one would be=20 > used. If no locally-known hash functions are in the list, it=20 > should behave as if there were no DHCID records present for=20 > that name. DNSSEC could protect against downgrade attacks. > (Speaking of which -- were I still AD, I'd ding this document=20 > for an inadequate Security Considerations section -- apart=20 > from the lack of discussion of brute force attacks, you=20 > should cite 3833 for DNS attacks and explain what the risks=20 > are if someone can crack the hash function by any means,=20 > including brute force or eavesdropping on the wire or=20 > (perhaps) a misbehaving updater.) >=20 > If you don't agree, I'd strongly suggest using SHA-256=20 > instead of MD5. =20 > Yes, it's more expensive, but I doubt that that's a major hit=20 > on overall system performance here. It would also be useful=20 > to include in the document some discussion of upgrade=20 > strategy -- how would we ever switch to a new hash function? =20 > That's non-trivial even for protocols designed for agility,=20 > as Eric Rescorla and I have shown. No matter how it's done,=20 > this one is among the very hardest, since DNS servers would=20 > have to supply DHCID records for several hashes for a number of years. >=20 > --Steven M. Bellovin, http://www.cs.columbia.edu/~smb >=20 >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf >=20 >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 28 17:14:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgrGG-0002pL-G1 for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 17:14:12 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00100 for ; Mon, 28 Nov 2005 17:13:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgrE2-0009M0-IS for namedroppers-data@psg.com; Mon, 28 Nov 2005 22:11:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [158.38.152.233] (helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgrE1-0009Lg-JW for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 22:11:54 +0000 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED9AD259712; Mon, 28 Nov 2005 23:11:18 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14890-07; Mon, 28 Nov 2005 23:11:14 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id E983725970F; Mon, 28 Nov 2005 23:11:13 +0100 (CET) Date: Mon, 28 Nov 2005 23:13:55 +0100 From: Harald Tveit Alvestrand To: "Bernie Volz (volz)" , "Steven M. Bellovin" , Ted Lemon Cc: dhcwg@ietf.org, Pekka Savola , ietf@ietf.org, namedroppers@ops.ietf.org Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard] Message-ID: <6471A3CCD9C93821B3AA3C5D@svartdal.hjemme.alvestrand.no> In-Reply-To: <8E296595B6471A4689555D5D725EBB21E712A4@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21E712A4@xmb-rtp-20a.amer.cisco.c om> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On mandag, november 28, 2005 17:00:39 -0500 "Bernie Volz (volz)" wrote: >> I confess that I don't see the problem. The updater would do a DNS >> query for DHCID RRs; it would be given all of the stored >> records. > > That's not how the current update algorithm works. Sure, we could do > almost anything but we'll be debating this for the next 100 years. It > has already gone on for almost 10 years!!! > > Can we get serious about this and really ask what are we trying to > protect. > > And where were you folks when IPv6 was designed to use the mac address > as the interface identifier. Come on. > > We're trying to make it NON-TRIVIAL, not impossible. > > This technique has been in use for years by implementations using TXT > records because we've been unable to get the DHCID RR approved. Bernie, just checking.... this puzzle seems to have several distinct pieces: - the DHCP options to talk about DNS names. Nobody seems to have any large problem with that. - the mechanism for detecting conflicts. Nobody seems to have any large problem with that. - the exact mechanism by which one stores a value identifying the client in the DNS without giving out useful information about the client. That's where all the shouting is. Can you verify for me that all three parts are being done today in production, in just the way (apart from RR type) specified in the I-Ds? Harald -- to unsubscribe send a message to namedroppers-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 28 18:35:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgsX5-0004SM-S7 for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 18:35:39 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09292 for ; Mon, 28 Nov 2005 18:34:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgsUO-0006dZ-Dd for namedroppers-data@psg.com; Mon, 28 Nov 2005 23:32:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, SUBJECT_ENCODED_TWICE,SUBJECT_EXCESS_QP autolearn=no version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgsUN-0006dM-JG for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 23:32:51 +0000 Received: from vpn-38.vpn.nominum.com (vpn-38.vpn.nominum.com [128.177.199.38]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 18A2056905; Mon, 28 Nov 2005 15:32:51 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) From: Ted Lemon Organization: Nominum, Inc. To: "David W. Hankins" Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: =?iso-8859-1?q?=27Resolution=09ofFQDN_Conflicts_among_DHCP_Clients=27_to?= =?iso-8859-1?q?_Proposed?= Standard] Date: Mon, 28 Nov 2005 16:32:40 -0700 User-Agent: KMail/1.8.3 Cc: "Bernie Volz (volz)" , Harald Tveit Alvestrand , "Steven M. Bellovin" , dhcwg@ietf.org, namedroppers@ops.ietf.org, Pekka Savola , ietf@ietf.org References: <8E296595B6471A4689555D5D725EBB21E712BF@xmb-rtp-20a.amer.cisco.com> <20051128231828.GD19835@isc.org> In-Reply-To: <20051128231828.GD19835@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511281632.41130.Ted.Lemon@nominum.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The Nominum DHCP server (DCS) supports the exact mechanism described in the collection of documents, except that the data is stored in a TXT record rather than a DHCID record, because we are waiting on the DHCID record. We also implement the older version of the protocol that the ISC server supports, which as David says is only slightly different than the current spec. -- to unsubscribe send a message to namedroppers-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 28 23:39:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgxHW-0000g5-W7 for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 23:39:55 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08289 for ; Mon, 28 Nov 2005 23:39:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgxE0-0004bV-8p for namedroppers-data@psg.com; Tue, 29 Nov 2005 04:36:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgxDz-0004bB-D6 for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 04:36:15 +0000 Received: from vpn-38.vpn.nominum.com (vpn-38.vpn.nominum.com [128.177.199.38]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 700DB5684B; Mon, 28 Nov 2005 20:36:12 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) From: Ted Lemon Organization: Nominum, Inc. To: "Hallam-Baker, Phillip" Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard] Date: Mon, 28 Nov 2005 21:36:05 -0700 User-Agent: KMail/1.8.3 Cc: "Bernie Volz (volz)" , "Steven M. Bellovin" , dhcwg@ietf.org, "Pekka Savola" , ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org References: <198A730C2044DE4A96749D13E167AD377C2612@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <198A730C2044DE4A96749D13E167AD377C2612@MOU1WNEXMB04.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511282136.06370.Ted.Lemon@nominum.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday 28 November 2005 20:00, Hallam-Baker, Phillip wrote: > OK so why are you proposing a new protocol rather than writing a > description of the protocols that are already in use? It's inconvenient to use TXT records, because they are not specific to the purpose. If the user wants TXT records on the name for some *other* purpose than marking the name with a DHCID, it doesn't work. We aren't defining a new protocol - just a new RRtype. The DNSEXT working group passed this through last call. The only reason we're not yet using it is that, well, it's been very slow getting the entire package through last call, as witness this current conversation. I appreciate that you like an opportunity to pontificate about DNSSEC, and am duly amused that you saw one here and leapt upon it. However, those of us who have been working on standardizing a method by which DHCP servers may interoperate while maintaining DNS records for DHCP clients, for the past decade, would appreciate it if you would leave off it in this case. This protocol has absolutely nothing to do with DNSSEC, other than that, like DNSSEC, it is related to the DNS. 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 Mon Nov 28 23:50:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgxRS-0005Lb-EQ for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 23:50:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09292 for ; Mon, 28 Nov 2005 23:49:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgxPZ-0005kH-Pt for namedroppers-data@psg.com; Tue, 29 Nov 2005 04:48:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgxPW-0005k0-TK for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 04:48:11 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id F1F68E603E for ; Tue, 29 Nov 2005 04:48:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id jAT4PnBL079755; Tue, 29 Nov 2005 15:25:50 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200511290425.jAT4PnBL079755@drugs.dv.isc.org> To: "Hallam-Baker, Phillip" Cc: "Bernie Volz \(volz\)" , "Steven M. Bellovin" , "Ted Lemon" , iesg@ietf.org, dhcwg@ietf.org, namedroppers@ops.ietf.org, Pekka Savola , ietf@ietf.org From: Mark Andrews Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard] In-reply-to: Your message of "Mon, 28 Nov 2005 19:00:43 -0800." <198A730C2044DE4A96749D13E167AD377C2612@MOU1WNEXMB04.vcorp.ad.vrsn.com> Date: Tue, 29 Nov 2005 15:25:49 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > This technique has been in use for years by implementations > > using TXT records because we've been unable to get the DHCID > > RR approved. > > OK so why are you proposing a new protocol rather than writing a > description of the protocols that are already in use? > > Correctly prefixed TXT records work just as well as new RRs and are > completely compatible with the deployed infrastructure. If you attempt > to cut new DNS RRs you will hit the problem that your proposal is now > dependent on deployment of a new infrastructure which has no deployment > strategy. Not this old chestnut again. > Lets get back to the idea that a standard is a description of running > code. The DNS group has become a bottleneck for deployment of a lot of > technology. This should not be acceptable. There is a fundamental > extensibility flaw in DNS, new RRs must be understood by the sender, > receiver and intermediate infrastructure. Incorrect. Only the DHCP elements need to understand this. For everything else it should be treated as a opaque blob. The intent of RFC 1034/1035 was for new RRs to be treated as opaque blobs. You don't need RDLEN if you don't expect to treat unknown as opaque blobs. This was clear to me when I first read those RFC's back in the early 90's. RFC2535 (March 1999) made it absolutely clear that unknown RR's were to be treated as opaque blobs. It is now 6 years later and you are saying we should be worrying about implementations that were clearly broken on the first day they deployed. > The DNSEXT group appears to believe that their objectives should be to > create as much of an incentive to upgrade to DNSSEC capable > infrastructure as possible and that the way to do this is to gate all > proposed uses of the DNS on cutting a new RR. Hogwash. > This is not a good strategy, DNSSEC is a double ended adoption problem, > the problem is not that the promise of DNSSEC is insufficient incentive > for deployment, the problem is that early adopter deployment of DNSSEC > has negligible incentive. This has absolutely nothing to do with the deployment of DNSSEC. > The Pareto optimal solution here is for the IAB to specify a method of > introducing new features that use the DNS that is entirely compatible > with deployed DNS infrastructure. These in turn create new dependencies > on the DNS that create a near term demand for DNSSEC and an early > adopter incentive. The DNSSEC people get an early adopter market for > their proposal, people looking to extend the DNS can do so without > committing error 33. > For example one of the discussions in DKIM is on what to do with the > ESTG vehicle set up for early development. The idea that most people > seem to think is a good one is to turn it into a branding vehicle > similar to WiFi. So that just as people advertise that their product is > WiFi compatible to mean 'yes it really works' there would be an ESTG > brand that a registrar could use to say 'yes I do provide the services > necessary to support DKIM signed email'. This then leads naturally to > the question of levels of support, a level 1 registrar might do the bare > minimum necessary to support DKIM (allow the relevant records to be > defined), the requirements for level 2 might well include support for > DNSSEC (at least I would argue that they should require DNSSEC support). > > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > -- 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 28 23:51:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgxTB-0005ap-9Y for dnsext-archive@megatron.ietf.org; Mon, 28 Nov 2005 23:51:57 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09540 for ; Mon, 28 Nov 2005 23:51:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgxRS-0005yS-NF for namedroppers-data@psg.com; Tue, 29 Nov 2005 04:50:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgxRS-0005y4-4T for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 04:50:10 +0000 Received: from vpn-38.vpn.nominum.com (vpn-38.vpn.nominum.com [128.177.199.38]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 8B8F1568DC; Mon, 28 Nov 2005 20:50:09 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) From: Ted Lemon Organization: Nominum, Inc. To: dhcwg@ietf.org Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard] Date: Mon, 28 Nov 2005 21:50:00 -0700 User-Agent: KMail/1.8.3 Cc: "Steven M. Bellovin" , Pekka Savola , namedroppers@ops.ietf.org, iesg@ietf.org, ietf@ietf.org References: <20051126165635.EB1463BFFBD@berkshire.machshav.com> In-Reply-To: <20051126165635.EB1463BFFBD@berkshire.machshav.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511282150.01493.Ted.Lemon@nominum.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Saturday 26 November 2005 09:56, Steven M. Bellovin wrote: > In fact, the Security Considerations section should analyze the > (non-trivial) probability of a brute-force attack. It doesn't matter. The point of the DHCID is to allow two servers to avoid accidentally stepping on each other. If you break the DHCID, what you get is the ability to pretend that you are another DHCP client. If you succeed in doing this, you can take over that DHCP client's name, but you don't get to keep it, because you are using the same identification as the other client, and so it's going to take it back. The information that you would use to pretend to be the other client is routinely being sent over the network in the clear, so you don't need to break the DHCID to get it - you just need to listen on the wire for a packet from that client. You can't do the attack I've described unless you are on a network managed by a DHCP server that manages the same namespace as the server that put in the legitimate DHCID. It's true that we could exhaustively go over all possible exploits, no matter how trivial, no matter how useless, in the security considerations section. Do you honestly believe that this is necessary? -- to unsubscribe send a message to namedroppers-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 29 00:02:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgxdJ-0003JK-Gn for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 00:02:25 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10917 for ; Tue, 29 Nov 2005 00:01:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgxbW-0007F4-UD for namedroppers-data@psg.com; Tue, 29 Nov 2005 05:00:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgxbO-0007Di-Aw for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 05:00:26 +0000 Received: from vpn-38.vpn.nominum.com (vpn-38.vpn.nominum.com [128.177.199.38]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id A1E47568F8; Mon, 28 Nov 2005 21:00:25 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) From: Ted Lemon Organization: Nominum, Inc. To: Sam Hartman Subject: Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard] Date: Mon, 28 Nov 2005 22:00:18 -0700 User-Agent: KMail/1.8.3 Cc: "Steven M. Bellovin" , Pekka Savola , dhcwg@ietf.org, namedroppers@ops.ietf.org, iesg@ietf.org, ietf@ietf.org References: <20051126165635.EB1463BFFBD@berkshire.machshav.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200511282200.19403.Ted.Lemon@nominum.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On Sunday 27 November 2005 15:21, Sam Hartman wrote: > Actually, no, it's worse than that. =A0A preimage attack is sufficient > to break this. =A0However you cannot reduce a break of this system to a > preimage attack. =A0 It's always inspiring to meet someone who knows a lot about a complex topic= =20 like hash algorithms. > I am not happy with a protocol whose security depends on treating md5 > as a random oracle. Again, very inspiring to meet someone who knows about md5, random oracles, = et=20 cetera. However, this protocol's security does not rely in any way on md5= =20 or any other hash. The hash is present as a privacy mask. It has limite= d=20 value since the thing being protected is broadcast over the wire on a regul= ar=20 basis, but we put it in because we were asked to. The security of the=20 protocol rests on the security of the DNS update mechanism; if you are=20 concerned about DNS update security with your DHCP server, I suggest using= =20 some kind of cryptographic authentication. I use TSIG, and am reasonably= =20 happy with it. In order for the DHCID hash to be a security issue, it has to be the case t= hat=20 you have more than one DHCP server that is permitted to update the same zon= e=20 in the DNS, and yet have no trust relationship between these DHCP servers. = =20 This is a contradiction in terms - if you don't have a trust relationship=20 between two updaters of the same zone, you don't have any update security a= t=20 all for that zone. I would really encourage people who are commenting on this to please, pleas= e=20 read the drafts for detailed comprehension, not just for keywords. I get= =20 the impression that a lot of keyword triggering is going off here, and it's= =20 really not constructive. -- to unsubscribe send a message to namedroppers-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 29 01:41:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgzBA-00032U-5i for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 01:41:28 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20681 for ; Tue, 29 Nov 2005 01:40:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Egz7x-000EV6-BQ for namedroppers-data@psg.com; Tue, 29 Nov 2005 06:38:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [158.38.152.233] (helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Egz7s-000ETz-OM for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 06:38:04 +0000 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 909BC25970B; Tue, 29 Nov 2005 07:37:29 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00360-05; Tue, 29 Nov 2005 07:37:24 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id ADC17259707; Tue, 29 Nov 2005 07:37:24 +0100 (CET) Date: Tue, 29 Nov 2005 07:40:08 +0100 From: Harald Tveit Alvestrand To: "Bernie Volz (volz)" , "Steven M. Bellovin" , Ted Lemon Cc: dhcwg@ietf.org, Pekka Savola , ietf@ietf.org, namedroppers@ops.ietf.org Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard] Message-ID: In-Reply-To: <8E296595B6471A4689555D5D725EBB21E712BF@xmb-rtp-20a.amer.cisco.com> References: <8E296595B6471A4689555D5D725EBB21E712BF@xmb-rtp-20a.amer.cisco.c om> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks - these responses point out very clearly that the mechanism is being used as described, *except* for the bit that's contentious (use of MD5 for information hiding). This means that we will not have a backwards compatibility issue with the installed base if we change the format of the record, but *will* have a procedural compatibility issue if we don't keep the property of "you can know the expected content of the record without fetching it". Harald --On mandag, november 28, 2005 17:20:09 -0500 "Bernie Volz (volz)" wrote: > Harald: > > Yes, I can. > > The ISC's DHCP server (www.isc.org) does this (I'm not sure whether it > uses MD5 to encode the client identity or not). Ted might know for sure. > > As does Cisco's Network Registrar (though it presently doesn't encode > the data using MD5). > > And, I'm pretty sure several other DHCP vendors do this -- though > whether they're using MD5 or not I can't be sure. > > These servers are in production all over and have been doing this for > many years. -- to unsubscribe send a message to namedroppers-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 29 01:59:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgzSz-0006vT-H9 for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 01:59:53 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22673 for ; Tue, 29 Nov 2005 01:59:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgzQt-000G4y-CV for namedroppers-data@psg.com; Tue, 29 Nov 2005 06:57:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [202.214.123.16] (helo=ns.64translator.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgzQs-000G4f-CC for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 06:57:42 +0000 Received: from bahamas.64translator.com ([10.21.32.3]) by ns.64translator.com (8.13.1/8.13.1) with ESMTP id jAT6veKa074206; Tue, 29 Nov 2005 15:57:40 +0900 (JST) (envelope-from Hideshi.Enokihara@jp.yokogawa.com) Received: from thinkpad.64translator.com (dhcp248.64translator.com [10.21.32.248]) by bahamas.64translator.com (8.13.1/8.13.1) with SMTP id jAT6vXTn025711; Tue, 29 Nov 2005 15:57:33 +0900 (JST) (envelope-from Hideshi.Enokihara@jp.yokogawa.com) Date: Tue, 29 Nov 2005 15:56:52 +0900 From: Hideshi Enokihara To: namedroppers@ops.ietf.org, dnstest@tahi.org Subject: Question about some bits in DNS header Message-Id: <20051129155652.23526ed0.Hideshi.Enokihara@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I have two questions about treatment of DNS header format. ------------------------------------------------- 1.Treatment of the AA bit in response For example, the following topologys are assumed. AP Server1 DNS Server2 |A.example.org |example.org |3ffe:501:ffff:101::10 |3ffe:501:fffff:101::20 |192.168.1.10 |192.168.1.20 | | Net-y --+--------+---------------+---------------------- 3ffe:501:ffff:101::/64 | 192.168.1/24 | | Router |3ffe:501:ffff:100::1 |192.168.0.1 | | Net-z --+--------+-----------------+-------------------- 3ffe:501:ffff:100::/64 | | 192.168.0/24 | | DNS Server1 DNS Cient1 3ffe:501:ffff:100::XXXX 3ffe:501:fffff:100::20 192.168.0.10 192.168.0.20 In this topology, 1.DNS Client1 send query for QNAME=A.example.org,QTYPE=A to DNS Server1. And 2.DNS Server1 send (recursive) query to DNS Server2 that is Authority of "example.com". 3. DNS Server2 send response with AA bit=1 to DNS Server1. I have the question about next response(4). DNS Client1 DNS Server1 DNS Server2 | | | |----------------------------->| | | 1. Send standard query | | | QNAME=A.example.org | | | QTYPE=A | | | | | | |-------------------------------->| | | 2. Send standard query | | | QNAME=A.example.org | | | QTYPE=A | | | | | |<--------------------------------| | | 3. Send standard response | | | QNAME=A.example.org | | | QTYPE=A | | | ANSWER Name=A.example.org | | | ANSWER Address=192.168.1.10 | | | AUTHORITY Name=example.org | | | AUTHORITY Name Server | | | =NS2.example.org | | | ADDITIONAL Name=NS2.example.org| | | ADDITIONAL Address=192.168.1.20| | | | |<-----------------------------| | | 4. Standard query response | | | QNAME=A.example.org | | | QTYPE=A | | | ANSWER Name=A.example.org | | | ANSWER Address=192.168.1.10 | | | Authority Name=example.org | | | Authority Name Server | | | =NS2.example.org | | v v v In this response(4), should DNS Server1 set AA bit to 1 or 0? Which behavior is correct as DNS Server in accordance with RFC? ------------------------------------------------- 2.Treatment of the AA, RA bits in query RFC1035 says, ----------- AA Authoritative Answer - this bit is valid in responses, and specifies that the responding name server is an authority for the domain name in question section. ----------- and, ----------- RA Recursion Available - this be is set or cleared in a response, and denotes whether recursive query support is available in the name server. ----------- These two bits(AA,RA) is valid in response. How should I treat this bit in query? If I want to check these bits in query, should I assume these values to be 0? Or, should not I assume any value? How do you think? Any comment are welcome. Best Regards, -- ************************************* Hideshi Enokihara IPv6 Business Network & Software Development Dept. Yokogawa Electric Corporation -- to unsubscribe send a message to namedroppers-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 29 02:05:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgzYN-0001Bi-9M for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 02:05:31 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23014 for ; Tue, 29 Nov 2005 02:04:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EgzWB-000GXj-Co for namedroppers-data@psg.com; Tue, 29 Nov 2005 07:03:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, SUBJECT_ENCODED_TWICE,SUBJECT_EXCESS_QP autolearn=no version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgzWA-000GXT-VO for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 07:03:11 +0000 Received: from vpn-38.vpn.nominum.com (vpn-38.vpn.nominum.com [128.177.199.38]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 7A3875689E; Mon, 28 Nov 2005 23:03:10 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) From: Ted Lemon Organization: Nominum, Inc. To: Harald Tveit Alvestrand Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: =?iso-8859-1?q?=27Resolution=09ofFQDN_Conflicts_among_DHCP_Clients=27_to?= =?iso-8859-1?q?_Proposed?= Standard] Date: Tue, 29 Nov 2005 00:03:03 -0700 User-Agent: KMail/1.8.3 Cc: "Bernie Volz (volz)" , "Steven M. Bellovin" , dhcwg@ietf.org, Pekka Savola , ietf@ietf.org, namedroppers@ops.ietf.org References: <8E296595B6471A4689555D5D725EBB21E712BF@xmb-rtp-20a.amer.cisco.c om> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511290003.04210.Ted.Lemon@nominum.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday 28 November 2005 23:40, Harald Tveit Alvestrand wrote: > This means that we will not have a backwards compatibility issue with the > installed base if we change the format of the record, but *will* have a > procedural compatibility issue if we don't keep the property of "you can > know the expected content of the record without fetching it". Yup. My only objection to changing the hash algorithm is that it means a rev of the document that could cause us to go through another wglc or ietf last call (as opposed to editorial changes, which presumably would not). Otherwise, while I don't think it makes any difference, it's otherwise fine to use SHA-256 instead of MD5. -- to unsubscribe send a message to namedroppers-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 29 02:27:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgztZ-0003RN-Vx for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 02:27:22 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24915 for ; Tue, 29 Nov 2005 02:26:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Egzr5-000IAH-A6 for namedroppers-data@psg.com; Tue, 29 Nov 2005 07:24:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [158.38.152.233] (helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Egzr4-000IA6-KQ for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 07:24:46 +0000 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B93725970C; Tue, 29 Nov 2005 08:24:11 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01601-07; Tue, 29 Nov 2005 08:24:07 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 982E4259707; Tue, 29 Nov 2005 08:24:07 +0100 (CET) Date: Tue, 29 Nov 2005 08:26:51 +0100 From: Harald Tveit Alvestrand To: Ted Lemon Cc: "Bernie Volz (volz)" , "Steven M. Bellovin" , dhcwg@ietf.org, Pekka Savola , ietf@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard] Message-ID: In-Reply-To: <200511290003.04210.Ted.Lemon@nominum.com> References: <8E296595B6471A4689555D5D725EBB21E712BF@xmb-rtp-20a.amer.cisco.c om> <200511290003.04210.Ted.Lemon@nominum.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On tirsdag, november 29, 2005 00:03:03 -0700 Ted Lemon wrote: > On Monday 28 November 2005 23:40, Harald Tveit Alvestrand wrote: >> This means that we will not have a backwards compatibility issue with the >> installed base if we change the format of the record, but *will* have a >> procedural compatibility issue if we don't keep the property of "you can >> know the expected content of the record without fetching it". > > Yup. My only objection to changing the hash algorithm is that it means > a rev of the document that could cause us to go through another wglc or > ietf last call (as opposed to editorial changes, which presumably would > not). Otherwise, while I don't think it makes any difference, it's > otherwise fine to use SHA-256 instead of MD5. After reading the docs, I don't think it makes any difference either. Harald -- to unsubscribe send a message to namedroppers-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 29 03:31:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh0th-00037c-Ca for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 03:31:37 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01053 for ; Tue, 29 Nov 2005 03:30:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eh0pu-000LXe-5p for namedroppers-data@psg.com; Tue, 29 Nov 2005 08:27:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Eh0pt-000LXQ-1P for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 08:27:37 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 409FC2D4B3; Tue, 29 Nov 2005 09:27:34 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 391392D4AC; Tue, 29 Nov 2005 09:27:34 +0100 (CET) Date: Tue, 29 Nov 2005 09:27:33 +0100 (CET) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Hideshi Enokihara cc: namedroppers@ops.ietf.org, dnstest@tahi.org Subject: Re: Question about some bits in DNS header In-Reply-To: <20051129155652.23526ed0.Hideshi.Enokihara@jp.yokogawa.com> Message-ID: References: <20051129155652.23526ed0.Hideshi.Enokihara@jp.yokogawa.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi Hideshi-san, On Tue, 29 Nov 2005, Hideshi Enokihara wrote: > I have two questions about treatment of DNS header format. > > DNS Client1 DNS Server1 DNS Server2 > | | | > |----------------------------->| | > | 1. Send standard query | | > | QNAME=A.example.org | | > | QTYPE=A | | > | | | > | |-------------------------------->| > | | 2. Send standard query | > | | QNAME=A.example.org | > | | QTYPE=A | > | | | > | |<--------------------------------| > | | 3. Send standard response | > | | QNAME=A.example.org | > | | QTYPE=A | > | | ANSWER Name=A.example.org | > | | ANSWER Address=192.168.1.10 | > | | AUTHORITY Name=example.org | > | | AUTHORITY Name Server | > | | =NS2.example.org | > | | ADDITIONAL Name=NS2.example.org| > | | ADDITIONAL Address=192.168.1.20| > | | | > |<-----------------------------| | > | 4. Standard query response | | > | QNAME=A.example.org | | > | QTYPE=A | | > | ANSWER Name=A.example.org | | > | ANSWER Address=192.168.1.10 | | > | Authority Name=example.org | | > | Authority Name Server | | > | =NS2.example.org | | > v v v > > In this response(4), should DNS Server1 set AA bit to 1 or 0? > Which behavior is correct as DNS Server in accordance with RFC? DNS Server1 must not set the AA bit in the response to DNS Client1, since it is not the authority for A.example.org nor example.org. > ------------------------------------------------- > 2.Treatment of the AA, RA bits in query > > RFC1035 says, > ----------- > AA Authoritative Answer - this bit is valid in responses, > and specifies that the responding name server is an > authority for the domain name in question section. > ----------- > and, > ----------- > RA Recursion Available - this be is set or cleared in a > response, and denotes whether recursive query support is > available in the name server. > ----------- > > These two bits(AA,RA) is valid in response. > How should I treat this bit in query? The server should ignore the AA and RA bits in a query. The only place I can think of where the AA bit appears in a request is with notify (rfc1996) but that is not a query. > If I want to check these bits in query, > should I assume these values to be 0? > Or, should not I assume any value? I would not assume any value for AA and RA in a query. It has no meaning. 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 Tue Nov 29 05:12:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh2T2-0006ts-5Q for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 05:12:08 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12202 for ; Tue, 29 Nov 2005 05:11:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eh2PI-0000X2-Fo for namedroppers-data@psg.com; Tue, 29 Nov 2005 10:08:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Eh2PG-0000Wm-V4 for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 10:08:15 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 31AAA2D4A5; Tue, 29 Nov 2005 11:08:12 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 3062E2D490 for ; Tue, 29 Nov 2005 11:08:12 +0100 (CET) Date: Tue, 29 Nov 2005 11:08:11 +0100 (CET) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: IETF DNSEXT WG Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-trans-02.txt In-Reply-To: Message-ID: References: <200502242137.j1OLbqU02800@grimsvotn.TechFak.Uni-Bielefeld.DE> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk disclaimer: I'm one of the authors of this draft and of the nsec3-draft. On Thu, 24 Nov 2005, Samuel Weiler wrote: > I've partially reviewed trans-03. I don't think the doc is ready for > WGLC. > > Overall recommendation: I have concerns about the wisdom of a partial > typecode rollover (especially of DS, with it's oh-so-funky > only-RR-not-in-the-child semantics), which is what this doc > recommends. I'm OK with pushing this doc forward as a historical > record, but it needs to be clearly noted (in the abstract, intro, and > section 3) that the recommendation was current as of date XXX (~1 year > ago), not the date of publication. I agree. I do not see this document as standards track, more likely informational. The recommendation is from the authors, not particular the entire wg. > Numerous editorial comments have been sent to the editors. Here are > some slightly more substantive ones: Thanks for the editorial comments. > ---- > > 2.2.3 > > I don't necessarily assume that the NSEC RR type won't change Yes. I would assume the NSEC RR type stay the same and for an alternative denial mechanism, use a new type, like NSEC3 (as an example), with a different typecode and its own interpretation independent of the NSEC RR type. > -- I > think algorithm number signaling might be used with or without a RR > type code change. Perhaps that means we should duplicate this > section. Or just suggest that these signaling mechanisms might be > mixed-and-matched. Good point. Will think about this a little bit more. > ---- > > 2.2.3.2 and 2.2.4.2 > > As I wrote in February, I see no need to split the algorithm number or > digest algorithm number space -- we could specifcy NSEC v. NSEC3 on a > per-number basis rather than saying "numbers above X are for NSEC3". Agreed, splitting space is costly. Per-number basis is more straightforward. > On Mon, 28 Feb 2005, Samuel Weiler wrote: > > > I also noticed that 2.2.3.2 suggests splitting the algorithm space > > with each version of DNSSEC. As David Blacka's experiments draft > > suggests, there might be more efficient ways to do this, and blindly > > allocating half of the algorithm numbers at each versioning sounds > > very limiting. agree. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 29 09:13:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh6F5-00061M-8Y for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 09:13:59 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09009 for ; Tue, 29 Nov 2005 09:13:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eh6Ag-000Bzj-80 for namedroppers-data@psg.com; Tue, 29 Nov 2005 14:09:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eh6Af-000BzW-Kl for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 14:09:25 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 29 Nov 2005 06:09:25 -0800 X-IronPort-AV: i="3.97,388,1125903600"; d="scan'208"; a="371466592:sNHT26533856" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jATE8xsK003653; Tue, 29 Nov 2005 06:09:21 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Nov 2005 09:09:00 -0500 Received: from [161.44.65.172] ([161.44.65.172]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Nov 2005 09:09:00 -0500 Message-ID: <438C60DA.1010900@cisco.com> Date: Tue, 29 Nov 2005 09:08:26 -0500 From: Mark Stapp User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: "Bernie Volz (volz)" , "Steven M. Bellovin" , Ted Lemon , iesg@ietf.org, dhcwg@ietf.org, namedroppers@ops.ietf.org, Pekka Savola , ietf@ietf.org Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard] References: <198A730C2044DE4A96749D13E167AD377C2612@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <198A730C2044DE4A96749D13E167AD377C2612@MOU1WNEXMB04.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Nov 2005 14:09:00.0397 (UTC) FILETIME=[721F39D0:01C5F4EE] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit there is one thing buried in here that's worth answering: Hallam-Baker, Phillip wrote: >>From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On >>Behalf Of Bernie Volz (volz) >> >> >>This technique has been in use for years by implementations >>using TXT records because we've been unable to get the DHCID >>RR approved. >> >> > >OK so why are you proposing a new protocol rather than writing a >description of the protocols that are already in use? > >Correctly prefixed TXT records work just as well as new RRs and are >completely compatible with the deployed infrastructure. If you attempt >to cut new DNS RRs you will hit the problem that your proposal is now >dependent on deployment of a new infrastructure which has no deployment >strategy. > > what we are trying to do is to produce something that allows interoperability. that's different from documenting existing similar-but-not-quite implementations. there is no "compatible" at this time - but we would like to get there. -- Mark -- to unsubscribe send a message to namedroppers-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 29 09:27:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh6SG-0006zD-EO for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 09:27:36 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11513 for ; Tue, 29 Nov 2005 09:26:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eh6OH-000Cm2-9z for namedroppers-data@psg.com; Tue, 29 Nov 2005 14:23:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eh6OE-000Clj-Qb for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 14:23:26 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 29 Nov 2005 06:23:26 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,388,1125903600"; d="scan'208"; a="16155585:sNHT25102088" 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 jATEMPeV015523; Tue, 29 Nov 2005 09:23:19 -0500 (EST) 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.211); Tue, 29 Nov 2005 09:23:15 -0500 Received: from [161.44.65.172] ([161.44.65.172]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Nov 2005 09:23:14 -0500 Message-ID: <438C6431.7090808@cisco.com> Date: Tue, 29 Nov 2005 09:22:41 -0500 From: Mark Stapp User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Steven M. Bellovin" CC: Ted Lemon , iesg@ietf.org, dhcwg@ietf.org, ietf@ietf.org, Pekka Savola , namedroppers@ops.ietf.org Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard] References: <20051129050202.EAA973C0139@berkshire.machshav.com> In-Reply-To: <20051129050202.EAA973C0139@berkshire.machshav.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Nov 2005 14:23:15.0017 (UTC) FILETIME=[6F83E390:01C5F4F0] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I don't object to Steve's proposal to clarify the goal and limitations of the use of md5 in the security considerations section. what we're trying to achieve in the DHCID rrs is certainly no stronger than the 'privacy' offered by stateless v6 addresses or rfc3041 addresses. we aren't really making a 'privacy' claim; there's plenty of other un-obscured information available in the DNS along with the DHCIDs. we're only trying to make it difficult to track a DHCP client as it moves from address to address. md5 makes it more difficult than the plain-text version of an ethernet MAC address; that's "enough" for our purpose. would such a clarification be "enough" to resolve your DISCUSS, Sam Hartman? that is, if it were clearer that we're only aiming for more difficult than not difficult at all - would that be sufficiently clear guidance to admins about what they should expect from this mechanism? -- Mark Steven M. Bellovin wrote: >In message <200511282150.01493.Ted.Lemon@nominum.com>, Ted Lemon writes: > > >>On Saturday 26 November 2005 09:56, Steven M. Bellovin wrote: >> >> >>>In fact, the Security Considerations section should analyze the >>>(non-trivial) probability of a brute-force attack. >>> >>> >>It doesn't matter. The point of the DHCID is to allow two servers to avoid >>accidentally stepping on each other. If you break the DHCID, what you get >>is the ability to pretend that you are another DHCP client. If you succeed >>in doing this, you can take over that DHCP client's name, but you don't get >>to keep it, because you are using the same identification as the other >>client, and so it's going to take it back. The information that you would >>use to pretend to be the other client is routinely being sent over the >>network in the clear, so you don't need to break the DHCID to get it - you >>just need to listen on the wire for a packet from that client. You can't do >>the attack I've described unless you are on a network managed by a DHCP >>server that manages the same namespace as the server that put in the >>legitimate DHCID. >> >>It's true that we could exhaustively go over all possible exploits, no matter >>how trivial, no matter how useless, in the security considerations section. >>Do you honestly believe that this is necessary? >> >> >> >It's the privacy aspect I'm concerned about. The protocol has a >mechanism -- the hash -- intended to protect privacy. There are >limitations to how well it works. These may be unavoidable; that said, >they should be documented. See Section 5 of RFC 3552, a BCP: > > Authors MUST describe > > 1. which attacks are out of scope (and why!) > 2. which attacks are in-scope > 2.1 and the protocol is susceptible to > 2.2 and the protocol protects against > > ... > > There should be a clear description of the residual risk to the user > or operator of that protocol after threat mitigation has been > deployed. > >Put another way, against a certain grade of attacker the mechanism >doesn't do its job. That needs to be documented, so that people who >are concerned about the issue know to avoid this option. > > --Steven M. Bellovin, http://www.cs.columbia.edu/~smb > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > > > -- to unsubscribe send a message to namedroppers-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 29 11:27:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh8KO-0008Br-O4 for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 11:27:39 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28680 for ; Tue, 29 Nov 2005 11:26:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eh8FI-000JFj-0k for namedroppers-data@psg.com; Tue, 29 Nov 2005 16:22:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Eh8FE-000JFS-6c for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 16:22:16 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id jATGHjaY010514 for ; Tue, 29 Nov 2005 11:17:45 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAExaaHu; Tue, 29 Nov 05 11:17:40 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id jATGJWbS012789; Tue, 29 Nov 2005 11:19:32 -0500 (EST) Date: Tue, 29 Nov 2005 11:19:31 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Edward Lewis cc: namedroppers@ops.ietf.org, =?ISO-8859-1?Q?Johan_Ihr=E9n?= Subject: Re: editorial comment on DNSEXT WG's Minimally Covering In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 28 Nov 2005, Edward Lewis wrote: > In this document, in section 2, there is this line: > > ).com 3600 IN NSEC +.com ( RRSIG NSEC ) > > The line should read > > \).com 3600 IN NSEC \+.com ( RRSIG NSEC ) > > Using the escape characters as defined in RFC 1035. > > A minor point - but the documentation of DNS records ought to > continue to follow this syntax. Thanks, Ed. I'll make sure we get this in AUTH48 if not before. -- 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 Tue Nov 29 12:18:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh97z-0007Rv-UA for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 12:18:52 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06600 for ; Tue, 29 Nov 2005 12:18:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eh95C-000MJz-MJ for namedroppers-data@psg.com; Tue, 29 Nov 2005 17:15:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Eh95B-000MJf-FK for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 17:15:57 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id jATHForI067704 for ; Tue, 29 Nov 2005 12:15:50 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id jATHFojT067703 for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 12:15:50 -0500 (EST) (envelope-from namedroppers) Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgrFQ-0009U9-2I for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 22:13:20 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 28 Nov 2005 14:13:20 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jASMCl6w004462; Mon, 28 Nov 2005 14:13:16 -0800 (PST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 17:13:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard] Date: Mon, 28 Nov 2005 17:13:09 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21E712B2@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard] Thread-Index: AcX0ZfMKgXh1lY8JS0CKC/cYOlvUpQAAUFKg From: "Bernie Volz \(volz\)" To: "Steven M. Bellovin" , "Ted Lemon" Cc: , , , "Pekka Savola" , X-OriginalArrivalTime: 28 Nov 2005 22:13:10.0538 (UTC) FILETIME=[EAF136A0:01C5F468] X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable [ 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. ] BTW, whatever algorithm you use (SHA-256 or even something much more complex) is not going to help -- it may make the work someone has to do a bit more involved, but it really doesn't make it impossible. 1. You always have a brute force attack. As you indicate, calculating the hash based on the mac address is always going to be a possible attack. And, 8000 is not 8-bits, but more like 13. But agreed that many of the Ethernet OIDs are unlikely to be of much interest. 2. If the attacker is on the same network as the client at some point, they can learn the identifier of the client (snoop DHCP and/or ARP traffic). Once they have that, it is possible to query DNS for DHCID RRs (query for the PTR, query for a DHCID RR for the name). Once you have that, you use the name and client's identity and run it through the algorithm and check for a match. If you looked up all 2^32 PTRs, you'd be able to locate the client at other sites that use DHCP and export the DHCID RR information. The number of PTRs you'd likely have to query is much smaller than 2^32s. You could target just some domains (network addresses) that you were most interested in or where you suspect the client connects to the network. Far reducing the number of queries needed. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Steven M. Bellovin > Sent: Monday, November 28, 2005 11:49 AM > To: Ted Lemon > Cc: iesg@ietf.org; dhcwg@ietf.org; namedroppers@ops.ietf.org;=20 > Pekka Savola; ietf@ietf.org > Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:=20 > 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed=20 > Standard]=20 >=20 > In message <200511261243.21694.mellon@fugue.com>, Ted Lemon writes: > >Making a hash function interchangeable in DHCID makes the=20 > conflict detection=20 > >algorithm hugely more complicated, and possibly not workable=20 > at all. Think=20 > >about how that would work. > > > I confess that I don't see the problem. The updater would do a DNS=20 > query for DHCID RRs; it would be given all of the stored=20 > records. The=20 > updater would then use local policy -- that is, an ordered list of=20 > preferred hash functions -- until it found one that was in the=20 > response. That one would be used. If no locally-known hash=20 > functions=20 > are in the list, it should behave as if there were no DHCID records=20 > present for that name. DNSSEC could protect against=20 > downgrade attacks. > (Speaking of which -- were I still AD, I'd ding this document for an > inadequate Security Considerations section -- apart from the=20 > lack of discussion of brute force attacks, you should cite=20 > 3833 for DNS=20 > attacks and explain what the risks are if someone can crack the hash=20 > function by any means, including brute force or eavesdropping on the=20 > wire or (perhaps) a misbehaving updater.) >=20 > If you don't agree, I'd strongly suggest using SHA-256=20 > instead of MD5. =20 > Yes, it's more expensive, but I doubt that that's a major hit on=20 > overall system performance here. It would also be useful to=20 > include in=20 > the document some discussion of upgrade strategy -- how would we ever=20 > switch to a new hash function? That's non-trivial even for protocols=20 > designed for agility, as Eric Rescorla and I have shown. No=20 > matter how=20 > it's done, this one is among the very hardest, since DNS=20 > servers would=20 > have to supply DHCID records for several hashes for a number of years. >=20 > --Steven M. Bellovin, http://www.cs.columbia.edu/~smb >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 29 12:19:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh98V-0007n5-UX for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 12:19:24 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06638 for ; Tue, 29 Nov 2005 12:18:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eh96N-000MQU-5R for namedroppers-data@psg.com; Tue, 29 Nov 2005 17:17:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Eh96M-000MQD-BY for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 17:17:10 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id jATHH4Kr067722 for ; Tue, 29 Nov 2005 12:17:04 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id jATHH46K067721 for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 12:17:04 -0500 (EST) (envelope-from namedroppers) Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EgsGT-0004ca-Bd for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 23:18:29 +0000 Received: by farside.isc.org (Postfix, from userid 10200) id CF31AE603D; Mon, 28 Nov 2005 23:18:28 +0000 (UTC) Date: Mon, 28 Nov 2005 23:18:28 +0000 From: "David W. Hankins" To: "Bernie Volz (volz)" Cc: Harald Tveit Alvestrand , "Steven M. Bellovin" , Ted Lemon , dhcwg@ietf.org, namedroppers@ops.ietf.org, Pekka Savola , ietf@ietf.org Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard] Message-ID: <20051128231828.GD19835@isc.org> References: <8E296595B6471A4689555D5D725EBB21E712BF@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8E296595B6471A4689555D5D725EBB21E712BF@xmb-rtp-20a.amer.cisco.com> User-Agent: Mutt/1.4.2.1i X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ 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 Mon, Nov 28, 2005 at 05:20:09PM -0500, Bernie Volz (volz) wrote: > Yes, I can. > > The ISC's DHCP server (www.isc.org) does this (I'm not sure whether it > uses MD5 to encode the client identity or not). Ted might know for sure. It does, though it only encodes the client identity (client identifier option or chaddr), it does not include the FQDN like the current DHCID draft does. There are a few niggling bits that are different, and obviously incompatible (not just because it's encoded as hexadecimal in a TXT record), but on all points that are topical to this discussion it's the same. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -- to unsubscribe send a message to namedroppers-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 29 12:18:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh97Z-0006dT-M4 for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 12:18:30 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06561 for ; Tue, 29 Nov 2005 12:17:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eh94r-000MID-RA for namedroppers-data@psg.com; Tue, 29 Nov 2005 17:15:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Eh94q-000MHr-OJ for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 17:15:37 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id jATHFSvj067698 for ; Tue, 29 Nov 2005 12:15:28 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id jATHFS5i067697 for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 12:15:28 -0500 (EST) (envelope-from namedroppers) Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Egr3H-00081R-Ip for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 22:00:47 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 Nov 2005 17:00:47 -0500 X-IronPort-AV: i="3.97,385,1125892800"; d="scan'208"; a="76646322:sNHT25709568" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jASM0AmF027293; Mon, 28 Nov 2005 17:00:44 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 17:00:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard] Date: Mon, 28 Nov 2005 17:00:39 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21E712A4@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard] Thread-Index: AcX0ZfMKgXh1lY8JS0CKC/cYOlvUpQAAIFAw From: "Bernie Volz \(volz\)" To: "Steven M. Bellovin" , "Ted Lemon" Cc: , , , "Pekka Savola" , X-OriginalArrivalTime: 28 Nov 2005 22:00:42.0025 (UTC) FILETIME=[2CCB3190:01C5F467] X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] > I confess that I don't see the problem. The updater would do a DNS=20 > query for DHCID RRs; it would be given all of the stored=20 > records. That's not how the current update algorithm works. Sure, we could do almost anything but we'll be debating this for the next 100 years. It has already gone on for almost 10 years!!! Can we get serious about this and really ask what are we trying to protect. And where were you folks when IPv6 was designed to use the mac address as the interface identifier. Come on. We're trying to make it NON-TRIVIAL, not impossible. This technique has been in use for years by implementations using TXT records because we've been unable to get the DHCID RR approved. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Steven M. Bellovin > Sent: Monday, November 28, 2005 11:49 AM > To: Ted Lemon > Cc: iesg@ietf.org; dhcwg@ietf.org; namedroppers@ops.ietf.org;=20 > Pekka Savola; ietf@ietf.org > Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:=20 > 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed=20 > Standard]=20 >=20 > In message <200511261243.21694.mellon@fugue.com>, Ted Lemon writes: > >Making a hash function interchangeable in DHCID makes the=20 > conflict detection=20 > >algorithm hugely more complicated, and possibly not workable=20 > at all. Think=20 > >about how that would work. > > > I confess that I don't see the problem. The updater would do a DNS=20 > query for DHCID RRs; it would be given all of the stored=20 > records. The=20 > updater would then use local policy -- that is, an ordered list of=20 > preferred hash functions -- until it found one that was in the=20 > response. That one would be used. If no locally-known hash=20 > functions=20 > are in the list, it should behave as if there were no DHCID records=20 > present for that name. DNSSEC could protect against=20 > downgrade attacks. > (Speaking of which -- were I still AD, I'd ding this document for an > inadequate Security Considerations section -- apart from the=20 > lack of discussion of brute force attacks, you should cite=20 > 3833 for DNS=20 > attacks and explain what the risks are if someone can crack the hash=20 > function by any means, including brute force or eavesdropping on the=20 > wire or (perhaps) a misbehaving updater.) >=20 > If you don't agree, I'd strongly suggest using SHA-256=20 > instead of MD5. =20 > Yes, it's more expensive, but I doubt that that's a major hit on=20 > overall system performance here. It would also be useful to=20 > include in=20 > the document some discussion of upgrade strategy -- how would we ever=20 > switch to a new hash function? That's non-trivial even for protocols=20 > designed for agility, as Eric Rescorla and I have shown. No=20 > matter how=20 > it's done, this one is among the very hardest, since DNS=20 > servers would=20 > have to supply DHCID records for several hashes for a number of years. >=20 > --Steven M. Bellovin, http://www.cs.columbia.edu/~smb >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 29 12:18:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh97k-00075Z-GZ for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 12:18:36 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06584 for ; Tue, 29 Nov 2005 12:17:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eh95z-000MON-Hq for namedroppers-data@psg.com; Tue, 29 Nov 2005 17:16:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Eh95x-000MO5-RD for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 17:16:46 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id jATHGbWi067716 for ; Tue, 29 Nov 2005 12:16:37 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id jATHGbQP067715 for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 12:16:37 -0500 (EST) (envelope-from namedroppers) Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgriR-0000tM-5K for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 22:43:20 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 28 Nov 2005 17:43:19 -0500 X-IronPort-AV: i="3.97,385,1125892800"; d="scan'208"; a="76648847:sNHT29186020" 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 jASMgseD026681; Mon, 28 Nov 2005 17:43:16 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 17:43:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard] Date: Mon, 28 Nov 2005 17:43:13 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21E712CC@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard] Thread-Index: AcX0ZLv+hsPzGP3RSkSozhMfHLeeGgAB4/hQ From: "Bernie Volz \(volz\)" To: "Steven M. Bellovin" , "Pekka Savola" Cc: , , , X-OriginalArrivalTime: 28 Nov 2005 22:43:14.0198 (UTC) FILETIME=[1E01E360:01C5F46D] X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable [ 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. ] BTW: Just to be clear, the MD5 hash is calculated using both the client identifier AND the domain name. But the domain name is known (it is the entry under which the DHCID RR lives). However, this means that the DHCID data for a client changes with its name. The RDATA for all type codes other than 0xffff, which is reserved for future expansion, is formed by concatenating the two type bytes and a 16-byte MD5 hash value. The input to the hash function is defined to be: data =3D MD5(< identifier > < FQDN >) The FQDN is represented in the buffer in unambiguous canonical form as described in RFC 2535 [8], section 8.1. The type code and the identifier are related as specified in Section 3.3: the type code describes the source of the identifier. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Steven M. Bellovin > Sent: Saturday, November 26, 2005 11:57 AM > To: Pekka Savola > Cc: dhcwg@ietf.org; namedroppers@ops.ietf.org; iesg@ietf.org;=20 > ietf@ietf.org > Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:=20 > 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed=20 > Standard]=20 >=20 > In message ,=20 > Pekka Savola writes: > >Hi, > > > >I'll break out the most substantial comments in separate messages.. > > > >On Mon, 14 Nov 2005, The IESG wrote: > >> The IESG has received a request from the Dynamic Host=20 > Configuration WG to > >> consider the following documents: > >> > >> - 'A DNS RR for Encoding DHCP Information (DHCID RR) ' > >> as a Proposed Standard > >> - 'Resolution of FQDN Conflicts among DHCP Clients ' > >> as a Proposed Standard > >> - 'The DHCP Client FQDN Option ' > >> as a Proposed Standard > >> - 'The DHCPv6 Client FQDN Option ' > >> as a Proposed Standard > > > >I have only one major comment on DHCID on its use of MD5 as a=20 > >glued-in hash-function. The rest of the comments are rather=20 > >straightforward. > > > >substantial > >---------- > > > > In order to avoid exposing potentially sensitive identifying > > information, the data stored is the result of a one-way=20 > MD5 [5] hash > > computation. The hash includes information from the=20 > DHCP client's > > REQUEST message as well as the domain name itself, so=20 > that the data > > stored in the DHCID RR will be dependent on both the client > > identification used in the DHCP protocol interaction and=20 > the domain > > name. This means that the DHCID RDATA will vary if a=20 > single client > > is associated over time with more than one name. This makes it > > difficult to 'track' a client as it is associated with=20 > various domain > > names. > > > > The MD5 hash algorithm has been shown to be weaker than the SHA-1 > > algorithm; it could therefore be argued that SHA-1 is a better > > choice. However, SHA-1 is significantly slower than MD5. A > > successful attack of MD5's weakness does not reveal the=20 > original data > > that was used to generate the signature, but rather=20 > provides a new > > set of input data that will produce the same signature. =20 > Because we > > are using the MD5 hash to conceal the original data, the=20 > fact that an > > attacker could produce a different plaintext resulting=20 > in the same > > MD5 output is not significant concern. > > > >=3D=3D> while the informatione exposure of someone cracking the MD5 = hash=20 > >is not too huge, I believe it is unacceptable to design new=20 > protocols=20 > >without the capability to switch the hash function as need be. This=20 > >could be achieved for example by reserving one additional byte from=20 > >the start of the DHCID record to designate the hash function used.=20 > >If you don't bother to define your own registry (for all of me, you=20 > >could include MD5 there as well, but at least include SHA1 and=20 > >preferably also SHA-256), you could possibly re-use=20 > >http://www.iana.org/assignments/ds-rr-types or something like that. > > > >That way, we can introduce new hash functions in a backward=20 > compatible=20 > >manner later on, with no need to revamp the protocol. > > > >If we don't do this, we'll need to define DHCID2, DHCID3, .. etc.=20 > >records further down in the future (w/ different hash functions) and=20 > >make DHCP co-exist with all of them. That's bound to cause a lot of=20 > >protocol complexity, and I don't think we want to go there. >=20 > I agree with this comment. The draft is wrong -- it asserts that a > "successful attack of MD5's weakness does not reveal the=20 > original data". > That's an overassumption -- we have no idea what such an attack would=20 > yield, since no such attack currently exists. >=20 > More generally... The currently-known attacks on MD5 are collision=20 > attacks: it's possible to generate two inputs that produce the same=20 > hash value. This scenario requires a preimage attack; none are known. > It would not surprise me if someone were to develop one, but=20 > until that=20 > happens we can't speculate on its properties. There are,=20 > however, some=20 > reasons for concern. One of the options defined, the DHCPv4 Client=20 > Identifier, probably doesn't have much entropy. For example, a=20 > suggestion in RFC 2132 says to use the ARP hardware type code and MAC=20 > address. There's exactly one interesting hardware type code for most > users, and the high-order 3 bytes of the MAC address are the=20 > manufacturer's ID, not many of which are actually used. Given that=20 > this is an 8-byte input string and that MD5 has an 8-byte=20 > output, it is=20 > plausible that comparatively few input strings hash to any=20 > given output. > If several of the input bytes are fixed, or at least=20 > constrained, there=20 > may be only one. For that matter, that assumption alone may=20 > lead to a=20 > successful attack on MD5.=20 >=20 > In fact, the Security Considerations section should analyze the=20 > (non-trivial) probability of a brute-force attack. Again,=20 > consider the=20 > Client Identifier, which is likely 8 bytes long. 2 are fixed, and=20 > hence irrelevant. According to today's copy of > http://standards.ieee.org/regauth/oui/oui.txt there are 8786=20 > manufacturer IDs, or slightly more than 8 bits. Effectively, though,=20 > it's less, since the usage is very non-uniform. Even if is uniform,=20 > though, that field plus the unit identifier only total=20 > slightly over 32=20 > bits -- well within anyone's capabilities. >=20 > Most of this analysis applies to the other two options as well. >=20 > --Steven M. Bellovin, http://www.cs.columbia.edu/~smb >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 29 12:19:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh98o-0007on-6J for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 12:19:42 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06650 for ; Tue, 29 Nov 2005 12:18:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eh977-000MX1-3U for namedroppers-data@psg.com; Tue, 29 Nov 2005 17:17:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Eh974-000MW6-BF for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 17:17:54 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id jATHHlcV067728 for ; Tue, 29 Nov 2005 12:17:47 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id jATHHl5X067727 for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 12:17:47 -0500 (EST) (envelope-from namedroppers) Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Egvjq-000OC3-6b for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 03:01:02 +0000 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id jAT30ifw008543; Mon, 28 Nov 2005 19:00:44 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 28 Nov 2005 19:00:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard] Date: Mon, 28 Nov 2005 19:00:43 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD377C2612@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard] Thread-Index: AcX0ZfMKgXh1lY8JS0CKC/cYOlvUpQAAIFAwAAFvOpA= From: "Hallam-Baker, Phillip" To: "Bernie Volz \(volz\)" , "Steven M. Bellovin" , "Ted Lemon" Cc: , "Pekka Savola" , , , X-OriginalArrivalTime: 29 Nov 2005 03:00:43.0838 (UTC) FILETIME=[16B5DDE0:01C5F491] X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On=20 > Behalf Of Bernie Volz (volz) > This technique has been in use for years by implementations=20 > using TXT records because we've been unable to get the DHCID=20 > RR approved. OK so why are you proposing a new protocol rather than writing a description of the protocols that are already in use? Correctly prefixed TXT records work just as well as new RRs and are completely compatible with the deployed infrastructure. If you attempt to cut new DNS RRs you will hit the problem that your proposal is now dependent on deployment of a new infrastructure which has no deployment strategy. Lets get back to the idea that a standard is a description of running code. The DNS group has become a bottleneck for deployment of a lot of technology. This should not be acceptable. There is a fundamental extensibility flaw in DNS, new RRs must be understood by the sender, receiver and intermediate infrastructure. The DNSEXT group appears to believe that their objectives should be to create as much of an incentive to upgrade to DNSSEC capable infrastructure as possible and that the way to do this is to gate all proposed uses of the DNS on cutting a new RR. This is not a good strategy, DNSSEC is a double ended adoption problem, the problem is not that the promise of DNSSEC is insufficient incentive for deployment, the problem is that early adopter deployment of DNSSEC has negligible incentive. The Pareto optimal solution here is for the IAB to specify a method of introducing new features that use the DNS that is entirely compatible with deployed DNS infrastructure. These in turn create new dependencies on the DNS that create a near term demand for DNSSEC and an early adopter incentive. The DNSSEC people get an early adopter market for their proposal, people looking to extend the DNS can do so without committing error 33.=20 For example one of the discussions in DKIM is on what to do with the ESTG vehicle set up for early development. The idea that most people seem to think is a good one is to turn it into a branding vehicle similar to WiFi. So that just as people advertise that their product is WiFi compatible to mean 'yes it really works' there would be an ESTG brand that a registrar could use to say 'yes I do provide the services necessary to support DKIM signed email'. This then leads naturally to the question of levels of support, a level 1 registrar might do the bare minimum necessary to support DKIM (allow the relevant records to be defined), the requirements for level 2 might well include support for DNSSEC (at least I would argue that they should require DNSSEC support). -- to unsubscribe send a message to namedroppers-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 29 12:20:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh996-00084A-O3 for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 12:20:01 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06728 for ; Tue, 29 Nov 2005 12:19:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eh97P-000MaN-Na for namedroppers-data@psg.com; Tue, 29 Nov 2005 17:18:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Eh97O-000Ma0-Pl for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 17:18:15 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id jATHI74A067734 for ; Tue, 29 Nov 2005 12:18:08 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id jATHI7eA067733 for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 12:18:07 -0500 (EST) (envelope-from namedroppers) Received: from [147.28.0.16] (helo=machshav.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1Egxcz-0007Od-E8 for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 05:02:05 +0000 Received: by machshav.com (Postfix, from userid 512) id 38B25FB283; Tue, 29 Nov 2005 00:02:05 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3E638FB27D; Tue, 29 Nov 2005 00:02:04 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id EAA973C0139; Tue, 29 Nov 2005 00:02:02 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Ted Lemon Cc: dhcwg@ietf.org, Pekka Savola , namedroppers@ops.ietf.org, iesg@ietf.org, ietf@ietf.org Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard] In-Reply-To: (Your message of "Mon, 28 Nov 2005 21:50:00 MST.") <200511282150.01493.Ted.Lemon@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 29 Nov 2005 00:02:02 -0500 Message-Id: <20051129050202.EAA973C0139@berkshire.machshav.com> X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ 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. ] In message <200511282150.01493.Ted.Lemon@nominum.com>, Ted Lemon writes: >On Saturday 26 November 2005 09:56, Steven M. Bellovin wrote: >> In fact, the Security Considerations section should analyze the >> (non-trivial) probability of a brute-force attack. > >It doesn't matter. The point of the DHCID is to allow two servers to avoid >accidentally stepping on each other. If you break the DHCID, what you get >is the ability to pretend that you are another DHCP client. If you succeed >in doing this, you can take over that DHCP client's name, but you don't get >to keep it, because you are using the same identification as the other >client, and so it's going to take it back. The information that you would >use to pretend to be the other client is routinely being sent over the >network in the clear, so you don't need to break the DHCID to get it - you >just need to listen on the wire for a packet from that client. You can't do >the attack I've described unless you are on a network managed by a DHCP >server that manages the same namespace as the server that put in the >legitimate DHCID. > >It's true that we could exhaustively go over all possible exploits, no matter >how trivial, no matter how useless, in the security considerations section. >Do you honestly believe that this is necessary? > It's the privacy aspect I'm concerned about. The protocol has a mechanism -- the hash -- intended to protect privacy. There are limitations to how well it works. These may be unavoidable; that said, they should be documented. See Section 5 of RFC 3552, a BCP: Authors MUST describe 1. which attacks are out of scope (and why!) 2. which attacks are in-scope 2.1 and the protocol is susceptible to 2.2 and the protocol protects against ... There should be a clear description of the residual risk to the user or operator of that protocol after threat mitigation has been deployed. Put another way, against a certain grade of attacker the mechanism doesn't do its job. That needs to be documented, so that people who are concerned about the issue know to avoid this option. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb -- to unsubscribe send a message to namedroppers-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 29 12:23:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh9C5-0002Gp-UT for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 12:23:06 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07497 for ; Tue, 29 Nov 2005 12:22:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1Eh95X-000ML0-D8 for namedroppers-data@psg.com; Tue, 29 Nov 2005 17:16:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1Eh95V-000MKb-6v for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 17:16:17 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id jATHGAit067710 for ; Tue, 29 Nov 2005 12:16:10 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id jATHGAiX067709 for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 12:16:10 -0500 (EST) (envelope-from namedroppers) Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EgrM9-000ASo-P6 for namedroppers@ops.ietf.org; Mon, 28 Nov 2005 22:20:17 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 28 Nov 2005 14:20:17 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jASMKDCP010949; Mon, 28 Nov 2005 14:20:17 -0800 (PST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 17:20:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard] Date: Mon, 28 Nov 2005 17:20:09 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21E712BF@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard] Thread-Index: AcX0aMLK64S8IV+uSmKL3bUvuhGOTgAAEz1Q From: "Bernie Volz \(volz\)" To: "Harald Tveit Alvestrand" , "Steven M. Bellovin" , "Ted Lemon" Cc: , "Pekka Savola" , , X-OriginalArrivalTime: 28 Nov 2005 22:20:10.0657 (UTC) FILETIME=[E55A4910:01C5F469] X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable [ 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. ] Harald: Yes, I can. The ISC's DHCP server (www.isc.org) does this (I'm not sure whether it uses MD5 to encode the client identity or not). Ted might know for sure. As does Cisco's Network Registrar (though it presently doesn't encode the data using MD5).=20 And, I'm pretty sure several other DHCP vendors do this -- though whether they're using MD5 or not I can't be sure. These servers are in production all over and have been doing this for many years. - Bernie > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no]=20 > Sent: Monday, November 28, 2005 5:14 PM > To: Bernie Volz (volz); Steven M. Bellovin; Ted Lemon > Cc: dhcwg@ietf.org; Pekka Savola; ietf@ietf.org;=20 > namedroppers@ops.ietf.org > Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last=20 > Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to=20 > Proposed Standard]=20 >=20 >=20 >=20 > --On mandag, november 28, 2005 17:00:39 -0500 "Bernie Volz (volz)"=20 > wrote: >=20 > >> I confess that I don't see the problem. The updater would do a DNS > >> query for DHCID RRs; it would be given all of the stored > >> records. > > > > That's not how the current update algorithm works. Sure, we could do > > almost anything but we'll be debating this for the next 100=20 > years. It > > has already gone on for almost 10 years!!! > > > > Can we get serious about this and really ask what are we trying to > > protect. > > > > And where were you folks when IPv6 was designed to use the=20 > mac address > > as the interface identifier. Come on. > > > > We're trying to make it NON-TRIVIAL, not impossible. > > > > This technique has been in use for years by implementations=20 > using TXT > > records because we've been unable to get the DHCID RR approved. >=20 > Bernie, >=20 > just checking.... > this puzzle seems to have several distinct pieces: >=20 > - the DHCP options to talk about DNS names. Nobody seems to=20 > have any large=20 > problem with that. > - the mechanism for detecting conflicts. Nobody seems to have=20 > any large=20 > problem with that. > - the exact mechanism by which one stores a value identifying=20 > the client in=20 > the DNS without giving out useful information about the=20 > client. That's=20 > where all the shouting is. >=20 > Can you verify for me that all three parts are being done today in=20 > production, in just the way (apart from RR type) specified in=20 > the I-Ds? >=20 > Harald >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 29 14:50:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhBV9-0006zz-EY for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 14:50:55 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26322 for ; Tue, 29 Nov 2005 14:50:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhBRy-0006pL-3Q for namedroppers-data@psg.com; Tue, 29 Nov 2005 19:47:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [64.142.16.245] (helo=a.mail.sonic.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.54 (FreeBSD)) id 1EhBRx-0006p7-EO for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 19:47:37 +0000 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id jATJlaun000395 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 29 Nov 2005 11:47:36 -0800 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Samuel Weiler Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: draft-ietf-dnsext-dnssec-online-signing-00 Date: Tue, 29 Nov 2005 11:47:51 -0800 To: Namedroppers X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In the Security Consideration section, There was no advice given on avoiding a timing-attack. Essentially, the time required to sign a reply should not provide clues related to the underlying private-key. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 29 17:11:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhDhA-0002jc-2v for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 17:11:28 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16648 for ; Tue, 29 Nov 2005 17:10:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhDeT-000Fza-Ai for namedroppers-data@psg.com; Tue, 29 Nov 2005 22:08:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EhDeS-000FzC-1h for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 22:08:40 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 6E7CE33C40 for ; Tue, 29 Nov 2005 22:08:38 +0000 (GMT) Message-ID: <438CD16E.3000307@algroup.co.uk> Date: Tue, 29 Nov 2005 22:08:46 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Namedroppers Subject: Re: draft-ietf-dnsext-dnssec-online-signing-00 References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Douglas Otis wrote: > In the Security Consideration section, > > There was no advice given on avoiding a timing-attack. Essentially, the > time required to sign a reply should not provide clues related to the > underlying private-key. For non-crypto folk thinking "wtf?", here's a reference: http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html. OpenSSL defends against this by default, but I guess that's not universally true. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 29 20:07:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhGRy-0003W8-Gw for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 20:07:58 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06368 for ; Tue, 29 Nov 2005 20:07:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhGO5-000PNn-Kc for namedroppers-data@psg.com; Wed, 30 Nov 2005 01:03:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EhGO3-000PNa-2I for namedroppers@ops.ietf.org; Wed, 30 Nov 2005 01:03:55 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id AC03611D412; Tue, 29 Nov 2005 17:03:54 -0800 (PST) From: Wes Hardaker To: Samuel Weiler Cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ds-sha256-00.txt Organization: Sparta References: <6.2.5.6.2.20051116235002.04170e60@ogud.com> Date: Tue, 29 Nov 2005 17:03:53 -0800 In-Reply-To: (Samuel Weiler's message of "Sun, 27 Nov 2005 11:48:51 -0500 (EST)") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On Sun, 27 Nov 2005 11:48:51 -0500 (EST), Samuel Weiler said: >> I don't think that a bis-update that includes a new mandatory >> algorithm is truly a good way to go forward, as it would require >> cycling at proposed. I'm not sure the rest of the bis-update thought >> would require that. Samuel> It sounds like we may be talking about different things: I'm not Samuel> talking about adding this new digest algorithm to bis-updates. I'm Samuel> suggesting that the ds-sha256 doc refer to the discussion in Samuel> bis-updates of handling unknown digest algorithms. I don't think referencing a document that has no timeline associated with it would be a good thing... Samuel> Another option, and one which avoids a reference to Samuel> bis-updates, is to include text in ds-sha256 similar to what's Samuel> in bis-updates section 3.2 Samuel> -- make this doc, in addition to defining a new digest algorithm, Samuel> explicitly tell resolvers what to do when they see an unknown (or Samuel> unsupported/disabled) one. I could copy it if there is consensus to do so, but I think it'd be better to define it without a huge amount of discussion and let that be defined in the bis-update when it's published. -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From ryan_panos@archiveguide.com Tue Nov 29 20:36:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhGt6-0006NE-La for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 20:36:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08600 for ; Tue, 29 Nov 2005 20:35:15 -0500 (EST) Received: from user-0ccegpd.cable.mindspring.com ([24.199.67.45] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EhHDF-0006N5-BQ for dnsext-archive@ietf.org; Tue, 29 Nov 2005 20:56:51 -0500 Message-ID: <000001c5f54d$17c4fd80$0100007f@localhost> From: "Jimmy Jones" To: Subject: Buy OEM Software Date: Tue, 29 Nov 2005 20:35:48 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C5F54D.17C4FD80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5F54D.17C4FD80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 36 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 44 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 42 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C5F54D.17C4FD80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    ! Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 35 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: ! $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 48 reviews)

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 35 reviews)

------=_NextPart_000_0001_01C5F54D.17C4FD80-- From owner-namedroppers@ops.ietf.org Tue Nov 29 23:12:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhJKf-0007CW-6z for dnsext-archive@megatron.ietf.org; Tue, 29 Nov 2005 23:12:39 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21339 for ; Tue, 29 Nov 2005 23:11:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhJHP-0009JA-8U for namedroppers-data@psg.com; Wed, 30 Nov 2005 04:09:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EhJHO-0009Iv-9V for namedroppers@ops.ietf.org; Wed, 30 Nov 2005 04:09:14 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id jAU493x8070507 for ; Tue, 29 Nov 2005 23:09:03 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id jAU492lp070506 for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 23:09:02 -0500 (EST) (envelope-from namedroppers) Received: from [18.188.3.148] (helo=carter-zimmerman.mit.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EhBSS-0006qb-13 for namedroppers@ops.ietf.org; Tue, 29 Nov 2005 19:48:08 +0000 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id AC9E8E0073; Tue, 29 Nov 2005 14:47:49 -0500 (EST) To: Mark Stapp Cc: "Steven M. Bellovin" , namedroppers@ops.ietf.org, Pekka Savola , Ted Lemon , iesg@ietf.org, dhcwg@ietf.org, ietf@ietf.org Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard] References: <20051129050202.EAA973C0139@berkshire.machshav.com> <438C6431.7090808@cisco.com> From: Sam Hartman Date: Tue, 29 Nov 2005 14:47:49 -0500 In-Reply-To: <438C6431.7090808@cisco.com> (Mark Stapp's message of "Tue, 29 Nov 2005 09:22:41 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ 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. ] >>>>> "Mark" == Mark Stapp writes: Mark> would such a clarification be "enough" to resolve your Mark> DISCUSS, Sam Hartman? that is, if it were clearer that we're Mark> only aiming for more difficult than not difficult at all - Mark> would that be sufficiently clear guidance to admins about Mark> what they should expect from this mechanism? So, as I described in my response to Russ, I'm asking for three things: 1) algorithm agility 2) Remove the paragraph explaining why md5 is OK or provide a theoretical model under which we can reason about how good a hash is at keeping stuff private. 3) Use sha-1 or sha-256 instead of md5. I feel very strongly about point 1. Unfortunately I think this is the point the working group most objects to. I understand the concerns about the complexity of the update process. However I also know that security primitives are things that you need to replace from time to time. If you were using md5 because it had a relatively even distribution of outputs you could probably convince me that you don't need a way to update it. However even if weakly you're using md5 for its cryptographic properties. Those can change over time so you need a mechanism to react to those changes. I suspect we can all agree that we need to either reword claims about security of cryptographic primitives so they are clearly true or remove those claims. So I don't think that we're going to have much of an issue with point 2. I think there is room for discussion on point 3. I think sha-1 or sha-256 would be a better choice. I think that there is an argument that md5 is not so bad that it cannot be used. If the working group ends up responding that it would really like to use md5, I can go to the security community and see what people think there. --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 Wed Nov 30 04:42:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhOUG-0000Qd-K7 for dnsext-archive@megatron.ietf.org; Wed, 30 Nov 2005 04:42:52 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21513 for ; Wed, 30 Nov 2005 04:42:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhOP5-0001p5-AN for namedroppers-data@psg.com; Wed, 30 Nov 2005 09:37:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EhOP2-0001jN-1S for namedroppers@ops.ietf.org; Wed, 30 Nov 2005 09:37:28 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1EhONF-0006Wv-Mn for namedroppers@ops.ietf.org; Wed, 30 Nov 2005 10:35:37 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.54) id 1EhOND-0003eV-KZ for namedroppers@ops.ietf.org; Wed, 30 Nov 2005 10:35:35 +0100 From: Florian Weimer To: namedroppers@ops.ietf.org Subject: EDNS0 traffic amplification attacks in the wild Date: Wed, 30 Nov 2005 10:35:35 +0100 Message-ID: <87mzjmcwbc.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk There are some reorts on BUGTRAQ which indicate that open resolvers with EDNS0 support are now abused for traffic amplification purposes: (The posted packet capture contains an OPT RR with a buffer size of 10000.) I know that people generally think this is a non-issue because you should offer resolver service to the Internet at large anyway, but I'm reporting this here in case anyone is working on RFC 2671bis and wants to include an updated Security Considerations 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 Wed Nov 30 05:46:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhPU3-0004Dh-14 for dnsext-archive@megatron.ietf.org; Wed, 30 Nov 2005 05:46:43 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27472 for ; Wed, 30 Nov 2005 05:45:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhPRZ-0005VO-9J for namedroppers-data@psg.com; Wed, 30 Nov 2005 10:44:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EhPRY-0005VC-9i for namedroppers@ops.ietf.org; Wed, 30 Nov 2005 10:44:08 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 6DF68E6034 for ; Wed, 30 Nov 2005 10:44:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id jAUAhpVA030448; Wed, 30 Nov 2005 21:43:51 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200511301043.jAUAhpVA030448@drugs.dv.isc.org> To: Florian Weimer Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: EDNS0 traffic amplification attacks in the wild In-reply-to: Your message of "Wed, 30 Nov 2005 10:35:35 BST." <87mzjmcwbc.fsf@mid.deneb.enyo.de> Date: Wed, 30 Nov 2005 21:43:51 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > There are some reorts on BUGTRAQ which indicate that open resolvers > with EDNS0 support are now abused for traffic amplification purposes: > > > > (The posted packet capture contains an OPT RR with a buffer size of > 10000.) > > I know that people generally think this is a non-issue because you > should offer resolver service to the Internet at large anyway, but I'm > reporting this here in case anyone is working on RFC 2671bis and wants > to include an updated Security Considerations section. Just another reason to deploy BCP38 everywhere. -- 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 30 08:59:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhSUM-0007We-Ke for dnsext-archive@megatron.ietf.org; Wed, 30 Nov 2005 08:59:14 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18720 for ; Wed, 30 Nov 2005 08:58:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhSQM-000HTr-MY for namedroppers-data@psg.com; Wed, 30 Nov 2005 13:55:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EhSQL-000HTZ-Sv for namedroppers@ops.ietf.org; Wed, 30 Nov 2005 13:55:06 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id jAUDsvAS072796; Wed, 30 Nov 2005 08:54:58 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200511301043.jAUAhpVA030448@drugs.dv.isc.org> References: <200511301043.jAUAhpVA030448@drugs.dv.isc.org> Date: Wed, 30 Nov 2005 08:53:37 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: EDNS0 traffic amplification attacks in the wild Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 21:43 +1100 11/30/05, Mark Andrews wrote: > Just another reason to deploy BCP38 everywhere. I've already tried to ask the RFC editor to make it easier to find the BCPs (e.g., putting a link on their home page to a list of them). One answer I was given was "if you know the RFC number, just look that up." So, in that spirit, what is the RFC number of BCP38? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store. -- to unsubscribe send a message to namedroppers-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 30 09:51:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhTIv-0002OL-5k for dnsext-archive@megatron.ietf.org; Wed, 30 Nov 2005 09:51:29 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25851 for ; Wed, 30 Nov 2005 09:50:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhTG2-000L3z-FP for namedroppers-data@psg.com; Wed, 30 Nov 2005 14:48:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EhTG1-000L3l-GK for namedroppers@ops.ietf.org; Wed, 30 Nov 2005 14:48:29 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1EhTFz-0006x2-6j for namedroppers@ops.ietf.org; Wed, 30 Nov 2005 15:48:27 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.54) id 1EhTFy-00057p-4A for namedroppers@ops.ietf.org; Wed, 30 Nov 2005 15:48:26 +0100 From: Florian Weimer To: namedroppers@ops.ietf.org Subject: Re: EDNS0 traffic amplification attacks in the wild References: <200511301043.jAUAhpVA030448@drugs.dv.isc.org> Date: Wed, 30 Nov 2005 15:48:26 +0100 In-Reply-To: (Edward Lewis's message of "Wed, 30 Nov 2005 08:53:37 -0500") Message-ID: <87lkz65gzp.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * Edward Lewis: > At 21:43 +1100 11/30/05, Mark Andrews wrote: > >> Just another reason to deploy BCP38 everywhere. > > I've already tried to ask the RFC editor to make it easier to find > the BCPs (e.g., putting a link on their home page to a list of them). works quite well. Just enter "BCP38" in the search field. > One answer I was given was "if you know the RFC number, just look > that up." So, in that spirit, what is the RFC number of BCP38? From the context, it's likely that Mark means the RFC on ingress filtering. 8-P -- to unsubscribe send a message to namedroppers-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 30 12:47:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhW3Q-0001Nb-Jr for dnsext-archive@megatron.ietf.org; Wed, 30 Nov 2005 12:47:40 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16605 for ; Wed, 30 Nov 2005 12:46:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhVyo-000737-8E for namedroppers-data@psg.com; Wed, 30 Nov 2005 17:42:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.54 (FreeBSD)) id 1EhVyl-00072o-DI for namedroppers@ops.ietf.org; Wed, 30 Nov 2005 17:42:51 +0000 Received: from [66.93.162.226] (lam.fugue.com [66.93.162.226]) by toccata.fugue.com (Postfix) with ESMTP id 9B9741B204D; Wed, 30 Nov 2005 10:42:50 -0700 (MST) From: Ted Lemon Organization: Nominum, Inc. To: Sam Hartman Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard] Date: Wed, 30 Nov 2005 10:42:48 -0700 User-Agent: KMail/1.9 Cc: "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org, "Bernie Volz (volz)" , dhcwg@ietf.org, "Steven M. Bellovin" , Pekka Savola References: <198A730C2044DE4A96749D13E167AD377C2612@MOU1WNEXMB04.vcorp.ad.vrsn.com> <200511282136.06370.Ted.Lemon@nominum.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511301042.49489.Ted.Lemon@nominum.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 30 November 2005 01:51, Sam Hartman wrote: > Phil is suggesting something like _dhcid.domain . This is why it's so important to read the drafts carefully, and in detail, to the point where you understand how the protocol works, and only then consider proposing changes to it. Because of the way the protocol uses DNS update prerequisites, that can't work. And the way the protocol uses DNS update prerequisites is required to get the functionality that we want. -- to unsubscribe send a message to namedroppers-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 30 15:27:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYY6-00079o-Fl for dnsext-archive@megatron.ietf.org; Wed, 30 Nov 2005 15:27:30 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09122 for ; Wed, 30 Nov 2005 15:26:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.54 (FreeBSD)) id 1EhYUk-000J09-Rh for namedroppers-data@psg.com; Wed, 30 Nov 2005 20:24:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EhYUk-000Izx-A7 for namedroppers@ops.ietf.org; Wed, 30 Nov 2005 20:24:02 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id BCA72E6047 for ; Wed, 30 Nov 2005 20:24:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id jAUKNpw0036699; Thu, 1 Dec 2005 07:23:52 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200511302023.jAUKNpw0036699@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: EDNS0 traffic amplification attacks in the wild In-reply-to: Your message of "Wed, 30 Nov 2005 08:53:37 CDT." Date: Thu, 01 Dec 2005 07:23:51 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 21:43 +1100 11/30/05, Mark Andrews wrote: > > > Just another reason to deploy BCP38 everywhere. > > I've already tried to ask the RFC editor to make it easier to find > the BCPs (e.g., putting a link on their home page to a list of them). > One answer I was given was "if you know the RFC number, just look > that up." So, in that spirit, what is the RFC number of BCP38? The RFC editor should have known better. Google for it :-) Network Working Group P. Ferguson Request for Comments: 2827 Cisco Systems, Inc. Obsoletes: 2267 D. Senie BCP: 38 Amaranth Networks Inc. Category: Best Current Practice May 2000 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing -- 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: