From owner-namedroppers@ops.ietf.org Sat Jun 1 02:04:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16209 for ; Sat, 1 Jun 2002 02:04:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17E1bK-0001tx-00 for namedroppers-data@psg.com; Fri, 31 May 2002 22:38:54 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17E1bJ-0001tm-00 for namedroppers@ops.ietf.org; Fri, 31 May 2002 22:38:53 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17E1bJ-0002Hb-00 for namedroppers@ops.ietf.org; Fri, 31 May 2002 22:38:53 -0700 Message-Id: <200205311934.TAA02939@vacation.karoshi.com> In-Reply-To: <20020531191908.Q2453-100000@padda.telia.net> from "Mats Dufberg" at May 31, 2002 07:20:38 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: bmanning@karoshi.com Subject: Re: A6/DNAME - game over To: dufberg@telia.net (Mats Dufberg) Date: Fri, 31 May 2002 19:34:06 +0000 (UCT) Cc: bmanning@ISI.EDU (Bill Manning), paul@vix.com (Paul Vixie), namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] My comment was based on Pauls subject: A6/DNAME A6 status seems pretty clear, I've not seen that DNAME will go to experimental or historic.... > > On May 31, 2002, 08:03 (-0700) Bill Manning wrote: > > > Humph. A6/DNAME are being moved to -EXPERIMENTAL- not > > Only A6 is being moved to experimental, not DNAME. There is no change of > DNAME as such, only the recommended solution for the reverse tree is > changed. > > > > Mats > > ---------------------------------------------------------------------- > Mats Dufberg Registry TeliaNet > dufberg@telia.net Skanova/AO Networks > +46 8 456 7274 Box 10707 > +46 70 258 2588 SE-121 29 Stockholm > ---------------------------------------------------------------------- > > > > -- > to 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 Jun 1 02:41:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22038 for ; Sat, 1 Jun 2002 02:41:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17E2K9-0003sC-00 for namedroppers-data@psg.com; Fri, 31 May 2002 23:25:13 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.36 #1) id 17E2K7-0003rx-00 for namedroppers@ops.ietf.org; Fri, 31 May 2002 23:25:12 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 968354B22; Sat, 1 Jun 2002 15:24:56 +0900 (JST) To: bmanning@karoshi.com Cc: dufberg@telia.net (Mats Dufberg), bmanning@ISI.EDU (Bill Manning), paul@vix.com (Paul Vixie), namedroppers@ops.ietf.org In-reply-to: bmanning's message of Fri, 31 May 2002 19:34:06 GMT. <200205311934.TAA02939@vacation.karoshi.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: A6/DNAME - game over From: itojun@iijlab.net Date: Sat, 01 Jun 2002 15:24:56 +0900 Message-ID: <2730.1022912696@itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> Only A6 is being moved to experimental, not DNAME. There is no change of >> DNAME as such, only the recommended solution for the reverse tree is >> changed. > > My comment was based on Pauls subject: A6/DNAME > A6 status seems pretty clear, I've not seen that > DNAME will go to experimental or historic.... just to clarify, draft-ietf-dnsext-ipv6-addresses-01.txt itojun 4 DNAME in IPv6 reverse tree The issues for DNAME chaining in the reverse tree are substantially identical to the issues for A6 chaining in the forward tree. Therefore, in moving RFC 2874 to experimental, the intent of this document is that use of DNAME RRs in the reverse tree be deprecated. -- to unsubscribe send a message to namedroppers-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 Jun 1 06:17:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15648 for ; Sat, 1 Jun 2002 06:17:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17E5g2-000AIl-00 for namedroppers-data@psg.com; Sat, 01 Jun 2002 03:00:02 -0700 Received: from randy by psg.com with local (Exim 3.36 #1) id 17E5g0-000AIf-00 for namedroppers@ops.ietf.org; Sat, 01 Jun 2002 03:00:00 -0700 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Sat, 01 Jun 2002 03:00:00 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. 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. the list is moderated. 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, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. 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. -- to unsubscribe send a message to namedroppers-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 Jun 1 12:32:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25169 for ; Sat, 1 Jun 2002 12:32:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EBYb-000JmO-00 for namedroppers-data@psg.com; Sat, 01 Jun 2002 09:16:45 -0700 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 17EBYb-000JmI-00 for namedroppers@ops.ietf.org; Sat, 01 Jun 2002 09:16:45 -0700 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g51GGie21452; Sat, 1 Jun 2002 09:16:44 -0700 (PDT) From: Bill Manning Message-Id: <200206011616.g51GGie21452@boreas.isi.edu> Subject: implementation catalog? To: namedroppers@ops.ietf.org Date: Sat, 1 Jun 2002 09:16:44 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning) X-Mailer: ELM [version 2.4ME+ PL39 (25)] 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 Would those who have or think they have a working implementation of DNS that supports DS (either server or resolver) please send me a note? --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 1 21:09:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29203 for ; Sat, 1 Jun 2002 21:09:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EJcN-0008wz-00 for namedroppers-data@psg.com; Sat, 01 Jun 2002 17:53:11 -0700 Received: from ws.couchpotato.net ([208.147.134.103] helo=couchpotato.net) by psg.com with smtp (Exim 3.36 #1) id 17EJcL-0008wr-00 for namedroppers@ops.ietf.org; Sat, 01 Jun 2002 17:53:09 -0700 Received: (qmail 7411 invoked from network); 2 Jun 2002 00:53:08 -0000 Received: from david.couchpotato.net (green@208.147.134.100) by ws.couchpotato.net with SMTP; 2 Jun 2002 00:53:08 -0000 Date: Sat, 1 Jun 2002 20:49:48 -0400 (EDT) From: David Green To: namedroppers@ops.ietf.org Subject: Mail-Transmitter RR Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1815059322-2023138283-1022978988=:8349" 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. Send mail to mime@docserver.cac.washington.edu for more info. ---1815059322-2023138283-1022978988=:8349 Content-Type: TEXT/PLAIN; charset=US-ASCII -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm sorry if this is off-topic, but I couldn't find a working group that is working on dealing with spam, so this is the closest match I could find. I know this is in no way related to IPv6 or anything else you guys are working on, but it is an idea I had involving the addition of a RR type. If this is not the right place to be sending this, any pointers to other working groups/forums would be greatly appreciated. And I appreciate all of the hard work you guys are doing... My idea is attached (domauth.txt) Thanks, David Green -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8+WuwCi6CzkbyeRQRAhgwAKCMt8l88znXNKkC2QQMFAcsKCApsACggDIn 8dBjMHAeIVCIinb/g4HKyEE= =s/yu -----END PGP SIGNATURE----- ---1815059322-2023138283-1022978988=:8349 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="domauth.txt" Content-ID: Content-Description: Content-Disposition: attachment; filename="domauth.txt" Content-Transfer-Encoding: BASE64 SnVuZSAxLCAyMDAyDQoNCg0KDQoNCiAgICAgICAgICAgICAgICAgICBEb21h aW4tQXV0aG9yaXplZCBTTVRQIE1haWwNCg0KDQpDb3B5cmlnaHQgTm90aWNl DQoNCiAgIENvcHlyaWdodCAoQykgRGF2aWQgTi4gR3JlZW4gKDIwMDIpLiAg QWxsIFJpZ2h0cyBSZXNlcnZlZC4NCg0KDQpBYnN0cmFjdA0KDQogICBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyB3aGVuIGFuZCBob3cgdG8gc3BlY2lmeSBN YWlsIFRyYW5zbWl0dGVyIChNVCkNCiAgIHJlc291cmNlIHJlY29yZHMgKFJS cykgaW4gdGhlIERvbWFpbiBOYW1lIFN5c3RlbSAoRE5TKSwgaG93IHRvDQog ICBjb25maWd1cmUgU01UUCBzZXJ2ZXJzIHRvIHF1ZXJ5IHRoZW0gZWZmZWN0 aXZlbHksIGFuZCBob3cgdG8NCiAgIGNvbmZpZ3VyZSBNYWlsIFVzZXIgQWdl bnRzIChNVUFzKSB0byBmaWx0ZXIgYmFzZWQgb24gdGhlbS4NCg0KDQoxLiBJ bnRyb2R1Y3Rpb24NCg0KICAgSGlzdG9yaWNhbGx5LCBJbnRlcm5ldCBtYWls IGhhcyBiZWVuIHBsYWd1ZWQgYnkgZm9yZ2VyaWVzLiBUaGlzIGhhcw0KICAg YmVjb21lIG1vcmUgcHJvYmxlbWF0aWMgYXMgdGhlIHByYWN0aWNlIG9mIHNl bmRpbmcgVW5zb2xpY2l0ZWQNCiAgIENvbW1lcmljaWFsIEVtYWlsIChVQ0Up IGhhcyBnYWluZWQgcG9wdWxhcml0eS4gVGhlIGFkZGl0aW9uIG9mIE1UDQog ICBSUnMgdG8gRE5TIHdpbGwgc29sdmUgdGhlIHByb2JsZW0gb2YgZm9yZ2Vy eSBvZiBkb21haW4sIHdpdGhvdXQNCiAgIHBsYWNpbmcgdW5kdWUgYnVyZGVu IG9uIGFueSBJbnRlcm5ldCBTZXJ2aWNlIFByb3ZpZGVyLiBUaGlzIGFsbG93 cw0KICAgdGhlIEludGVybmV0IFNlcnZpY2UgUHJvdmlkZXIgdG8gYmVnaW4g dGhlIHByb2Nlc3Mgb2YgcHJldmVudGlvbg0KICAgb2YgZm9yZ2VyeSBvZiB1 c2VyLiBUaGUgdXNlIG9mIE1UIFJScyBhdCBhbnkgc2l0ZSBpcyBSRUNPTU1F TkRFRC4NCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIs ICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTA0KICAgTk9UIiwgIlNIT1VM RCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgICJNQVkiLCBhbmQN CiAgICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50 ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluDQogICBSRkMgMjExOS4NCg0KDQoy LiBNYWlsIFRyYW5zbWl0dGVyIFJlc291cmNlIFJlY29yZHMNCiAgIA0KICAg QWxsIGhvc3RzIHdoaWNoIGFyZSBhdXRob3JpemVkIHRyYW5zbWl0dGVycyBv ZiBtYWlsIGZvciBhIGRvbWFpbiwNCiAgIGluY2x1ZGluZyBhbnkgYXV0aG9y aXplZCBmb3J3YXJkZXJzLCBTSE9VTEQgYmUgZGVzaWduYXRlZCBhcyBNYWls IA0KICAgVHJhbnNtaXR0ZXJzIHRocm91Z2ggdGhlIHVzZSBvZiBhbiBNVCBS Ui4NCg0KDQozLiBNVCBETlMgcXVlcmllcyBhbmQgQXV0aG9yaXplZC1CeSBT TVRQIGhlYWRlcnMNCg0KICAgU01UUCBzZXJ2ZXJzIFNIT1VMRCByZW1vdmUg YW55IEF1dGhvcml6ZWQtQnkgU01UUCBoZWFkZXJzIG9mDQogICBpbmNvbWlu ZyBtYWlsLiBUaGV5IE1BWSBiZSBjb25maWd1cmFibGUgdG8gcHJlc2VydmUg QXV0aG9yaXplZC1CeQ0KICAgaGVhZGVycyBvbiBpbmNvbWluZyBtYWlsIGZy b20gYSBzZXQgb2YgdHJ1c3RlZCBzZXJ2ZXJzLg0KDQogICBTTVRQIHNlcnZl cnMgU0hPVUxEIHBlcmZvcm0gYW4gTVQgRE5TIHF1ZXJ5IG9uIHRoZSBkb21h aW4gb2YNCiAgIHRoZSBGcm9tIGhlYWRlci4gSWYgdGhlIGluY29taW5nIG1h aWwgd2FzIHNlbnQgYnkgYSBzZXJ2ZXIgcmV0dXJuZWQNCiAgIGluIHRoZSBx dWVyeSwgdGhlIFNNVFAgc2VydmVyIFNIT1VMRCBhdHRhY2ggYW4gQXV0aG9y aXplZC1CeQ0KICAgaGVhZGVyIHRvIHRoZSBtZXNzYWdlLCB3aG9zZSB2YWx1 ZSBpcyB0aGUgaG9zdG5hbWUgb2YgdGhlIHNlcnZlcg0KICAgcGVyZm9ybWlu ZyB0aGUgTVQgYXV0aG9yaXphdGlvbi4NCg0KDQo0LiBNYWlsIFVzZXIgQWdl bnQgaGFuZGxpbmcgb2YgQXV0aG9yaXplZC1CeSBoZWFkZXJzDQoNCiAgIE1h aWwgVXNlciBBZ2VudHMgKE1VQXMpIE1BWSBhbGxvdyB0aGUgdXNlciB0byBm aWx0ZXIgaW5jb21pbmcNCiAgIG1lc3NhZ2VzIGJhc2VkIG9uIHRoZSBwcmVz ZW5jZSBvZiBhbiBBdXRob3JpemVkLUJ5IGhlYWRlci4NCiAgIE1VQXMgTUFZ IGFsbG93IHRoZSB1c2VyIHRvIGZ1cnRoZXIgZmlsdGVyIGF1dGhvcml6ZWQg bWVzc2FnZXMNCiAgIGJhc2VkIG9uIHRoZSBkb21haW4gb2YgdGhlIEZyb20g aGVhZGVyLg0KDQoNCjUuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAg IElmIGEgdXNlcidzIElTUCBkb2VzIG5vdCBzdXBwb3J0IGF0IGxlYXN0IHRo ZSByZW1vdmFsIG9mDQogICBBdXRob3JpemVkLUJ5IGhlYWRlcnMgYXMgc3Rh dGVkIGluIHNlY3Rpb24gMywgaW5jb21pbmcgbWFpbCBtYXkNCiAgIGJlIGVh c2lseSBmb3JnZWQuDQoNCiAgIEFkZGl0aW9uYWxseSwgYW55IGhvc3QgYmV0 d2VlbiB0aGUgc2VuZGVyIGFuZCByZWNpcGllbnQsIG9yIHdobw0KICAgY2Fu IG90aGVyd2lzZSBtYXNxdWVyYWRlIGFzIHRoZSBzZW5kZXIsIGNhbiBhbHNv IG1hc3F1ZXJhZGUNCiAgIGFzIGFuIGF1dGhvcml6ZWQgdHJhbnNtaXR0ZXIg Zm9yIHRoZSBkb21haW4gb2YgdGhlIHNlbmRlci4NCg0KDQpBdXRob3IncyBB ZGRyZXNzDQoNCiAgIERhdmlkIE4uIEdyZWVuDQogICA1NjMgQmlsbCBSdXRs ZWRnZSBSZA0KICAgV2luZGVyLCBHQSAzMDY4MCBVU0ENCg0KICAgUGhvbmU6 ICAgKzEtNzcwLTg2OC0wNzU0ICh3KQ0KICAgICAgICAgICAgKzEtNzcwLTg2 OC0xNTcyIChoKQ0KICAgRmF4ICAgICAgKzEtNzcwLTIyMC0xOTM3DQogICBF TWFpbDogICBncmVlbkBjb3VjaHBvdGF0by5uZXQNCg0K ---1815059322-2023138283-1022978988=:8349-- -- to unsubscribe send a message to namedroppers-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 Jun 1 21:15:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29238 for ; Sat, 1 Jun 2002 21:15:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EJoY-0009IW-00 for namedroppers-data@psg.com; Sat, 01 Jun 2002 18:05:46 -0700 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #1) id 17EJoX-0009IQ-00 for namedroppers@ops.ietf.org; Sat, 01 Jun 2002 18:05:45 -0700 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Sat, 1 Jun 2002 18:05:44 -0700 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 01 Jun 2002 18:05:44 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Sat, 1 Jun 2002 18:05:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Sat, 1 Jun 2002 18:05:43 -0700 Message-ID: <8BD7226E07DDFF49AF5EF4030ACE0B7E04569FD0@red-msg-06.redmond.corp.microsoft.com> Thread-Index: AcIJ0Z6ugb/G8hq8Sg6ZLu3G+bQiGg== From: "Art Shelest" To: X-OriginalArrivalTime: 02 Jun 2002 01:05:44.0261 (UTC) FILETIME=[9F24F750:01C209D1] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA29238 Hi: Secure name resolution question: is there an existing mechanism that permits configuring DNS server to only resolve name X for authorized clients? For example, I would like to have www.example.com only be resolvable by members of a specific group, and make it "invisible" to others. 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 Sat Jun 1 21:31:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29350 for ; Sat, 1 Jun 2002 21:31:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EJz5-0009ei-00 for namedroppers-data@psg.com; Sat, 01 Jun 2002 18:16:39 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17EJz4-0009ec-00 for namedroppers@ops.ietf.org; Sat, 01 Jun 2002 18:16:38 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id CE9FC28EDD for ; Sat, 1 Jun 2002 18:16:37 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR In-Reply-To: Message from David Green of "Sat, 01 Jun 2002 20:49:48 EDT." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Sat, 01 Jun 2002 18:16:37 -0700 Message-Id: <20020602011637.CE9FC28EDD@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I'm sorry if this is off-topic, but I couldn't find a working group that > is working on dealing with spam, so this is the closest match I could > find. I know this is in no way related to IPv6 or anything else you guys > are working on, but it is an idea I had involving the addition of a RR > type. If this is not the right place to be sending this, any pointers to > other working groups/forums would be greatly appreciated. And I appreciate > all of the hard work you guys are doing... My idea is attached (domauth.txt) In 1998, Jim Miller suggested this. A few weeks ago, I wrote the following. Comments are welcome. Independent Paul Vixie (Ed.) Request for Comments: XXXX Category: Experimental May 28, 2002 Repudiating MAIL FROM Status of this Memo This memo describes an experimental procedure for handling received e-mail. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract At the time of this writing, more than half of all e-mail received by the author has a forged return address, due to the total absence of address authentication in SMTP (see [RFC2821]). We present a simple and backward compatible method whereby cooperating e-mail senders and receivers can detect forged source/return addresses in e-mail. 1 - Introduction and Overview 1.1. Internet e-mail return addresses are nonrepudiable by design of the relevant transport protocols (see [RFC2821]). Simply put, there is no cause for ANY confidence in the proposition "this e-mail came from where it says it came from." 1.2. Irresponsible actors who wish to transmit unwanted bulk e-mail routinely use this designed-in lack of source/return authenticity to hide their point of origin, which usually involves forging a valid return address belonging to some highly visible and popular ISP (for example, HOTMAIL.COM). 1.3. Recipients who wish to reject unwanted bulk e-mail containing forged source/return addresses are prevented from doing so since the addresses, as presented, are nonrepudiable by design. Simply put, there would be too many false positives, and too much valid e-mail rejected, if one were to program an e-mail relay to "reject all e-mail claiming to be from HOTMAIL.COM" since, statistically, most e-mail claiming to be from HOTMAIL.COM is actually from somewhere else. HOTMAIL.COM, in this example, is a victim of forgery. Vixie Experimental [Page 1] RFC XXXX Repudiating MAIL FROM May 26, 2002 1.4. What's needed is a way to guaranty that each received e-mail message did in fact come from some mail server or relay which can rightfully originate or relay messages from the purported source/return address. 1.5. Approaches of the form "use PGP" and "use SSL" are not scalable in the short term since they depend on end-to-end action and there are just too many endpoints. An effective solution has to be applicable to mail relay, not just final delivery. 1.6. Valid ("wanted") e-mail must not be rejected by side effect or partial adoption of this proposal. Source/return authenticity must be a confidence effector, as in "we can be sure that this did not come from where it claims" and simple uncertainty must remain in effect otherwise. 2 - Behaviour 2.1. Domain owners who wish their mail source/return information to be repudiable will enter stylized MX RR's into their DNS data, whose owner name is "MAIL-FROM", whose priority is zero, and whose servername registers an outbound (border) relay for the domain. For example, to tell the rest of the Internet who they should believe when they receive mail claiming to be from VIXIE@ISC.ORG, the following DNS MX RR's should be entered: $ORIGIN isc.org. MAIL-FROM MX 0 rc MX 0 rc1 In this example, hosts RC.ISC.ORG, and RC1.ISC.ORG are given as appropriate places to originate mail from @ISC.ORG. Note that this differs from the normal inbound MX RRset for this example domain: $ORIGIN isc.org. @ MX 0 rc MX 0 isrv4 So, the inbound mail server set partially overlaps with, but differs from, the example outbound mail server set. This is quite common in the Internet, and is the reason why the normal inbound mail server set described by a domain's apex MX RRset cannot be used for repudiation purposes. Vixie Experimental [Page 2] RFC XXXX Repudiating MAIL FROM May 26, 2002 2.2. Second-stage relays such as ISP mail servers are often used and can be described by adding as many relays as necessary to the MAIL-FROM MX RRset. In our example, if ISC sometimes used UUNET for outbound mail services, the DNS data describing this relationship might be as follows: $ORIGIN isc.org. MAIL-FROM MX 0 rc MX 0 rc1 MX 0 uunet.uu.net. Let it be noted that a domain owner's power to repudiate forged e-mail is only as strong as the security policy of its registed outbound mail relays, and that if UUNET.UU.NET were (in the above example) open to third party relay, then no value will be added by registering a domain MAIL-FROM. 2.3. SMTP receivers wishing to attempt repudiation on inbound e-mail would check the SMTP (see [RFC2821]) MAIL FROM payload at the time of receipt. The precise method to be used is as follows: on (MAIL FROM mailfrom) { if (repudiated(mailfrom, ipsource)) { reply(5xx, "you've got to be joking 1"); reset(); } } And: repudiated(mailfrom, ipsource) = { (lhs, rhs) = parse_addr(mailfrom); mxset = get_mx("MAIL-FROM" "." rhs); if (mxset == NULL) return FALSE; mxset += configured(perimeter_relays); foreach mx (mxset) { aset = get_a(mx.server); if (ipsource IN aset) return FALSE; } return TRUE; } (EDITOR'S NOTE: need to establish a value for 5xx, and also get someone from the SMTP community to rule on the reset() shown here.) Vixie Experimental [Page 3] RFC XXXX Repudiating MAIL FROM May 26, 2002 The method amounts to "if there's a MAIL-FROM for the purported domain and if the IP source isn't on the resulting list, then reject the mail". Multistage inbound relays are allowed for, by implicitly appending one's own outer perimeter relay names to every extant MAIL-FROM. 3 - Impact 3.1. This specification is optional, and will only affect cooperating parties. Any domain owner who does not enter a MAIL-FROM will be unaffected, and any SMTP receiver who does not look for a MAIL-FROM at time of receipt will be unaffected. However, both parties working together CAN work to repudiate forged e-mail return/source information. 3.2. Transport-level e-mail forwarding must be more explicit under this specification. For example if VIXIE@NETBSD.ORG's account has a ".forward" file pointing at VIXIE@ISC.ORG, then e-mail sent to the former will be received by the latter, but with no change in the payload of SMTP MAIL FROM. Thus, ISC's inbound relays would have to be configured to implicitly add NETBSD's outbound mail relays as "multistage inbound relays." This could scale poorly and may add pressure toward transport remailing (with a new envelope) rather than transport forwarding (reusing the old envelope.) 3.3. The likely endgame for this behaviour is to force senders of unwanted bulk e-mail to stop lying about who they are, which is illegal in meatspace anyway -- but such laws are unenforceable due to the nature of the Internet's mail system. Under this proposal, any domain owner who is the victim of forgery can respond by adding MAIL-FROM data to their DNS zone, and any relay owner who is the victim of forged unwanted e-mail can respond by checking for MAIL-FROM data upon receipt of all incoming e-mail. 4 - Security Considerations In the continuing absence of widely deployed security for DNS, this proposal effectively places an access control list for forged source/return information in a place where it can be attacked. However, it must be noted that the current senders of forged unwanted bulk e-mail are typically not technologically capable of attacking the DNS to insert forged MAIL-FROM data. 5 - Acknowledgements This idea originated with Jim Miller in 1998. Vixie Experimental [Page 4] RFC XXXX Repudiating MAIL FROM May 26, 2002 5 - Author's Address Paul Vixie 950 Charter Street Redwood City, CA 94063 +1 650 779 7000 paul@vix.com Vixie Experimental [Page 5] -- to unsubscribe send a message to namedroppers-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 Jun 1 21:33:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29391 for ; Sat, 1 Jun 2002 21:33:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EK6q-0009ue-00 for namedroppers-data@psg.com; Sat, 01 Jun 2002 18:24:40 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17EK6p-0009uY-00 for namedroppers@ops.ietf.org; Sat, 01 Jun 2002 18:24:39 -0700 Received: from drugs.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.12.3/8.12.3) with ESMTP id g521OUOI005448; Sun, 2 Jun 2002 11:24:30 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200206020124.g521OUOI005448@drugs.dv.isc.org> To: David Green Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Mail-Transmitter RR In-reply-to: Your message of "Sat, 01 Jun 2002 20:49:48 -0400." Date: Sun, 02 Jun 2002 11:24:30 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Email addresses are tied to individuals not machines. I don't think anyone wants to give up sending email as themselves from a arbitary machine. Without the will to give this up you won't reach the critical match to make this idea work. SPAM is a political problem and as such technical solutions won't, in general, work. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 1 21:53:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29901 for ; Sat, 1 Jun 2002 21:53:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EKSC-000AhT-00 for namedroppers-data@psg.com; Sat, 01 Jun 2002 18:46:44 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17EKSB-000AhN-00 for namedroppers@ops.ietf.org; Sat, 01 Jun 2002 18:46:43 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA19267; Sat, 1 Jun 2002 21:46:40 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA17107; Sat, 1 Jun 2002 21:46:39 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id VAA09141; Sat, 1 Jun 2002 21:46:39 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id VAA10711; Sat, 1 Jun 2002 21:46:40 -0400 (EDT) To: Mark.Andrews@isc.org Cc: David Green , namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR References: <200206020124.g521OUOI005448@drugs.dv.isc.org> From: Derek Atkins Date: 01 Jun 2002 21:46:40 -0400 In-Reply-To: <200206020124.g521OUOI005448@drugs.dv.isc.org> Message-ID: Lines: 47 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Agreed. I send mail from my laptop, which travels with me all over the place, but my From address is elsewhere. How is my home address supposed to know what IP address I'm using at any particular point in time? Forcing me to forward all my mail through my home network just means more latency when they get clogged. Worse, I've got _multiple_ addresses that I use -- how is my mail agent (UA or TA) supposed to know how to forward the mail? I agree that this technical solution wont really work. However I disagree that all technical solutions are out of the question. Some of the technical proposals I've seen might help. For example, if all email required PGP security, or if all email required a "digital postage stamp" where the sender has to pay real money to the recipient if they consider the message spam. For real email usage the recipient would never cash in the postage, but for spammers it would (hopefully) be a financial disincentive to spam. MTAs could verify the postage on messages or drop them, MUAs would be given an option of "cash the postage or ignore it". -derek Mark.Andrews@isc.org writes: > Email addresses are tied to individuals not machines. I don't > think anyone wants to give up sending email as themselves from > a arbitary machine. Without the will to give this up you won't > reach the critical match to make this idea work. > > SPAM is a political problem and as such technical solutions won't, > in general, work. > > Mark > -- > Mark Andrews, Internet Software Consortium > 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: -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-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 Jun 1 21:54:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29952 for ; Sat, 1 Jun 2002 21:54:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EKVQ-000Aog-00 for namedroppers-data@psg.com; Sat, 01 Jun 2002 18:50:04 -0700 Received: from yoyo.akc.com ([192.188.192.5]) by psg.com with esmtp (Exim 3.36 #1) id 17EKVP-000Anq-00 for namedroppers@ops.ietf.org; Sat, 01 Jun 2002 18:50:03 -0700 Received: from backup ([65.195.106.55]) by yoyo.akc.com (8.9.3/8.9.3) with SMTP id VAA25603; Sat, 1 Jun 2002 21:49:54 -0400 Message-ID: <002801c209d5$150aab60$376ac341@akc.com> From: "Al Costanzo" To: "David Green" , References: Subject: Re: Mail-Transmitter RR Date: Sat, 1 Jun 2002 21:30:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, The draft needs work but its a -- good concept -- you could add code the mail agent to look for the RR record. I think this will need to be discussed on the SMTP side of the house first because a RR does nothing if the mail protocol does not use it IMHO. Regards, Al ----- Original Message ----- From: "David Green" To: Sent: Saturday, June 01, 2002 8:49 PM Subject: Mail-Transmitter RR > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I'm sorry if this is off-topic, but I couldn't find a working group that > is working on dealing with spam, so this is the closest match I could > find. I know this is in no way related to IPv6 or anything else you guys > are working on, but it is an idea I had involving the addition of a RR > type. If this is not the right place to be sending this, any pointers to > other working groups/forums would be greatly appreciated. And I appreciate > all of the hard work you guys are doing... My idea is attached > (domauth.txt) > > Thanks, > > David Green > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE8+WuwCi6CzkbyeRQRAhgwAKCMt8l88znXNKkC2QQMFAcsKCApsACggDIn > 8dBjMHAeIVCIinb/g4HKyEE= > =s/yu > -----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 Sat Jun 1 23:18:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00877 for ; Sat, 1 Jun 2002 23:18:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ELm6-000CtG-00 for namedroppers-data@psg.com; Sat, 01 Jun 2002 20:11:22 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17ELm3-000Ct6-00 for namedroppers@ops.ietf.org; Sat, 01 Jun 2002 20:11:19 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id C68FB28EDD for ; Sat, 1 Jun 2002 19:49:00 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR In-Reply-To: Message from Mathias Koerber of "Sun, 02 Jun 2002 10:38:55 +0800." <15060000.1022985535@noisy.koerber.org> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Sat, 01 Jun 2002 19:49:00 -0700 Message-Id: <20020602024900.C68FB28EDD@as.vix.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk note that the proposal as written is about smtp source repudiation, not spam. while it's true that spammers are the most common forgers of smtp source information, they are by no means alone. also note that this proposal uses a DNS RR but is not about DNS itself, and there may be a more appropriate forum for the discussion than namedroppers. (i wasn't going to release my proposal without further private review, but the question came up here today and so i sent my working draft in answer.) > I do like this approcah, though this method only protects against spammers > (etc) forging those domains that exist and apply this method to protect > themselves. exactly. if i've learnt anything about making spam more difficult, more expensive, and less effective, it's that it has to be done by someone with "standing" (such as the recipient or someone whose domain is being forged.) > While the 'sender domain must exist' test already acts well > to protect against use of non-existing domains, spammers will still be free > to use existing domains that are not thusly protected in their mails. it is the responsibility of anyone whose domain is forged to add a MAIL-FROM under this proposal. there are 30,000,000 of them but at least the ones who are common targets of forgery will have a way to put an end to it. > There will also be issues with sites that have off-site MX hosts to hold > mail in case of downtime, viz: > > $ORIGIN domain.example. > @ IN MX 10 mail > IN MX 20 mail.myisp.example. > > Both hosts in such a configuration will have to be able to perform the > test, as both may receive mail directly from the sender's MAIL-FROM > MTAs and the final destination MTA cannot perform this test on mail ... understood and agreed. however, i can't think of a less onerous way for a domain holder to protect themselves against forgery of this kind, and i see forgery of this kind as a huge huge huge source of domain-holder pain. -- to unsubscribe send a message to namedroppers-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 Jun 1 23:18:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00890 for ; Sat, 1 Jun 2002 23:18:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ELks-000CrF-00 for namedroppers-data@psg.com; Sat, 01 Jun 2002 20:10:06 -0700 Received: from ad202.166.27.108.magix.com.sg ([202.166.27.108] helo=matjes.koerber.org) by psg.com with esmtp (Exim 3.36 #1) id 17ELko-000Cqn-00 for namedroppers@ops.ietf.org; Sat, 01 Jun 2002 20:10:02 -0700 Received: from [172.22.22.252] (mathias@noisy.koerber.org [172.22.22.252]) by matjes.koerber.org (8.11.1/8.11.1) with ESMTP id g522g1W07266; Sun, 2 Jun 2002 10:42:02 +0800 Date: Sun, 02 Jun 2002 10:42:01 +0800 From: Mathias Koerber To: Derek Atkins , Mark.Andrews@isc.org cc: David Green , namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR Message-ID: <15390000.1022985721@noisy.koerber.org> In-Reply-To: References: <200206020124.g521OUOI005448@drugs.dv.isc.org> X-Mailer: Mulberry/2.2.0 (Linux/x86 Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Saturday, June 01, 2002 09:46:40 PM -0400 Derek Atkins wrote: > Agreed. I send mail from my laptop, which travels with me all over > the place, but my From address is elsewhere. How is my home address > supposed to know what IP address I'm using at any particular point in > time? Forcing me to forward all my mail through my home network just > means more latency when they get clogged. Worse, I've got _multiple_ > addresses that I use -- how is my mail agent (UA or TA) supposed to > know how to forward the mail? There are mail clients that can distinguish between different sender-accounts and select different outgoing SMPT servers for each. In addition, I tunnel all such traffic through SSH to my home-site anyway, mostly to have a central log of all mail and to have a unified sending-location anyway.. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 1 23:18:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00904 for ; Sat, 1 Jun 2002 23:18:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ELh4-000CjS-00 for namedroppers-data@psg.com; Sat, 01 Jun 2002 20:06:10 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17ELgz-000CjB-00 for namedroppers@ops.ietf.org; Sat, 01 Jun 2002 20:06:05 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id WAA01718; Sat, 1 Jun 2002 22:44:34 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA18413; Sat, 1 Jun 2002 22:40:28 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id WAA06936; Sat, 1 Jun 2002 22:40:28 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id WAA10814; Sat, 1 Jun 2002 22:40:29 -0400 (EDT) To: Ted Lemon Cc: namedroppers@ops.ietf.org, David Green , Mark.Andrews@isc.org Subject: Re: Mail-Transmitter RR References: From: Derek Atkins Date: 01 Jun 2002 22:40:29 -0400 In-Reply-To: Message-ID: Lines: 55 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.4 required=5.0 tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ted Lemon writes: > > Agreed. I send mail from my laptop, which travels with me all over > > the place, but my From address is elsewhere. How is my home address > > supposed to know what IP address I'm using at any particular point in > > time? > > You contact an SMTP server for your domain over SSL, authenticate yourself, > and drop the main on that server, which can then safely forward it. Who is "you" in this case? My MUA? My MTA? I'm currently running sendmail on my laptop. My MUA just passes the mail on to there, and it gets forwarded appropriately. This is a nice feature because there are many times when I have better connectivity between my laptop and my recipient than I would going from laptop->home->recipient. Are you saying that instead of distributing the load of mail I now have to centralize mail delivery just because people are abusing the distributed nature? > So don't use MAIL-FROM if it doesn't work for you. I think this is > an unlikely problem, though. I use a remote mail drop for every > email message I send, and it has never caused me any inconvenience. Perhaps your definition of inconvenience and mine are different? But consider this: if not everyone is doing it, then what's the point? If it's not a ubiquitous solution, then it's not going to solve the spam problem. All it will do is prevent spammers from forging a valid email address to recipients that have agreements with that individual. I was hit by this today... Some spammer used my address to send out a bunch of messages, and I was lucky enough to get all the bounces into my inbox. I certainly did not know any of the recipients whose mail bounced back to me. So, how would this have helped me (or them) in this case, especially if you're telling me not to use it? > This proposal doesn't solve the spam problem, but it _does_ make it > harder for spammers to get away with forging email addresses, which > would be a big improvement. What's more, it does not require that > you agree to it. It only requires that people who are victims of > forgery agree to it, and that people who care about forgery agree to > it. So if you don't like it, don' > t do it. See, I'm not convinced it will make it much more difficult unless it's a upqiwuitous deployment, and I believe that the functionality that is destroyed by deploying this technology is not worth the perceived benefit. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-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 Jun 1 23:29:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01032 for ; Sat, 1 Jun 2002 23:29:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ELyb-000DN0-00 for namedroppers-data@psg.com; Sat, 01 Jun 2002 20:24:17 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17ELyW-000DMo-00 for namedroppers@ops.ietf.org; Sat, 01 Jun 2002 20:24:12 -0700 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 120027; Sat, 01 Jun 2002 21:52:23 -0500 Message-ID: <3CF988D1.8091D240@ehsco.com> Date: Sat, 01 Jun 2002 21:54:09 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: David Green CC: namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR References: Content-Type: multipart/mixed; boundary="------------B854663555F6E85BFAB4E598" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------B854663555F6E85BFAB4E598 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Green wrote: > Name: domauth.txt > domauth.txt Type: Plain Text (TEXT/PLAIN) > Encoding: BASE64 This comes up every few months. Welcome to the club. See draft-church-dns-mail-sender-01.txt as another approach, and one that considers how to deal with roadblock relays. See the attached message for some ideas on getting more mileage out of a single RR (such as allowing an org to declare their entire reverse PTR space as valid relays). See the ietf-822@imc.org archives for flames, accusations, innuendos, and unsupported arguments against it. Some people are very opposed to it. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ --------------B854663555F6E85BFAB4E598 Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from [208.184.76.43] (HELO above.proper.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP id 92868 for lists@ntrg.com; Fri, 17 May 2002 12:49:26 -0500 Received: by above.proper.com (8.11.6/8.11.3) id g4HHapT09394 for ietf-822-bks; Fri, 17 May 2002 10:36:51 -0700 (PDT) Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4HHanL09390 for ; Fri, 17 May 2002 10:36:49 -0700 (PDT) Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 92867; Fri, 17 May 2002 12:36:53 -0500 Message-ID: <3CE53FB1.9293E9FC@ehsco.com> Date: Fri, 17 May 2002 12:36:49 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: ietf-822@imc.org, achurch@achurch.org Subject: Re: authenticating the source of mail References: <200205112101.g4BL1cg25178@astro.cs.utk.edu> <5.1.0.14.2.20020511232010.08bc5bc0@lmail.pscs.co.uk> <3CE28DFC.FD52A098@ehsco.com> Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit More thinking on this, probably the best approach here is to define a flags sub-field in the MS RR, which allows for domain indirection. Two flags which could be used right away: bit 1 off=value refers to a host on=value refers to a domain bit 2 off=use A/AAAA RRs associated with value on=use MX RRs associated with value Combining these flags would allow for various functions, with a minimal amount of overhead. Some examples below. Use the IP addresses associated with outbound.example.com as the authorized relay servers for example.com: [Answer Section] example.com. MS 0 outbound.example.com. [Additional-Data Section] outbound.example.com. A 10.0.0.3 Use the MX RRs associated with mail.example.com as the authorized relay servers for example.com: [Answer Section] example.com. MS 3 mail.example.com. [Additional-Data Section] mail.example.com. MX 5 mx-1.example.com. mail.example.com. MX 5 mx-2.example.com. mx-1.example.com. A 10.0.0.1 mx-2.example.com. A 10.0.0.2 [note that the MX RRs would not be provided in the Additional-Data section if a query for ALL resulted in them being provided in the Answer section of the response] Any and all hosts in the mail.example.com domain are authorized relay servers for example.com: [Answer Section] example.com. MS 1 mail.example.com. [Additional-Data Section] [the PTR for the current mail session should be examined, and if it resides within the specified domain, then it is authorized] These could also be cumulative. EG, use the IP addresses associated with outbound.example.com PLUS the MX RRs associated with the mail.example.com domain as the authorized relay servers for example.com: [Answer Section] example.com. MS 0 outbound.example.com. MS 3 mail.example.com. [Additional-Data Section] outbound.example.com. A 10.0.0.3 mail.example.com. MX 5 mx-1.example.com. mail.example.com. MX 5 mx-2.example.com. mx-1.example.com. A 10.0.0.1 mx-2.example.com. A 10.0.0.2 The benefit of this approach is that it allows for sender-based customization of the interpretation (hosts vs MX lists), but minimizes the risk of overloads. The above needs more smoothing out but I think it is workable. Any other flags which would be useful? Any comments on this approach? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ --------------B854663555F6E85BFAB4E598-- -- to unsubscribe send a message to namedroppers-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 Jun 1 23:49:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01630 for ; Sat, 1 Jun 2002 23:49:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EMGc-000Dyx-00 for namedroppers-data@psg.com; Sat, 01 Jun 2002 20:42:54 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17EMGZ-000Dyo-00 for namedroppers@ops.ietf.org; Sat, 01 Jun 2002 20:42:51 -0700 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 120032; Sat, 01 Jun 2002 22:41:02 -0500 Message-ID: <3CF9942F.982FEEF9@ehsco.com> Date: Sat, 01 Jun 2002 22:42:39 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Derek Atkins CC: Ted Lemon , namedroppers@ops.ietf.org, David Green , Mark.Andrews@isc.org Subject: Re: Mail-Transmitter RR References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Derek Atkins wrote: > consider this: if not everyone is doing it, then what's the point? If > it's not a ubiquitous solution, then it's not going to solve the spam > problem. All it will do is prevent spammers from forging a valid > email address to recipients that have agreements with that individual. This is the crux of *an* argument, but not *the* argument, IMO. Negative: The spammers will stop using hotmail.com, will scurry away from the bright light, and will start forging mail from somebody else's domain. Zero-sum gain for us, the recipients of spam. Negative: We lose a valuable filter (DENY HOTMAIL.COM). Positive: Hotmail has control over it's domain. I can accept mail from them again. Positive: Nobody will send forgeries from *my* domain. They will not announce winners for contests I've never held. They will not spread trojans *from other networks* claiming to be coming from me. Positive: Nobody will send forgeries from *your* domain, if you choose to opt-in to the self-ACL scheme. Positive: I have another weighting filter for my post-transfer filtering scheme, whereby non-participants are slightly less credible, while participants get whitelisted automatically. There is only one negative that hurts. The other negative is a neutral. There are certainly other valid issues with this approach. It can be very difficult for ultra-mobile users to participate, for example. But it is also elective, and only applies to the mail domain under your control. I just can't see anything wrong with letting people say "only accept mail from me if it comes from this network". -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-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 Jun 2 00:17:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01758 for ; Sun, 2 Jun 2002 00:17:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EMXf-000ETN-00 for namedroppers-data@psg.com; Sat, 01 Jun 2002 21:00:31 -0700 Received: from ad202.166.27.108.magix.com.sg ([202.166.27.108] helo=matjes.koerber.org) by psg.com with esmtp (Exim 3.36 #1) id 17EMXc-000ETE-00 for namedroppers@ops.ietf.org; Sat, 01 Jun 2002 21:00:28 -0700 Received: from [172.22.22.252] (mathias@noisy.koerber.org [172.22.22.252]) by matjes.koerber.org (8.11.1/8.11.1) with ESMTP id g5240IW07497; Sun, 2 Jun 2002 12:00:19 +0800 Date: Sun, 02 Jun 2002 12:00:18 +0800 From: Mathias Koerber To: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR Message-ID: <17500000.1022990418@noisy.koerber.org> In-Reply-To: <20020602024900.C68FB28EDD@as.vix.com> References: <20020602024900.C68FB28EDD@as.vix.com> X-Mailer: Mulberry/2.2.0 (Linux/x86 Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > understood and agreed. however, i can't think of a less onerous way for a > domain holder to protect themselves against forgery of this kind, and i > see forgery of this kind as a huge huge huge source of domain-holder pain. Neither can I, but my point is that this approach should be combined with whatever (authenticatable) indication the SMTP folx can come up with between first incoming MX and further MX hosts into one document, as this will only be useful if the SMTP server side is properly defined. mk -- to unsubscribe send a message to namedroppers-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 Jun 2 00:26:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01840 for ; Sun, 2 Jun 2002 00:26:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EMi5-000EoX-00 for namedroppers-data@psg.com; Sat, 01 Jun 2002 21:11:17 -0700 Received: from ad202.166.27.108.magix.com.sg ([202.166.27.108] helo=matjes.koerber.org) by psg.com with esmtp (Exim 3.36 #1) id 17EMi1-000EoN-00 for namedroppers@ops.ietf.org; Sat, 01 Jun 2002 21:11:13 -0700 Received: from [172.22.22.252] (mathias@noisy.koerber.org [172.22.22.252]) by matjes.koerber.org (8.11.1/8.11.1) with ESMTP id g524B5W07532; Sun, 2 Jun 2002 12:11:05 +0800 Date: Sun, 02 Jun 2002 12:11:05 +0800 From: Mathias Koerber To: Derek Atkins , Ted Lemon cc: namedroppers@ops.ietf.org, David Green , Mark.Andrews@isc.org Subject: Re: Mail-Transmitter RR Message-ID: <18290000.1022991065@noisy.koerber.org> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Linux/x86 Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Who is "you" in this case? My MUA? My MTA? I'm currently running > sendmail on my laptop. My MUA just passes the mail on to there, and > it gets forwarded appropriately. This is a nice feature because there > are many times when I have better connectivity between my laptop and > my recipient than I would going from laptop->home->recipient. Are you > saying that instead of distributing the load of mail I now have to > centralize mail delivery just because people are abusing the > distributed nature? I wouldn;t say 'have to'. If you have other ,ethods of authenticating your mail (ie pgp etc), the receiving MTAs should be free to ignore the MAIL-FROM RR if they can authenticate you that way. The problem with that approach is that they would have to receive the complete email first, *and* that they'd need the ability to do authentication which usually now is done in the MUA. On the otherhand, this approach is *voluntary*, and no-one forces you to publish your MAIL-FROM MX ifyoudon't want to use it. > >> So don't use MAIL-FROM if it doesn't work for you. I think this is >> an unlikely problem, though. I use a remote mail drop for every >> email message I send, and it has never caused me any inconvenience. > > Perhaps your definition of inconvenience and mine are different? But > consider this: if not everyone is doing it, then what's the point? If > it's not a ubiquitous solution, then it's not going to solve the spam > problem. All it will do is prevent spammers from forging a valid > email address to recipients that have agreements with that individual. No. The beuaty of thes approach is that there is no specific agreement between each pair of potential senders and recipients necessary. A recipeint decides whether s/he wants to use this method of MAIL-FROM is such an RR exists for the sender, and the sender simply published it if they want their addresses protected from abuse (at least to those sides that actually check for it). > > I was hit by this today... Some spammer used my address to send out a > bunch of messages, and I was lucky enough to get all the bounces into > my inbox. I certainly did not know any of the recipients whose mail > bounced back to me. So, how would this have helped me (or them) in > this case, especially if you're telling me not to use it? You can't have it both ways. It will help you only if you use it, but that means using list of predefined MX hosts. There are tradeoffs. If you really want, you can list your laptop in the MAIL-FROM MX list and use DDNS to update its IP address before sending mail. There should not be any problems with the mail hanging around and someone checking the MX after you lose that IP address, as it is the first MTA after your sender that will have to perform this check. > See, I'm not convinced it will make it much more difficult unless it's > a upqiwuitous deployment, and I believe that the functionality that is > destroyed by deploying this technology is not worth the perceived > benefit. I don's see any functionality being destroyed. You will have to make a choice which is more important to you, fast, shortest-hop delivery to the nearest recipient MTAs or the protection of your address(es). mk -- to unsubscribe send a message to namedroppers-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 Jun 2 08:24:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13533 for ; Sun, 2 Jun 2002 08:24:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EU7L-0009CV-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 05:05:51 -0700 Received: from adsl-63-206-121-247.dsl.snfc21.pacbell.net ([63.206.121.247] helo=blade.unixpeople.internal) by psg.com with esmtp (Exim 3.36 #1) id 17EU7G-0009C2-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 05:05:46 -0700 Received: from unixpeople.com (localhost [127.0.0.1]) by blade.unixpeople.internal (8.12.2/8.12.2) with ESMTP id g52C5UoW020190 for ; Sun, 2 Jun 2002 05:05:31 -0700 (PDT) Message-ID: <3CFA09C8.8030008@unixpeople.com> Date: Sun, 02 Jun 2002 05:04:24 -0700 From: "Andy W. Barclay" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Derek, Actually, I do advocate that you send all mail from your laptop through your home machine, then on to the final recipient. This is no different from the way 90% of the population of the Internet does things now. Most people don't run sendmail on their laptop. In fact, I am currently connected to the net via a dsl connection to sympatico in Canada right now. The sympatico firewalls block out-bound SMTP, so you are supposed to use their SMTP servers. (I tunnel smtp to my home server via ssh). This would adversely affect your ability to use your laptop as a relay. Lastly, the mail-abuse.com people define a method of blocking mail which comes from "dial-up" addresses. I think that your solution of using your laptop will slowly become less and less reliable, and I think that both Paul's proposal and David Green's proposal have merit. (In case anyone is interested, several of my compatriots are using spamassassin to kill spam, and its working very well for them (99.5% success rate, .4% false positives) Derek Atkins wrote: > Ted Lemon writes: > > >>>Agreed. I send mail from my laptop, which travels with me all over >>>the place, but my From address is elsewhere. How is my home address >>>supposed to know what IP address I'm using at any particular point in >>>time? >> >>You contact an SMTP server for your domain over SSL, authenticate yourself, >> and drop the main on that server, which can then safely forward it. > > > Who is "you" in this case? My MUA? My MTA? I'm currently running > sendmail on my laptop. My MUA just passes the mail on to there, and > it gets forwarded appropriately. This is a nice feature because there > are many times when I have better connectivity between my laptop and > my recipient than I would going from laptop->home->recipient. Are you > saying that instead of distributing the load of mail I now have to > centralize mail delivery just because people are abusing the > distributed nature? > > >>So don't use MAIL-FROM if it doesn't work for you. I think this is >>an unlikely problem, though. I use a remote mail drop for every >>email message I send, and it has never caused me any inconvenience. > > > Perhaps your definition of inconvenience and mine are different? But > consider this: if not everyone is doing it, then what's the point? If > it's not a ubiquitous solution, then it's not going to solve the spam > problem. All it will do is prevent spammers from forging a valid > email address to recipients that have agreements with that individual. > > I was hit by this today... Some spammer used my address to send out a > bunch of messages, and I was lucky enough to get all the bounces into > my inbox. I certainly did not know any of the recipients whose mail > bounced back to me. So, how would this have helped me (or them) in > this case, especially if you're telling me not to use it? > > >>This proposal doesn't solve the spam problem, but it _does_ make it >>harder for spammers to get away with forging email addresses, which >>would be a big improvement. What's more, it does not require that >>you agree to it. It only requires that people who are victims of >>forgery agree to it, and that people who care about forgery agree to >>it. So if you don't like it, don' >>t do it. > > > See, I'm not convinced it will make it much more difficult unless it's > a upqiwuitous deployment, and I believe that the functionality that is > destroyed by deploying this technology is not worth the perceived > benefit. > > -derek > -- Regards, Andy W. Barclay. abarclay@unixpeople.com fax (781) 823-8276 Always a UNIX Evangelist (and sometimes a system and network architect) The truth of a proposition has nothing to do with its credibility. And Vice-Versa. -- to unsubscribe send a message to namedroppers-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 Jun 2 12:08:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16750 for ; Sun, 2 Jun 2002 12:08:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EXl3-000J1f-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 08:59:05 -0700 Received: from ws.couchpotato.net ([208.147.134.103] helo=couchpotato.net) by psg.com with smtp (Exim 3.36 #1) id 17EXkz-000J1R-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 08:59:02 -0700 Received: (qmail 11573 invoked from network); 2 Jun 2002 15:58:57 -0000 Received: from david.couchpotato.net (green@208.147.134.100) by ws.couchpotato.net with SMTP; 2 Jun 2002 15:58:57 -0000 Date: Sun, 2 Jun 2002 11:55:40 -0400 (EDT) From: David Green To: Mathias Koerber cc: Derek Atkins , Ted Lemon , , Subject: Re: Mail-Transmitter RR In-Reply-To: <18290000.1022991065@noisy.koerber.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.5 required=5.0 tests=IN_REP_TO,PGP_SIGNATURE version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 2 Jun 2002, Mathias Koerber wrote: > I don's see any functionality being destroyed. You will have to make a > choice which is more important to you, fast, shortest-hop delivery to > the nearest recipient MTAs or the protection of your address(es). Nicely put :) UCE is THE killing factor of using email today. Checking my email is a love/hate relationship. At least I have an excellent filter on it, but a dozen spams still get through every day. What I don't care about is how long it takes me to send one via my isdn (once queued on the server, who cares...) Paul, your proposal is thought out much better than mine. However, I don't agree with overloading the MX RR to make this happen. I think that using an SRV RR would be a better choice, as this might lead to domain-authentication of other services in the future: out.smtp.tcp SRV 0 0 smtpsender.asdf.com out.http.tcp SRV 0 0 httpproxy.asdf.com Perhaps even put source port-numbers in there as well... David Green -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8+j/8Ci6CzkbyeRQRArTUAJ9ncR8kAd5+BQt26cFRPQ25k2b1zACgwH1X zrVOH6KTmVrZE56QXCIIhUw= =hUIx -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 2 12:52:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17041 for ; Sun, 2 Jun 2002 12:52:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EYOG-000KmE-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 09:39:36 -0700 Received: from h49n3c1o274.bredband.skanova.com ([217.209.54.49] helo=slimsixten.pilsnet.sunet.se) by psg.com with esmtp (Exim 3.36 #1) id 17EYOC-000KlW-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 09:39:32 -0700 Received: from localhost (localhost.pilsnet.sunet.se [127.0.0.1]) by slimsixten.pilsnet.sunet.se (8.12.1/8.12.1) with ESMTP id g52GcTNj015342 for ; Sun, 2 Jun 2002 18:38:30 +0200 (MEST) Date: Sun, 02 Jun 2002 18:38:29 +0200 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR Message-ID: <145480000.1023035909@slimsixten.pilsnet.sunet.se> In-Reply-To: <3CFA09C8.8030008@unixpeople.com> References: <3CFA09C8.8030008@unixpeople.com> X-Mailer: Mulberry/2.2.0 (OpenBSD/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA17041 --On Sunday, June 02, 2002 05:04:24 -0700 "Andy W. Barclay" wrote: > This is no different from the way 90% of the population of the Internet > does things now. Perhaps 90% of the people on the Internet use Windows. Are you suggesting we should force everyone to use Windows just because 90% of the people on the Internet do so? The proposal(s) break(s) e-mail in fundamental and worrying ways, and make the probability of e-mail delivery in adverse conditions much lower (think backhoe incident on main internet connectivity, trigging the use of dialup for backup connectivity, and nobody remembering to add that netblock to the good, allowed ones). Us moderately and above clued people should not destroy the "survive-all" capabilities of the Internet. There are others doing that much better. This is a bad suggestion, and it needs to be stopped. /Mns, who has a sendmail running on his laptop. -- Mns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. -- to unsubscribe send a message to namedroppers-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 Jun 2 13:00:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17145 for ; Sun, 2 Jun 2002 13:00:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EYbU-000LOz-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 09:53:16 -0700 Received: from ws.couchpotato.net ([208.147.134.103] helo=couchpotato.net) by psg.com with smtp (Exim 3.36 #1) id 17EYbQ-000LOg-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 09:53:12 -0700 Received: (qmail 9114 invoked from network); 2 Jun 2002 16:53:11 -0000 Received: from david.couchpotato.net (green@208.147.134.100) by ws.couchpotato.net with SMTP; 2 Jun 2002 16:53:11 -0000 Date: Sun, 2 Jun 2002 12:49:54 -0400 (EDT) From: David Green To: Derek Atkins cc: Mark.Andrews@isc.org, Subject: Re: Mail-Transmitter RR In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.5 required=5.0 tests=IN_REP_TO,PGP_SIGNATURE version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1 Jun 2002, Derek Atkins wrote: > Agreed. I send mail from my laptop, which travels with me all over > the place, but my From address is elsewhere. How is my home address > supposed to know what IP address I'm using at any particular point in > time? Forcing me to forward all my mail through my home network just > means more latency when they get clogged. Worse, I've got _multiple_ > addresses that I use -- how is my mail agent (UA or TA) supposed to > know how to forward the mail? Or use a different From: address for the network you are currently on, and use the Reply-To header to point to your real email address. I imagine that once domains become authenticated, then ISPs will start to do user-based authentication. Therefore, if you're using green@mindspring.com's Internet account, then green@mindspring.com would be forced by MindSpring to be the From: address for all outgoing mail from your particular IP. Which is, actually, correct; the email IS coming from green@mindspring.com's connection/computer. Then set the appropriate Reply-To field. David Green -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8+kyzCi6CzkbyeRQRAjpUAJ9MBGsQL/DiOvBFInYki1KQ7/twVwCeLyQS uibcqAhvieHzFROHcbHDXPE= =QeKp -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 2 13:03:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17178 for ; Sun, 2 Jun 2002 13:03:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EYYW-000LGQ-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 09:50:12 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17EYYS-000LGA-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 09:50:08 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 5309C28EDD; Sun, 2 Jun 2002 09:50:07 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: David Green Cc: Mathias Koerber , Derek Atkins , Ted Lemon , namedroppers@ops.ietf.org, Mark.Andrews@isc.org Subject: Re: Mail-Transmitter RR In-Reply-To: Message from David Green of "Sun, 02 Jun 2002 11:55:40 EDT." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Sun, 02 Jun 2002 09:50:07 -0700 Message-Id: <20020602165007.5309C28EDD@as.vix.com> X-Spam-Status: No, hits=-1.2 required=5.0 tests=IN_REP_TO,OPT_IN,BULK_EMAIL version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > From: David Green > > Paul, your proposal is thought out much better than mine. However, I > don't agree with overloading the MX RR to make this happen. I think > that using an SRV RR would be a better choice, as this might lead to > domain authentication of other services in the future: [...] We would be overloading SRV just as much as the current proposal does MX. More to the point, the patch to sendmail to implement MAIL-FROM is less than 100 lines if MX is used. Given the number of disparite code bases out there, ease of implementation will translate directly to the growth of an installed base. > out.smtp.tcp SRV 0 0 smtpsender.asdf.com > out.http.tcp SRV 0 0 httpproxy.asdf.com > > Perhaps even put source port-numbers in there as well... Unless there's something _needed_ that SRV provides (load balancing, port numbers) I think it would be better to avoid it. And I speak as an author of the SRV RR when I say that in this case. > From: Derek Atkins > > The problem with this proposal is that only the first-hop can actually > check the message. All the spammer needs to do is find an open relay > that does not implement the "remove the Authorized-by header" and they > are home free, and even this MAIL-FROM technique wont help. > Considering that spammers are already utilizing open relays, this > isn't really a big change for them. So even if people opt-in to this > proposal, I don't see it actually helping. I've strengthened the wording on [MAILFROM 2.2] which now reads: 2.2. Second-stage relays such as ISP mail servers are often used and can be described by adding as many relays as necessary to the MAIL-FROM MX RRset. In our example, if ISC sometimes used UUNET for outbound mail services, the DNS data describing this relationship might be as follows: $ORIGIN isc.org. MAIL-FROM MX 0 rc MX 0 rc1 MX 0 uunet.uu.net. Let it be noted that a domain owner's power to repudiate forged e-mail is only as strong as the security policy of its registered inbound and outbound mail relays, and that if such a relay is (for example) open to third party relay, then no value will be added by registering a domain MAIL-FROM MX containing that relay, and no inbound MAIL-FROM checking will be possible on final delivery relays for a domain @ MX containing that relay. Multistage relays (both inbound and outbound) are a breeding ground for anonymity unless they are very carefully configured. I think that there's a LOT of help to be had from this, amongst anonymous but cooperating domain owners and relay owners. I'm not pushing this as the one true way to stop all spam for all time, because I don't think there is any such. It's an optional, low-impact way to protect folks like hotmail from widespread forgery. Probably it won't slow spam down one whit, but it will reduce the overall injury from spam. > Unfortunately second-hop mail proxies can't perform the same check on > the MAIL-FROM, because all they have is the Received-By headers. In > fact, how is an MTA supposed to know whether it is the first-hop or not? For the record, I'm against header munging and against Received: parsing by MTA's. Both are layering violations, though of different kinds. The right solution is to know and trust the configuration of your @ MX relays and also, if you choose to use MAIL-FROM, of your MAIL-FROM MX relays. The text above strengthens the case for this requirement, which is in fact already present in the existing mail system in any case. > Also, without DNSsec the spammer could try DNS forging attacks as well. OK, so I hate it when I have to quote something you've already seen, but: 4 - Security Considerations In the continuing absence of widely deployed security for DNS, this proposal effectively places an access control list for forged source/return information in a place where it can be attacked. However, it must be noted that the current senders of forged unwanted bulk e-mail are typically not technologically capable of attacking the DNS to insert forged MAIL-FROM data. You can call the above a cop-out if you want, but since we're moving a problem from a solutionless arena (end-to-end MTA authentication) to a solutionful arena (deploy DNSSEC) I consider the movement to be "progress." > From: David Green > > > The problem with this proposal is that only the first-hop can actually > > check the message. All the spammer needs to do is find an open relay > > that does not implement the "remove the Authorized-by header" and they > > are home free, and even this MAIL-FROM technique wont help. > > There should only be a single hop between separate logical entities on the > public Internet. The final sending host of the sending entity would need > to be marked as an authorized mail transmitter for the domain. Inside of > each entity, they can set up any rules they like. If a cooperating set of MX's (inbound @ or outbound MAIL-FROM or both) wants to implement such a scheme then it falls under the general category of "knowing and trusting the configs of your domain's MX relays". It's out of scope for this proposal, but implementation experience, open source patches, and a BCP would go a long way toward advancing this particular form of trust. -- to unsubscribe send a message to namedroppers-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 Jun 2 13:13:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17248 for ; Sun, 2 Jun 2002 13:13:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EYit-000Lnq-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 10:00:55 -0700 Received: from yoyo.akc.com ([192.188.192.5]) by psg.com with esmtp (Exim 3.36 #1) id 17EYip-000LnS-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 10:00:51 -0700 Received: from backup ([65.195.106.55]) by yoyo.akc.com (8.9.3/8.9.3) with SMTP id NAA20403; Sun, 2 Jun 2002 13:00:46 -0400 Message-ID: <000701c20a53$9b042a60$376ac341@akc.com> From: "Al Costanzo" To: =?iso-8859-1?Q?M=E5ns_Nilsson?= , References: <3CFA09C8.8030008@unixpeople.com> <145480000.1023035909@slimsixten.pilsnet.sunet.se> Subject: Re: Mail-Transmitter RR Date: Sun, 2 Jun 2002 12:36:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Sorry, IMHO it breaks nothing. It is not a required RR it is a suggested one. If you cant SPAM in your mailbox fine, for those of us who do not it is an excellent idea. -al ----- Original Message ----- From: "Mns Nilsson" To: Sent: Sunday, June 02, 2002 12:38 PM Subject: Re: Mail-Transmitter RR > > > --On Sunday, June 02, 2002 05:04:24 -0700 "Andy W. Barclay" > wrote: > > > This is no different from the way 90% of the population of the Internet > > does things now. > > Perhaps 90% of the people on the Internet use Windows. Are you suggesting > we should force everyone to use Windows just because 90% of the people on > the Internet do so? > > The proposal(s) break(s) e-mail in fundamental and worrying ways, and make > the probability of e-mail delivery in adverse conditions much lower (think > backhoe incident on main internet connectivity, trigging the use of dialup > for backup connectivity, and nobody remembering to add that netblock to the > good, allowed ones). > > Us moderately and above clued people should not destroy the "survive-all" > capabilities of the Internet. There are others doing that much better. > > This is a bad suggestion, and it needs to be stopped. > > /Mns, who has a sendmail running on his laptop. > -- > Mns Nilsson Systems Specialist > +46 70 681 7204 KTHNOC MN1334-RIPE > > We're sysadmins. To us, data is a protocol-overhead. > > -- > to 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 Sun Jun 2 13:36:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17408 for ; Sun, 2 Jun 2002 13:36:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EZ6a-000Mxu-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 10:25:24 -0700 Received: from ws.couchpotato.net ([208.147.134.103] helo=couchpotato.net) by psg.com with smtp (Exim 3.36 #1) id 17EZ6U-000Mxc-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 10:25:18 -0700 Received: (qmail 13391 invoked from network); 2 Jun 2002 17:25:16 -0000 Received: from david.couchpotato.net (green@208.147.134.100) by ws.couchpotato.net with SMTP; 2 Jun 2002 17:25:16 -0000 Date: Sun, 2 Jun 2002 13:21:58 -0400 (EDT) From: David Green To: =?ISO-8859-1?Q?M=E5ns_Nilsson?= cc: namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR In-Reply-To: <145480000.1023035909@slimsixten.pilsnet.sunet.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-Spam-Status: No, hits=-6.5 required=5.0 tests=IN_REP_TO,PGP_SIGNATURE version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id NAA17408 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 2 Jun 2002, [ISO-8859-1] Mns Nilsson wrote: > The proposal(s) break(s) e-mail in fundamental and worrying ways, and make > the probability of e-mail delivery in adverse conditions much lower (think > backhoe incident on main internet connectivity, trigging the use of dialup > for backup connectivity, and nobody remembering to add that netblock to the > good, allowed ones). My idea doesn't break or change anything. It just allows endpoint SMTP servers to add a header to mail, which may or may not be examined by end-user MUAs. David Green -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8+lQ3Ci6CzkbyeRQRAtEEAJ9S60ydAihWpzqlOatQNuRIg+23kgCgiLgS ++WA3uBs8ZUJx3hn5qpGxyM= =iqi4 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 2 13:40:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17461 for ; Sun, 2 Jun 2002 13:40:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EZF2-000NOJ-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 10:34:08 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17EZEz-000NO4-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 10:34:05 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17EZEy-000Gh5-00; Sun, 02 Jun 2002 10:34:04 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: =?ISO-8859-1?Q?M=E5ns_Nilsson?= Cc: namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR References: <3CFA09C8.8030008@unixpeople.com> <145480000.1023035909@slimsixten.pilsnet.sunet.se> Message-Id: Date: Sun, 02 Jun 2002 10:34:04 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit thanks, mns. indeed, many of us don't run windoze and don't think colonial mail routing. the problem is that this is really a side-eddy to the spam maelstrom. this discussion is about all sorts of hacks to allow one to force the source of the mail to be honest about whence it comes. while this is nice, it is indirect and merely gives you a slight leg up on chasing ten thousand slimeballs. it is like trying to use source spoofing prevention to stop ddos attacks, a useful tool but not a real solution by a long shot. so how much should we mangle the net (prevent direct delivery of mail from laptops etc) for a partial approach to being able to assign responsibility to spammers who will ignore responsibility anyway? randy -- to unsubscribe send a message to namedroppers-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 Jun 2 13:42:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17479 for ; Sun, 2 Jun 2002 13:42:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EZDa-000NIk-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 10:32:38 -0700 Received: from citadel.cequrux.com ([192.96.22.18]) by psg.com with esmtp (Exim 3.36 #1) id 17EZDV-000NIR-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 10:32:34 -0700 Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id TAA03622 for ; Sun, 2 Jun 2002 19:32:17 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 3534; Sun Jun 2 19:31:25 2002 Date: Sun, 2 Jun 2002 19:31:24 +0200 From: Alan Barrett To: namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR Message-ID: <20020602173124.GD426@apb.cequrux.com> References: <20020602011637.CE9FC28EDD@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020602011637.CE9FC28EDD@as.vix.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, 01 Jun 2002, Paul Vixie wrote: > 2.1. Domain owners who wish their mail source/return information to be > repudiable will enter stylized MX RR's into their DNS data, whose owner > name is "MAIL-FROM", whose priority is zero, and whose servername > registers an outbound (border) relay for the domain. For example, to > tell the rest of the Internet who they should believe when they receive > mail claiming to be from VIXIE@ISC.ORG, the following DNS MX RR's should > be entered: > > $ORIGIN isc.org. > MAIL-FROM MX 0 rc > MX 0 rc1 I think that the magic label should begin with an underscore (e.g. "_MAIL-FROM"), for the same reasons that we use "_tcp" rather than just "tcp" as a label for SRV records. --apb (Alan Barrett) -- to unsubscribe send a message to namedroppers-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 Jun 2 13:54:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17631 for ; Sun, 2 Jun 2002 13:54:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EZTn-000OBb-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 10:49:23 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17EZTj-000OBN-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 10:49:19 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 120084; Sun, 02 Jun 2002 12:47:31 -0500 Message-ID: <3CFA5A9C.F6A9B157@ehsco.com> Date: Sun, 02 Jun 2002 12:49:16 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Paul Vixie CC: David Green , Mathias Koerber , Derek Atkins , Ted Lemon , namedroppers@ops.ietf.org, Mark.Andrews@isc.org Subject: Re: Mail-Transmitter RR References: <20020602165007.5309C28EDD@as.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > We would be overloading SRV just as much as the current proposal does MX. Moreover, it overloads SRV in a bizarro way, defining a client rather than a server. Avoid mangling the interpretation of SRV please, adoption is slow enough as it is. > More to the point, the patch to sendmail to implement MAIL-FROM is less > than 100 lines if MX is used. MX is not flexible enough by itself. At the very least, you also need a way to map PTR space to the sender domain such that EG anybody with a PTR of ehsco.com. is hereby authorized by me to send mail from @ehsco.com.[1] Also, having the ability to define specific hosts lets mobile users setup user.domain.dom mail domains on a dynamic basis, so you need a way to map in A/AAAA RRs as well. I think that all of the above illustrates why you really need a new RR using codes (as in the mail I forwarded earlier), rather using a static owner name. [1] Two subordinate issues with PTRs. First of all, there must be a mandatory forward-path verification of the PTR data, otherwise any idiot can add a PTR to their in-addr space and spoof me, which solves nothing. Second, remember that this option would only be definable by the owner of the domain, so it couldn't be used as a casual attack even when the forward lookups were not used. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-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 Jun 2 14:13:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17825 for ; Sun, 2 Jun 2002 14:13:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EZiY-000Ow8-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 11:04:38 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17EZiU-000Ovq-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 11:04:34 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 120088; Sun, 02 Jun 2002 13:02:46 -0500 Message-ID: <3CFA5E30.B0F9F7BA@ehsco.com> Date: Sun, 02 Jun 2002 13:04:32 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Randy Bush CC: =?iso-8859-1?Q?M=E5ns?= Nilsson , namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR References: <3CFA09C8.8030008@unixpeople.com> <145480000.1023035909@slimsixten.pilsnet.sunet.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=2.6 required=5.0 tests=NO_OBLIGATION version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush wrote: > so how much should we mangle the net (prevent direct delivery of mail > from laptops etc) for a partial approach to being able to assign > responsibility to spammers who will ignore responsibility anyway? I would suggest that the mail network is already mangled. This is a way to clean up my own little corner of the network with no impact to you. You would be under no obligation to do this for your own network, or to query my network. You can ignore it, just as you ignore any other scheme you do not want to participate with. The silver bullet exists, but in the form of a new message format and transfer protocol. Goooood luck with that one. Leathering through RBLs, reverse-path verification, keyword filters, distributed checksums, are all things that people use now. An authorized sender RR/owner/whatever is just another tool in the toolbelt. This one at least has the interesting property that it is voluntary, meaning that when it exists, it has more credibility than third-party mechanisms. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-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 Jun 2 14:42:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18124 for ; Sun, 2 Jun 2002 14:42:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EaAG-0000KF-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 11:33:16 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17EaAC-0000K0-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 11:33:12 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id EB13628EDD for ; Sun, 2 Jun 2002 11:33:11 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR In-Reply-To: Message from Randy Bush of "Sun, 02 Jun 2002 10:34:04 PDT." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Sun, 02 Jun 2002 11:33:11 -0700 Message-Id: <20020602183311.EB13628EDD@as.vix.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk there are three replies contained here, plus a big finish. -------- > From: Randy Bush > > the problem is that this is really a side-eddy to the spam maelstrom. > this discussion is about all sorts of hacks to allow one to force the > source of the mail to be honest about whence it comes. while this is > nice, it is indirect and merely gives you a slight leg up on chasing > ten thousand slimeballs. it is like trying to use source spoofing > prevention to stop ddos attacks, a useful tool but not a real solution > by a long shot. that's all spam-related and it's from the perspective of the recipient. this proposal is not about spam, and the primary expected beneficiaries are domain owners who presently have no power to repudiate forgeries of their intellectual property. at the moment, the "abuse@hotmail.com" mailbox is full beyond overflow, and 98% or more of the traffic is about incidents which hotmail's own customers and servers had nothing to do with. this is a DDoS against an isp abuse/support desk which protects the flow of the other 2%. > so how much should we mangle the net (prevent direct delivery of mail > from laptops etc) for a partial approach to being able to assign > responsibility to spammers who will ignore responsibility anyway? my laptop will still deliver mail directly, either because i'll send it from a domain with no MAIL-FROM, or because i'll use RFC2136 dynamic updates on my own A RR (note: this is not DHCP or PTR related!) when i travel. -------- > From: Alan Barrett > > > $ORIGIN isc.org. > > MAIL-FROM MX 0 rc > > MX 0 rc1 > > I think that the magic label should begin with an underscore > (e.g. "_MAIL-FROM"), for the same reasons that we use "_tcp" rather > than just "tcp" as a label for SRV records. i thought of that, but my concern is the number of extant getmxrr() library implementations who "just know" that a leading _ is invalid. randy and others would be quick to point out that such implementations are broken, but fixing them is going to add more inertia to the equation and it's a battle i'd rather postpone. MAIL-FROM is sufficiently unique (i grepped a few gig of mail logs and found no occurances) that it ought not have any collisions. i still remember the debate over the _ in _tcp and _udp with the SRV RR, and as an author of SRV i'd like to not tread that ground again so soon. -------- > From: "Eric A. Hall" > > > More to the point, the patch to sendmail to implement MAIL-FROM is less > > than 100 lines if MX is used. > > MX is not flexible enough by itself. At the very least, you also need a > way to map PTR space to the sender domain such that EG anybody with a PTR > of ehsco.com. is hereby authorized by me to send mail from @ehsco.com.[1] that's a strictly local configuration issue, as everything PTR-related must be and in every case will be. > Also, having the ability to define specific hosts lets mobile users setup > user.domain.dom mail domains on a dynamic basis, so you need a way to map > in A/AAAA RRs as well. see my comments above regarding my own laptop's choices in this scenario. > I think that all of the above illustrates why you really need a new RR > using codes (as in the mail I forwarded earlier), rather using a static > owner name. i think this debate illustrates why the ietf is so broken -- anyone can say no and there's nobody anywhere who can definitively say yes (witness A6/DNAME in IPv6, and RSA/DSA/RSA/DSA/etc in DNSSEC). my big plan is to get as many good ideas as possible from this community and then market this proposal in "ietf bypass mode". it's completely optional and specifies no wire protocol changes, and when it does finally come through the ietf it will be as a successful and widespread method which has become worthy of its own BCP. you are welcome to roll out a custom RR in parallel. BIND will support it, and i will adopt it on my own servers, and if it happens to work, we'll all be happier for it. but i rather expect that you'll be shot in the back every day for three years, told to use IPsec, told to use SSL, told to use PGP, told to use S/MIME, told you're approved, told you're not, and so on. -------- i keep thinking of how the world would be different if i'd helped jim miller get this proposal written and circulated back in 1998 when he thought of 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 Sun Jun 2 15:40:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18651 for ; Sun, 2 Jun 2002 15:40:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Eb6h-0003AO-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 12:33:39 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17Eb6e-0003AC-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 12:33:36 -0700 Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id DBCF51CC9; Sun, 2 Jun 2002 15:33:35 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id 62D2B5BA; Sun, 2 Jun 2002 11:39:44 +0000 (GMT) Date: Sun, 02 Jun 2002 13:39:43 +0200 From: Rob Austein To: "Art Shelest" Cc: namedroppers@ops.ietf.org Subject: Re: In-Reply-To: <8BD7226E07DDFF49AF5EF4030ACE0B7E04569FD0@red-msg-06.redmond.corp.microsoft.com> References: <8BD7226E07DDFF49AF5EF4030ACE0B7E04569FD0@red-msg-06.redmond.corp.microsoft.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigorymae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020602113944.62D2B5BA@thangorodrim.hactrn.net> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Sat, 1 Jun 2002 18:05:43 -0700, Art Shelest wrote: > > Secure name resolution question: is there an existing mechanism that > permits configuring DNS server to only resolve name X for authorized > clients? > > For example, I would like to have www.example.com only be resolvable by > members of a specific group, and make it "invisible" to others. This was an explict non-goal for DNSSEC (RFC 2535 et seq). DNSSEC explicitly does not attempt to provide confidentiality. You could probably hack together something based on TSIG (RFC 2845). It wouldn't scale, and I wouldn't advise it, but it's your life.... -- to unsubscribe send a message to namedroppers-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 Jun 2 16:39:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19057 for ; Sun, 2 Jun 2002 16:39:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EbzM-00062D-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 13:30:08 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17EbzI-00061x-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 13:30:04 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 120090; Sun, 02 Jun 2002 15:28:16 -0500 Message-ID: <3CFA8049.9772806B@ehsco.com> Date: Sun, 02 Jun 2002 15:30:01 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR References: <20020602183311.EB13628EDD@as.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > this proposal is not about spam, and the primary expected beneficiaries > are domain owners who presently have no power to repudiate forgeries of > their intellectual property. Bingo. It's about me being the master of my own freaking domain. As to your plan, I think there is certainly merit to doing it as a private agreement type of thing first. We can see how well it works without burning cycles on the IETF (my own suspicion is that it will be popular with small networks, but unpopular with hotmail et al). If it works, we'll have better understanding for future efforts, and without having to worry about collisions. Not to mention the "running code" value. Having said all of that, I truly despise the MAIL-FROM label. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-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 Jun 2 17:32:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19501 for ; Sun, 2 Jun 2002 17:32:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Eclb-0008aE-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 14:19:59 -0700 Received: from yoyo.akc.com ([192.188.192.5]) by psg.com with esmtp (Exim 3.36 #1) id 17EclY-0008Zt-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 14:19:56 -0700 Received: from backup ([65.195.106.55]) by yoyo.akc.com (8.9.3/8.9.3) with SMTP id RAA31213; Sun, 2 Jun 2002 17:19:44 -0400 Message-ID: <002c01c20a77$a610cca0$376ac341@akc.com> From: "Al Costanzo" To: "Eric A. Hall" , "Paul Vixie" Cc: References: <20020602183311.EB13628EDD@as.vix.com> <3CFA8049.9772806B@ehsco.com> Subject: Re: Mail-Transmitter RR Date: Sun, 2 Jun 2002 16:54:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If the IETF system is not completely broken as I suspect it is. I do not see why the draft could not be written, given to the RFC Editor to publish as Experimental and then move it to a working group to get it onto standards track at a later date. If my memory serves me properly (and I am getting on in years now), this is what Experimental was all about. -Al ----- Original Message ----- From: "Eric A. Hall" To: "Paul Vixie" Cc: Sent: Sunday, June 02, 2002 4:30 PM Subject: Re: Mail-Transmitter RR > > Paul Vixie wrote: > > > this proposal is not about spam, and the primary expected beneficiaries > > are domain owners who presently have no power to repudiate forgeries of > > their intellectual property. > > Bingo. It's about me being the master of my own freaking domain. > > As to your plan, I think there is certainly merit to doing it as a private > agreement type of thing first. We can see how well it works without > burning cycles on the IETF (my own suspicion is that it will be popular > with small networks, but unpopular with hotmail et al). If it works, we'll > have better understanding for future efforts, and without having to worry > about collisions. Not to mention the "running code" value. > > Having said all of that, I truly despise the MAIL-FROM label. > > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ > > -- > to 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 Sun Jun 2 18:02:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19740 for ; Sun, 2 Jun 2002 18:02:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EdBz-000A4J-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 14:47:15 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17EdBv-000A44-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 14:47:11 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id A68D928EDD for ; Sun, 2 Jun 2002 14:47:10 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR In-Reply-To: Message from "Al Costanzo" of "Sun, 02 Jun 2002 16:54:11 EDT." <002c01c20a77$a610cca0$376ac341@akc.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Sun, 02 Jun 2002 14:47:10 -0700 Message-Id: <20020602214710.A68D928EDD@as.vix.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk let's not all start worrying about the wrong things here. > > As to your plan, I think there is certainly merit to doing it as a > > private agreement type of thing first. We can see how well it works > > without burning cycles on the IETF (my own suspicion is that it will > > be popular with small networks, but unpopular with hotmail et > > al). If it works, we'll have better understanding for future > > efforts, and without having to worry about collisions. Not to > > mention the "running code" value. > If the IETF system is not completely broken as I suspect it is. I do > not see why the draft could not be written, given to the RFC Editor to > publish as Experimental and then move it to a working group to get it > onto standards track at a later date. > > If my memory serves me properly (and I am getting on in years now), > this is what Experimental was all about. two things. first, experimental means that the people who have ietf secret decoder rings weren't properly involved and so they now wish your protocol had never existed. SRV is an example, even though win2k and kerberos use it in production and have wide deployment bases. second, getting an RFC number can in some cases help with deployment even if the status is experimental, but this is not one of those cases. it was nec'y with SRV because the behaviour wasn't going to be optional, and interoperability of wire formatting was a requirement. once i'm satisfied that every technical contribution has been made (short of "this needs its own RR type and wire format") and considered and that the proposal isn't just plain bad, i'll submit it to the rfc editor as experimental, and then in parallel i will market it on my own. years will go by during which the ietf will do nothing, except perhaps launch its own deeper effort while rejecting the experimental rfc on the grounds that it's an end run around the standards process. later, we'll all have forgotten about this. but if it succeeds anyway, then i will resubmit it to the ietf as a BCP, since by "success" that's what i'll mean. i hope this doesn't come across as bitter. several people have tried to give me my very own ietf secret decoder ring over the years, but though i have tried, i mostly can't figure out how it's supposed to work. (all real progress is either decoder-ring-friendly like IXFR/NOTIFY/UPDATE, or it's decoder-ring-unfriendly like IMAP and SRV and ICP and HTCP.) in case my own preferences are unclear, i killed BIND's UID and GID RRtypes as well as mike schwartz's pre-standard dynamic update support, even though a whole lot of people were using them, and i did it because things on the wire have to be, in my way of looking at things, standardized. MAIL-FROM adds nothing to any wire format, so i'm willing to take a BCP path to 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 Sun Jun 2 22:05:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22378 for ; Sun, 2 Jun 2002 22:05:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Eh2W-000M8W-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 18:53:44 -0700 Received: from smtprelay7.dc2.adelphia.net ([64.8.50.39]) by psg.com with esmtp (Exim 3.36 #1) id 17Eh2R-000M8G-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 18:53:39 -0700 Received: from ZANNIE ([216.174.53.189]) by smtprelay7.dc2.adelphia.net (Netscape Messaging Server 4.15 smtprelay7 Dec 7 2001 09:58:59) with ESMTP id GX3X9B00.VSP; Sun, 2 Jun 2002 21:53:35 -0400 Date: Sun, 2 Jun 2002 21:53:27 -0400 From: Allan Liska X-Mailer: The Bat! (v1.53d) Personal Reply-To: Allan Liska Organization: http://www.allan.org X-Priority: 3 (Normal) Message-ID: <83172118033.20020602215327@allan.org> To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR In-Reply-To: <20020602165007.5309C28EDD@as.vix.com> References: <20020602165007.5309C28EDD@as.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Sunday, June 02, 2002, 12:50:07 PM, Paul wrote: PV> I've strengthened the wording on [MAILFROM 2.2] which now reads: PV> 2.2. Second-stage relays such as ISP mail servers are often used and can PV> be described by adding as many relays as necessary to the MAIL-FROM MX PV> RRset. In our example, if ISC sometimes used UUNET for outbound mail PV> services, the DNS data describing this relationship might be as follows: PV> $ORIGIN isc.org. PV> MAIL-FROM MX 0 rc PV> MX 0 rc1 PV> MX 0 uunet.uu.net. PV> Let it be noted that a domain owner's power to repudiate forged e-mail PV> is only as strong as the security policy of its registered inbound and PV> outbound mail relays, and that if such a relay is (for example) open to PV> third party relay, then no value will be added by registering a domain PV> MAIL-FROM MX containing that relay, and no inbound MAIL-FROM checking PV> will be possible on final delivery relays for a domain @ MX containing PV> that relay. Multistage relays (both inbound and outbound) are a PV> breeding ground for anonymity unless they are very carefully configured. PV> I think that there's a LOT of help to be had from this, amongst anonymous PV> but cooperating domain owners and relay owners. I'm not pushing this as PV> the one true way to stop all spam for all time, because I don't think there PV> is any such. It's an optional, low-impact way to protect folks like hotmail PV> from widespread forgery. Probably it won't slow spam down one whit, but it PV> will reduce the overall injury from spam. There are a couple of problems I see with this. One may not be a problem at all, but here goes. In the example you used above, and I am sure this is the same with many large ISPs, UUNET's mail server, mail.uu.net, is actually 5 different machines: mail.uu.net. 300 IN A 199.171.54.106 mail.uu.net. 300 IN A 199.171.54.122 mail.uu.net. 300 IN A 199.171.54.245 mail.uu.net. 300 IN A 199.171.54.246 mail.uu.net. 300 IN A 199.171.54.98 If I add mail.uu.net as one my MAIL-FROM records, but the server delivering the message is actually ashd1-2.relay.mail.uu.net, is that message going to be rejected? I don't imagine most DNS "administrators" will know that mail.uu.net is really multiple servers. Secondly, doesn't this have the potential to be abused by mail administrators that only kinda-sorta know what they are doing? If a mail administrator decides s/he doesn't want to accept mail from anyone without a MAIL-FROM record, then it is no longer a voluntary action. Or is that not going to be part of the functionality? I hope these made sense. allan -- allan allan@allan.org http://www.allan.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 Jun 2 22:36:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23010 for ; Sun, 2 Jun 2002 22:36:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EhaV-000Nxg-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 19:28:51 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17EhaI-000Nwf-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 19:28:38 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 1F3B228EDD for ; Sun, 2 Jun 2002 19:28:38 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR In-Reply-To: Message from Allan Liska of "Sun, 02 Jun 2002 21:53:27 EDT." <83172118033.20020602215327@allan.org> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Sun, 02 Jun 2002 19:28:38 -0700 Message-Id: <20020603022838.1F3B228EDD@as.vix.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > In the example you used above, and I am sure this is the same with > many large ISPs, UUNET's mail server, mail.uu.net, is actually 5 > different machines: > > mail.uu.net. 300 IN A 199.171.54.106 > mail.uu.net. 300 IN A 199.171.54.122 > mail.uu.net. 300 IN A 199.171.54.245 > mail.uu.net. 300 IN A 199.171.54.246 > mail.uu.net. 300 IN A 199.171.54.98 > > If I add mail.uu.net as one my MAIL-FROM records, but the server > delivering the message is actually ashd1-2.relay.mail.uu.net, is that > message going to be rejected? I don't imagine most DNS > "administrators" will know that mail.uu.net is really multiple > servers. i note that the server you mentioned... ;; ANSWER SECTION: ashd1-2.relay.mail.uu.net. 59m34s IN A 199.171.54.246 ...has the same address as one of the mail.uu.net A RR's. so, the published psuedocode... repudiated(mailfrom, ipsource) = { (lhs, rhs) = parse_addr(mailfrom); mxset = get_mx("MAIL-FROM" "." rhs); if (mxset == NULL) return FALSE; mxset += configured(perimeter_relays); foreach mx (mxset) { aset = get_a(mx.server); if (ipsource IN aset) return FALSE; } return TRUE; } ...would indeed permit your mail to come from that host if all you added to your own domain's MAIL-FROM MX RR was "mail.uu.net". this kind of address antialiasing can be a problem, as witnessed by the PTR RR for this address... ;; ANSWER SECTION: 246.54.171.199.in-addr.arpa. 1H IN PTR ashd1-2.relay.mail.uu.net. ...which can only point to one name even though two names are usable. however, it's not a problem for the MAIL-FROM proposal as written. > Secondly, doesn't this have the potential to be abused by mail > administrators that only kinda-sorta know what they are doing? no moreso than DNS itself. i just "tail"'d my daemon.log file and saw... Jun 3 02:22:36 isrv3 named[184]: wrong ans. name \ (. != 10.7.118.135.in-addr.arpa) Jun 3 02:22:36 isrv3 named[184]: invalid RR type 'PTR' in authority section \ (name = '10.7.118.135.in-addr.arpa') from [192.11.222.170].53 Jun 3 02:22:36 isrv3 named[184]: invalid RR type 'NS' in additional section \ (name = '7.118.135.in-addr.arpa') from [192.11.222.170].53 ...that even without this new-fangled MAIL-FROM business, either a sysadmin or a protocol implementor (or most likely, both) are able to get the power cord wrapped around both legs while trying to drill this hole. > If a mail administrator decides s/he doesn't want to accept mail from > anyone without a MAIL-FROM record, then it is no longer a voluntary > action. ... internet communication is bilaterally consensual, or doesn't occur at all. if a mail server operator doesn't want to accept mail from me because i don't have a MAIL-FROM, then no power on earth can compel them otherwise. -- to unsubscribe send a message to namedroppers-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 Jun 2 23:01:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23368 for ; Sun, 2 Jun 2002 23:01:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EhyL-000PD7-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 19:53:29 -0700 Received: from ws.couchpotato.net ([208.147.134.103] helo=couchpotato.net) by psg.com with smtp (Exim 3.36 #1) id 17EhyH-000PCq-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 19:53:25 -0700 Received: (qmail 14058 invoked from network); 3 Jun 2002 02:53:23 -0000 Received: from david.couchpotato.net (green@208.147.134.100) by ws.couchpotato.net with SMTP; 3 Jun 2002 02:53:23 -0000 Date: Sun, 2 Jun 2002 22:49:57 -0400 (EDT) From: David Green To: Allan Liska cc: Paul Vixie , Subject: Re: Mail-Transmitter RR In-Reply-To: <83172118033.20020602215327@allan.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.5 required=5.0 tests=IN_REP_TO,PGP_SIGNATURE version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 2 Jun 2002, Allan Liska wrote: > If I add mail.uu.net as one my MAIL-FROM records, but the server > delivering the message is actually ashd1-2.relay.mail.uu.net, is that > message going to be rejected? I don't imagine most DNS > "administrators" will know that mail.uu.net is really multiple > servers. I really don't see any choice but to authorize by IP address rather than by hostname, not only for security reasons, but also to avoid a double query for each incoming mail; one is quite enough. I'm still trying to figure out how to handle an ISP that would like to designate a range of IPs as valid senders, or one that has a very large number of valid senders. > mail administrator decides s/he doesn't want to accept mail from > anyone without a MAIL-FROM record, then it is no longer a voluntary > action. Or is that not going to be part of the functionality? That would not be part of the functionality in my proposal, although I think it would be in Paul's. Any filtering would be the choice of the end user (assisted by their MUA). This choice was made to avoid the situation that you have mentioned here. David Green -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8+tlYCi6CzkbyeRQRAi/7AKDCfxQQ9Ydgu+VtEOtcVwkbqsEtKgCfaaBA eab1ufxMQkuD6OvRrW7s+Gs= =VkDo -----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 Jun 3 01:59:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25705 for ; Mon, 3 Jun 2002 01:59:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EkiN-0007PQ-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 22:49:11 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17EkiJ-0007PC-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 22:49:07 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 3A1F028EDD for ; Sun, 2 Jun 2002 22:49:03 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR In-Reply-To: Message from David Green of "Sun, 02 Jun 2002 22:49:57 EDT." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Sun, 02 Jun 2002 22:49:03 -0700 Message-Id: <20020603054903.3A1F028EDD@as.vix.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I really don't see any choice but to authorize by IP address rather than > by hostname, not only for security reasons, but also to avoid a double > query for each incoming mail; one is quite enough. fortunately for all of us, two queries are rarely needed. let's watch dig: ;; ANSWER SECTION: uu.net. 1H IN MX 10 external-mail-router.uu.net. ;; AUTHORITY SECTION: uu.net. 1H IN NS auth00.ns.uu.net. uu.net. 1H IN NS auth60.ns.uu.net. uu.net. 1H IN NS auth200.ns.uu.net. uu.net. 1H IN NS auth210.ns.uu.net. ;; ADDITIONAL SECTION: external-mail-router.uu.net. 5M IN A 198.5.241.38 external-mail-router.uu.net. 5M IN A 198.5.241.40 external-mail-router.uu.net. 5M IN A 198.5.241.39 auth00.ns.uu.net. 1H IN A 198.6.1.65 auth60.ns.uu.net. 1H IN A 198.6.1.181 auth200.ns.uu.net. 1H IN A 195.129.12.82 auth210.ns.uu.net. 1H IN A 195.129.12.74 by god, look at all those A RR's. i guess we won't be needing a second query, huh? as for security reasons, i'm going to quote the pseudocode from my proposal one more time, so you can see that addresses are indeed used. i know that it seems, from reading the rest of what's been written on this thread, that i must be interested in parsing headers and in comparing hostnames. but if you read the proposal itself you'll see that i'm advocating no such thing. repudiated(mailfrom, ipsource) = { (lhs, rhs) = parse_addr(mailfrom); mxset = get_mx("MAIL-FROM" "." rhs); if (mxset == NULL) return FALSE; mxset += configured(perimeter_relays); foreach mx (mxset) { aset = get_a(mx.server); if (ipsource IN aset) return FALSE; } return TRUE; } for the record, i'm through with quoting excerpts from the proposal, and any questions which could have been answered by reading all four short pages of the document, will hereinafter be ignored by me. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 3 02:23:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04575 for ; Mon, 3 Jun 2002 02:23:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17El8l-0008dt-00 for namedroppers-data@psg.com; Sun, 02 Jun 2002 23:16:27 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17El8h-0008dR-00 for namedroppers@ops.ietf.org; Sun, 02 Jun 2002 23:16:23 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17El8h-000Hgw-00; Sun, 02 Jun 2002 23:16:23 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR References: <20020603054903.3A1F028EDD@as.vix.com> Message-Id: Date: Sun, 02 Jun 2002 23:16:23 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > by god, look at all those A RR's. i guess we won't be needing a second > query, huh? add sigs and stir randy -- to unsubscribe send a message to namedroppers-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 Jun 3 07:49:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08823 for ; Mon, 3 Jun 2002 07:49:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EqBe-000O65-00 for namedroppers-data@psg.com; Mon, 03 Jun 2002 04:39:46 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17EqBb-000O5o-00 for namedroppers@ops.ietf.org; Mon, 03 Jun 2002 04:39:43 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08590; Mon, 3 Jun 2002 07:39:13 -0400 (EDT) Message-Id: <200206031139.HAA08590@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2539bis-dhk-02.txt Date: Mon, 03 Jun 2002 07:39:12 -0400 X-Spam-Status: No, hits=0.8 required=5.0 tests=NO_REAL_NAME,TO_MALFORMED,EXCUSE_6 version=2.20 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 : Storage of Diffie-Hellman Keys in the Domain Name System (DNS) Author(s) : D. Eastlake Filename : draft-ietf-dnsext-rfc2539bis-dhk-02.txt Pages : 9 Date : 31-May-02 A standard method for storing Diffie-Hellman keys in the Domain Name System is described which utilizes DNS KEY resource records. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rfc2539bis-dhk-02.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-rfc2539bis-dhk-02.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: <20020531145918.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2539bis-dhk-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020531145918.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 Mon Jun 3 07:51:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08927 for ; Mon, 3 Jun 2002 07:51:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EqAE-000O0O-00 for namedroppers-data@psg.com; Mon, 03 Jun 2002 04:38:18 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17EqA8-000Nzk-00 for namedroppers@ops.ietf.org; Mon, 03 Jun 2002 04:38:12 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08321; Mon, 3 Jun 2002 07:37:42 -0400 (EDT) Message-Id: <200206031137.HAA08321@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2536bis-dsa-02.txt Date: Mon, 03 Jun 2002 07:37:42 -0400 X-Spam-Status: No, hits=0.8 required=5.0 tests=NO_REAL_NAME,TO_MALFORMED,EXCUSE_6 version=2.20 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 : DSA KEYs and SIGs in the Domain Name System (DNS) Author(s) : D. Eastlake Filename : draft-ietf-dnsext-rfc2536bis-dsa-02.txt Pages : 7 Date : 31-May-02 A standard method for storing US Government Digital Signature Algorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rfc2536bis-dsa-02.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-rfc2536bis-dsa-02.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: <20020531131603.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2536bis-dsa-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020531131603.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 Mon Jun 3 09:48:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13038 for ; Mon, 3 Jun 2002 09:48:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ErxQ-0004Ll-00 for namedroppers-data@psg.com; Mon, 03 Jun 2002 06:33:12 -0700 Received: from portal.east.saic.com ([198.151.13.15]) by psg.com with smtp (Exim 3.36 #1) id 17ErxJ-0004L0-00 for namedroppers@ops.ietf.org; Mon, 03 Jun 2002 06:33:05 -0700 Received: from mclmx.saic.com by portal.east.saic.com via smtpd (for psg.com [147.28.0.62]) with SMTP; 3 Jun 2002 13:33:05 UT Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Mon, 3 Jun 2002 09:32:52 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002060309325127176 ; Mon, 03 Jun 2002 09:32:51 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Jun 2002 09:32:47 -0400 Message-Id: <3C1E3607B37295439F7C409EFBA08E680E2B86@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: "'Rob Austein'" , Art Shelest Cc: namedroppers@ops.ietf.org Subject: Access controls on DNS queries (was RE: [no subject]) Date: Mon, 3 Jun 2002 09:33:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.1 required=5.0 tests=PORN_10 version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sunday, 02 June, 2002 06:40, Rob Austein wrote: > At Sat, 1 Jun 2002 18:05:43 -0700, Art Shelest wrote: > > > > Secure name resolution question: is there an existing mechanism that > > permits configuring DNS server to only resolve name X for authorized > > clients? Short answer: Yes--this is implemented in BIND 8/9 and in other independent code bases--the primary implementation of which I'm aware is in BIND. Establish an ACL for specific authorized clients (authorization either to "those in netblock XXX" or "those who hold TSIG key XXX"). Then use either "views" (BIND 9 only) or "allow-query{}" to allow/deny access to specific data. If there is a single zone that will contain both "public" and "private" data records (similar to what Axent Raptor FW DNS provides) then use views--if the limitation is on a zone-by-zone basis then one could simply use allow-query{} (but views might be a better choice if BIND 9 is to be used). There's no capability to effectively do this sort of thing in any current MS product...but if you're going to add it (in an interoperable way) then I have a rather large customer who would love to know more...since the lack of this functionality in MS products causes much wailing and gnashing of teeth. > > For example, I would like to have www.example.com only be > > resolvable by members of a specific group, and make it > > "invisible" to others. > This was an explict non-goal for DNSSEC (RFC 2535 et seq). DNSSEC > explicitly does not attempt to provide confidentiality. True, but he didn't ask for confidentiality on the wire--or if that was what he wanted then it wasn't clear. I read it as asking about access control on specific data--it's not an uncommon request/ problem. > You could probably hack together something based on TSIG (RFC 2845). > It wouldn't scale, and I wouldn't advise it, but it's your life.... Actually, if it's for MS and it starts out based on GSS-TSIG, then it likely would scale...it just wouldn't be highly interoperable. (Note that GSS-TSIG as currently implemented in Win2K/XP is supported only for secure dynamic update--not for protection/authentication of zone transfers or regular query/response traffic. It would appear that all Art needs is to extend the existing GSS-TSIG implementation to also protect these other common DNS transactions, and then provide a pointy-clicky GUI to configure the access controls.) -- Rip Loomis Senior Systems Security Engineer SAIC Secure Business Solutions Group www.saic.com/securebiz Center for Information Security Technology www.cist-east.saic.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 Jun 3 12:48:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22669 for ; Mon, 3 Jun 2002 12:48:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EulV-000EXH-00 for namedroppers-data@psg.com; Mon, 03 Jun 2002 09:33:05 -0700 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 17EulR-000EWi-00; Mon, 03 Jun 2002 09:33:01 -0700 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g53GSkp00132; Mon, 3 Jun 2002 09:28:46 -0700 (PDT) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Jun 2002 09:34:18 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869AE5@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Eric A. Hall'" , Randy Bush Cc: =?iso-8859-1?Q?M=E5ns_Nilsson?= , namedroppers@ops.ietf.org Subject: RE: Mail-Transmitter RR Date: Mon, 3 Jun 2002 09:34:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Leathering through RBLs, reverse-path verification, keyword filters, > distributed checksums, are all things that people use now. An > authorized > sender RR/owner/whatever is just another tool in the > toolbelt. I think that this is the key to adoption, think of incentives that are created that drive adoption. Any protocol change that requires mass adoption before it provides value is going to be a hard sell. I think that the problem of SPAM needs more than just a DNS tweak or two. I think that we need to take a more systemic approach, work out what it would take to build a mail network that severely discourages SPAM, claculate the delta to what we have today, work out a migration plan that delivers value to adopters each step of the way. Email messaging has in any case been in need of an overhaul for a long time. SMTP has suffered the fate of many 'simple' protocols, inadequate analysis of the requirements and under-engineering of the initial specification has lead to numerous ad-hoc extensions and work arrounds with the result that we don't have a standard, we have a set of heuristics. Handling of mailing lists is particularly broken. What we need is some sort of summit that brings together the people working on the various parts of SPAN control strategy. Real Time Blacklists are not a long term solution that many are invested in, especially as the scum attempt to litigate their way off lists with strategic lawsuits. First consider the possible incentives for adoption of spam control infrastructure for the sender: 1) Reduced probability of appearing on Real Time Blacklist 2) Allow recovery from the stolen email address problem in which a spammer uses a genuine email address (often taken from a mailing list) to send SPAM, thus causing the email address to become unusable due to complaint backlash. 3) Comply with regulatory controls Yes I know these are unpopular in the states, however, coertion is a legitimate tool and coertion by democratic elected governments is preferable to coertion by unelected self appointed vigilantes which is what we often have with black lists. 3a) Discourage imposition of regulatory controls The US version of argument 3... 4) Reduce the cost of email management. 5) Reduce the number of messages that are erroneously rejected BTW I don't believe that configuration alone will lead to blacklists becomming unnecessary. I have personal experience of an Israeli ISP which bombarded me with SIRCAM virus and refused to cut off their 'subscriber' (I suspect that it was the ISP network administrators) until threatened with blacklisting. I think that architecturally we need to take a systemic approach that includes such components as: 1) Means of authenticating origination points. These are likely to involve both public key techniques and IP filtering techniques Public key mechanisms are likely to involve both authentication of the services (via SSL) and authentication of actual messages. Here we need to fullfil a longstanding hole in the email security world, establishing an authentifiable binding between the email security mechanism and the DNS system: IE if I want to send email to warlord@mit.edu I should be able to query mit.edu, pull up an SRV record for a key location service (no not a directory, LDAP is not a good place to put PGP keys and a pretty bad place for X.509 certificates). The key location service gives me a chain of PGP keys which I then forward to my validation engine to get out a raw key and a policy (Derek signs all his mails so reject unsigned mail as SPAM). Equally if you look me up via the SRV record of Verisign you will get an X.509 certificate and a policy (I sign all my mail too). 2) Means of advertising origination policy. The Mail From: hack described by Paul is essentially a means of advertising policy, it is similar to work that has been going on in the context of Web Services security, how do I advertise the fact that my service always authenticates its responses or accepts a certain level of security enhancement to prevent downgrade attacks? The technical mechanisms employed to support these mechanisms are likely to include: 1) DNSSEC (solve the SPAM problem and you have a killer app for DNSSEC) 2) DNS Records Possibly the SRV record to a client oriented service Possibly new records that are client oriented 3) PKI in the form of PGP, X.509 and possibly SPKI 4) XKMS responders to navigate the disparate PKI infrastructures on behalf of clients Possibly the XKMS protocol is extended to support publication of security policies. 5) Clients with enhanced SPAM rejection capabilities leveraging the above. 6) Mail server with enhanced SPAM rejection leveraging the above. Phill -- to unsubscribe send a message to namedroppers-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 Jun 3 14:15:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26065 for ; Mon, 3 Jun 2002 14:15:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ew7V-000JdQ-00 for namedroppers-data@psg.com; Mon, 03 Jun 2002 10:59:53 -0700 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74] helo=fxodpr10.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 3.36 #1) id 17Ew7Q-000Jd8-00 for namedroppers@ops.ietf.org; Mon, 03 Jun 2002 10:59:48 -0700 Received: (from uucp@localhost) by fxodpr10.extra.daimlerchrysler.com (8.11.4/8.9.0) id g53Hv2f27494 for ; Mon, 3 Jun 2002 13:57:02 -0400 (EDT) Received: from nodnsquery(129.9.202.19) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAANaOS1; Mon, 3 Jun 02 13:57:02 -0400 Received: from wokcdts1.is.chrysler.com (wokcdts1-eri0-1.is.chrysler.com [53.230.102.56]) by odmrspr1-pf0.oddc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id g53Hxl517828 for ; Mon, 3 Jun 2002 13:59:47 -0400 (EDT) Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.61]) by wokcdts1.is.chrysler.com (8.11.2/8.9.1) with ESMTP id g53HwYU17748 for ; Mon, 3 Jun 2002 13:58:34 -0400 (EDT) Message-ID: <3CFBAE4A.AD23CD1F@daimlerchrysler.com> Date: Mon, 03 Jun 2002 13:58:34 -0400 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: References: <8BD7226E07DDFF49AF5EF4030ACE0B7E04569FD0@red-msg-06.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Art Shelest wrote: > Hi: > > Secure name resolution question: is there an existing mechanism that > permits > configuring DNS server to only resolve name X for authorized clients? > > For example, I would like to have www.example.com only be resolvable by > members of a specific group, and make it "invisible" to others. I assume by "invisible" you mean that the nameserver responds that the name doesn't exist, as opposed to REFUSE'ing the query, which would let the "forbidden" clients know that something is there (?) You could define those "special" names as zones by themselves, and then define separate "view"s for the "permitted" versus the "forbidden" clients. This would require BIND 9, which supports "view". Note, however, that this would be a lot of work to set up and maintain, since *every* existing zone on the nameserver would need to be defined and maintained in each "view" (but you may be able to play multiple-references-to-the-same-file or $INCLUDE-file games to make your life easier in this regard...). - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 3 14:29:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26515 for ; Mon, 3 Jun 2002 14:29:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EwSK-000Kvc-00 for namedroppers-data@psg.com; Mon, 03 Jun 2002 11:21:24 -0700 Received: from gemma.techfak.uni-bielefeld.de ([129.70.136.103]) by psg.com with esmtp (Exim 3.36 #1) id 17EwSA-000Kv6-00 for namedroppers@ops.ietf.org; Mon, 03 Jun 2002 11:21:14 -0700 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by gemma.TechFak.Uni-Bielefeld.DE (8.9.1/8.9.1/TechFak/pk+ro20010720) with SMTP id UAA12524 for ; Mon, 3 Jun 2002 20:21:09 +0200 (MET DST) Received: from localhost by grimsvotn.TechFak.Uni-Bielefeld.DE (SMI-8.6/pk19971205) id UAA19881; Mon, 3 Jun 2002 20:21:09 +0200 Message-Id: <200206031821.UAA19881@grimsvotn.TechFak.Uni-Bielefeld.DE> To: namedroppers@ops.ietf.org Subject: ``Secure name resolution'' [Re: ] In-reply-to: Your message of "Mon, 03 Jun 2002 13:58:34 EDT." <3CFBAE4A.AD23CD1F@daimlerchrysler.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Mon, 03 Jun 2002 20:21:09 +0200 From: Peter Koch X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, > > For example, I would like to have www.example.com only be resolvable by > > members of a specific group, and make it "invisible" to others. [...] > You could define those "special" names as zones by themselves, and then > define separate "view"s for the "permitted" versus the > "forbidden" clients. This would require BIND 9, which supports "view". while all these implementation specific solutions (hacks, YMMV) exist, they are applicable in limited scenarios only. There is no interoperable way to communicate scopes or views between primary and secondary nameservers, since the amount of metadata exchanged in a zone transfer is limited to what the SOA RR can carry. -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 Mon Jun 3 15:00:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27649 for ; Mon, 3 Jun 2002 15:00:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ewua-000Mhu-00 for namedroppers-data@psg.com; Mon, 03 Jun 2002 11:50:36 -0700 Received: from outpost.ds9a.nl ([213.244.168.210]) by psg.com with esmtp (Exim 3.36 #1) id 17EwuU-000MhY-00 for namedroppers@ops.ietf.org; Mon, 03 Jun 2002 11:50:30 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 9077044E0; Mon, 3 Jun 2002 20:50:25 +0200 (CEST) Date: Mon, 3 Jun 2002 20:50:25 +0200 From: bert hubert To: "Loomis, Rip" Cc: "'Rob Austein'" , Art Shelest , namedroppers@ops.ietf.org Subject: Re: Access controls on DNS queries (was RE: [no subject]) Message-ID: <20020603185025.GA18344@outpost.ds9a.nl> References: <3C1E3607B37295439F7C409EFBA08E680E2B86@US-Columbia-CIST.mail.saic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C1E3607B37295439F7C409EFBA08E680E2B86@US-Columbia-CIST.mail.saic.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Jun 03, 2002 at 09:33:09AM -0400, Loomis, Rip wrote: > Actually, if it's for MS and it starts out based on GSS-TSIG, then > it likely would scale...it just wouldn't be highly interoperable. There are a lot of GSS-TSIG documents out there currently and it looks like there is enough available to write an implementation. But it has proved too complex for us to determine this within a working day of trying to make sense of what is what, and if everything is there. Does anybody know if it is theoretically possible to interoperate with GSS-TSIG from something that is not written on Windows or tightly integrated with it? We'd love to be able to authenticate the origin of W2K dynamic updates and authorize them. Regards, bert hubert PowerDNS -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO -- to unsubscribe send a message to namedroppers-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 Jun 3 15:07:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27894 for ; Mon, 3 Jun 2002 15:07:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ex2B-000NAn-00 for namedroppers-data@psg.com; Mon, 03 Jun 2002 11:58:27 -0700 Received: from limes.nic.dtag.de ([194.25.1.113]) by psg.com with esmtp (Exim 3.36 #1) id 17Ex26-000NAR-00 for namedroppers@ops.ietf.org; Mon, 03 Jun 2002 11:58:22 -0700 Received: from kronos.NIC.DTAG.DE (kronos.NIC.DTAG.DE [194.25.1.92]) by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id UAA11071; Mon, 3 Jun 2002 20:57:39 +0200 (MET DST) Received: (from uz@localhost) by kronos.NIC.DTAG.DE (8.8.5/8.7.1) id UAA22734 for office@k1-web.com; Mon, 3 Jun 2002 20:23:54 +0200 (MET DST) From: pk@TechFak.Uni-Bielefeld.DE To: pk@TechFak.Uni-Bielefeld.DE Cc: dns@VISEMA.AT, office@VISEMA.AT, hostmaster@hotmail.com, admin@storm.ca, hostmaster@systemscope.com, hostmaster@yahoo-inc.com, szaam@euol.com Reply-To: pk@TechFak.Uni-Bielefeld.DE X-Defender: topreventfromreceivingmyownmailrcg49320a Received: from limes.NIC.DTAG.DE (limes.NIC.DTAG.DE [194.25.1.113]) by kronos.NIC.DTAG.DE (8.8.5/8.7.1) with ESMTP id UAA22729 for ; Mon, 3 Jun 2002 20:23:53 +0200 (MET DST) Received: from psg.com (exim@psg.com [147.28.0.62]) by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id UAA10831 for ; Mon, 3 Jun 2002 20:23:11 +0200 (MET DST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EwSK-000Kvc-00 for namedroppers-data@psg.com; Mon, 03 Jun 2002 11:21:24 -0700 Received: from gemma.techfak.uni-bielefeld.de ([129.70.136.103]) by psg.com with esmtp (Exim 3.36 #1) id 17EwSA-000Kv6-00 for namedroppers@ops.ietf.org; Mon, 03 Jun 2002 11:21:14 -0700 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by gemma.TechFak.Uni-Bielefeld.DE (8.9.1/8.9.1/TechFak/pk+ro20010720) with SMTP id UAA12524 for ; Mon, 3 Jun 2002 20:21:09 +0200 (MET DST) Received: from localhost by grimsvotn.TechFak.Uni-Bielefeld.DE (SMI-8.6/pk19971205) id UAA19881; Mon, 3 Jun 2002 20:21:09 +0200 Message-Id: <200206031821.UAA19881@grimsvotn.TechFak.Uni-Bielefeld.DE> To: namedroppers@ops.ietf.org Subject: ``Secure name resolution'' [Re: ] In-reply-to: Your message of "Mon, 03 Jun 2002 13:58:34 EDT." <3CFBAE4A.AD23CD1F@daimlerchrysler.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Mon, 03 Jun 2002 20:21:09 +0200 From: Peter Koch X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, > > For example, I would like to have www.example.com only be resolvable by > > members of a specific group, and make it "invisible" to others. [...] > You could define those "special" names as zones by themselves, and then > define separate "view"s for the "permitted" versus the > "forbidden" clients. This would require BIND 9, which supports "view". while all these implementation specific solutions (hacks, YMMV) exist, they are applicable in limited scenarios only. There is no interoperable way to communicate scopes or views between primary and secondary nameservers, since the amount of metadata exchanged in a zone transfer is limited to what the SOA RR can carry. -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: -- to unsubscribe send a message to namedroppers-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 Jun 3 16:33:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00184 for ; Mon, 3 Jun 2002 16:33:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EyLQ-0002Dc-00 for namedroppers-data@psg.com; Mon, 03 Jun 2002 13:22:24 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17EyLE-0002DF-00 for namedroppers@ops.ietf.org; Mon, 03 Jun 2002 13:22:12 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 8800228EDD for ; Mon, 3 Jun 2002 13:22:12 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR In-Reply-To: Message from Ted Lemon of "Mon, 03 Jun 2002 11:28:32 CDT." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Mon, 03 Jun 2002 13:22:12 -0700 Message-Id: <20020603202212.8800228EDD@as.vix.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > So do you have a patch to sendmail that implements this draft? :') i don't even have a sendmail source pool any more. sorry. i'll do postfix and somebody else can do sendmail. -- to unsubscribe send a message to namedroppers-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 Jun 3 17:30:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01730 for ; Mon, 3 Jun 2002 17:30:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ez8U-0005BM-00 for namedroppers-data@psg.com; Mon, 03 Jun 2002 14:13:06 -0700 Received: from p104.usnyc4.stsn.com ([199.106.219.104] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17Ez8R-0005B3-00 for namedroppers@ops.ietf.org; Mon, 03 Jun 2002 14:13:03 -0700 Received: from randy by roam.psg.com with local (Exim 4.04) id 17Ez8M-0000mK-00; Mon, 03 Jun 2002 14:12:58 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) In-Reply-To: <20020602165007.5309C28EDD@as.vix.com> Message-Id: Content-Transfer-Encoding: 7bit Date: Mon, 3 Jun 2002 11:28:32 -0500 Subject: Re: Mail-Transmitter RR Cc: Mark.Andrews@isc.org, namedroppers@ops.ietf.org, Derek Atkins , Mathias Koerber , David Green To: Paul Vixie From: Ted Lemon X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] So do you have a patch to sendmail that implements this draft? :') -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 3 17:30:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01744 for ; Mon, 3 Jun 2002 17:30:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ez9l-0005HF-00 for namedroppers-data@psg.com; Mon, 03 Jun 2002 14:14:25 -0700 Received: from p104.usnyc4.stsn.com ([199.106.219.104] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17Ez9j-0005Gz-00 for namedroppers@ops.ietf.org; Mon, 03 Jun 2002 14:14:23 -0700 Received: from randy by roam.psg.com with local (Exim 4.04) id 17Ez9Z-0000mZ-00; Mon, 03 Jun 2002 14:14:13 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Hallam-Baker, Phillip" Cc: "'Eric A. Hall'" , =?iso-8859-1?Q?M=E5ns_Nilsson?= , namedroppers@ops.ietf.org Subject: RE: Mail-Transmitter RR References: <2F3EC696EAEED311BB2D009027C3F4F405869AE5@vhqpostal.verisign.com> Message-Id: Date: Mon, 03 Jun 2002 14:14:13 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I think that the problem of SPAM needs more than just a DNS tweak > or two. I think that we need to take a more systemic approach, work > out what it would take to build a mail network that severely > discourages SPAM, claculate the delta to what we have today, work > out a migration plan that delivers value to adopters each step of > the way. bingo! -- to unsubscribe send a message to namedroppers-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 Jun 3 17:46:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02247 for ; Mon, 3 Jun 2002 17:46:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17EzSc-0006Us-00 for namedroppers-data@psg.com; Mon, 03 Jun 2002 14:33:54 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17EzSZ-0006Ub-00 for namedroppers@ops.ietf.org; Mon, 03 Jun 2002 14:33:51 -0700 Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0134A1D06 for ; Mon, 3 Jun 2002 17:33:50 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id 5F5943F4 for ; Mon, 3 Jun 2002 21:33:47 +0000 (GMT) Date: Mon, 03 Jun 2002 17:33:47 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Access controls on DNS queries (was RE: [no subject]) In-Reply-To: <3C1E3607B37295439F7C409EFBA08E680E2B86@US-Columbia-CIST.mail.saic.com> References: <3C1E3607B37295439F7C409EFBA08E680E2B86@US-Columbia-CIST.mail.saic.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigorymae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020603213347.5F5943F4@thangorodrim.hactrn.net> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Mon, 3 Jun 2002 09:33:09 -0400, Rip Loomis wrote: > > On Sunday, 02 June, 2002 06:40, Rob Austein wrote: >> >> This was an explict non-goal for DNSSEC (RFC 2535 et seq). DNSSEC >> explicitly does not attempt to provide confidentiality. > > True, but he didn't ask for confidentiality on the wire--or if that > was what he wanted then it wasn't clear. I read it as asking about > access control on specific data--it's not an uncommon request/ > problem. Rip is correct. My oops. -- to unsubscribe send a message to namedroppers-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 Jun 4 00:40:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10053 for ; Tue, 4 Jun 2002 00:40:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17F5tN-0005VG-00 for namedroppers-data@psg.com; Mon, 03 Jun 2002 21:25:57 -0700 Received: from mail3.noc.ntt.co.jp ([210.163.32.58]) by psg.com with esmtp (Exim 3.36 #1) id 17F5tK-0005V2-00 for namedroppers@ops.ietf.org; Mon, 03 Jun 2002 21:25:54 -0700 Received: from ms1-gw.noc.ntt.com (ms1-gw.noc.ntt.com) by mail3.noc.ntt.co.jp (8.9.3/NOC-MAIL3) id NAA27609; Tue, 4 Jun 2002 13:25:51 +0900 (JST) Received: from mr1-gw.noc.ntt.com by ms1-gw.noc.ntt.com (8.9.3/3.7W) id NAA01415; Tue, 4 Jun 2002 13:25:50 +0900 (JST) Received: from mail1.noc.ntt.com by mr1-gw.noc.ntt.com (8.9.3/3.7W) id NAA01397; Tue, 4 Jun 2002 13:25:49 +0900 (JST) Received: from KAMITE2 by mail1.noc.ntt.com (8.9.3/3.7W) id NAA09771; Tue, 4 Jun 2002 13:25:49 +0900 (JST) From: "Yuji KAMITE" To: "bert hubert" , Cc: Subject: RE: Access controls on DNS queries (was RE: [no subject]) Date: Tue, 4 Jun 2002 13:26:43 +0900 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.2416 (9.0.2911.0) In-Reply-To: <20020603185025.GA18344@outpost.ds9a.nl> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > There are a lot of GSS-TSIG documents out there currently and it looks like > there is enough available to write an implementation. But it has proved too > complex for us to determine this within a working day of trying to make > sense of what is what, and if everything is there. > > Does anybody know if it is theoretically possible to interoperate with > GSS-TSIG from something that is not written on Windows or tightly integrated > with it? It is said that recent BIND9 has interoperability with GSS-TSIG, (according to BIND configuration manual and source code) but I don't know what actually it is like ( I haven't made use of it),, sorry. - GSS-TSIG DNS would be one of local approach for providing security, but I have had a question for long time .. Is it possilbe or proper to apply GSS-TSIG in more general DNS world as practical/ideal soluction? (especially, in what sense GSS-TSIG can be more scalabe or useful??...etc) I think today GSS-TSIG cannot help being closed within the limited world of the Kerberos-(or something) compatible environment.(in fact, Win2k/XP today). My impression is, when it comes to the interoperablity with all other approaches (i.e, protocols not using GSS-like highly abstract mechanism), we tend to be confronted with quite a few difficluties ... so I need clear explanation/document about GSS-TSIG, too. --- Yuji Kamite (mailto:y.kamite@ntt.com) Innovateive IP Architecture Center, NTT Communications Tel:+81-3-6800-3112, Fax:+81-3-5365-2990 -- to unsubscribe send a message to namedroppers-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 Jun 4 08:01:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24375 for ; Tue, 4 Jun 2002 08:01:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FCiu-0002ol-00 for namedroppers-data@psg.com; Tue, 04 Jun 2002 04:43:36 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17FCiq-0002oX-00 for namedroppers@ops.ietf.org; Tue, 04 Jun 2002 04:43:32 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23282; Tue, 4 Jun 2002 07:43:01 -0400 (EDT) Message-Id: <200206041143.HAA23282@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-ecc-key-02.txt Date: Tue, 04 Jun 2002 07:43:01 -0400 X-Spam-Status: No, hits=0.8 required=5.0 tests=NO_REAL_NAME,TO_MALFORMED,EXCUSE_6 version=2.20 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 : Elliptic Curve KEYs in the DNS Author(s) : R. Schroeppel, D. Eastlake Filename : draft-ietf-dnsext-ecc-key-02.txt Pages : 14 Date : 03-Jun-02 A standard method for storing elliptic curve cryptographic keys in the Domain Name System is described which utilizes DNS KEY resource record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ecc-key-02.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-ecc-key-02.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: <20020603125235.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ecc-key-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ecc-key-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020603125235.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 Tue Jun 4 09:13:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27213 for ; Tue, 4 Jun 2002 09:13:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FDwq-0007A1-00 for namedroppers-data@psg.com; Tue, 04 Jun 2002 06:02:04 -0700 Received: from cnri-2-115.cnri.reston.va.us ([132.151.2.115] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17FDwl-00079j-00 for namedroppers@ops.ietf.org; Tue, 04 Jun 2002 06:01:59 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17FDwi-0001uU-00 for namedroppers@ops.ietf.org; Tue, 04 Jun 2002 06:01:56 -0700 Message-Id: <200206041147.g54Blqt03548@harvee.billerica.ma.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE References: In-Reply-To: Date: Tue, 4 Jun 2002 07:47:52 -0400 (Eastern Daylight Time) From: "Eric S. Johansson" Subject: Re: [camram-spam] from the IETF Namedroppers list To: namedroppers@ops.ietf.org, camram-spam@camram.org, pbaker@verisign.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] "Hallam-Baker, Phillip" wrote: > 1) Means of authenticating origination points. .. > 2) Means of advertising origination policy. .. unfortunately, identity based mechanisms such as the one you are proposing increase control over e-mail as communications tool. First, it effectively eliminates anonymous communication. Second, it makes it increases the difficulty of having one's own mail server without the cooperation of your bandwidth provider. Third, centralization of infrastructure for key management increases the ability of outside sources to shut off your voice by eliminating or controlling your keys. Fourth, it does nothing to eliminate spammers who are able to corrupt the system. They can generate keys and identities faster than you can filter them out. If you restrict who can generate keys, then you provide yet another channel for control. Instead, I would encourage people to think about developing a system that works at the edges. A system that does not require any centralized control, monitoring, or issuance of identity certificates. I've been working on one such model with the camram project (http://www.camram.org). It uses a proof of work postage stamp as an indicator that the sender really, really, really wants the recipient to get that e-mail. It's not perfect, it has some human factors issues, the impact of which can be minimized but not eliminated. It does have the following positive features: 1)peer to peer orientation (i.e. no centralized servers or changes needed) 2) very low impact after initial e-mail exchange 3) will cause significant slowdown of spammer's ability to send spam 4) effectively 0 UI spam filtering 5) effectively 0 UI encryption of e-mail in transit 6) mailing list friendly (well, maybe tolerant is a better word) 7) methods in place for backwards compatibility with existing e-mail infrastructure 8) easy (maybe automatic) adaptability to new proof of work techniques as spammers adapt. 9) allows legitimate bulk mailers (commercial mailing lists etc.) to operate. I have worked the numbers on the impact and assuming spammers are all running top-of-the-line PCs, the camram techniques will slow them down by a factor of 5 (on modem lines) to a factor of 70 (on 384k lines). now I believe there are other models that can also be implemented at the edges and without any centralized control. I haven't found them but I believe that they are there and I would appreciate hearing about them. If you want to find out more about the camram project, feel free to e-mail me and I'll be glad to discuss it with you. ---eric -- to unsubscribe send a message to namedroppers-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 Jun 4 12:07:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03949 for ; Tue, 4 Jun 2002 12:07:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FGYV-000Ge9-00 for namedroppers-data@psg.com; Tue, 04 Jun 2002 08:49:07 -0700 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 17FGYS-000Gdq-00 for namedroppers@ops.ietf.org; Tue, 04 Jun 2002 08:49:04 -0700 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by pigeon.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g54FiQw05660; Tue, 4 Jun 2002 08:44:26 -0700 (PDT) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 08:50:34 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40C6F716A@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "Eric S. Johansson" , namedroppers@ops.ietf.org, camram-spam@camram.org, pbaker@verisign.com Subject: RE: [camram-spam] from the IETF Namedroppers list Date: Tue, 4 Jun 2002 08:50:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > unfortunately, identity based mechanisms such as the one you are > proposing increase control over e-mail as communications tool. First, > it effectively eliminates anonymous communication. No, it just means that if you send me anonymous email it goes into the junk email inbox with the rest of the garbage I don't want to ever read. If you want to talk to me I want to know that you are a person I have granted the talk to Phill privilege. That does not mean that I have to tie that net identity to any offline identity. > Second, it makes > it increases the difficulty of having one's own mail server without > the cooperation of your bandwidth provider. Not my problem. > Third, centralization of > infrastructure for key management increases the ability of outside > sources to shut off your voice by eliminating or controlling your > keys. No such centralization was proposed. Actually what was proposed was a decentralization using the clasical DNS model. > Fourth, it does nothing to eliminate spammers who are able to > corrupt the system. They can generate keys and identities faster than > you can filter them out. If you restrict who can generate keys, then > you provide yet another channel for control. The Spammers can create keys, however they will not be granted the send email to Phill privilege so their Spam goes straight into the 'junk folder'. It is possible that we have an intelligent client that does the trick of sending an automatic response to an unsolicited email saying "you need to respond to this email with this activation code". The SPAMer can only respond to such a message if they have sent an email with a legitimate sender address. Phill -- to unsubscribe send a message to namedroppers-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 Jun 4 12:07:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03968 for ; Tue, 4 Jun 2002 12:07:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FGYm-000Gge-00 for namedroppers-data@psg.com; Tue, 04 Jun 2002 08:49:24 -0700 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 17FGYT-000Ge2-00; Tue, 04 Jun 2002 08:49:05 -0700 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by pigeon.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g54FiTw05670; Tue, 4 Jun 2002 08:44:29 -0700 (PDT) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 08:50:37 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40C6F716C@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Randy Bush , "Hallam-Baker, Phillip" Cc: "'Eric A. Hall'" , =?iso-8859-1?Q?M=E5ns_Nilsson?= , namedroppers@ops.ietf.org Subject: RE: Mail-Transmitter RR Date: Tue, 4 Jun 2002 08:50:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I should have added that Paul's tweak may well have a place to play in such a scheme however we need to look at the big picture. Also I think that we need to look at more than incremental measures. The problem with incremental measures is that they simply perpetuate the arms race. The SPAMers have time to react to each ad hoc measure and devise a counter measure - witness the current practice of mining email lists to harvest sender/receiver pairs in response to registered sender filtering. > > I think that the problem of SPAM needs more than just a DNS tweak > > or two. I think that we need to take a more systemic approach, work > > out what it would take to build a mail network that severely > > discourages SPAM, claculate the delta to what we have today, work > > out a migration plan that delivers value to adopters each step of > > the way. > > bingo! > -- to unsubscribe send a message to namedroppers-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 Jun 4 13:08:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06235 for ; Tue, 4 Jun 2002 13:08:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FHak-000KpG-00 for namedroppers-data@psg.com; Tue, 04 Jun 2002 09:55:30 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17FHag-000Koz-00 for namedroppers@ops.ietf.org; Tue, 04 Jun 2002 09:55:26 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id DC8AD28EDD for ; Tue, 4 Jun 2002 09:55:25 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR In-Reply-To: Message from "Hallam-Baker, Phillip" of "Tue, 04 Jun 2002 08:50:12 PDT." <2F3EC696EAEED311BB2D009027C3F4F40C6F716C@vhqpostal.verisign.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 04 Jun 2002 09:55:25 -0700 Message-Id: <20020604165525.DC8AD28EDD@as.vix.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I should have added that Paul's tweak may well have a place to play in such > a scheme however we need to look at the big picture. agreed on both points. however: > Also I think that we need to look at more than incremental measures. The > problem with incremental measures is that they simply perpetuate the arms > race. The SPAMers have time to react to each ad hoc measure and devise a > counter measure - witness the current practice of mining email lists to > harvest sender/receiver pairs in response to registered sender filtering. i'm still waiting to see a spammer who can reliably beat DCC. see http://www.rhyolite.com/anti-spam/dcc/ for details. my take on DCC is that the thing that keeps it from killing all spam for all time is the difficulty in widely deploying it, not the technology itself. spammers who manage to beat the checksum engine will just force a rolling upgrade. that's not to say internet messaging technology hasn't been completely outstripped by cultural "advances". i look favorably upon XNS in general and http://www.onename.com/ in particular. if we can widely deploy some kind of digital identity standard such that the only way i'll accept a message (e-mail, popup, etc) from someone is if they've been trustedly introduced and i have recourse if they violate my inbox's terms of service, then spam as we know it today can't exist. this seems far adrift for namedroppers, though. -- to unsubscribe send a message to namedroppers-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 Jun 4 13:58:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07820 for ; Tue, 4 Jun 2002 13:58:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FISc-000OXK-00 for namedroppers-data@psg.com; Tue, 04 Jun 2002 10:51:10 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17FISY-000OX5-00 for namedroppers@ops.ietf.org; Tue, 04 Jun 2002 10:51:06 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 130196; Tue, 04 Jun 2002 12:49:10 -0500 Message-ID: <3CFCFE06.E26F8ED8@ehsco.com> Date: Tue, 04 Jun 2002 12:51:03 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR References: <20020604165525.DC8AD28EDD@as.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > see http://www.rhyolite.com/anti-spam/dcc/ for details. my take on DCC > is that the thing that keeps it from killing all spam for all time is > the difficulty in widely deploying it, not the technology itself. There are two reasons why DCC is not a silver bullet. First of all, if you are EG aardvark@a1.com then you get the message before DCC triggers. Unless you are willing to delay the mail -- sending in the checksum as part of the transfer function, wait a while, then check the pool as part of the delivery function -- it cannot have guaranteed success. Secondarily, it only works AFTER you have burned bandwidth, processes, storage and compute time. For hotmail and aol, the only advantage to DCC is that their customers don't have to see the crap. They're operational costs are as high as before, if not higher. Don't get me wrong, things like DCC and Vipul's Razor are both compelling technologies, and are certainly good tools to use. But they are most effective when used in conjunction with filters that work at the protocol level (a la RBLs and the MAIL-FROM.domain hack). The real objective is to keep the crap out of my spool, and on the spammer's disk, sucking up his costs rather than mine. Give me more network filters, I'll use them all. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-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 Jun 4 14:04:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08122 for ; Tue, 4 Jun 2002 14:04:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FIY0-000OxZ-00 for namedroppers-data@psg.com; Tue, 04 Jun 2002 10:56:44 -0700 Received: from cnri-2-115.cnri.reston.va.us ([132.151.2.115] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17FIXw-000OxC-00 for namedroppers@ops.ietf.org; Tue, 04 Jun 2002 10:56:41 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17FIXv-0002Ol-00 for namedroppers@ops.ietf.org; Tue, 04 Jun 2002 10:56:39 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) In-Reply-To: <200206041147.g54Blqt03548@harvee.billerica.ma.us> Message-Id: <86ECBB7B-77E0-11D6-9ED5-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit Date: Tue, 4 Jun 2002 12:28:47 -0500 Subject: Re: [camram-spam] from the IETF Namedroppers list Cc: namedroppers@ops.ietf.org, camram-spam@camram.org, pbaker@verisign.com To: "Eric S. Johansson" From: Ted Lemon X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] > First, > it effectively eliminates anonymous communication. Not really. AFAIK Yahoo still doesn't check your identity, and you can check in from a different public terminal every time. Depends on how badly you want anonymity. What this prevents you from doing is *lying* about your identity, not not providing an identity. > Second, it makes > it increases the difficulty of having one's own mail server without > the cooperation of your bandwidth provider. Not true. Because this scheme does not depend on PTR records, you are not at the mercy of your ISP. > Third, centralization of > infrastructure for key management increases the ability of outside > sources to shut off your voice by eliminating or controlling your > keys. Sure. DoS attacks are always a problem. I don't think this provides a new DoS attack - my SMTP server will already reject your email if I can't get to your nameserver. > Fourth, it does nothing to eliminate spammers who are able to > corrupt the system. They can generate keys and identities faster than > you can filter them out. If you restrict who can generate keys, then > you provide yet another channel for control. Right, and it's not intended to solve that problem. It's intended to solve the problem of spammers lying by saying that mail they've sent comes from *my* domain. It definitely does not prevent them from asserting that it comes from their own domain. > Instead, I would encourage people to think about developing a system > that works at the edges. A system that does not require any > centralized control, monitoring, or issuance of identity certificates. This statement suggests that you don't even understand the thing you're arguing against. The whole point of this draft is that it's opt-in - it does not require centralized control, nor deployment of some vast new architecture that nobody's ever going to deploy. -- to unsubscribe send a message to namedroppers-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 Jun 4 14:10:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08391 for ; Tue, 4 Jun 2002 14:10:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FIdO-000PKq-00 for namedroppers-data@psg.com; Tue, 04 Jun 2002 11:02:18 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17FIdH-000PK6-00 for namedroppers@ops.ietf.org; Tue, 04 Jun 2002 11:02:11 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 29B3628EDD for ; Tue, 4 Jun 2002 11:02:11 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Mail-Transmitter RR In-Reply-To: Message from "Eric A. Hall" of "Tue, 04 Jun 2002 12:51:03 CDT." <3CFCFE06.E26F8ED8@ehsco.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 04 Jun 2002 11:02:11 -0700 Message-Id: <20020604180211.29B3628EDD@as.vix.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk warning - this is not dns related. just hit delete. > There are two reasons why DCC is not a silver bullet. First of all, if you > are EG aardvark@a1.com then you get the message before DCC triggers. > Unless you are willing to delay the mail -- sending in the checksum as > part of the transfer function, wait a while, then check the pool as part > of the delivery function -- it cannot have guaranteed success. there will be universal willingness to embargo inbound mail for 20 minutes among DCC users who know that doing so will increase the effectiveness. (the spammers, to combat this, would have to slow down their spam runs, which is not technically possible in some cases, and increases the exposure window for catch-in-the-act even where it is possible.) > Secondarily, it only works AFTER you have burned bandwidth, processes, > storage and compute time. For hotmail and aol, the only advantage to DCC > is that their customers don't have to see the crap. They're operational > costs are as high as before, if not higher. and yet the strongest incentive for today's spam is the success of yesterday's. i've said for years that the only way to stop spam was to stop its lifecycle. (sort of the same as how we cut down mosquito populations by removing puddles rather than poisoning the adults.) > Don't get me wrong, things like DCC and Vipul's Razor are both compelling > technologies, and are certainly good tools to use. But they are most > effective when used in conjunction with filters that work at the protocol > level (a la RBLs and the MAIL-FROM.domain hack). > > The real objective is to keep the crap out of my spool, and on the > spammer's disk, sucking up his costs rather than mine. Give me more > network filters, I'll use them all. yea, verily. though MAIL-FROM is not designed to stop spam but rather allow a domain owner to protect his/her intellectual property. -- to unsubscribe send a message to namedroppers-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 Jun 4 15:16:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11268 for ; Tue, 4 Jun 2002 15:16:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FJbD-0003fR-00 for namedroppers-data@psg.com; Tue, 04 Jun 2002 12:04:07 -0700 Received: from nat.dsl.flame.org ([64.133.235.52] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 17FJb9-0003fA-00 for namedroppers@ops.ietf.org; Tue, 04 Jun 2002 12:04:03 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g54J3vg22247; Tue, 4 Jun 2002 12:03:58 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Tue, 4 Jun 2002 12:03:56 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: Yuji KAMITE cc: namedroppers@ops.ietf.org Subject: RE: Access controls on DNS queries (was RE: [no subject]) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 4 Jun 2002, Yuji KAMITE wrote: > It is said that recent BIND9 has interoperability with GSS-TSIG, > (according to BIND configuration manual and source code) > but I don't know what actually it is like ( I haven't made use of it),, sorry. Where do you see that? There is basic (read: incomplete) support for the GSS-TSIG algorithm, but it does not work and is not built by default (and can't be built without changing the source code). It is not mentioned anywhere in the documentation. Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 4 15:42:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12100 for ; Tue, 4 Jun 2002 15:42:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FK4Q-0005Yd-00 for namedroppers-data@psg.com; Tue, 04 Jun 2002 12:34:18 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17FK4L-0005Y1-00 for namedroppers@ops.ietf.org; Tue, 04 Jun 2002 12:34:14 -0700 Received: from [128.177.195.171] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id ECE8E3190D; Tue, 4 Jun 2002 12:34:12 -0700 (PDT) User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Tue, 04 Jun 2002 12:34:28 -0700 Subject: Re: Access controls on DNS queries (was RE: [no subject]) From: David Conrad To: Yuji KAMITE , bert hubert , namedroppers Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, On 6/3/02 9:26 PM, "Yuji KAMITE" wrote: > It is said that recent BIND9 has interoperability with GSS-TSIG, (according to > BIND configuration manual and source code) Unless things have changed radically since I stopped following BIND closely, no, it doesn't. There were some preliminary attempts, but we ran into the problem that what Microsoft documented in the then-current draft and what they actually did in Windows were different. At that time, they also had not published some of the security context goop that made it possible to use GSS-TSIG in a useful fashion. I'm told they have remedied both of these (albeit, in .Net server, not in Win2K). I understand that the folks over at Lucent have gotten BIND to interoperate with Windows GSS-TSIG, however I do not believe they have released that code. > Is it possilbe or proper to apply GSS-TSIG in more general DNS world as > practical/ideal soluction? (especially, in what sense GSS-TSIG can be more > scalabe or useful??...etc) I think you answer your own question: > I think today GSS-TSIG cannot help being closed within the limited world of > the Kerberos-(or something) compatible environment.(in fact, Win2k/XP today). 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 Tue Jun 4 17:14:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15425 for ; Tue, 4 Jun 2002 17:14:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FLSR-000AuK-00 for namedroppers-data@psg.com; Tue, 04 Jun 2002 14:03:11 -0700 Received: from mail3.microsoft.com ([131.107.3.123]) by psg.com with esmtp (Exim 3.36 #1) id 17FLSN-000Au1-00 for namedroppers@ops.ietf.org; Tue, 04 Jun 2002 14:03:07 -0700 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 4 Jun 2002 14:03:06 -0700 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 04 Jun 2002 14:03:06 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 4 Jun 2002 14:03:06 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 4 Jun 2002 14:03:06 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Tue, 4 Jun 2002 14:03:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Access controls on DNS queries (was RE: [no subject]) Date: Tue, 4 Jun 2002 14:02:41 -0700 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD06C1B712@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Access controls on DNS queries (was RE: [no subject]) Thread-Index: AcIL/wYA1YXfsRHJTaC8McmZ7/uHHwACglng From: "James Gilroy" To: "David Conrad" , "Yuji KAMITE" , "bert hubert" , "namedroppers" X-OriginalArrivalTime: 04 Jun 2002 21:03:05.0522 (UTC) FILETIME=[38B2F120:01C20C0B] X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA15425 > Unless things have changed radically since I stopped > following BIND closely, no, it doesn't. There were some > preliminary attempts, but we ran into the problem that what > Microsoft documented in the then-current draft and what they > actually did in Windows were different. At that time, they > also had not published some of the security context goop that > made it possible to use GSS-TSIG in a useful fashion. I'm > told they have remedied both of these (albeit, in .Net > server, not in Win2K). > > I understand that the folks over at Lucent have gotten BIND > to interoperate with Windows GSS-TSIG, however I do not > believe they have released that code. David pretty much summed up the situation: => Lucent has the interoperable implementation working on BIND => I did screw up a couple things in the win2K implementation -- and feedback forced an additional change in the GSS-TSIG draft relative to what shipped in win2K. => However, one clarification, the WindowsXP client is in compliance with the spec. Anyone who wants help interoperating I'll certainly be glad to provide it -- including explanations of how Win2K clients deviates from the GSS-TSIG RFC, if Win2K interop is desired. Not being a security person, I'll skip comment on the merits of the GSS approach relative others. jim -- to unsubscribe send a message to namedroppers-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 Jun 5 03:36:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22021 for ; Wed, 5 Jun 2002 03:36:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FV4W-000NoF-00 for namedroppers-data@psg.com; Wed, 05 Jun 2002 00:19:08 -0700 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=delta.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.36 #1) id 17FV4C-000Nnb-00 for namedroppers@ops.ietf.org; Wed, 05 Jun 2002 00:18:56 -0700 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g555cpR02013; Wed, 5 Jun 2002 12:38:52 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Ted Lemon cc: "Eric S. Johansson" , namedroppers@ops.ietf.org, camram-spam@camram.org, pbaker@verisign.com Subject: Re: [camram-spam] from the IETF Namedroppers list In-Reply-To: <86ECBB7B-77E0-11D6-9ED5-00039367340A@nominum.com> References: <86ECBB7B-77E0-11D6-9ED5-00039367340A@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Jun 2002 12:38:51 +0700 Message-ID: <2011.1023255531@munnari.OZ.AU> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 4 Jun 2002 12:28:47 -0500 From: Ted Lemon Message-ID: <86ECBB7B-77E0-11D6-9ED5-00039367340A@nominum.com> | Right, and it's not intended to solve that problem. It's intended to | solve the problem of spammers lying by saying that mail they've sent comes | from *my* domain. It definitely does not prevent them from asserting that | it comes from their own domain. And this is the biggest problem with this approach (aside from the sheer ugliness of adding yet one more "magic" name into the DNS namespace, just because that's easier to accomplish than adding a new RR type). That is - you're asking me to add extra work to my sendmail (postfix or whatever) for your benefit, not mine. The code in my mailer prevents the spammer from claiming to be you - but I still get the spam, just claiming to be from someone else instead. (And of course, vice versa - if I create the magic name in the DNS, it only protects my domain name as long as everyone else has bothered to install mailers that implement this check, and we know that isn't really likely to happen all that much). There's simply no incentive here, no way this is really going to achieve the critical mass to have it even slightly effective. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 5 10:15:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01863 for ; Wed, 5 Jun 2002 10:15:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FbHy-000KaI-00 for namedroppers-data@psg.com; Wed, 05 Jun 2002 06:57:26 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17FbHt-000KZu-00 for namedroppers@ops.ietf.org; Wed, 05 Jun 2002 06:57:22 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 130401; Wed, 05 Jun 2002 08:55:26 -0500 Message-ID: <3CFE18BD.78A0B00B@ehsco.com> Date: Wed, 05 Jun 2002 08:57:17 -0500 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Robert Elz CC: Ted Lemon , "Eric S. Johansson" , namedroppers@ops.ietf.org, camram-spam@camram.org, pbaker@verisign.com Subject: Re: [camram-spam] from the IETF Namedroppers list References: <86ECBB7B-77E0-11D6-9ED5-00039367340A@nominum.com> <2011.1023255531@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > That is - you're asking me to add extra work to my sendmail (postfix or > whatever) for your benefit, not mine. The code in my mailer prevents > the spammer from claiming to be you - but I still get the spam, just > claiming to be from someone else instead. Ah, adding code to your MTA to detect spam from known open relays will be fruitless. You'll still get the spam, just relayed through someone else. This is the same kind of change. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-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 Jun 5 13:22:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07956 for ; Wed, 5 Jun 2002 13:22:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FeIP-0006jN-00 for namedroppers-data@psg.com; Wed, 05 Jun 2002 10:10:05 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17FeIJ-0006ii-00 for namedroppers@ops.ietf.org; Wed, 05 Jun 2002 10:09:59 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 3DB1C28B6C; Wed, 5 Jun 2002 10:09:53 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org, camram-spam@camram.org Subject: Re: [camram-spam] from the IETF Namedroppers list In-Reply-To: Message from Robert Elz of "Wed, 05 Jun 2002 12:38:51 +0700." <2011.1023255531@munnari.OZ.AU> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 05 Jun 2002 10:09:53 -0700 Message-Id: <20020605170953.3DB1C28B6C@as.vix.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > And this is the biggest problem with this approach ... > > That is - you're asking me to add extra work to my sendmail (postfix or > whatever) for your benefit, not mine. The code in my mailer prevents the > spammer from claiming to be you - but I still get the spam, just claiming > to be from someone else instead. well, then i suppose you won't be adding any MAIL-FROM's to your domains since you won't care to repudiate forgeries of your domain name, nor will you be hacking your postfix/sendmail/whatever to look for other folks' MAIL-FROM's on inbound mail. > (And of course, vice versa - if I create the magic name in the DNS, it > only protects my domain name as long as everyone else has bothered to > install mailers that implement this check, and we know that isn't really > likely to happen all that much). thanks for setting the challenge. i have a very different view, of course. > There's simply no incentive here, no way this is really going to achieve > the critical mass to have it even slightly effective. an allegorical translation of this statement is "i only care about poisoning the existing adult mosquitos who are making my outdoor party unbearable, and i see no point in draining all the small ponds and sinkholes surrounding my house so that they cannot be breeding grounds for mosquito larvae." since the MAIL-FROM MX is completely optional, you can't be injured by its adoption by others, nor can others be injured by your lack of adoption. a fine plan! -- to unsubscribe send a message to namedroppers-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 Jun 5 13:22:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07976 for ; Wed, 5 Jun 2002 13:22:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FeNZ-00072d-00 for namedroppers-data@psg.com; Wed, 05 Jun 2002 10:15:25 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 17FeNV-00072N-00 for namedroppers@ops.ietf.org; Wed, 05 Jun 2002 10:15:21 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20761; Wed, 5 Jun 2002 11:14:47 -0600 (MDT) Received: from lillen ([192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g55HEhK27241; Wed, 5 Jun 2002 19:14:43 +0200 (MEST) Date: Wed, 5 Jun 2002 19:13:33 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Change to restrict KEY draft - dropping RRsets debate To: Scott Rose Cc: DNSEXT WG Mailing list , masseyd@isi.edu In-Reply-To: "Your message with ID" <004501c1fdb2$927ee400$b9370681@BARNACLE> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I haven't seen any followup discussion on this, and I'm awaiting an updated draft before I'll start the IETF last call. In addition to the below text about "SHOULD accept" shouldn't the document also say that name servers and resolvers MUST NOT use KEYs with a protocol other than 3 when verifying signatures? Erik > Starting with Ed's question/comment on how to best deal with "illegal" RRs > in a potentially valid set, I am suggesting this change to the Restrict KEY > draft: > > original: > > > Name servers and resolvers SHOULD reject any KEY with a Protocol > other than 3. Assignment of any future KEY record Protocol Octet > values requires a standards action. > > New: > > Name servers should not load any KEY record with a protocol number other > than 3 as authoritative data for a zone. However, to aid backward > compatibility, name servers and resolvers SHOULD accept any KEY with a > Protocol > other than 3 if received as part of a KEY RR set in a response. Assignment > of any future KEY record Protocol Octet values requires a standards action. > > . . . > > Basically stating that nameservers should check the validity (format) of the > KEY before loading it into the database. If an invalid KEY is detected, > some sort of warning/error message is generated. If an invalid KEY RR comes > to a caching server, it should accept it as normal. This seems (to me) to > be the best "be conservative in what you give out, be liberal with what you > accept" solution. > > > 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: -- to unsubscribe send a message to namedroppers-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 Jun 5 13:24:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08082 for ; Wed, 5 Jun 2002 13:24:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FePD-0007AG-00 for namedroppers-data@psg.com; Wed, 05 Jun 2002 10:17:07 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 17FePA-0007A3-00; Wed, 05 Jun 2002 10:17:04 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01838; Wed, 5 Jun 2002 11:17:02 -0600 (MDT) Received: from lillen ([192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g55HGuK27677; Wed, 5 Jun 2002 19:16:57 +0200 (MEST) Date: Wed, 5 Jun 2002 19:15:46 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on delegation signer To: Ed Lewis Cc: Erik Nordmark , randy@psg.com, ogud@ogud.com, namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I haven't seen any followup past this email. Once I have an updated I-D with the editorial clarifications I can start the IETF last call. Erik >----- Begin Included Message -----< Date: Fri, 10 May 2002 08:17:43 -0400 (EDT) From: "Ed Lewis" Subject: Re: Comments on delegation signer To: "Erik Nordmark" Cc: randy@psg.com, ogud@ogud.com, namedroppers@ops.ietf.org On Fri, 10 May 2002, Erik Nordmark wrote: > The reason I assumed that saying "Secure delegations" here is because > the paragraph in question start with the text > For every secure delegation there MUST be a DS RRset stored in the > > How should that whole paragraph be rewritten to capture the difference > you point out? In order for a delegation to appear to be signed, the parent zone MUST contain a DS RR set for the child. Whether or not the resolver making the determination of security will decide that the child zone is secure will start with the evaluation of a DS RR set, unless the resolver has already configured a key for the child zone. Delegation points MAY contain only the following RR sets: NS, DS, NXT, and SIG. Delegation points MUST not hold any other RR sets, implicitly including KEY RR sets. The NS RR set MUST NOT be signed by the parent zone regardless of the security status of the delegation. Note that although the NXT RR set held in the parent and the set held in the child will share the same owner name, class, and type, the two are distinct sets and will have different values in their respective RDATA. ...this assumes that "delegation point" refers to the data in the parent to identify a cut point. I did make two pararaphs out of this to try and provide more clarity. I also rearranged the decription of the types held to put what can be done first (+) and what can't be done second (-). Finally, the original text explicitly mentions that the NXT's will differ from parent to child, but then again, so will the SIG set, and possibly the NS set.... > I don't think I said that tags aren't useful - I'm just confused by the > values in the example. I misunderstood the intent of your comment. > My reading of the document was that the tag value is also useful for the > resolver to more quickly find the key. > My question is how this is done given the tag values in the example. In looking a the example (section 3), it appears that the zone is "broken" as the DS RR does not refer to a KEY RR. The tag in the DS should be the same as (one of) the tag(s) in the KEY RR set. I think that's obvious - IOW, the example is broken. >----- End Included Message -----< -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 5 14:16:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10247 for ; Wed, 5 Jun 2002 14:16:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FfBI-000Ahp-00 for namedroppers-data@psg.com; Wed, 05 Jun 2002 11:06:48 -0700 Received: from is1-50.antd.nist.gov ([129.6.50.251]) by psg.com with esmtp (Exim 3.36 #1) id 17FfBB-000AhA-00 for namedroppers@ops.ietf.org; Wed, 05 Jun 2002 11:06:42 -0700 Received: from BARNACLE (barnacle.antd.nist.gov [129.6.55.185]) by is1-50.antd.nist.gov (8.9.3/8.9.3) with SMTP id OAA07786; Wed, 5 Jun 2002 14:06:34 -0400 (EDT) Message-ID: <004101c20cbb$06114d10$b9370681@BARNACLE> From: "Scott Rose" To: "Erik Nordmark" Cc: "DNSEXT WG Mailing list" References: Subject: Re: Change to restrict KEY draft - dropping RRsets debate Date: Wed, 5 Jun 2002 14:01:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think some text about only having "dnssec" protocol keys generating and verifying SIG records already exists in previous RFCs and also the spec revision drafts. Is there need to repeat it in this draft? Scott ----- Original Message ----- From: "Erik Nordmark" To: "Scott Rose" Cc: "DNSEXT WG Mailing list" ; Sent: Wednesday, June 05, 2002 1:13 PM Subject: Re: Change to restrict KEY draft - dropping RRsets debate > > I haven't seen any followup discussion on this, and I'm awaiting > an updated draft before I'll start the IETF last call. > > In addition to the below text about "SHOULD accept" shouldn't > the document also say that name servers and resolvers MUST NOT use > KEYs with a protocol other than 3 when verifying signatures? > > Erik > > > Starting with Ed's question/comment on how to best deal with "illegal" RRs > > in a potentially valid set, I am suggesting this change to the Restrict KEY > > draft: > > > > original: > > > > > > Name servers and resolvers SHOULD reject any KEY with a Protocol > > other than 3. Assignment of any future KEY record Protocol Octet > > values requires a standards action. > > > > New: > > > > Name servers should not load any KEY record with a protocol number other > > than 3 as authoritative data for a zone. However, to aid backward > > compatibility, name servers and resolvers SHOULD accept any KEY with a > > Protocol > > other than 3 if received as part of a KEY RR set in a response. Assignment > > of any future KEY record Protocol Octet values requires a standards action. > > > > . . . > > > > Basically stating that nameservers should check the validity (format) of the > > KEY before loading it into the database. If an invalid KEY is detected, > > some sort of warning/error message is generated. If an invalid KEY RR comes > > to a caching server, it should accept it as normal. This seems (to me) to > > be the best "be conservative in what you give out, be liberal with what you > > accept" solution. > > > > > > 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: > > > > -- > to 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 Jun 6 05:11:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02988 for ; Thu, 6 Jun 2002 05:11:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ft0y-000LG5-00 for namedroppers-data@psg.com; Thu, 06 Jun 2002 01:53:04 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 17Ft0t-000LFq-00 for namedroppers@ops.ietf.org; Thu, 06 Jun 2002 01:52:59 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20499; Thu, 6 Jun 2002 02:52:57 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g568quK08749; Thu, 6 Jun 2002 10:52:56 +0200 (MEST) Date: Thu, 6 Jun 2002 10:51:48 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Change to restrict KEY draft - dropping RRsets debate To: Scott Rose Cc: Erik Nordmark , DNSEXT WG Mailing list In-Reply-To: "Your message with ID" <004101c20cbb$06114d10$b9370681@BARNACLE> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-4.3 required=5.0 tests=IN_REP_TO,PORN_10 version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I think some text about only having "dnssec" protocol keys generating and > verifying SIG records already exists in previous RFCs and also the spec > revision drafts. Is there need to repeat it in this draft? I think it can't hurt to add Note: per RFCxxx only the DNSSEC keys are used when verifying ... Without this somebody might incorrectly think that the compatibilty text implies something about the verification. Erik -- to unsubscribe send a message to namedroppers-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 Jun 6 11:01:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17317 for ; Thu, 6 Jun 2002 11:01:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FyYr-000CFH-00 for namedroppers-data@psg.com; Thu, 06 Jun 2002 07:48:25 -0700 Received: from [212.234.238.114] (helo=givenchy) by psg.com with esmtp (Exim 3.36 #1) id 17FyYo-000CF0-00 for namedroppers@ops.ietf.org; Thu, 06 Jun 2002 07:48:22 -0700 Received: from intranet.6wind.com (intranet.6wind.com [10.0.0.113]) by givenchy (Postfix) with ESMTP id B4FE387E for ; Thu, 6 Jun 2002 16:57:47 +0200 (CEST) Received: from 6wind.com (unknown [10.16.0.134]) by intranet.6wind.com (Postfix) with ESMTP id B10E8B4FE for ; Thu, 6 Jun 2002 09:54:45 -0500 (CDT) Message-ID: <3CFF765E.14487FDE@6wind.com> Date: Thu, 06 Jun 2002 16:49:02 +0200 From: Jean-Mickael Guerin X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Dynamic update & A record for SOA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I'm using bind 9.2.1 (freebsd4.5) and configure a server to allow dynamic update. When I run nsupdate, I notice nsupdate sends one request to find SOA name, then force one request to get A record for this name, But I have only a AAAA record for SOA name, and nsupdate fails. If I add a A record for SOA name, nsupdate works fine. Is there another way to do it ? special option for nsupdate ? Jean-Mickael -- to unsubscribe send a message to namedroppers-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 Jun 6 11:54:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18595 for ; Thu, 6 Jun 2002 11:54:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17FzJ6-000F4O-00 for namedroppers-data@psg.com; Thu, 06 Jun 2002 08:36:12 -0700 Received: from [212.234.238.114] (helo=givenchy) by psg.com with esmtp (Exim 3.36 #1) id 17FzJ3-000F49-00 for namedroppers@ops.ietf.org; Thu, 06 Jun 2002 08:36:09 -0700 Received: from intranet.6wind.com (intranet.6wind.com [10.0.0.113]) by givenchy (Postfix) with ESMTP id 0C8849A5 for ; Thu, 6 Jun 2002 17:45:35 +0200 (CEST) Received: from 6wind.com (unknown [10.16.0.134]) by intranet.6wind.com (Postfix) with ESMTP id ADF88B500 for ; Thu, 6 Jun 2002 10:42:32 -0500 (CDT) Message-ID: <3CFF8191.D5D8A030@6wind.com> Date: Thu, 06 Jun 2002 17:36:49 +0200 From: Jean-Mickael Guerin X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Dynamic update & A record for SOA References: <3CFF765E.14487FDE@6wind.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Sorry, my previous mail should be sent to bind9 mailing list. Maybe someone can confirm that A record for SOA name is not mandtory for dynamic update ? Thanks you and sorry again. Jean-Mickael Jean-Mickael Guerin a crit : > > Hello, > I'm using bind 9.2.1 (freebsd4.5) and configure a server to allow > dynamic update. > When I run nsupdate, I notice nsupdate sends one request to find SOA > name, then force one request to get A record for this name, > But I have only a AAAA record for SOA name, and nsupdate fails. > If I add a A record for SOA name, nsupdate works fine. > Is there another way to do it ? special option for nsupdate ? > > Jean-Mickael > > -- > to 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 Jun 6 18:49:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03304 for ; Thu, 6 Jun 2002 18:49:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17G5gn-000G0Y-00 for namedroppers-data@psg.com; Thu, 06 Jun 2002 15:25:05 -0700 Received: from mx04.gis.net ([208.218.130.12] helo=gis.net) by psg.com with esmtp (Exim 3.36 #1) id 17G5gi-000Fzy-00 for namedroppers@ops.ietf.org; Thu, 06 Jun 2002 15:25:00 -0700 Received: from tecotoo.www.gis.net ([63.209.233.45]) by mx04.gis.net; Thu, 06 Jun 2002 18:24:30 -0400 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id ba027379 for ; Thu, 6 Jun 2002 18:24:19 -0400 Message-Id: <4.3.1.2.20020606182325.00e1fef0@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 06 Jun 2002 18:24:04 -0400 To: Mark.Andrews@isc.org, Jean-Mickael Guerin From: Danny Mayer Subject: Re: Dynamic update & A record for SOA Cc: namedroppers@ops.ietf.org In-Reply-To: <200206062131.g56LVpOI058771@drugs.dv.isc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Spam-Status: No, hits=-2.4 required=5.0 tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA03304 At 05:31 PM 6/6/02, Mark.Andrews@isc.org wrote: > > Sorry, my previous mail should be sent to bind9 mailing list. > > Maybe someone can confirm that A record for SOA name is not mandtory for > > dynamic update ? > > > > Thanks you and sorry again. > > > > Jean-Mickael > > It should be looking up AAAA records as well. > > > > > Jean-Mickael Guerin a crit : > > > > > > Hello, > > > I'm using bind 9.2.1 (freebsd4.5) and configure a server to allow > > > dynamic update. > > > When I run nsupdate, I notice nsupdate sends one request to find SOA > > > name, then force one request to get A record for this name, > > > But I have only a AAAA record for SOA name, and nsupdate fails. > > > If I add a A record for SOA name, nsupdate works fine. > > > Is there another way to do it ? special option for nsupdate ? > > > What version of nsupdate are you running? Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 6 18:49:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03346 for ; Thu, 6 Jun 2002 18:49:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17G2ne-0003Ex-00 for namedroppers-data@psg.com; Thu, 06 Jun 2002 12:19:58 -0700 Received: from firewall.isoc.org ([198.6.250.5] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17G2nY-0003Ea-00 for namedroppers@ops.ietf.org; Thu, 06 Jun 2002 12:19:52 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17G2nK-0004Aw-00; Thu, 06 Jun 2002 12:19:38 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Matt Larson" Cc: "Olafur Gudmundsson" , "DNSEXT mailing list" Subject: Re: Opt-in Decission day: Postponed References: <20020410120723.C16672-100000@hlid.dc.ogud.com> <002501c20d88$37ce3750$8000a8c0@whirlwind> Message-Id: Date: Thu, 06 Jun 2002 12:19:38 -0700 X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Could the chairs please give an update regarding Opt-in? major pushback from the dns directorate. we've been talking with roy to try and get more comfortable with it. roy and rob are working on documenting an analysis. patience. randy -- to unsubscribe send a message to namedroppers-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 Jun 6 18:49:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03488 for ; Thu, 6 Jun 2002 18:49:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17G21t-00001l-00 for namedroppers-data@psg.com; Thu, 06 Jun 2002 11:30:37 -0700 Received: from tornado.acmebw.com ([209.8.5.250] helo=tornado.kahlerlarson.org) by psg.com with esmtp (Exim 3.36 #1) id 17G21k-000Q0Z-00 for namedroppers@ops.ietf.org; Thu, 06 Jun 2002 11:30:29 -0700 Received: from whirlwind (whirlwind.kahlerlarson.org [192.168.0.128]) by tornado.kahlerlarson.org (Postfix) with SMTP id 26569100B9E; Thu, 6 Jun 2002 14:30:22 -0400 (EDT) Message-ID: <002501c20d88$37ce3750$8000a8c0@whirlwind> Reply-To: "Matt Larson" From: "Matt Larson" To: "Olafur Gudmundsson" , "DNSEXT mailing list" References: <20020410120723.C16672-100000@hlid.dc.ogud.com> Subject: Re: Opt-in Decission day: Postponed Date: Thu, 6 Jun 2002 14:30:21 -0400 Organization: VeriSign Global Registry Services MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Could the chairs please give an update regarding Opt-in? Matt ----- Original Message ----- From: "Olafur Gudmundsson" To: "DNSEXT mailing list" Sent: Wednesday, April 10, 2002 12:16 PM Subject: Opt-in Decission day: Postponed > > At the Minneapolis meeting Randy and I stated that today would be > the day that Opt-in fate would be announced. > Due to fact that over the last two weeks both chairs have been > traveling with limited (or no) email connectivity, we have not able > jointly judge consensus of the working group. > > The new decission date is now April 15'th. > > > Olafur, today's chair withe e-mail connectivity :-) -- to unsubscribe send a message to namedroppers-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 Jun 6 19:56:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03307 for ; Thu, 6 Jun 2002 18:49:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17G4rT-000CBA-00 for namedroppers-data@psg.com; Thu, 06 Jun 2002 14:32:03 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17G4rP-000CAv-00 for namedroppers@ops.ietf.org; Thu, 06 Jun 2002 14:31:59 -0700 Received: from drugs.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.12.3/8.12.3) with ESMTP id g56LVpOI058771; Fri, 7 Jun 2002 07:31:51 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200206062131.g56LVpOI058771@drugs.dv.isc.org> To: Jean-Mickael Guerin Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Dynamic update & A record for SOA In-reply-to: Your message of "Thu, 06 Jun 2002 17:36:49 +0200." <3CFF8191.D5D8A030@6wind.com> Date: Fri, 07 Jun 2002 07:31:51 +1000 X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Sorry, my previous mail should be sent to bind9 mailing list. > Maybe someone can confirm that A record for SOA name is not mandtory for > dynamic update ? > > Thanks you and sorry again. > > Jean-Mickael It should be looking up AAAA records as well. > > Jean-Mickael Guerin a crit : > > > > Hello, > > I'm using bind 9.2.1 (freebsd4.5) and configure a server to allow > > dynamic update. > > When I run nsupdate, I notice nsupdate sends one request to find SOA > > name, then force one request to get A record for this name, > > But I have only a AAAA record for SOA name, and nsupdate fails. > > If I add a A record for SOA name, nsupdate works fine. > > Is there another way to do it ? special option for nsupdate ? > > > > Jean-Mickael > > > > -- > > to 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: -- Mark Andrews, Internet Software Consortium 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 Jun 7 02:56:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19330 for ; Fri, 7 Jun 2002 02:56:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GDTD-000B8y-00 for namedroppers-data@psg.com; Thu, 06 Jun 2002 23:43:35 -0700 Received: from mailhost.6wind.com ([212.234.238.114] helo=givenchy.6wind.com) by psg.com with esmtp (Exim 3.36 #1) id 17GDTA-000B8k-00 for namedroppers@ops.ietf.org; Thu, 06 Jun 2002 23:43:32 -0700 Received: from intranet.6wind.com (intranet.6wind.com [10.0.0.113]) by givenchy.6wind.com (Postfix) with ESMTP id 8605A863 for ; Fri, 7 Jun 2002 08:52:54 +0200 (CEST) Received: from 6wind.com (unknown [10.16.0.134]) by intranet.6wind.com (Postfix) with ESMTP id D7C47B500 for ; Fri, 7 Jun 2002 01:49:49 -0500 (CDT) Message-ID: <3D005639.E30FC45A@6wind.com> Date: Fri, 07 Jun 2002 08:44:09 +0200 From: Jean-Mickael Guerin X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Dynamic update & A record for SOA References: <4.3.1.2.20020606182325.00e1fef0@pop.gis.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit I was using original nsupdate. No more problem with nsupdate of bind-9.2.1 Thanks to Danny Jean-Mickael Danny Mayer a crit : > > At 05:31 PM 6/6/02, Mark.Andrews@isc.org wrote: > > > > Sorry, my previous mail should be sent to bind9 mailing list. > > > Maybe someone can confirm that A record for SOA name is not mandtory for > > > dynamic update ? > > > > > > Thanks you and sorry again. > > > > > > Jean-Mickael > > > > It should be looking up AAAA records as well. > > > > > > > > Jean-Mickael Guerin a crit : > > > > > > > > Hello, > > > > I'm using bind 9.2.1 (freebsd4.5) and configure a server to allow > > > > dynamic update. > > > > When I run nsupdate, I notice nsupdate sends one request to find SOA > > > > name, then force one request to get A record for this name, > > > > But I have only a AAAA record for SOA name, and nsupdate fails. > > > > If I add a A record for SOA name, nsupdate works fine. > > > > Is there another way to do it ? special option for nsupdate ? > > > > > > What version of nsupdate are you running? > > Danny > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-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 Jun 7 10:03:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26652 for ; Fri, 7 Jun 2002 10:03:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GK56-000La4-00 for namedroppers-data@psg.com; Fri, 07 Jun 2002 06:47:08 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17GK50-000LZt-00 for namedroppers@ops.ietf.org; Fri, 07 Jun 2002 06:47:02 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17GK50-000LAC-00; Fri, 07 Jun 2002 06:47:02 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mark Kosters Cc: DNSEXT mailing list Subject: Re: Opt-in Decission day: Postponed References: <20020410120723.C16672-100000@hlid.dc.ogud.com> <002501c20d88$37ce3750$8000a8c0@whirlwind> <20020606202557.GQ30763@slam.admin.cto.netsol.com> Message-Id: Date: Fri, 07 Jun 2002 06:47:02 -0700 X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Who is on the DNS directorate? What role do they play in approving the > work that comes out of DNSEXT? directorates are chosen by and advise area directors, in this case erik and me. currently, the dns directorate is composed of bob.halley@nominum.com erik.nordmark@sun.com harald@alvestrand.no liman@autonomica.se mankin@isi.edu ogud@ogud.com paf@cisco.com randy@psg.com roy.arends@nominum.com smb@research.att.com sob@harvard.edu sra@hactrn.net warlord@mit.edu dns-dir is a mailing list, of course, and a face-to-face dinner sunday of ietf. though we also did meet the beginning of week before last specifically to hear roy on this issue and try and think about it a bit more. randy -- to unsubscribe send a message to namedroppers-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 Jun 7 10:50:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29012 for ; Fri, 7 Jun 2002 10:50:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GKt7-000MNu-00 for namedroppers-data@psg.com; Fri, 07 Jun 2002 07:38:49 -0700 Received: from mail.storm.ca ([209.87.239.66]) by psg.com with esmtp (Exim 3.36 #1) id 17GKsx-000MNU-00 for namedroppers@ops.ietf.org; Fri, 07 Jun 2002 07:38:39 -0700 Received: from storm.ca (ppp-209-87-255-6.ottawa.storm.ca [209.87.255.6]) by mail.storm.ca (8.11.6+Sun/8.11.6) with ESMTP id g57EcbD17658; Fri, 7 Jun 2002 10:38:37 -0400 (EDT) Message-ID: <3D00ED4E.54B98E50@storm.ca> Date: Fri, 07 Jun 2002 10:28:46 -0700 From: Sandy Harris X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: DNSEXT mailing list CC: markk@verisignlabs.com Subject: Re: Opt-in Decission day: Postponed References: <20020410120723.C16672-100000@hlid.dc.ogud.com> <002501c20d88$37ce3750$8000a8c0@whirlwind> <20020606202557.GQ30763@slam.admin.cto.netsol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark Kosters wrote: > Who is on the DNS directorate? Area directors for Internet Area Working Groups, which include DNSEXT: http://www.ietf.org/html.charters/wg-dir.html#Internet Area > What role do they play in approving the > work that comes out of DNSEXT? BCPs on the process: ftp://ftp.isi.edu/in-notes/rfc2026.txt ftp://ftp.isi.edu/in-notes/rfc2028.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 Fri Jun 7 10:58:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26649 for ; Fri, 7 Jun 2002 10:03:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GK5K-000LaO-00 for namedroppers-data@psg.com; Fri, 07 Jun 2002 06:47:22 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17GK5H-000La9-00 for namedroppers@ops.ietf.org; Fri, 07 Jun 2002 06:47:19 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17GK5H-000LAs-00 for namedroppers@ops.ietf.org; Fri, 07 Jun 2002 06:47:19 -0700 Message-ID: <20020606202557.GQ30763@slam.admin.cto.netsol.com> References: <20020410120723.C16672-100000@hlid.dc.ogud.com> <002501c20d88$37ce3750$8000a8c0@whirlwind> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Date: Thu, 6 Jun 2002 16:25:57 -0400 From: Mark Kosters To: Randy Bush Cc: Matt Larson , Olafur Gudmundsson , DNSEXT mailing list Subject: Re: Opt-in Decission day: Postponed X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,OPT_IN,SIGNATURE_DELIM version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Randy Who is on the DNS directorate? What role do they play in approving the work that comes out of DNSEXT? Mark On Thu, Jun 06, 2002 at 12:19:38PM -0700, Randy Bush wrote: > major pushback from the dns directorate. we've been talking with > roy to try and get more comfortable with it. roy and rob are working > on documenting an analysis. patience. -- Mark Kosters markk@netsol.com 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 Fri Jun 7 11:33:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01188 for ; Fri, 7 Jun 2002 11:33:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GLby-000NMA-00 for namedroppers-data@psg.com; Fri, 07 Jun 2002 08:25:10 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17GLbv-000NLw-00 for namedroppers@ops.ietf.org; Fri, 07 Jun 2002 08:25:07 -0700 Received: from [10.0.1.9] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 5668F3191F; Fri, 7 Jun 2002 08:25:04 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Fri, 07 Jun 2002 08:25:14 -0700 Subject: Re: Opt-in Decission day: Postponed From: David Conrad To: Sandy Harris , namedroppers Cc: Message-ID: In-Reply-To: <3D00ED4E.54B98E50@storm.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sandy, On 6/7/02 10:28 AM, "Sandy Harris" wrote: > Mark Kosters wrote: > >> Who is on the DNS directorate? > > Area directors for Internet Area Working Groups, > which include DNSEXT: > http://www.ietf.org/html.charters/wg-dir.html#Internet Area The question was about the DNS directorate, not the ADs. >> What role do they play in approving the >> work that comes out of DNSEXT? > > BCPs on the process: > > ftp://ftp.isi.edu/in-notes/rfc2026.txt > ftp://ftp.isi.edu/in-notes/rfc2028.txt I can't find a reference to "directorate" in either of these documents. Can you provide a pointer? Tnx, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 7 11:53:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01750 for ; Fri, 7 Jun 2002 11:53:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GLvN-000Nz7-00 for namedroppers-data@psg.com; Fri, 07 Jun 2002 08:45:13 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17GLvK-000Nys-00 for namedroppers@ops.ietf.org; Fri, 07 Jun 2002 08:45:10 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17GLvK-000PYH-00 for namedroppers@ops.ietf.org; Fri, 07 Jun 2002 08:45:10 -0700 Message-ID: <20020607154220.GD4661@slam.admin.cto.netsol.com> References: <20020410120723.C16672-100000@hlid.dc.ogud.com> <002501c20d88$37ce3750$8000a8c0@whirlwind> <20020606202557.GQ30763@slam.admin.cto.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Date: Fri, 7 Jun 2002 11:42:20 -0400 From: Mark Kosters To: Randy Bush Cc: Mark Kosters , DNSEXT mailing list Subject: Re: Opt-in Decission day: Postponed X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,OPT_IN,SIGNATURE_DELIM version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] On Fri, Jun 07, 2002 at 06:47:02AM -0700, Randy Bush wrote: > > Who is on the DNS directorate? What role do they play in approving the > > work that comes out of DNSEXT? > > directorates are chosen by and advise area directors, in this case erik and > me. currently, the dns directorate is composed of Thanks for the list. However, I have not seen an answer to what role does this group play in approving the work that comes out of DNSEXT. > dns-dir is a mailing list, of course, and a face-to-face dinner sunday > of ietf. though we also did meet the beginning of week before last > specifically to hear roy on this issue and try and think about it a bit > more. Is the mailing list open? If so, where are the archives? Mark -- Mark Kosters markk@netsol.com 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 Fri Jun 7 11:54:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01809 for ; Fri, 7 Jun 2002 11:54:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GLv8-000Ny1-00 for namedroppers-data@psg.com; Fri, 07 Jun 2002 08:44:58 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17GLv5-000NxV-00 for namedroppers@ops.ietf.org; Fri, 07 Jun 2002 08:44:55 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17GLv4-000PXa-00; Fri, 07 Jun 2002 08:44:54 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mark Kosters Cc: DNSEXT mailing list Subject: Re: Opt-in Decission day: Postponed References: <20020410120723.C16672-100000@hlid.dc.ogud.com> <002501c20d88$37ce3750$8000a8c0@whirlwind> <20020606202557.GQ30763@slam.admin.cto.netsol.com> <20020607154220.GD4661@slam.admin.cto.netsol.com> Message-Id: Date: Fri, 07 Jun 2002 08:44:54 -0700 X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> directorates are chosen by and advise area directors, in this case erik and >> me. currently, the dns directorate is composed of > Thanks for the list. However, I have not seen an answer to what role does > this group play in approving the work that comes out of DNSEXT. it advises the area directors > Is the mailing list open? If so, where are the archives? no randy -- to unsubscribe send a message to namedroppers-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 Jun 7 12:00:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01990 for ; Fri, 7 Jun 2002 12:00:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GM1e-000ODP-00 for namedroppers-data@psg.com; Fri, 07 Jun 2002 08:51:42 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17GM1b-000ODE-00 for namedroppers@ops.ietf.org; Fri, 07 Jun 2002 08:51:39 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17GM1b-000PnL-00; Fri, 07 Jun 2002 08:51:39 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: David Conrad Cc: Sandy Harris , namedroppers , Subject: Re: Opt-in Decission day: Postponed References: <3D00ED4E.54B98E50@storm.ca> Message-Id: Date: Fri, 07 Jun 2002 08:51:39 -0700 X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > On 6/7/02 10:28 AM, "Sandy Harris" wrote: > > Mark Kosters wrote: > > > >> Who is on the DNS directorate? > > > > Area directors for Internet Area Working Groups, > > which include DNSEXT: > > http://www.ietf.org/html.charters/wg-dir.html#Internet Area > > The question was about the DNS directorate, not the ADs. > > >> What role do they play in approving the > >> work that comes out of DNSEXT? > > > > BCPs on the process: > > > > ftp://ftp.isi.edu/in-notes/rfc2026.txt > > ftp://ftp.isi.edu/in-notes/rfc2028.txt > > I can't find a reference to "directorate" in either of these documents. > Can you provide a pointer? sounds like time to move this non-technical and ietf-generic discussion to the poised list. randy -- to unsubscribe send a message to namedroppers-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 Jun 7 13:13:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04495 for ; Fri, 7 Jun 2002 13:13:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GN6j-000Pp9-00 for namedroppers-data@psg.com; Fri, 07 Jun 2002 10:01:01 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17GN6f-000Poq-00 for namedroppers@ops.ietf.org; Fri, 07 Jun 2002 10:00:57 -0700 Received: from [128.177.195.171] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 1790D31922; Fri, 7 Jun 2002 10:00:57 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Fri, 07 Jun 2002 10:01:08 -0700 Subject: Re: Opt-in Decission day: Postponed From: David Conrad To: Randy Bush Cc: Sandy Harris , namedroppers , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 6/7/02 8:51 AM, "Randy Bush" wrote: >> I can't find a reference to "directorate" in either of these documents. >> Can you provide a pointer? > sounds like time to move this non-technical and ietf-generic discussion > to the poised list. Perhaps so. However, the questions that Mark has raised, specifically: >>> What role do they play in approving the >>> work that comes out of DNSEXT? would seem to be specific to DNSEXT and would (presumably, given the weight their advice seems to play) have direct impact on the technical direction of the working group. Would you mind answering the question? Tnx, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 7 13:17:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04622 for ; Fri, 7 Jun 2002 13:17:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GNDA-000PyW-00 for namedroppers-data@psg.com; Fri, 07 Jun 2002 10:07:40 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17GND7-000PyK-00 for namedroppers@ops.ietf.org; Fri, 07 Jun 2002 10:07:37 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17GND6-0002cM-00; Fri, 07 Jun 2002 10:07:36 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: David Conrad Cc: Sandy Harris , namedroppers , Subject: Re: Opt-in Decission day: Postponed References: Message-Id: Date: Fri, 07 Jun 2002 10:07:36 -0700 X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>> What role do they play in approving the >>>> work that comes out of DNSEXT? > would seem to be specific to DNSEXT and would (presumably, given the > weight their advice seems to play) have direct impact on the technical > direction of the working group. i agree that it is germane > Would you mind answering the question? sure, for the third time. they advise the area directors, in the case of dns-dir, erik for dnsext and me for dnsops. and again for good measure, directorates are chosen by area directors to advise them. that's it, pure and simple. they have no power other than having their advice taken or not, as they area director(s) may choose. think of it as "hmmm, this is deep stuff. maybe some folk i know and can work with would be able to advise me." there are directorates in transport, sub-ip, wireless, and a number of other areas or subjects. randy -- to unsubscribe send a message to namedroppers-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 Jun 7 13:35:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05112 for ; Fri, 7 Jun 2002 13:35:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GNWq-0000Tp-00 for namedroppers-data@psg.com; Fri, 07 Jun 2002 10:28:00 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17GNWm-0000TK-00 for namedroppers@ops.ietf.org; Fri, 07 Jun 2002 10:27:56 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 6270B28B6C for ; Fri, 7 Jun 2002 10:27:56 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers Subject: Re: Opt-in Decission day: Postponed In-Reply-To: Message from Randy Bush of "Fri, 07 Jun 2002 10:07:36 PDT." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Fri, 07 Jun 2002 10:27:56 -0700 Message-Id: <20020607172756.6270B28B6C@as.vix.com> X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > and again for good measure, directorates are chosen by area directors to > advise them. that's it, pure and simple. they have no power other than > having their advice taken or not, as they area director(s) may choose. > > think of it as "hmmm, this is deep stuff. maybe some folk i know and can > work with would be able to advise me." there are directorates in transport, > sub-ip, wireless, and a number of other areas or subjects. > > randy so, the dnsext working group (even though it shares members with the dns directorate, and is chaired by an area director) is considered to have gone well and truly off into the weeks (like dnswg and dnsind before it) and so now we're disbanding it, and ignoring its conclusions, and letting the grownups come in and clean things up? what a relief. i almost thought i understood the ietf. i'm better now. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 7 13:56:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05948 for ; Fri, 7 Jun 2002 13:56:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GNny-0000uh-00 for namedroppers-data@psg.com; Fri, 07 Jun 2002 10:45:42 -0700 Received: from h220.s231.netsol.com ([216.168.231.220] helo=borg.admin.cto.netsol.com) by psg.com with esmtp (Exim 3.36 #1) id 17GNnv-0000uU-00; Fri, 07 Jun 2002 10:45:39 -0700 Received: (from markk@localhost) by borg.admin.cto.netsol.com (8.11.6/8.11.6) id g57HiIx05590; Fri, 7 Jun 2002 13:44:18 -0400 Date: Fri, 7 Jun 2002 13:44:18 -0400 From: Mark Kosters To: Randy Bush Cc: David Conrad , Sandy Harris , namedroppers , markk@verisignlabs.com Subject: Re: Opt-in Decission day: Postponed Message-ID: <20020607174418.GG4661@slam.admin.cto.netsol.com> References: <3D00ED4E.54B98E50@storm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,OPT_IN,SIGNATURE_DELIM version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Jun 07, 2002 at 08:51:39AM -0700, Randy Bush wrote: > sounds like time to move this non-technical and ietf-generic discussion > to the poised list. I disagree. I'd like to see what the undocumented* decision process that affects work items that are on this mailing list and within the DNSEXT wg sessions discussed here. If there is a process issue that needs to be formalized, then it should move on to poised. People need to know what is really going on (including myself) as we volunteer work to improve DNS standards. The reason I'm specifically concerned is that there was wg consensus on opt-in with delegations only restriction at ietf 53. This dns directoriate group seems to be running against the consensus of the wg by "not liking" opt-in. Additionally, this group has not publically produced anything that defines their dislike that the authors can defend against. To me, the issue of having an undocumented decision point by a small group of people in a "open" standards organization smells bad. If this is the way it is I think it would be prudent for the architects of this directorate to then formalize this structure on poised. Mark *it may be documented but I have not seen a pointer. If I haven't seen it as a long time participant, then I'm sure there are others lurking about that have not seen it as well. -- Mark Kosters markk@netsol.com 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 Fri Jun 7 14:42:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08212 for ; Fri, 7 Jun 2002 14:42:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GOVI-00024J-00 for namedroppers-data@psg.com; Fri, 07 Jun 2002 11:30:28 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17GOVE-00023x-00 for namedroppers@ops.ietf.org; Fri, 07 Jun 2002 11:30:24 -0700 Received: from [128.177.195.171] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 788AF31925; Fri, 7 Jun 2002 11:30:23 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Fri, 07 Jun 2002 11:30:34 -0700 Subject: Re: Opt-in Decission day: Postponed From: David Conrad To: Randy Bush Cc: Sandy Harris , namedroppers , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In response to a private question: > On 6/7/02 8:51 AM, "Randy Bush" wrote: >> sounds like time to move this non-technical and ietf-generic discussion >> to the poised list. > Where? Interesting. Both POISED and POISSON (ONgoing? Um, yeah.) have concluded. For those wondering where the mailing list Randy mentions is, try poised@lists.tislabs.com (to subscribe, poised-request@lists.tislabs.com). Rgds, -drc (seatac astronomy) -- to unsubscribe send a message to namedroppers-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 Jun 7 15:13:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09236 for ; Fri, 7 Jun 2002 15:13:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GOzJ-00031z-00 for namedroppers-data@psg.com; Fri, 07 Jun 2002 12:01:29 -0700 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 17GOzG-00031h-00; Fri, 07 Jun 2002 12:01:26 -0700 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g57IvPp15989; Fri, 7 Jun 2002 11:57:26 -0700 (PDT) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Jun 2002 12:02:59 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869AEC@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Randy Bush'" , David Conrad Cc: Sandy Harris , namedroppers , markk@verisignlabs.com Subject: RE: Opt-in Decission day: Postponed Date: Fri, 7 Jun 2002 12:02:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > sounds like time to move this non-technical and ietf-generic > discussion to the poised list. I can certainly understand why you would prefer that approach however the rest of the working group appears to have a different opinion. We are not discussing a change in the rules of IETF working group process. What we are discussing is something rather different. We are discussing our outrage at being told what we believed to be the rules of the game turn out not to be. This is particularly bad when the working group chair is an area director. So the recourse the working group might normally have through their Working Group chair to the IESG is lost. Nor does it help when the working group chair makes it clear that he does not feel that he has any duty to defend his actions to the working group as a whole and is openly contemptuous of those who complain. The IETF works on a finely balanced set of understandings and counter balances. One of the most important principles being that the standards group decision process is open and runs according to certain rules. If area directors start saying that decisions are actually dependent on approval by cabals that discuss in secret, keep no minutes of their discussions and whose existence is not fully documented then working groups are likely to loose confidence in IETF process. The formation of a consultation body, whether formal or informal to advise area directors cannot be equated with taking advice from the members of the body individually. The message you sent to the group states that the directorate has made a corporate decision and moreover it is implied that that corporate decision overrides the consensus of the working group. If the area directors accept advice from individuals then that may be rebutted by advice from an individual. If on the other hand the advice of a 'directorate' is accepted the rebuttal by an individual may appear to have less weight. Also in the case of a statement by an individual I can call up that individual and discuss the issues with them personally. If the opinion is that of the directorate I can call up each member of the directorate personally and reach agreement with them that opt-in is a reasonable proposal but that is still trumped by the 'decision' reached by the directorate en-cabal. I am currently contacting each member of the cabal individually and discussing the issue with them. It is clear that the information made available to them fell far short of the information provided to the working group list. I am very concerned that when I try to ask certain questions I am told 'that is confidential'. So I am placed in the position of rebutting arguments that I cannot even find out. Again taking confidential advice from an individual is very different from taking confidential advice from a group. If the area director takes advice in confidence from Alice I can still call up Alice and ask her her opinion and she can choose to share her confidential advice with me if she chooses. If however Alice par I am not a lawyer but I have to wonder what the legal status of such a body is. However 'advisory' you claim the directorate to be it can be argued that they have been ascribed standing in the decision process. This drives a coach and horses through the carefully constructed set of proceedures designed to protect area directors from littigation. Worse yet many of the members of the directorate are probably not covered by the indemnity insurance that ISOC buys to protect area directors. More significantly from my point of view I have very grave reservations about working in a standards body that includes my competitors if that body is taking advice from confidential cabals. That type of activity may well invalidate the safe harbor provisions of the Sherman act. So before things spin too far out of control I will ask nicely. Can you please provide the working group with a list of concrete objections to opt-in from the directorate? Phill -- to unsubscribe send a message to namedroppers-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 Jun 7 17:05:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12772 for ; Fri, 7 Jun 2002 17:05:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GQi1-0006CI-00 for namedroppers-data@psg.com; Fri, 07 Jun 2002 13:51:45 -0700 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 17GQhy-0006C6-00; Fri, 07 Jun 2002 13:51:42 -0700 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g57Klfp07254; Fri, 7 Jun 2002 13:47:41 -0700 (PDT) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Jun 2002 13:53:15 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869AF1@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Randy Bush'" , David Conrad Cc: Sandy Harris , namedroppers , markk@verisignlabs.com Subject: RE: Opt-in Decission day: Postponed Date: Fri, 7 Jun 2002 13:52:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > think of it as "hmmm, this is deep stuff. maybe some folk i > know and can work with would be able to advise me." there are > directorates in transport, sub-ip, wireless, and a number of > other areas or subjects. That may be convenient for you as an AD but that does not mean that it is proper for you to take advice from such a body. In particular a lot of IETF standards relate to products for which there are competing suppliers. Agreements made involving such competitors have to meet a very strict set of requirements to ensure that there are no anti-trust entanglements. Taking advice in confidence from an unrepresentative ad-hoc comittee does not meet those requirements to say the least. The IETF fiction that we represent ourselves and not our companies is unlikely to help very much in this respect. It certainly did not help the head of Sotherby's. In this case I doubt the fiction would be accepted in court because the IESG minutes list the members along with their companies as do RFCs and Drafts. In this case the Working Group is at a further disadvantage because we are talking to you with your WG chair hat on and then you go talk to yourself with an AD hat on and then go talk to the cabal you appointed. [Let us leave aside the curious issue that you are AD of Ops and not the internet area where DNSEXT is listed] There is a clear conflict of interest there. Discussion of that conflict of interest that affects its work is certainly a legitimate topic of conversation for the working group list. Phill -- to unsubscribe send a message to namedroppers-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 Jun 7 17:14:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13179 for ; Fri, 7 Jun 2002 17:14:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GQva-0006dz-00 for namedroppers-data@psg.com; Fri, 07 Jun 2002 14:05:46 -0700 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 17GQvX-0006dk-00; Fri, 07 Jun 2002 14:05:43 -0700 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by pigeon.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g57L14w19192; Fri, 7 Jun 2002 14:01:05 -0700 (PDT) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Jun 2002 14:07:16 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869AF2@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Randy Bush'" , David Conrad Cc: Sandy Harris , namedroppers , markk@verisignlabs.com Subject: RE: Opt-in Decission day: Postponed Date: Fri, 7 Jun 2002 14:06:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Would you mind answering the question? > > sure, for the third time. they advise the area directors, in the case > of dns-dir, erik for dnsext and me for dnsops. The question remains unanswered. The issue is whether it is the case as implied by your initial message that you are taking advice form this body on the subject of whether a WG specification should be approved. Is it the case that you have asked for advice on whether OPT-IN is to proceed? The only public information I can find on the DNS Directorate is a comment that setting up a workshop on DNS Scaling issues was moved to them by the IESG in 1999. I don't think anyone has a problem with an AD passing off a set of long term research oriented issues to an ad-hoc group for consideration. There is a major problem treating a standards process issue in that fashion. Phill -- to unsubscribe send a message to namedroppers-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 Jun 7 19:37:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16985 for ; Fri, 7 Jun 2002 19:37:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GT6R-000Ah0-00 for namedroppers-data@psg.com; Fri, 07 Jun 2002 16:25:07 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17GT6M-000AgI-00 for namedroppers@ops.ietf.org; Fri, 07 Jun 2002 16:25:02 -0700 Received: from [128.177.195.171] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 86AC93190E; Fri, 7 Jun 2002 16:25:01 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Fri, 07 Jun 2002 16:25:12 -0700 Subject: What are the opt-in issues From: David Conrad To: Randy Bush Cc: namedroppers Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy, On 4/16, you wrote: > after much discussion and struggle, it seems the closest we can get > to consensus is a compromise with which few if any can not live, > opt-in restricted to delegation points. On 6/6, you wrote: > major pushback from the dns directorate In an attempt to bring the opt-in discussions back out into the light, what exactly was the pushback? I am not a particular fan of opt-in, however we have implemented delegation only opt-in in 3 separate name servers (including both authoritative and caching servers), it was painful but it works, and the functionality it provides addresses some scaling considerations at least one organization involved in large scale DNS operations believe are significant. Given the working group seemed to accept the arguments Mark Kosters put forth regarding the implications of fully signing .COM (and other TLD registries seem to want to follow Verisign into the same scaling swamp as quickly as they can), it would seem to me that the value of opt-in has been documented. As I have been reminded in the past, the question should be "is there a protocol issue here" not "do I like it". What are the opt-in protocol issues? Tnx, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 8 00:45:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22565 for ; Sat, 8 Jun 2002 00:45:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GXtU-000JPZ-00 for namedroppers-data@psg.com; Fri, 07 Jun 2002 21:32:04 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17GXtQ-000JOk-00; Fri, 07 Jun 2002 21:32:00 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA16532; Sat, 8 Jun 2002 00:31:50 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA01408; Sat, 8 Jun 2002 00:31:47 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id AAA27400; Sat, 8 Jun 2002 00:31:47 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id AAA00696; Sat, 8 Jun 2002 00:31:48 -0400 (EDT) To: David Conrad Cc: Randy Bush , namedroppers Subject: Re: What are the opt-in issues References: From: Derek Atkins Date: 08 Jun 2002 00:31:48 -0400 In-Reply-To: Message-ID: Lines: 37 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,OPT_IN,RCVD_IN_RELAYS_ORDB_ORG version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Thre are a number David Conrad writes: > In an attempt to bring the opt-in discussions back out into the light, what > exactly was the pushback? > > I am not a particular fan of opt-in, however we have implemented delegation > only opt-in in 3 separate name servers (including both authoritative and > caching servers), it was painful but it works, and the functionality it > provides addresses some scaling considerations at least one organization > involved in large scale DNS operations believe are significant. > > Given the working group seemed to accept the arguments Mark Kosters put > forth regarding the implications of fully signing .COM (and other TLD > registries seem to want to follow Verisign into the same scaling swamp as > quickly as they can), it would seem to me that the value of opt-in has been > documented. > > As I have been reminded in the past, the question should be "is there a > protocol issue here" not "do I like it". What are the opt-in protocol > issues? > > Tnx, > -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: -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-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 Jun 8 00:52:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22598 for ; Sat, 8 Jun 2002 00:52:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GY2y-000JiC-00 for namedroppers-data@psg.com; Fri, 07 Jun 2002 21:41:52 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17GY2u-000Jhx-00; Fri, 07 Jun 2002 21:41:49 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id AAA01323; Sat, 8 Jun 2002 00:41:47 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA01624; Sat, 8 Jun 2002 00:41:47 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id AAA20804; Sat, 8 Jun 2002 00:41:46 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id AAA00717; Sat, 8 Jun 2002 00:41:47 -0400 (EDT) To: David Conrad Cc: Randy Bush , namedroppers Subject: Re: What are the opt-in issues References: From: Derek Atkins Date: 08 Jun 2002 00:41:47 -0400 In-Reply-To: Message-ID: Lines: 63 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,OPT_IN,RCVD_IN_OSIRUSOFT_COM version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk First, note that the DNS Directorate does not have any real power, AFAICT (I've only recently been invited to join). We don't really make decisions -- instead we bring a bunch of knowledge from various fields and provide advice to the A/Ds. I think the best analogy is to the IESG: the IESG cannot create anything, but they can certainly destroy something. Similarly, I do not believe that the DNS Directorate can dictate policy or direction, but can urge the A/Ds to stop a potentially dangerous direction. Specifically on opt-in, there are a number of attacks that full DNSSec protects against but opt-in re-opens. In particular there are a few types of cache poisoning attacks that fall into this category. One of the real issues is that opt-in severly changes the security properties of DNSsec in a way that is not completely understood and without a clear and comprehensive security analysis. Being a security person myself I am uncomfortable mucking with security properties without a clear analysis of the ramifications. Said cache-poisoning attacks are one such ramification. Are there others? We don't know. And there-in lies the potential gotchas. -derek PS: These "cache poisoning" attacks have also been called "typo attacks", and I personally discussed these attacks with people in Minneapolis. I do not feel like describing them now -- perhaps next week after I get some rest. David Conrad writes: > In an attempt to bring the opt-in discussions back out into the light, what > exactly was the pushback? > > I am not a particular fan of opt-in, however we have implemented delegation > only opt-in in 3 separate name servers (including both authoritative and > caching servers), it was painful but it works, and the functionality it > provides addresses some scaling considerations at least one organization > involved in large scale DNS operations believe are significant. > > Given the working group seemed to accept the arguments Mark Kosters put > forth regarding the implications of fully signing .COM (and other TLD > registries seem to want to follow Verisign into the same scaling swamp as > quickly as they can), it would seem to me that the value of opt-in has been > documented. > > As I have been reminded in the past, the question should be "is there a > protocol issue here" not "do I like it". What are the opt-in protocol > issues? > > Tnx, > -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: -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-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 Jun 8 01:19:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22875 for ; Sat, 8 Jun 2002 01:19:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GYXb-000Kns-00 for namedroppers-data@psg.com; Fri, 07 Jun 2002 22:13:31 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17GYXW-000Knc-00 for namedroppers@ops.ietf.org; Fri, 07 Jun 2002 22:13:26 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 2E94D28B6C for ; Fri, 7 Jun 2002 22:13:26 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers Subject: Re: What are the opt-in issues In-Reply-To: Message from Derek Atkins of "08 Jun 2002 00:41:47 EDT." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Fri, 07 Jun 2002 22:13:26 -0700 Message-Id: <20020608051326.2E94D28B6C@as.vix.com> X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk A note before I begin. Derek has earned my deep respect over years, and no part of what I've got to say here should be thought of as directed at him, even though I'm going to couch my words here as a reply to his. I am quietly outraged at the closed nature of the standards body I thought I was part of. My words should be taken personally only by those who have set up and still maintain a secret second government here. Derek is a relative newcomer to DNSDIR (by his own words) and I'm not holding him responsible for its existence nor for the AD's reliance upon it. > ... Similarly, I do not believe that the DNS Directorate can dictate > policy or direction, but can urge the A/Ds to stop a potentially > dangerous direction. So, anyone who thought the WG was anything but a debating society were confused. A non-open process will be used to decide what is advanced, and the visible and open process is just "the show." > Specifically on opt-in, there are a number of attacks that full DNSSec > protects against but opt-in re-opens. In particular there are a few > types of cache poisoning attacks that fall into this category. We heard those concerns in the open process -- in the WG, that is -- and the moderately clear consensus of those involved was "go ahead with it." However, since the minority opposition included Randy Bush, a non-open process -- let's call these "the grownups" -- was convened to study the situation more seriously and make sure that the open process -- let's call ourselves "the kids" -- weren't going off in some crazy direction. What a relief. Now I don't have to pull up stakes in the bar and port myself and my laptop into a meeting room next time there's a DNSEXT time slot. You other kids can go have your fun and games, I'll just sip my beer and wait for the grownups to meet later in secret and decide what direction the DNS protocol will take. Simplicity itself. > One of the real issues is that opt-in severly changes the security > properties of DNSsec in a way that is not completely understood and > without a clear and comprehensive security analysis. Being a security > person myself I am uncomfortable mucking with security properties > without a clear analysis of the ramifications. Said cache-poisoning > attacks are one such ramification. Are there others? We don't know. > And there-in lies the potential gotchas. Well, noone with either DNS experience or security experience has been entirely comfortable with any version of the DNSSEC specification, ever. Many of us now treat that condition as a given. I guess not everybody! I guess we were deadass wrong back in 1996 when we deliberately proceeded toward what we thought was a short path toward implementation and deployment. We had at least five more years to debate these matters, and based on this latest DNS Directorate revelation, it appears that we have at least one more year of debate remaining. Goodbye, 2002, we hardly knew ye. I call upon Randy Bush to resign as DNSEXT WG co-chair. -- to unsubscribe send a message to namedroppers-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 Jun 8 08:50:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05889 for ; Sat, 8 Jun 2002 08:50:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GfTh-0006kn-00 for namedroppers-data@psg.com; Sat, 08 Jun 2002 05:37:57 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17GfTd-0006kP-00 for namedroppers@ops.ietf.org; Sat, 08 Jun 2002 05:37:53 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17GfTc-000JV0-00 for namedroppers@ops.ietf.org; Sat, 08 Jun 2002 05:37:52 -0700 Message-Id: <20020607230950.465ac173.mrose@dbc.mtview.ca.us> In-Reply-To: <20020608051326.2E94D28B6C@as.vix.com> References: <20020608051326.2E94D28B6C@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Fri, 7 Jun 2002 23:09:50 -0700 From: Marshall Rose Cc: namedroppers@ops.ietf.org Subject: Re: What are the opt-in issues X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,OPT_IN,SUPERLONG_LINE,MISSING_HEADERS version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] hi. sorry to comment on something that i know absolutely nothing about, i.e., "the opt-in issues". i will take the blame for having started the concept of an "area directorate" about 10 years ago when i was running the network management area. there are a lot of different goals for a directorate, ranging from "having more eyes on the ground" to "helping mid-level folks become senior level folks". i had pretty good success with the folks on my directorate, and a few even went on to greater things... what is important to understand is that no directorate has any power whatsoever. a directorate can give advice to some ADs, but ultimately it is the ADs who have to make, and then defend, those decisions. alternatively, the ADs can simply ignore the advice. citizen D is flat out wrong when he likens a directorate to the iesg. a directorate can not kill anything. they can suggest to some ADs that something be killed, but it is up to the ADs to pull the actual trigger. alternatively, the ADs can graciously thank the directorate for their advice and move on to the next topic. citizen P is flat out wrong when he says there is a conflict of interest here because an AD is also chair of this working group, and therefore the working group can't mount an effective appeal. citizen X is flat out wrong when he views a directorate as any kind of a formal body, similar to a working group, a design team, or an AD. a directorate is nothing more than an informal group of folks who advise an AD. and, let's say it again... the AD is free to take their advice, or ignore it, or do both or neither. the appeals process is clear: wg chair, relevant AD, entire IESG, entire IAB. if folks aren't happy about the way this "opt-in" thing isn't being handled by the WG chair, go to the relevant AD. if folks aren't happy about what the relevant AD says,, go to the entire IESG. if folks aren't happy about what the IESG says, then go the IAB. if folks aren't happy about what the IAB says, then perhaps you should get back on the court-ordered medication. again, i appolgize for taking everyone's time. /mtr -- to unsubscribe send a message to namedroppers-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 Jun 8 12:56:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09335 for ; Sat, 8 Jun 2002 12:56:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GjKp-000AXS-00 for namedroppers-data@psg.com; Sat, 08 Jun 2002 09:45:03 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17GjKl-000AWv-00 for namedroppers@ops.ietf.org; Sat, 08 Jun 2002 09:44:59 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17GjKl-0002IX-00 for namedroppers@ops.ietf.org; Sat, 08 Jun 2002 09:44:59 -0700 Message-ID: <000001c20f05$79063be0$0300a8c0@ne.mediaone.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit From: "Phillip Hallam-Baker" To: Subject: Re: What are the opt-in issues Date: Sat, 8 Jun 2002 11:59:28 -0400 X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit No Marshall, telling us everything is alright and we should just trust the great and the good is not going to help. You may be correct in stating what a directorate SHOULD be, however that is irrelevant. A directorate should not be an informal gatekeeper on the standards track which is the role the WG chair has attempted to assign to it. The issue is not whether the formation of a directorate is legitimate but whether the role of an unaccountable, unelected directorate meeting in secret in a standards process is legitimate. As for your statement that the directorate has no power, I have heard the statement from a member of the IESG and the Directorate only to then be directly contradicted as follows. "The Directorate has no power to create but it does have an effective power to block, the AD would find it hard to approve a specification against the advice of the directorate." Citizen D. is apparently not the only member of the directorate who is under the misapprehension that they hold an informal veto power. What we are talking about is a case in which their are two specifications, the status quo and the ammended specification. The power of veto thus becomes the power of decision. The right to give advice in a standards process is not the trivial matter you purport it to be. Given your experience of ISO processes I can't believe that you don't understand that to be the case. Moreover your description of the appeals process is incomplete in two respects. First you miss off step zero in any argument between a WG and a chair which is for the WG members to tell the chair that they have no confidence in him and it is time for them to resign. I second Paul's motion. I have had no confidence in Randy Bush since my first experience of a DNSEXT meeting. It is the only tme I have ever spoken in a standards group meeting and been hissed at by the WG chair when I stated my company. I have a pretty thick skin but I do not find such open intimidation acceptable which is why I made my earlier complaint concerning the incident to the ADs. That type of behaviour is I believe calculated to poison the atmosphere of any working group and discourage particpation by legitimate . The second respect in which your analysis is incomplete is that the IETF process is not the final recourse. That is why the irregular procedure adopted by the WG chair is so problematic. To put it bluntly the companies that pay ISOC subscription fees to buy indemnity insurance to cover ADs and WG chairs actions do not do so so that clowns like Bush can behave as if they can run a working group as their own personal fifedom. Phill -- to unsubscribe send a message to namedroppers-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 Jun 8 16:32:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11413 for ; Sat, 8 Jun 2002 16:32:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GmfW-000Dca-00 for namedroppers-data@psg.com; Sat, 08 Jun 2002 13:18:38 -0700 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 17GmfT-000DcP-00 for namedroppers@ops.ietf.org; Sat, 08 Jun 2002 13:18:35 -0700 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g58KIW319603; Sat, 8 Jun 2002 13:18:32 -0700 (PDT) From: Bill Manning Message-Id: <200206082018.g58KIW319603@boreas.isi.edu> Subject: Re: What are the opt-in issues In-Reply-To: <000001c20f05$79063be0$0300a8c0@ne.mediaone.net> from Phillip Hallam-Baker at "Jun 8, 2 11:59:28 am" To: phallam@attbi.com (Phillip Hallam-Baker) Date: Sat, 8 Jun 2002 13:18:32 -0700 (PDT) Cc: namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Noting that the WG list where most of this discussion is moderated by Mr. Bush. -- --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 8 17:12:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11920 for ; Sat, 8 Jun 2002 17:12:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GnKi-000EHE-00 for namedroppers-data@psg.com; Sat, 08 Jun 2002 14:01:12 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17GnKf-000EH0-00 for namedroppers@ops.ietf.org; Sat, 08 Jun 2002 14:01:09 -0700 Received: from [10.0.1.11] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 11ABD3190E; Sat, 8 Jun 2002 14:01:08 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Sat, 08 Jun 2002 14:01:19 -0700 Subject: Re: What are the opt-in issues From: David Conrad To: Derek Atkins Cc: Randy Bush , namedroppers Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Derek, On 6/7/02 9:41 PM, "Derek Atkins" wrote: > First, note that the DNS Directorate does not have any real power, > AFAICT (I've only recently been invited to join). Randy Bush has used "pushback from the DNS directorate" as justification for postponing a decision on opt-in. This would appear to imply some power delegated to a closed group that keeps no public record. However, I do not believe this is the appropriate venue for such discussions. The poised list is a better venue. Unfortunately, it appears the poised list is not currently accepting new subscriptions. > Specifically on opt-in, there are a number of attacks that full DNSSec > protects against but opt-in re-opens. In particular there are a few > types of cache poisoning attacks that fall into this category. It would seem to me that _publicly_ documenting these attacks would go a long way towards reducing this controversy. 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 Sat Jun 8 18:41:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12857 for ; Sat, 8 Jun 2002 18:41:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GolD-000FkR-00 for namedroppers-data@psg.com; Sat, 08 Jun 2002 15:32:39 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17Gol9-000FkG-00 for namedroppers@ops.ietf.org; Sat, 08 Jun 2002 15:32:35 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17Gol9-000EYb-00; Sat, 08 Jun 2002 15:32:35 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: David Conrad Cc: Derek Atkins , namedroppers Subject: Re: What are the opt-in issues References: Message-Id: Date: Sat, 08 Jun 2002 15:32:35 -0700 X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Randy Bush has used "pushback from the DNS directorate" as > justification for postponing a decision on opt-in. close. as explanation, not justification. and it was the ads who the directorate advises who received the pushback, exactly how a directorate is supposed to function. so we have done our best to get more expert technical input [0] by asking roy to talk with us a few times. and now roy and rob are working on writing up the technical issues. > The poised list is a better venue. Unfortunately, it appears > the poised list is not currently accepting new subscriptions. heck, yesterday my post there bounced. but i have heard rumor that the list is in a maint/move cycle this weekend. > It would seem to me that _publicly_ documenting these attacks > would go a long way towards reducing this controversy. i think rob and roy are working on writing up the technical issues. but a worrysome one is that folk are still discovering corner cases and having to explore technical issues while we are in what many hoped would be a spec freeze and ship cycle [1]. when will the tech issues stop arising? randy --- [0] - if we want political input, this forum seems to specialize in it sufficiently to cause a large flurry of unsubscribes in the last day or so. [1] - i know this is not the forum for technical issues :-), but here's a timy one that came up last week. how does opt-in affect ad-is-secure? it seems to further weaken what receiving ad==true tells a stub resolver. -- to unsubscribe send a message to namedroppers-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 Jun 8 21:51:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14946 for ; Sat, 8 Jun 2002 21:51:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17GrOm-000Hdy-00 for namedroppers-data@psg.com; Sat, 08 Jun 2002 18:21:40 -0700 Received: from nat.dsl.flame.org ([64.133.235.52] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 17GrOi-000Hdh-00; Sat, 08 Jun 2002 18:21:36 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g591LSi07989; Sat, 8 Jun 2002 18:21:28 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Sat, 8 Jun 2002 18:21:28 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: Randy Bush cc: namedroppers Subject: Re: What are the opt-in issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, 8 Jun 2002, Randy Bush wrote: > [1] - i know this is not the forum for technical issues :-), but > here's a timy one that came up last week. how does opt-in > affect ad-is-secure? it seems to further weaken what > receiving ad==true tells a stub resolver. Why? Insecure data from an opt-in zone will cause the AD bit to not be set in the response. The AD bit will be set if the response contains only secure data from the opt-in zone. Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 8 22:17:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15268 for ; Sat, 8 Jun 2002 22:17:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Grzz-000I7x-00 for namedroppers-data@psg.com; Sat, 08 Jun 2002 19:00:07 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17Grzv-000I7j-00 for namedroppers@ops.ietf.org; Sat, 08 Jun 2002 19:00:03 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 5DB8E28ED7 for ; Sat, 8 Jun 2002 19:00:03 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: What are the opt-in issues In-Reply-To: Message from Bill Manning of "Sat, 08 Jun 2002 13:18:32 PDT." <200206082018.g58KIW319603@boreas.isi.edu> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Sat, 08 Jun 2002 19:00:03 -0700 Message-Id: <20020609020003.5DB8E28ED7@as.vix.com> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Noting that the WG list where most > of this discussion is moderated by Mr. Bush. i don't think there's any problem with censorship. ops.ietf.org has the same A RR as psg.com, indicating that randy not only moderates this list, he also hosts it. i'm sure that, other issues aside, randy is doing everything possible to ensure that the namedroppers list works and his only moderation activity as far as i know is keeping spam 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 Sat Jun 8 23:32:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16272 for ; Sat, 8 Jun 2002 23:32:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Gt9V-000J70-00 for namedroppers-data@psg.com; Sat, 08 Jun 2002 20:14:01 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17Gt9P-000J6o-00; Sat, 08 Jun 2002 20:13:55 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id XAA17421; Sat, 8 Jun 2002 23:13:53 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA29134; Sat, 8 Jun 2002 23:13:53 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id XAA21001; Sat, 8 Jun 2002 23:10:28 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id XAA03097; Sat, 8 Jun 2002 23:10:28 -0400 (EDT) To: David Conrad Cc: Randy Bush , namedroppers Subject: Re: What are the opt-in issues References: From: Derek Atkins Date: 08 Jun 2002 23:10:28 -0400 In-Reply-To: Message-ID: Lines: 47 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,OPT_IN,RCVD_IN_OSIRUSOFT_COM version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David Conrad writes: > Randy Bush has used "pushback from the DNS directorate" as justification for > postponing a decision on opt-in. This would appear to imply some power > delegated to a closed group that keeps no public record. I don't think it is any more power than, theoretically, Jeff Schiller and Steve Bellovin asking a small set of people for their private opinion on "FooProtocol" and then blocking progress due to those private discussions. The directorate exists at the pleasure of the AD and exists to advise the ADs. The ADs can do whatever they wish using the information and advice of the directorate. Keep in mind that working group chairs and ADs have a lot of leeway here, and private discussions have as much place as discussions on public lists and WG meetings. An AD can base their decisions on whatever information they have, however they get it. The appeal process exists to make sure that such decisions are made reasonably. Complaining about private meetings at the IETF is just plain ludicrous. How much work gets accomplished during lunches and dinners during the IETF? Should all that be "outlawed" because it's not an open process? Or are you only complaining because this is blocking a protocol that you are interested in? You can't have it both ways. > > Specifically on opt-in, there are a number of attacks that full DNSSec > > protects against but opt-in re-opens. In particular there are a few > > types of cache poisoning attacks that fall into this category. > > It would seem to me that _publicly_ documenting these attacks would go a > long way towards reducing this controversy. Well, these attacks were only brought to my attention in Minneapolis. I believe that Roy and Rob are writing up a document and personally I am waiting to see what it says. I believe that Rob knows about this attack, and I'm fairly sure that Roy does as well. > Rgds, > -drc -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-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 Jun 8 23:57:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16531 for ; Sat, 8 Jun 2002 23:57:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Gti7-000Jbn-00 for namedroppers-data@psg.com; Sat, 08 Jun 2002 20:49:47 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17Gti1-000JbQ-00 for namedroppers@ops.ietf.org; Sat, 08 Jun 2002 20:49:42 -0700 Received: from [10.0.1.11] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 925E53190E; Sat, 8 Jun 2002 20:49:40 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Sat, 08 Jun 2002 20:49:52 -0700 Subject: Re: What are the opt-in issues From: David Conrad To: Derek Atkins Cc: Randy Bush , namedroppers Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Derek, On 6/8/02 8:10 PM, "Derek Atkins" wrote: > Complaining about private meetings at the IETF is just plain > ludicrous. How much work gets accomplished during lunches and dinners > during the IETF? Should all that be "outlawed" because it's not an > open process? Or are you only complaining because this is blocking a > protocol that you are interested in? You can't have it both ways. A) I've already stated I'm not a particular fan of opt-in. B) I am not suggesting outlawing private meetings -- that would indeed be ludicrous. What I am suggesting is that an action to kill a particular protocol should be justified based on objectively verifiable criteria, not because a small group of people decide in secret that the protocol should die. If opt-in should die, the reason should NOT be because of "major pushback from the DNS directorate". > I believe that Roy and Rob are writing up a document and personally I > am waiting to see what it says. I suspect Rob or Roy sending email to namedroppers pointing out the issue and asking what others think might have been a _much_ more effective way of hashing out the problem (if it is such). No slight intended towards Rob or Roy, but they are not the only ones who have a bit of a clue about opt-in, DNSSEC, and the way the DNS works. Contrary to Randy's opinion, namedroppers doesn't have to only be about politics. 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 Sun Jun 9 00:18:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16652 for ; Sun, 9 Jun 2002 00:18:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Gtt6-000Jn0-00 for namedroppers-data@psg.com; Sat, 08 Jun 2002 21:01:08 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17Gtt2-000Jmo-00 for namedroppers@ops.ietf.org; Sat, 08 Jun 2002 21:01:04 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17Gtt1-00008U-00; Sat, 08 Jun 2002 21:01:04 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: David Conrad Cc: namedroppers Subject: Re: What are the opt-in issues References: Message-Id: Date: Sat, 08 Jun 2002 21:01:04 -0700 X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Complaining about private meetings at the IETF is just plain >> ludicrous. How much work gets accomplished during lunches and dinners >> during the IETF? Should all that be "outlawed" because it's not an >> open process? Or are you only complaining because this is blocking a >> protocol that you are interested in? You can't have it both ways. > > A) I've already stated I'm not a particular fan of opt-in. > B) I am not suggesting outlawing private meetings -- that would indeed be > ludicrous. What I am suggesting is that an action to kill a particular > protocol should be justified based on objectively verifiable criteria, not > because a small group of people decide in secret that the protocol should > die. If opt-in should die, the reason should NOT be because of "major > pushback from the DNS directorate". > >> I believe that Roy and Rob are writing up a document and personally I >> am waiting to see what it says. > > I suspect Rob or Roy sending email to namedroppers pointing out the issue > and asking what others think might have been a _much_ more effective way of > hashing out the problem (if it is such). No slight intended towards Rob or > Roy, but they are not the only ones who have a bit of a clue about opt-in, > DNSSEC, and the way the DNS works. Contrary to Randy's opinion, > namedroppers doesn't have to only be about politics. and your message and most of this thread are such shining examples thereof. i don't think anyone but the paranoid have said that opt-in has been killed, let alone that it was killed by "a group of people meeting alone in secret." you might reread my original response to matt and my consistent responses thereafter before hyperventilating and indulging in black helicopter fantasies. randy -- to unsubscribe send a message to namedroppers-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 Jun 9 16:09:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06966 for ; Sun, 9 Jun 2002 16:09:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17H8kB-0006XU-00 for namedroppers-data@psg.com; Sun, 09 Jun 2002 12:52:55 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17H8jj-0006VM-00 for namedroppers@ops.ietf.org; Sun, 09 Jun 2002 12:52:27 -0700 Received: from [10.0.1.11] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 1B8083190C; Sun, 9 Jun 2002 12:52:26 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Sun, 09 Jun 2002 12:52:39 -0700 Subject: Re: What are the opt-in issues From: David Conrad To: Randy Bush Cc: namedroppers Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy, On 6/8/02 9:01 PM, "Randy Bush" wrote: >> Contrary to Randy's opinion, >> namedroppers doesn't have to only be about politics. > and your message and most of this thread are such shining examples > thereof. At least we can always count on you to bring either the match or the extra gasoline. > i don't think anyone but the paranoid have said that opt-in has > been killed, let alone that it was killed by "a group of people > meeting alone in secret." Then it would appear comments I received from three independent sources to the effect that opt-in was already dead were mistaken. How reassuring. > you might reread my original response to matt > > and my consistent responses thereafter "We're from the DNS Directorate, we're here to help". As I mentioned previously, raising the issues the directorate has with opt-in on the public mailing list could be helpful in exploring whether the issues are sufficient to kill opt-in. Why not be open? > before hyperventilating and > indulging in black helicopter fantasies. Speaking of shining examples, thanks for being so concerned about my health, both mental and physical. Let me reassure you that I have neither been hyperventilating nor have my fantasies involved black helicopters. I do have this fantasy about open and transparent standards processes, but that would, of course, be for another mailing list... 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 Sun Jun 9 16:27:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07160 for ; Sun, 9 Jun 2002 16:27:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17H98r-0006yl-00 for namedroppers-data@psg.com; Sun, 09 Jun 2002 13:18:25 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17H98l-0006yQ-00 for namedroppers@ops.ietf.org; Sun, 09 Jun 2002 13:18:19 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id BC3C128B6C for ; Sun, 9 Jun 2002 13:18:18 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers Subject: Re: What are the opt-in issues In-Reply-To: Message from David Conrad of "Sun, 09 Jun 2002 12:52:39 PDT." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Sun, 09 Jun 2002 13:18:18 -0700 Message-Id: <20020609201818.BC3C128B6C@as.vix.com> X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk the process as i understood it was that if the WG reached consensus the chair's job was to fwd the relevant drafts to the AD's. this appears to have happened. if the AD's don't feel comfortable with the document, they are supposed to throw it back to the WG with their concerns and questions noted, in a timely fashion. this appears not to have happened. now we're in an unhappy place. a subset of the WG (called a directorate) is meeting and discussing this in closed sessions for the purpose of advising the AD about these documents. the delay thus caused, and the lack of transparency, are intolerable. -- to unsubscribe send a message to namedroppers-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 Jun 9 17:29:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07803 for ; Sun, 9 Jun 2002 17:29:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HA86-0008AC-00 for namedroppers-data@psg.com; Sun, 09 Jun 2002 14:21:42 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17HA7v-00089q-00 for namedroppers@ops.ietf.org; Sun, 09 Jun 2002 14:21:31 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id OAA01274 for ; Sun, 9 Jun 2002 14:25:07 -0700 Message-Id: <5.1.1.2.2.20020609140039.02798298@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Sun, 09 Jun 2002 14:21:18 -0700 To: namedroppers From: Dave Crocker Subject: Re: What are the opt-in issues In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.4 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,TO_LOCALPART_EQ_REAL,OPT_IN,NO_MX_FOR_FROM version=2.20 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Folks, My reading of this protracted thread is that there are two, very different issues. One is technical and one is process. Technical: A range of difficult alternatives has been developed and debated at length and ad nauseam. My 50,000 foot scan of the list suggests opt-in won. If the actual rough consensus is different or unclear, then fine. That becomes a clear (and oddly straightforward) point to resolve. When there is a rough consensus, the last-minute roadblock that is always valid is "It won't work" as long as the roadblock is based on legitimate details. More often, this objection is raised using old material that is well-understood. Hence it is just a way to cause delay. It does not sound as if there are fresh insights to opt-in. If indeed there ARE fresh insights, I haven't noticed their being posted. To the casual reader, therefore, the technical situation appears to be that lengthy, diligent, technically competent debate has produced alternatives that each suffer from some difficult and even unsatisfying trade-offs. However, these alternatives are coupled with a strong desire to get resolution, leading to a rough consensus for opt-in. Would the working group chair please correct any details of this summary that are incorrect? Process: Difficult topics often benefit from having consultation by a small group of experts. The role of directorates in the IETF is lengthy, as Marshall has noted. The idea that prviate discussion groups may not be formed is silly enough that it surely is not what anyone is suggesting. The idea that a working group chair or an AD is to be prohibited from getting advice from such a group is equally silly. And of course the idea that such a group is given decision-making authority is also quite silly, given the IETF culture. No working group chair or AD would claim to have done such a thing. Were they to try, it would be an obvious basis for an immediate process appeal. What seems more likely -- and what fits IETF history better -- is that the relevant managers -- working group chair and/or AD -- have either communicated the role of that advice incorrectly or have used such advice incorrectly. The former is trivial to fix. The latter is pretty serious. One might claim that the relevant managers have already posted clarifications on this matter. To the extent that folks making objections are not satisfied with the response, I'll can't tell why, from the messages posted about this. So: I strongly suggest folks separate these lines of discussion. I equally strongly suggest that folks clarify exactly what problem(s) they claim are present and pursue fixing them in the usual ways done in the IETF. At the moment, the discussions are sufficiently laced with heat to prevent much other than more heat. Near as I can tell, all of the folks causing and reacting to the heat are trying to do the right thing. That they might not be succeeding does not reduce the seriousness of their intent. d/ -- to unsubscribe send a message to namedroppers-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 Jun 9 21:59:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11118 for ; Sun, 9 Jun 2002 21:59:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HEIC-000DSh-00 for namedroppers-data@psg.com; Sun, 09 Jun 2002 18:48:24 -0700 Received: from dhcp3202.nanog25.merit.net ([192.35.167.202] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17HEIA-000DSW-00 for namedroppers@ops.ietf.org; Sun, 09 Jun 2002 18:48:22 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17HEI9-0000cN-00 for namedroppers@ops.ietf.org; Sun, 09 Jun 2002 18:48:21 -0700 Message-ID: <000001c20fdb$a1a206c0$0300a8c0@ne.mediaone.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit From: "Phillip Hallam-Baker" To: Subject: Please state the 'attacks' in public Date: Sun, 9 Jun 2002 10:04:14 -0400 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] >Well, these attacks were only brought to my attention in Minneapolis. >I believe that Roy and Rob are writing up a document and personally >I am waiting to see what it says. I believe that Rob knows about this >attack, and I'm fairly sure that Roy does as well. Forgive me for asking for raising the same issue yet again, perhaps if the substantive issues were addressed there would not be the need. What are the security issues that Roy and Rob are addressing? Why can they not be shared with the group as a whole? If the AD needs advice on the security of OPTIN it would be more productive to address those concerns to one of the people who has done an extensive security analysis already. My understanding from certain members of the cabal is that what Roy and Rob have actually been asked to do is rehash the work on the necessity of the protocol change. I don't think that second guessing the working group on that issue is a proper matter for the cabal. As for Randy's splutterings about Black Helicopters, the existence of false conspiracy theories does not disprove the existence of conspiracies. Phill -- to unsubscribe send a message to namedroppers-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 Jun 9 22:00:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11165 for ; Sun, 9 Jun 2002 22:00:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HEEZ-000DMG-00 for namedroppers-data@psg.com; Sun, 09 Jun 2002 18:44:39 -0700 Received: from dhcp3202.nanog25.merit.net ([192.35.167.202] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17HEEX-000DM5-00 for namedroppers@ops.ietf.org; Sun, 09 Jun 2002 18:44:37 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17HEEW-0000bp-00 for namedroppers@ops.ietf.org; Sun, 09 Jun 2002 18:44:36 -0700 Message-ID: <000101c20f48$3dc55640$0300a8c0@ne.mediaone.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit From: "Phillip Hallam-Baker" To: Subject: Re: What are the opt-in issues Date: Sat, 8 Jun 2002 19:57:25 -0400 X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Randy is incorrect to claim that new technical issues have emerged. The Typo attack is simply a sub class of an attack that was identified in the original security analysis. Any party can apply for an unregistered domain name in a TLD at any time, the authentication criteria applied by registrars do not include verification that the applicant of the domain name has provided a bona fide address on which process can be served. This would have been clarified earlier if the objection had been posted to the working group where it belongs rather than an unrepresentative and unaccountable body meeting in secret. I suspect that if you are allowed to continue to take advice in secret you can continue to re-raise old technical issues as new ones for a very long time. Phill -- to unsubscribe send a message to namedroppers-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 Jun 9 22:00:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11201 for ; Sun, 9 Jun 2002 22:00:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HEES-000DM1-00 for namedroppers-data@psg.com; Sun, 09 Jun 2002 18:44:32 -0700 Received: from dhcp3202.nanog25.merit.net ([192.35.167.202] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17HEEJ-000DKu-00 for namedroppers@ops.ietf.org; Sun, 09 Jun 2002 18:44:24 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17HEEI-0000bk-00 for namedroppers@ops.ietf.org; Sun, 09 Jun 2002 18:44:22 -0700 Message-ID: <000001c20f47$16def3c0$0300a8c0@ne.mediaone.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit From: "Phillip Hallam-Baker" To: Date: Sat, 8 Jun 2002 19:49:10 -0400 X-Spam-Status: No, hits=2.4 required=5.0 tests=SUBJ_MISSING version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] > Noting that the WG list where most > of this discussion is moderated by Mr. Bush. Randy is not the only person with moderation power on the list. Phill -- to unsubscribe send a message to namedroppers-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 Jun 9 22:02:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11238 for ; Sun, 9 Jun 2002 22:02:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HEEj-000DMT-00 for namedroppers-data@psg.com; Sun, 09 Jun 2002 18:44:49 -0700 Received: from dhcp3202.nanog25.merit.net ([192.35.167.202] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17HEEg-000DMI-00 for namedroppers@ops.ietf.org; Sun, 09 Jun 2002 18:44:47 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17HEEg-0000bu-00 for namedroppers@ops.ietf.org; Sun, 09 Jun 2002 18:44:46 -0700 Message-Id: <200206090302.DAA00750@vacation.karoshi.com> In-Reply-To: <20020609020003.5DB8E28ED7@as.vix.com> from "Paul Vixie" at Jun 08, 2002 07:00:03 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: bmanning@karoshi.com Subject: Re: What are the opt-in issues To: paul@vix.com (Paul Vixie) Date: Sun, 9 Jun 2002 03:02:28 +0000 (UCT) Cc: namedroppers@ops.ietf.org X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] > > > Noting that the WG list where most > > of this discussion is moderated by Mr. Bush. > > i don't think there's any problem with censorship. ops.ietf.org has the > same A RR as psg.com, indicating that randy not only moderates this > list, he also hosts it. i'm sure that, other issues aside, randy is > doing everything possible to ensure that the namedroppers list works > and his only moderation activity as far as i know is keeping spam out. > That was the point. What ever else people may think, Mr. Bush is generally an reasonable person. Opinionated. Sarcastic. Does not suffer fools gladly. But he does his level best to ensure that the "right" thing happens. Sort of like a number of people I know. Questions regarding what is the "right" thing are, perhaps, not open to debate. :) --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 Sun Jun 9 22:26:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11489 for ; Sun, 9 Jun 2002 22:26:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HElk-000EIc-00 for namedroppers-data@psg.com; Sun, 09 Jun 2002 19:18:56 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17HElf-000EIM-00 for namedroppers@ops.ietf.org; Sun, 09 Jun 2002 19:18:51 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id WAA01704; Sun, 9 Jun 2002 22:18:49 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA19280; Sun, 9 Jun 2002 22:18:49 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id WAA04690; Sun, 9 Jun 2002 22:18:48 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id WAA05564; Sun, 9 Jun 2002 22:18:49 -0400 (EDT) To: "Phillip Hallam-Baker" Cc: Subject: Re: What are the opt-in issues References: <000101c20f48$3dc55640$0300a8c0@ne.mediaone.net> From: Derek Atkins Date: 09 Jun 2002 22:18:49 -0400 In-Reply-To: <000101c20f48$3dc55640$0300a8c0@ne.mediaone.net> Message-ID: Lines: 26 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,OPT_IN,RCVD_IN_RELAYS_ORDB_ORG version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Phillip Hallam-Baker" writes: > Randy is incorrect to claim that new technical issues have emerged. > > The Typo attack is simply a sub class of an attack that was identified in > the original security analysis. Any party can apply for an unregistered > domain name in a TLD at any time, the authentication criteria applied by > registrars do not include verification that the applicant of the domain name > has provided a bona fide address on which process can be served. Phill, you are misrepresting the attack. Please don't take my words and misrepresent them just to try to make your point. Sure, someone can register the domain under falsified information, but in that circumstance, if the domain is being used to defraud, the registrar has the power to un-register the domain. Under the typo attack against opt-in, an attacker could poison caches and work around the registrar's power to un-register a domain. Can you please point out where cache poisoning was mentioned in the opt-in discussions? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-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 Jun 9 22:29:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11526 for ; Sun, 9 Jun 2002 22:29:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HEpu-000EQ2-00 for namedroppers-data@psg.com; Sun, 09 Jun 2002 19:23:14 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17HEpr-000EPp-00 for namedroppers@ops.ietf.org; Sun, 09 Jun 2002 19:23:11 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id WAA02311; Sun, 9 Jun 2002 22:23:10 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA19439; Sun, 9 Jun 2002 22:23:09 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id WAA04776; Sun, 9 Jun 2002 22:23:09 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id WAA05567; Sun, 9 Jun 2002 22:23:10 -0400 (EDT) To: "Phillip Hallam-Baker" Cc: Subject: Re: Please state the 'attacks' in public References: <000001c20fdb$a1a206c0$0300a8c0@ne.mediaone.net> From: Derek Atkins Date: 09 Jun 2002 22:23:10 -0400 In-Reply-To: <000001c20fdb$a1a206c0$0300a8c0@ne.mediaone.net> Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.4 required=5.0 tests=IN_REP_TO,RCVD_IN_RELAYS_ORDB_ORG version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Phillip Hallam-Baker" writes: > Forgive me for asking for raising the same issue yet again, perhaps if > the substantive issues were addressed there would not be the need. > > What are the security issues that Roy and Rob are addressing? > > Why can they not be shared with the group as a whole? Phill, when Roy and Rob finish the document I'm sure it will be published as an I-D for all to read. These security issues "cannot be shared with the group as a whole" because, currently, they are in the brains of Rob and Roy, and are not written down. Patience, Phill. Take a deep breath, relax, and let Rob and Roy finish their document. There is no malice involved here, Phill. Just relax -- nobody here is out to get you. When they finish, don't worry, you'll know. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-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 Jun 9 22:41:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12067 for ; Sun, 9 Jun 2002 22:41:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HF2m-000EoS-00 for namedroppers-data@psg.com; Sun, 09 Jun 2002 19:36:32 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17HF2i-000Eo6-00 for namedroppers@ops.ietf.org; Sun, 09 Jun 2002 19:36:28 -0700 Received: from engill.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g5A2YeV38301; Sun, 9 Jun 2002 22:34:41 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020609223019.02de2ec0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sun, 09 Jun 2002 22:33:19 -0400 To: "Phillip Hallam-Baker" , From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: In-Reply-To: <000001c20f47$16def3c0$0300a8c0@ne.mediaone.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 07:49 PM 6/8/2002, Phillip Hallam-Baker wrote: >[ post by non-subscriber. with the massive amount of spam, it is easy to > miss and therefore delete mis-posts. so fix subscription addresses! ] > > > Noting that the WG list where most > > of this discussion is moderated by Mr. Bush. > >Randy is not the only person with moderation power on the list. > > Phill Namedroppers was a moderated mailing list, but not any more. Since early this year it is a member restricted mailing list. Randy has the unpleasant task to filtering spam and forward relevant non members postings to mailing list. Olafur ps: -- to unsubscribe send a message to namedroppers-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 Jun 10 05:40:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26476 for ; Mon, 10 Jun 2002 05:40:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HLPM-000NCE-00 for namedroppers-data@psg.com; Mon, 10 Jun 2002 02:24:16 -0700 Received: from dhcp3202.nanog25.merit.net ([192.35.167.202] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17HLPI-000NC1-00 for namedroppers@ops.ietf.org; Mon, 10 Jun 2002 02:24:12 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17HLPF-0000rX-00 for namedroppers@ops.ietf.org; Mon, 10 Jun 2002 02:24:10 -0700 In-Reply-To: References: <000101c20f48$3dc55640$0300a8c0@ne.mediaone.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1023677436.590.226.camel@error-messages.mit.edu> Mime-Version: 1.0 Subject: Re: What are the opt-in issues From: Greg Hudson To: Derek Atkins Cc: namedroppers@ops.ietf.org Date: 09 Jun 2002 22:50:36 -0400 X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] On Sun, 2002-06-09 at 22:18, Derek Atkins wrote: > Phill, you are misrepresting the attack. Please don't take my words > and misrepresent them just to try to make your point. Sure, someone > can register the domain under falsified information, but in that > circumstance, if the domain is being used to defraud, the registrar > has the power to un-register the domain. Under opt-in, if a registrar wants to "un-register" a domain which has been added through an insertion attack, it's a simple matter of adding a NXT record (without the opt-in bit set) for the two real records surrounding the inserted record. As I understand it, anyway. This doesn't sound like a substantial new issue. Certainly, we all knew that opt-in allows the insertion of unsigned records in a domain which uses it. (ObPolitics: In some sense, I do think some people are overreacting; but Randy and the directorate should realize that counseling "patience" isn't very compelling when the problem is an unwarranted delay.) -- to unsubscribe send a message to namedroppers-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 Jun 10 05:40:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26489 for ; Mon, 10 Jun 2002 05:40:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HLQN-000NE5-00 for namedroppers-data@psg.com; Mon, 10 Jun 2002 02:25:19 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17HLQJ-000NDr-00 for namedroppers@ops.ietf.org; Mon, 10 Jun 2002 02:25:15 -0700 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 5F23A3191F for ; Mon, 10 Jun 2002 02:25:14 -0700 (PDT) Date: Mon, 10 Jun 2002 11:40:17 +0200 (CEST) From: Roy Arends X-X-Sender: To: Subject: Re: Please state the 'attacks' in public In-Reply-To: <000001c20fdb$a1a206c0$0300a8c0@ne.mediaone.net> Message-ID: <20020610085728.G87120-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 9 Jun 2002, Phillip Hallam-Baker wrote: > What are the security issues that Roy and Rob are addressing? The process of caching/resolving opt-in material is not well understood. There is a potential burdon on a resolving nameserver which previously has cached opt-in NXT records. In 2535, NXT records will only appear in a "negative" response (as in:this record does not exist). With DS, NXT records appear in a "positive" response (in the case where NXT states: no DS). In that case, the owner name of the NXT record is identical to the QNAME. With Optin, NXT-Opt-in records (NXT without NXT bit set), appear in both "positive" responses and "negative" responses. Historically, nameservers use different internal-cache-lookup algorithms for both negative and positive responses. A memory efficient nameserver would cache NXT only once. Question: Is it okay to synthesize positive responses with negative responses. Since the TTL has different properties for both forward and reverse, this has the potential to be very ugly. It may even lead to security issues. There is another issue: When a nameserver has cached a positive Opt-In response: unsigned "www.example.com A" record set in an Optin zone. NXT record states "aaa.example.com NXT zzz.example.com ..."; the NXT record makes a statement for all between aaa and zzz. The owner name of the NXT record does NOT match the owner name of the A record set. Now, a choice between two evils should be made: 1) Match an incoming query with the owner name of the NXT record. This leads to verifying and caching of all unique QNAME/QTYPE combinations between aaa and zzz.example.com, including all NXT records and their accompanying signature. This is potentially putting the burdon from authoritative nameservers to recursive nameservers. Needless to say, this is inefficient, since there is a lot of redundant crypto-verification. Getting rid of crypto-redundancy was one of the design principles of opt-in. 2) Match an incoming query to the NXT records owner/nxt-owner interval. This is unique in the history of positive caching. Also an extra burdon on the ca hing server. A third issue that was brought up was how the AD bit should be interpreted. The AD bit says (short answer) all records have been verified to be okay. One one hand, with opt-in, there is an unsigned record which cannot be verified that it is "okay" -> AD bit clear. On the other hand, there is an unsigned record which can be verified that it is not signed -> AD bit set. In both cases, ALL signatures have been checked. ALL "crypto-statements" have been verified, and still, both AD bit states can be appropriate. Though the AD bit is a minor issue, this has to be written very clear and unambigous. The last issue "The typo attack" is absolutely no issue. It is discussed to death !!!! Since one uses opt-in, unsigned/unverified/untrue records can and may appear in the NXT-Optin interval. This should be clear before using opt-in. As with everything: if it is not signed, who knows what the state of the record is. No "security holes" are opened here. One has to decide consciously to use opt-in. > Why can they not be shared with the group as a whole? The whole "directorate push-back" hype was as follows: Rob Austein mentioned some of the above open issues. At that moment there was simply no written material about this (or none to my knowledge). The IESG annual meeting was coming up two weeks ago, Rob would be there, and some other folk who tend to show some clue once in a while were there as well. I happen to live in Holland, and Randy saw this as a good opportunity to have a face to face on this. A few folk there were also part of this dns-directorate. The list of names is known and is/was no secret. The conclusion was simply that the above issues needed to be documented. Rob and I volunteered to do this, and will do so. No hush hush, no secrets. We simply wanted to write this, and publish it, then discuss this on namedroppers, instead of discussing air. From that moment, I was added to this directorate. This way, Rob and I could discuss this matter while others could listen in. We might have chosen to do this in a private mail discussion. We did not. We might have chosen to discuss this on namedroppers, with a big potential of polarizing this whole discussion yet again, causing more delay. We did not. However. "Push back of the directorate" is a big misnomer. When I first heard about this "push-back" I was mad as hell. What directorate ? Who are they ? This was IMHO totally against NOTE WELL. If the directory had any such power, it should be dismanteld. "Push-back of the directorate" essentially means that the WG-chairs had to extend D-Day on opt-in once again, while we're writing this doc. Brave thing to do, since there is an enormous pressure on deploying DNSSEC yesterday. Turns out to be push-back as in "Deadline postponed yet once more". Not Optin is dead. Randy could have spend some more words about this. If any of you (really, anyone) can bring up design flaws in Opt-in that opens security holes due to protocol bugs, please do so, you will safe me a lot of work and pain. So, in short. Rob and I are going to write these issues up issues up. These issues are not (!) related to the opt-in, but simply issues that can pop-up due to the fact that these corner-cases are not well understood, and might be interpreted the wrong way. This document has nothing to do with directorates whatsoever. Once its finished, its dumped on namedroppers. > If the AD needs advice on the security of OPTIN it would be more productive > to address those concerns to one of the people who has done an extensive > security analysis already. > > My understanding from certain members of the cabal is that what Roy and Rob > have actually been asked to do is rehash the work on the necessity of the > protocol change. No, absolutely not. We were asked to address the above cases which are not well understood, and might cause ambiguity in deployment. IMHO the necessity of the protocol change is crystal clear. 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 Jun 10 05:43:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26568 for ; Mon, 10 Jun 2002 05:43:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HLWL-000NLj-00 for namedroppers-data@psg.com; Mon, 10 Jun 2002 02:31:29 -0700 Received: from dhcp3202.nanog25.merit.net ([192.35.167.202] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17HLWI-000NLY-00 for namedroppers@ops.ietf.org; Mon, 10 Jun 2002 02:31:26 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17HLWH-0000sz-00 for namedroppers@ops.ietf.org; Mon, 10 Jun 2002 02:31:25 -0700 Message-ID: <000101c21030$c7e76320$0300a8c0@ne.mediaone.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit In-Reply-To: From: "Phillip Hallam-Baker" To: "'Derek Atkins'" Cc: Subject: RE: What are the opt-in issues Date: Sun, 9 Jun 2002 23:42:00 -0400 X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] OK if that turns out to be a serious problem we can modify the domain recovery procedure so that the typo address is then registered and secured. I still find the attack to be somewhat less than worrisome. Maintaining a cache poisoning attack for several days after detection does not seem very likely. The domain name protest procedure has a minimum time for completion measured in months. If the problem is a typo insertion attack then it can be remediated very quickly by registering the domain as secure. The malicious typo registration in false name remains easier to mount, harder to remedy and cannot be addressed using cryptography. I do not exhaustively list every sub class of an attack that has been considered. If as is the case here a more powerful attack can be shown to dominate all the attacks covered by a control the control is broken. As for misrepresentation, if the problems are stated in public then there can be no confusion as to who said what and if there is confusion over what they meant they can address it. The time to examine protocols is in last call. The talk of advice etc would not raise concern if it was the case that the issues were being raised by an independent AD of their own volition and put to an independent expert. When the AD is the chair of the working group and most of the experts consulted are a subset of the working group chosen by the chair/AD it becomes something else. It is quite clear that if the DS change and the OPTIN change are separated and OPTIN sufficiently delayed that the case could then be made that the group should reconsider the OPTIN consensus on the grounds that the justification had been contingent on the DS flag day. And before Randy 'W' Bush leaps to deny it I have already heard the suggestion from two independent sources neither of whom own black helicopters. Phill > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Sunday, June 09, 2002 10:19 PM > To: Phillip Hallam-Baker > Cc: namedroppers@ops.ietf.org > Subject: Re: What are the opt-in issues > > > "Phillip Hallam-Baker" writes: > > > Randy is incorrect to claim that new technical issues have emerged. > > > > The Typo attack is simply a sub class of an attack that was > identified in > > the original security analysis. Any party can apply for an > unregistered > > domain name in a TLD at any time, the authentication > criteria applied by > > registrars do not include verification that the applicant > of the domain name > > has provided a bona fide address on which process can be served. > > Phill, you are misrepresting the attack. Please don't take my words > and misrepresent them just to try to make your point. Sure, someone > can register the domain under falsified information, but in that > circumstance, if the domain is being used to defraud, the registrar > has the power to un-register the domain. Under the typo attack > against opt-in, an attacker could poison caches and work around the > registrar's power to un-register a domain. Can you please point out > where cache poisoning was mentioned in the opt-in discussions? > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-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 Jun 10 05:59:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26885 for ; Mon, 10 Jun 2002 05:59:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HLpv-000Nqe-00 for namedroppers-data@psg.com; Mon, 10 Jun 2002 02:51:43 -0700 Received: from dhcp3202.nanog25.merit.net ([192.35.167.202] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17HLps-000NqT-00 for namedroppers@ops.ietf.org; Mon, 10 Jun 2002 02:51:40 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17HLpr-0000wA-00 for namedroppers@ops.ietf.org; Mon, 10 Jun 2002 02:51:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200206100748.g5A7moI51941@open.nlnetlabs.nl> In-Reply-To: ""Phillip Hallam-Baker"'s message as of Jun 10, 4:06" From: ted@tednet.nl (Ted Lindgreen) Date: Mon, 10 Jun 2002 09:48:50 +0200 To: namedroppers@ops.ietf.org Subject: Re: What are the opt-in issues X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] [Quoting "Phillip Hallam-Baker", on Jun 10, 4:06, in "Re: What are the opt ..."] > The Typo attack is simply a sub class of an attack that was identified in > the original security analysis. Any party can apply for an unregistered > domain name in a TLD at any time, the authentication criteria applied by > registrars do not include verification that the applicant of the domain name > has provided a bona fide address on which process can be served. Phillip, You are confusing a Registry issue (a security problem due to lack of proper administration) with a security hole inside the protocol itself. The fact that the former exists at some Registries does not mean we don't need to care about the latter. -- ted -- to unsubscribe send a message to namedroppers-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 Jun 10 09:08:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02316 for ; Mon, 10 Jun 2002 09:08:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HOiS-0001Nz-00 for namedroppers-data@psg.com; Mon, 10 Jun 2002 05:56:12 -0700 Received: from dhcp3202.nanog25.merit.net ([192.35.167.202] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17HOiQ-0001No-00 for namedroppers@ops.ietf.org; Mon, 10 Jun 2002 05:56:10 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17HOiO-0001Km-00; Mon, 10 Jun 2002 05:56:08 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Olafur Gudmundsson Cc: namedroppers Subject: 3226 Message-Id: Date: Mon, 10 Jun 2002 05:56:08 -0700 X-Spam-Status: No, hits=1.9 required=5.0 tests=SUBJ_ALL_CAPS version=2.20 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit with a6 about to die, perhaps this needs to be updated? randy -- to unsubscribe send a message to namedroppers-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 Jun 10 09:36:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03615 for ; Mon, 10 Jun 2002 09:36:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HPDb-00028v-00 for namedroppers-data@psg.com; Mon, 10 Jun 2002 06:28:23 -0700 Received: from dhcp3202.nanog25.merit.net ([192.35.167.202] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17HPDY-00028j-00 for namedroppers@ops.ietf.org; Mon, 10 Jun 2002 06:28:20 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17HPDY-0001OQ-00 for namedroppers@ops.ietf.org; Mon, 10 Jun 2002 06:28:20 -0700 Message-ID: <000001c21082$379c7ab0$8000a8c0@DILBERT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: "Phill" To: Subject: Re: What are the opt-in issues Date: Mon, 10 Jun 2002 09:24:57 -0400 X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] >You are confusing a Registry issue (a security problem due to lack >of proper administration) with a security hole inside the protocol >itself. The fact that the former exists at some Registries does not >mean we don't need to care about the latter. No I am performing a security analysis of a system as opposed to a single component. Analysis of the system is almost always the preferred choice for an application protocol. I am fully aware of the fact that a security analysis that is performed in one context may fail in another. For example 4 digit account PINs works for ATM cards but has major failure modes when used on the Internet. Knowing the appropriate security analysis to apply is my job. That is why I frequently advise against blindly reusing protocols in applications that are beyond the context of the original security context. The decision to fully sign or OPTIN sign a zone is acknowledged to have security implications. You should not use OPTIN unless you have determined that either an insertion attack is not an issue (as is the case for the registries) or the cost of fully signing the domain is greater than the probability of an insertion attack multiplied by the cost of the damage caused. The term 'security hole' is not appropriate in this instance. A security hole is by definition an error in the design. A limitation of the applicability of a protocol is not a security hole if that limitation is clearly stated. Phill -- to unsubscribe send a message to namedroppers-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 Jun 10 10:06:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04824 for ; Mon, 10 Jun 2002 10:06:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HPeF-0002pp-00 for namedroppers-data@psg.com; Mon, 10 Jun 2002 06:55:55 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 17HPeB-0002pT-00; Mon, 10 Jun 2002 06:55:51 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28935; Mon, 10 Jun 2002 07:55:44 -0600 (MDT) Received: from lillen (vpn-129-156-96-43.EMEA.Sun.COM [129.156.96.43]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5ADtYK06097; Mon, 10 Jun 2002 15:55:38 +0200 (MEST) Date: Mon, 10 Jun 2002 15:54:22 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: IESG feedback on dnsext-ad-is-secure To: randy@psg.com, ogud@ogud.com Cc: namedroppers@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Folks, The IESG reviewed draft-ietf-dnsext-ad-is-secure-05.txt and has some significant concerns. While the document just tries to make the definition of the AD bit more clear and perhaps more useful than it is today, the document raises the issue of having stub resolvers place blind trust on a (recursive) resolver. To the extent that the document implicitly or explicitly encourages this, it isn't clear that the document is a good idea. The document doesn't explain the expected usage of the AD bit by the receiver. This makes it hard to evaluate the benefits. Is the intent that the application be notified? If so, what are some examples of what the application will do based on the value of the bit? The applicability of the document isn't clear. If the document is going to move forward it would need a "safe" applicability statement. For example, while the blind trust in a resolver might make sense e.g. in an enterprise network, it doesn't seem to make sense in the home/ISP setting where the ISP would run the resolver. The document is not in synch with the dns-threats I-D, which says: It is difficult to escape the conclusion that a properly paranoid resolver must always perform its own signature checking, and that this rule even applies to stub resolvers. That brings us to the motivation for delegating signature verification to some other entity. Is there an argument that stub resolver signature checking is too expensive? Are there numbers to back this up? Or is there a problem that one can't easily get stub resolver to verify all the signatures while using a recursive resolver to do the recursion? Thus, apart from the fact that the RFC 2535 definition isn't useful as it stands, what problem are we trying to solve by making the definition more useful? Smaller issues -------------- The document doesn't say what "AD" stands for. It makes sense making this clear early on (e.g. in the abstract and/or introduction). In section 2 it isn't clear what is the old vs. new behavior. For example, I think section 2.0 is unchanged behavior, but it could be new behavior. Is section 2.2 unmodified or new behavior? The abstract says "current behavior" which is a bit odd since the document redefines the current behavior. Assuming the AD bit semantics are defined in RFC 2535, it would make sense to instead say "the definition of the Authentic Data (AD) bit in RFC 2535 ...". The final paragraph of the Security Considerations is written in a way that obscures meaning, in contrast to the related final paragraph of Section 3. > Resolvers (full or stub) that blindly trust the AD bit without > knowing the security policy of the server generating the answer can > not be considered security aware. It isn't clear what "security aware" means here and that using that undefined term adds any clarity. I think the point is that the blind trust in the AD bit MUST only be used in an environment in which configuration somehow ensures that the security policy of the server is appropriate. Thus it doesn't make sense to use this, even is a secure channel with TSIG or SIG(0) is used, when the client might not trust the recursive resolver, or it doesn't trust how it discovered the IP address of the recursive resolver. (e.g. using DHCP). Please split the references into normative and non-normative per the rfc-editor's instructions. Nits ---- > application running on a host that has trust relationship with the s/has/has a/ The presence of the CD (checking disabled) bit in a query does not affect the setting of the AD bit in the response. If the CD bit is set, the server will not perform checking, but SHOULD still set the AD bit if the data has already been checked or complies with local policy. The AD bit MUST only be set if DNSSEC records have been requested [RFC3225] and relevant SIG records are returned. wouldn't hurt to better define "checked". I assume this means crypto sigs verified, or server is authoritative. This document redefines a bit in the DNS header. If a resolver trusts the value of the AD bit, it must be sure that the server is using the updated definition, which is any server supporting the OK bit. reference to OK bit? --- -- to unsubscribe send a message to namedroppers-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 Jun 10 13:45:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15882 for ; Mon, 10 Jun 2002 13:45:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HSya-0007cW-00 for namedroppers-data@psg.com; Mon, 10 Jun 2002 10:29:08 -0700 Received: from dhcp3202.nanog25.merit.net ([192.35.167.202] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17HSyW-0007cH-00 for namedroppers@ops.ietf.org; Mon, 10 Jun 2002 10:29:04 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.04) id 17HSyV-0001gE-00 for namedroppers@ops.ietf.org; Mon, 10 Jun 2002 10:29:03 -0700 In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1023722728.590.275.camel@error-messages.mit.edu> Mime-Version: 1.0 Subject: Re: IESG feedback on dnsext-ad-is-secure From: Greg Hudson To: Erik Nordmark Cc: namedroppers@ops.ietf.org Date: 10 Jun 2002 11:25:28 -0400 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Speaking as the author of a little-used stub resolver: On Mon, 2002-06-10 at 09:54, Erik Nordmark wrote: > That brings us to the motivation for delegating signature verification > to some other entity. Is there an argument that stub resolver signature > checking is too expensive? Are there numbers to back this up? > Or is there a problem that one can't easily get stub resolver to verify > all the signatures while using a recursive resolver to do the recursion? As I understand it, verifying signatures often requires going and fetching signature records which were not included in the original response, possibly due to packet size issues. One of the whole points of the stub/recursive resolver separation is to allow applications to perform DNS resolution using a single request/response pair, and let some separate big ugly program (as opposed to a library linked against the applications) handle the consolidation. We have a limited number of options here: 1. AD-is-secure 2. Mandate that recursive resolvers include all necessary signatures in their replies to the stub resolver. 3. Destroy, at least partially, the notion of a stub resolver, forcing applications to link in complicated multi-request resolvers in order to know the security status of domains. Option 2 might be better, but it would probably require a TCP fallback for domains with more than about (guessing here) six zone delegations. (Incidentally, what's with the blind request for quantitative data? An argument may or may not require quantitative data to be sound; it is not necessarily any more sound if it has that need and the need has been fulfilled.) > The document doesn't explain the expected usage of the AD bit > by the receiver. This makes it hard to evaluate the benefits. > Is the intent that the application be notified? If so, what are some > examples of what the application will do based on the value of the bit? Most of the time, you probably don't care; it is enough to know that if the domain was signed, then an attacker would have had a difficult time trying to spoof it. But sometimes an application might like to know. Examples: * A web browser might want to communicate to a user whether the page they went to had a signed domain name, just as it currently communicates whether the web page used SSL. * If we put application public keys into DNS as has been (controversially) suggested in the past, then an unsigned key would need to be ignored or red-flagged to the user. * If the Mail-Transmitter RR goes forward, then an MTA might want to note whether MT RR it looked up was signed; people might (at least some day) want to score down mail which wasn't authorized by a signed MT RR. Since the AD-is-secure draft just defines infrastructure, I wouldn't really expect it to document the possible uses of that infrastructure. > While the document just tries to make > the definition of the AD bit more clear and perhaps more useful than it > is today, the document raises the issue of having stub resolvers place > blind trust on a (recursive) resolver. To the extent that the document > implicitly or explicitly encourages this, it isn't clear that > the document is a good idea. There is one common case where that trust is perfectly justified: the recursive resolver runs on the same machine as the application. There are certainly common cases where that trust would not be justified (either the recursive resolver is run by horrible people, or the communication path to it is easily compromised). If I were writing a stub resolver using AD-is-secure to communicate the signedness of a domain, I would probably only report that the domain is signed if: * The AD bit is set on the reply, and * The reply came from 127.0.0.1, or * The server is explicitly marked as trusted in resolv.conf, and * TSIG was used to secure the communication channel, or * The TSIG requirement was explicitly overridden in resolv.conf. (Because the administer chooses to rely on firewall security, for instance.) That certainly leaves the system open to misconfiguration, but it would have to be quite explicit. > The document is not in synch with the dns-threats I-D, which > says: > It is difficult to escape the conclusion that a properly paranoid > resolver must always perform its own signature checking, and that > this rule even applies to stub resolvers. This is kind of an ambiguous statement (what's a "proper irrational fear that everyone is out to get you"?), but as you're interpreting it, I don't really agree with it. If AD-is-secure goes forward, then perhaps it should be weakened to merely say that performing your own signature checking is the best way to prevent spoofing and to determine the signedness of a record. -- to unsubscribe send a message to namedroppers-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 Jun 10 15:22:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20681 for ; Mon, 10 Jun 2002 15:22:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HUZK-0009mb-00 for namedroppers-data@psg.com; Mon, 10 Jun 2002 12:11:10 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17HUZH-0009mO-00; Mon, 10 Jun 2002 12:11:07 -0700 Received: from engill.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g5AJ9JV40146; Mon, 10 Jun 2002 15:09:20 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020610103810.02f738b0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 10 Jun 2002 15:08:39 -0400 To: Randy Bush , Olafur Gudmundsson From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: 3226 Cc: namedroppers In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 08:56 AM 6/10/2002, Randy Bush wrote: >with a6 about to die, perhaps this needs to be updated? > >randy A6 is not dying, it is being placed in experimental status for experimentation purposes if experience shows that it is a harmless/good idea, it may come back to standards track. Yes RFC3226 needs updating, there are two options minimal change: reword the document to entity that supports AAAA SHOULD/MUST support ENDS0 Or more drastic (but rational) change: all DNS servers MUST support EDNS0 all DNS resolvers SHOULD support ENDS0 comments Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 10 16:59:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25240 for ; Mon, 10 Jun 2002 16:59:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HW5M-000BwM-00 for namedroppers-data@psg.com; Mon, 10 Jun 2002 13:48:20 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17HW5I-000Bvm-00 for namedroppers@ops.ietf.org; Mon, 10 Jun 2002 13:48:17 -0700 Received: by as.vix.com (Postfix, from userid 716) id 74D2F28B6C; Mon, 10 Jun 2002 13:48:15 -0700 (PDT) To: namedroppers@ops.ietf.org Subject: Re: 3226 References: <5.1.1.6.2.20020610103810.02f738b0@localhost> From: Paul Vixie Date: 10 Jun 2002 13:48:15 -0700 In-Reply-To: <5.1.1.6.2.20020610103810.02f738b0@localhost> Message-ID: Lines: 9 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA25240 lafur Gumundsson writes: > > ... > this is unrealistic. please believe as though your chair hat is sewn on. -- Paul Vixie -- to unsubscribe send a message to namedroppers-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 Jun 10 20:56:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00313 for ; Mon, 10 Jun 2002 20:56:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HZYy-000IC3-00 for namedroppers-data@psg.com; Mon, 10 Jun 2002 17:31:08 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17HZYs-000IBs-00 for namedroppers@ops.ietf.org; Mon, 10 Jun 2002 17:31:02 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 1445F28B6C for ; Mon, 10 Jun 2002 17:31:02 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Matt Crawford: Re: Opt-in Decision day: Postponed X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Mon, 10 Jun 2002 17:31:02 -0700 Message-Id: <20020611003102.1445F28B6C@as.vix.com> X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk FYI ------- Forwarded Message Date: Mon, 10 Jun 2002 17:29:35 -0500 From: Matt Crawford Subject: Re: Opt-in Decision day: Postponed In-reply-to: "08 Jun 2002 11:40:20 EDT." <200206081540.LAA11783@sentry.gw.tislabs.com> To: markk@netsol.com, paul@vix.com Cc: poised@lists.tislabs.com, iesg@ietf.org, sra@hactrn.net, harald@alvestrand.no, mankin@isi.edu Message-id: <200206102229.g5AMTZC28477@gungnir.fnal.gov> The reason I'm specifically concerned is that there was wg consensus on opt-in with delegations only restriction at ietf 53. This dns directoriate group seems to be running against the consensus of the wg by "not liking" opt-in. Additionally, this group has not publically produced anything that defines their dislike that the authors can defend against. To me, the issue of having an undocumented decision point by a small group of people in a "open" standards organization smells bad. If the previous forms are followed, the next thing you should expect to see is a very large meeting room packed with persons who have never before been seen in a working group meeting or on the mailing list. The chairs will pose some ill-formed questions and then announce that they will write up a "consensus" they gleaned from the resulting noises. After a prolonged interval, such a document will appear and will repudiates any consensus which may have been supposed to exist prior to the packed meeting. Matt Crawford No longer seen in the wg meetings and on the mailing list. (Permission granted to forward to namedroppers. The chair/moderator/AD won't accept it from my address.) ------- End of Forwarded Message -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 11 03:55:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15634 for ; Tue, 11 Jun 2002 03:55:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HgAt-0005Wc-00 for namedroppers-data@psg.com; Tue, 11 Jun 2002 00:34:43 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 17HgAp-0005WR-00 for namedroppers@ops.ietf.org; Tue, 11 Jun 2002 00:34:39 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA07615; Tue, 11 Jun 2002 01:34:37 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5B7YaK12258; Tue, 11 Jun 2002 09:34:36 +0200 (MEST) Date: Tue, 11 Jun 2002 09:27:52 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IESG feedback on dnsext-ad-is-secure To: Greg Hudson Cc: Erik Nordmark , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <1023722728.590.275.camel@error-messages.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > We have a limited number of options here: > > 1. AD-is-secure > > 2. Mandate that recursive resolvers include all necessary signatures > in their replies to the stub resolver. > > 3. Destroy, at least partially, the notion of a stub resolver, forcing > applications to link in complicated multi-request resolvers in order to > know the security status of domains. I don't think those are all the options. As far as I can tell stub resolvers can place blind trust on the recursive resolver (including the recursive resolver's decisions to what unsigned information it accepts through) without requiring any single-bit indication from the recursive resolver. So putting the question whether "stub resolvers place blind trust on the recursive resolver" is a good thing or not, there is the question what the AD-bit would be useful for in the client - would applications somehow use it? Do applications today have an API by which they get "security status" from a local, full DNSsec resolver? How do applications use that information? Does such local information consist of just one bit? Or the ability to discover more information about the "security status" of the response? > Option 2 might be better, but it would probably require a TCP fallback > for domains with more than about (guessing here) six zone delegations. This is part of what folks want to understand better since presumbly there is utility in using recursive resolvers (such as less packets sent by the client etc) in the cases when blind trust in a recursive resolver isn't appropriate. > Most of the time, you probably don't care; it is enough to know that if > the domain was signed, then an attacker would have had a difficult time > trying to spoof it. But sometimes an application might like to know. > Examples: > > * A web browser might want to communicate to a user whether the page > they went to had a signed domain name, just as it currently communicates > whether the web page used SSL. Any indication that there is interest in adding such things to such applications? Or is this speculation? > * If we put application public keys into DNS as has been > (controversially) suggested in the past, then an unsigned key would need > to be ignored or red-flagged to the user. I hope that isn't the strongest motivation for this draft. > * If the Mail-Transmitter RR goes forward, then an MTA might want to > note whether MT RR it looked up was signed; people might (at least some > day) want to score down mail which wasn't authorized by a signed MT RR. > > Since the AD-is-secure draft just defines infrastructure, I wouldn't > really expect it to document the possible uses of that infrastructure. But it's very hard to evaluate something like this without any understanding what so ever for what it will be used... And I think folks are concerned because this specification might have the side-effect of silently endorsing blind trust in recursive resolvers even where such trust isn't appropriate. (Should a home user with a recursive resolver run by their service provider place blind trust in it? Perhaps it is only appropriate inside coorporations with an IT department which sets and enforces policies including security policies.) > There is one common case where that trust is perfectly justified: the > recursive resolver runs on the same machine as the application. But in that case, isn't this an API question more than a protocol question? I could speculate that in this case a richer interface might make sense (e.g. not only indicate that it was signed but that it used the manually configured key for the example.com zone since the whole path from the root isn't signed; indicate whether the zone uses opt-in or not; indicate that the signature lifetime has expired but it is deemed ok in spite of this). Erik -- to unsubscribe send a message to namedroppers-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 Jun 11 05:38:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16756 for ; Tue, 11 Jun 2002 05:38:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Hhox-0007Tn-00 for namedroppers-data@psg.com; Tue, 11 Jun 2002 02:20:11 -0700 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #1) id 17Hhos-0007TS-00 for namedroppers@ops.ietf.org; Tue, 11 Jun 2002 02:20:07 -0700 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 0854B52AA; Tue, 11 Jun 2002 11:20:05 +0200 (MEST) Received: from crt.se (fonbella.crt.se [172.16.1.169]) by mail.crt.se (Postfix) with ESMTP id 41D391DE9; Tue, 11 Jun 2002 11:20:04 +0200 (MEST) Date: Tue, 11 Jun 2002 11:20:04 +0200 (MEST) From: Jakob Schlyter To: Erik Nordmark Cc: Greg Hudson , Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 11 Jun 2002, Erik Nordmark wrote: > Do applications today have an API by which they get "security status" > from a local, full DNSsec resolver? yes, using getrrsetbyname(3): "The RRSET_VALIDATED flag in rri_flags is set if the AD (autenticated data) bit in the DNS answer is set. This flag should not be trusted unless the transport between the nameserver and the resolver is secure (e.g. IPsec, trusted network, loopback communication)." > How do applications use that information? the applications we have written use this information to put additional trust into certificates validated by a local resolver. > Does such local information consist of just one bit? Or the ability to > discover more information about the "security status" of the response? it is currently one bit only since it is only based on ad. more information would be useful, but one bit is a huge step compared to nothing. jakob -- to unsubscribe send a message to namedroppers-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 Jun 11 09:47:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24072 for ; Tue, 11 Jun 2002 09:47:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HlkO-000CoX-00 for namedroppers-data@psg.com; Tue, 11 Jun 2002 06:31:44 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17HlkL-000CoM-00 for namedroppers@ops.ietf.org; Tue, 11 Jun 2002 06:31:41 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 4FB1328B6C; Tue, 11 Jun 2002 06:31:40 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: Erik Nordmark Cc: Greg Hudson , namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: Message from Erik Nordmark of "Tue, 11 Jun 2002 09:27:52 +0200." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 11 Jun 2002 06:31:40 -0700 Message-Id: <20020611133140.4FB1328B6C@as.vix.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk stub resolvers already have blind trust in their recursive servers. (dnssec signature verification at the stub level makes no sense.) this is what tsig is for. let's look for a new problem. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 11 11:31:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29178 for ; Tue, 11 Jun 2002 11:31:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HnV4-000FzQ-00 for namedroppers-data@psg.com; Tue, 11 Jun 2002 08:24:02 -0700 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 17HnV2-000FzF-00 for namedroppers@ops.ietf.org; Tue, 11 Jun 2002 08:24:00 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05614; Tue, 11 Jun 2002 08:23:58 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5BFNvK27720; Tue, 11 Jun 2002 17:23:57 +0200 (MEST) Date: Tue, 11 Jun 2002 17:22:44 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Please state the 'attacks' in public To: Phillip Hallam-Baker Cc: namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <000001c20fdb$a1a206c0$0300a8c0@ne.mediaone.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > If the AD needs advice on the security of OPTIN it would be more productive > to address those concerns to one of the people who has done an extensive > security analysis already. Where are the results of this analysis written down? Thanks, Erik -- to unsubscribe send a message to namedroppers-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 Jun 11 11:33:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29218 for ; Tue, 11 Jun 2002 11:33:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HnT8-000FwJ-00 for namedroppers-data@psg.com; Tue, 11 Jun 2002 08:22:02 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 17HnT5-000Fw7-00 for namedroppers@ops.ietf.org; Tue, 11 Jun 2002 08:21:59 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15764; Tue, 11 Jun 2002 09:21:57 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5BFLuK27458; Tue, 11 Jun 2002 17:21:56 +0200 (MEST) Date: Tue, 11 Jun 2002 17:20:43 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: What are the opt-in issues To: Paul Vixie Cc: namedroppers In-Reply-To: "Your message with ID" <20020609201818.BC3C128B6C@as.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > the process as i understood it was that if the WG reached consensus the > chair's job was to fwd the relevant drafts to the AD's. this appears to > have happened. I'll respond to this thread in more detail once I've caught up with it. But this particular point warrants a short response. I have not seen the opt-in documents be forwarded to me as an AD. They are not on http://www.ietf.org/IESG/status.html I also think that the current draft is about unrestricted opt-in and the rough consensus discussion in Minneapolis was about opt-in restricted to delegation points. Thus I don't think there is or ever was a draft that *could* have been forwarded to the AD. I would expect, assuming for a second that we continue down the path of opt-in restricted to delegations, that the document would actually specify how servers check this (and whether the resolver verification is any different due to the restriction). Erik -- to unsubscribe send a message to namedroppers-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 Jun 11 11:47:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29774 for ; Tue, 11 Jun 2002 11:47:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Hngy-000GME-00 for namedroppers-data@psg.com; Tue, 11 Jun 2002 08:36:20 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 17Hngv-000GM2-00 for namedroppers@ops.ietf.org; Tue, 11 Jun 2002 08:36:17 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02696; Tue, 11 Jun 2002 09:37:53 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5BFaDK29187; Tue, 11 Jun 2002 17:36:14 +0200 (MEST) Date: Tue, 11 Jun 2002 17:35:01 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: What are the opt-in issues To: Phillip Hallam-Baker Cc: "'Derek Atkins'" , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <000101c21030$c7e76320$0300a8c0@ne.mediaone.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > When > the AD is the chair of the working group and most of the experts consulted > are a subset of the working group chosen by the chair/AD it becomes > something else. Phillip, Last time I checked I was the AD for DNSEXT and I was not one of the co-chairs. Randy is the AD for DNSOP. Erik -- to unsubscribe send a message to namedroppers-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 Jun 11 11:53:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00207 for ; Tue, 11 Jun 2002 11:53:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Hnph-000Gdn-00 for namedroppers-data@psg.com; Tue, 11 Jun 2002 08:45:21 -0700 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 17Hnpe-000GdW-00 for namedroppers@ops.ietf.org; Tue, 11 Jun 2002 08:45:18 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05439; Tue, 11 Jun 2002 08:45:16 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5BFjFK02674; Tue, 11 Jun 2002 17:45:15 +0200 (MEST) Date: Tue, 11 Jun 2002 17:44:03 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IESG feedback on dnsext-ad-is-secure To: Paul Vixie Cc: Erik Nordmark , Greg Hudson , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <20020611133140.4FB1328B6C@as.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > stub resolvers already have blind trust in their recursive servers. > (dnssec signature verification at the stub level makes no sense.) I don't understand why it would never make sense. Suppose I there is a CPU powerful client with a relatively high round-trip time to everywhere (many wireless things have high rtt due to coding necessary to deal with fast fading radio issues). Having that client do a single DNS query to a recursive resolver makes a lot of sense. But coupling this by design with blind trust in the resolver seems odd to me; having the option for the client to receive all information necessary to verify the response (as part of the response from the recursive resolver - yes, there are likely to be packet size issues - EDNS to the rescue?) seems to make sense when blind trust isn't appropriate. Erik -- to unsubscribe send a message to namedroppers-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 Jun 11 11:57:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00296 for ; Tue, 11 Jun 2002 11:57:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Hnts-000Gnt-00 for namedroppers-data@psg.com; Tue, 11 Jun 2002 08:49:40 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17Hntg-000Gmu-00 for namedroppers@ops.ietf.org; Tue, 11 Jun 2002 08:49:28 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id F0C4528B6C; Tue, 11 Jun 2002 08:49:27 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: Erik Nordmark Cc: Greg Hudson , namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: Message from Erik Nordmark of "Tue, 11 Jun 2002 17:44:03 +0200." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 11 Jun 2002 08:49:27 -0700 Message-Id: <20020611154927.F0C4528B6C@as.vix.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > stub resolvers already have blind trust in their recursive servers. > > (dnssec signature verification at the stub level makes no sense.) > > I don't understand why it would never make sense. because it will take a huge amount of bandwidth on every query. as in, several kilobytes of traffic to fully verify an A RR before your browser will follow a link. "stub" means no cache. -- to unsubscribe send a message to namedroppers-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 Jun 11 12:28:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01662 for ; Tue, 11 Jun 2002 12:27:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HoMP-000Hmj-00 for namedroppers-data@psg.com; Tue, 11 Jun 2002 09:19:09 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17HoME-000HmI-00 for namedroppers@ops.ietf.org; Tue, 11 Jun 2002 09:18:58 -0700 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 8B8EA1BFA for ; Tue, 11 Jun 2002 12:18:57 -0400 (EDT) Date: Tue, 11 Jun 2002 12:18:57 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: <20020611154927.F0C4528B6C@as.vix.com> References: <20020611154927.F0C4528B6C@as.vix.com> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020611161857.8B8EA1BFA@thrintun.hactrn.net> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 11 Jun 2002 08:49:27 -0700, Paul Vixie wrote: > > "stub" means no cache. A resolver which only issues queries with RD=1 may still have a cache. I don't care whether one calls such a thing a "stub resolver" 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 Tue Jun 11 14:50:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08095 for ; Tue, 11 Jun 2002 14:50:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HqV3-000Ll7-00 for namedroppers-data@psg.com; Tue, 11 Jun 2002 11:36:13 -0700 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 17HqV0-000Lkv-00 for namedroppers@ops.ietf.org; Tue, 11 Jun 2002 11:36:10 -0700 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id g5BIVSh6018838; Tue, 11 Jun 2002 11:31:28 -0700 (PDT) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 11:37:43 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869B03@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Erik Nordmark'" , Paul Vixie Cc: namedroppers Subject: RE: What are the opt-in issues Date: Tue, 11 Jun 2002 11:37:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Let us rewind, at this point we have been told that this issue has been discussed in the DNS Directorate and at the IESG retreat. The one place that discussion does not appear to be taking place is in the working group where it belongs. The original question was whether the Working Group Chairs had come to a decision concerning the consensus within the group regarding OPTIN. In this regard the WG chairs have only three options: WG consensus is for full OPTIN WG consensus is for OPTIN restricted to delegation zones WG consensus is for no OPTIN I have re-read the RFC section that concerns directorates. As Erik points out directorates advise the ADs, at no point is there any statement that says that a WG chair can consult a directorate to determine the consensus of a WG. If the WG consensus is in favor of full OPTIN then the existing documents can be forwarded to the AD. Otherwise we simply modify the draft to state the restriction and if there is consensus that this is done properly (appropriately enforced etc.) the document goes forward. Only after the document goes to the AD is it appropriate for the AD to consult the DNS directorate. The technical merits of OPTIN do not enter into the issue at this point. The question being asked is what the working group consensus is, not the consensus of the directorate. There may of course be value in the DNS directorate anticipating the OPTIN document at a moment when people happen to be in one physical location. However such a discussion should not prevent the regular process of the working group being followed. What we need is the co-Chair's statement on consensus, or if that is not going to be forthcomming should we simply take the statement by the AD as indicative of the consensus and proceed on that basis (i.e. make the mods to the draft etc) ? Phill > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: Tuesday, June 11, 2002 11:21 AM > To: Paul Vixie > Cc: namedroppers > Subject: Re: What are the opt-in issues > > > > the process as i understood it was that if the WG reached > consensus the > > chair's job was to fwd the relevant drafts to the AD's. > this appears to > > have happened. > > I'll respond to this thread in more detail once I've caught > up with it. > But this particular point warrants a short response. > > I have not seen the opt-in documents be forwarded to me as an AD. > They are not on http://www.ietf.org/IESG/status.html > > I also think that the current draft is about unrestricted opt-in > and the rough consensus discussion in Minneapolis was about opt-in > restricted to delegation points. Thus I don't think there is > or ever was > a draft that *could* have been forwarded to the AD. > > I would expect, assuming for a second that we continue down > the path of > opt-in restricted to delegations, that the document would > actually specify > how servers check this (and whether the resolver verification is any > different due to the restriction). > > Erik > > > > -- > to 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 Jun 11 16:28:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11487 for ; Tue, 11 Jun 2002 16:28:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Hs72-000Om0-00 for namedroppers-data@psg.com; Tue, 11 Jun 2002 13:19:32 -0700 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 17Hs6y-000Olp-00 for namedroppers@ops.ietf.org; Tue, 11 Jun 2002 13:19:28 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02440; Tue, 11 Jun 2002 13:19:22 -0700 (PDT) Received: from lillen ([192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5BKJCK23205; Tue, 11 Jun 2002 22:19:13 +0200 (MEST) Date: Tue, 11 Jun 2002 22:17:57 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: What are the opt-in issues To: "Hallam-Baker, Phillip" Cc: "'Erik Nordmark'" , Paul Vixie , namedroppers In-Reply-To: "Your message with ID" <2F3EC696EAEED311BB2D009027C3F4F405869B03@vhqpostal.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Only after the document goes to the AD is it appropriate for the AD to > consult the DNS directorate. I wouldn't be surprised if one could fine extracts of various process related RFCs that could be construed to support your statement. Have you already done so? But that doesn't mean it makes any sense. If the ADs are limited to input only when a WG is chartered/re-chartered and when the WG asks for a document to be published as an RFC then we are much more likely to waste time then when there can be more of a continious engagement. An example of wasted time would be when the AD or the whole IESG sends back a document telling the WG to basically start over e.g. because they made the wrong assumptions about security. So I think it is appropriate to apply common sense and not overly rigid application of rules, especially if we want to provide timely standards. Erik -- to unsubscribe send a message to namedroppers-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 Jun 11 18:18:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14906 for ; Tue, 11 Jun 2002 18:18:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Htq2-0002gs-00 for namedroppers-data@psg.com; Tue, 11 Jun 2002 15:10:06 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17Htpt-0002f7-00 for namedroppers@ops.ietf.org; Tue, 11 Jun 2002 15:09:57 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id PAA12830; Tue, 11 Jun 2002 15:13:38 -0700 Message-Id: <5.1.1.2.2.20020611150339.02587ec0@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Tue, 11 Jun 2002 15:08:04 -0700 To: Erik Nordmark From: Dave Crocker Subject: RE: What are the opt-in issues Cc: "Hallam-Baker, Phillip" , "'Erik Nordmark'" , Paul Vixie , namedroppers In-Reply-To: References: <"Your message with ID" <2F3EC696EAEED311BB2D009027C3F4F405869B03@vhqpostal.verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.8 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,OPT_IN,NO_MX_FOR_FROM version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:17 PM 6/11/2002 +0200, Erik Nordmark wrote: > > Only after the document goes to the AD is it appropriate for the AD to > > consult the DNS directorate. > >If the ADs are limited to input only when a WG is chartered/re-chartered >and when the WG asks for a document to be published as an RFC then In fact, the idea that anyone is limited from talking with anyone else is just plain silly. Certainly there is no precedent for such limitations in the IETF. Since the IETF is about collaboration, there should be no place for prohibiting discussions, private or public. But discussion is different from decision making. So, the only serious questions that seems to be floating around is a) whether a chair has asserted working consensus inaccurately, or b) whether an AD has reversed a working group rough consensus decision without pursuing a reasonable collaboration with that working group. I believe that the question of a) has been raised earlier today and awaits a response. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 -- to unsubscribe send a message to namedroppers-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 Jun 11 23:29:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22031 for ; Tue, 11 Jun 2002 23:29:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HyZf-000DSW-00 for namedroppers-data@psg.com; Tue, 11 Jun 2002 20:13:31 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 17HyZZ-000DSI-00 for namedroppers@ops.ietf.org; Tue, 11 Jun 2002 20:13:25 -0700 From: Masataka Ohta Message-Id: <200206120300.LAA24924@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA24924; Wed, 12 Jun 2002 11:59:57 +0859 Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: from Erik Nordmark at "Jun 11, 2002 05:44:03 pm" To: Erik Nordmark Date: Wed, 12 Jun 2002 11:59:56 +0859 () CC: Paul Vixie , Greg Hudson , namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Erik; > > stub resolvers already have blind trust in their recursive servers. > > (dnssec signature verification at the stub level makes no sense.) > > I don't understand why it would never make sense. > > Suppose I there is a CPU powerful client with a relatively high round-trip > time to everywhere (many wireless things have high rtt due to coding > necessary to deal with fast fading radio issues). > > Having that client do a single DNS query to a recursive resolver > makes a lot of sense. First, that is an issue addressed by additonal RRs. Second, non-stub resolver may ask recursive service. Third, rtt of most, if not all, wireless things, including those used for highly interactive service of telephony and plain WLAN, is low. 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 Tue Jun 11 23:49:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22395 for ; Tue, 11 Jun 2002 23:49:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17HyzU-000EV0-00 for namedroppers-data@psg.com; Tue, 11 Jun 2002 20:40:12 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17HyzQ-000ESb-00 for namedroppers@ops.ietf.org; Tue, 11 Jun 2002 20:40:09 -0700 Received: from drugs.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.12.3/8.12.3) with ESMTP id g5C3dvm0010053 for ; Wed, 12 Jun 2002 13:39:57 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200206120339.g5C3dvm0010053@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: wildcards and CNAMEs Date: Wed, 12 Jun 2002 13:39:57 +1000 X-Spam-Status: No, hits=0.6 required=5.0 tests=NO_REAL_NAME version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I suspect no one though people would want to use a CNAME wildcard record when RFC 1034 was written. The problem is that CNAMEs are not illegal with wildcard records and depending upon how you interperet RFC 1034 Section 4.3.2 Step 3 and the query type you can get wildcard CNAMES records being honored or ignored. If you make a query with a type CNAME quite clearly they are supposed to match. If you make a query with type != CNAME there is ambiguity. If you don't match you then get the situation where a cache will return different results depending upon whether there was a cached CNAME record or not. Currently different implementation match/don't match the wildcard CNAME record when the query type != CNAME. Mark -- Mark Andrews, Internet Software Consortium 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 Jun 12 01:28:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24845 for ; Wed, 12 Jun 2002 01:28:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17I0U1-000Hvf-00 for namedroppers-data@psg.com; Tue, 11 Jun 2002 22:15:49 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17I0Ty-000HvU-00 for namedroppers@ops.ietf.org; Tue, 11 Jun 2002 22:15:46 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17I0Ty-000M0K-00 for namedroppers@ops.ietf.org; Tue, 11 Jun 2002 22:15:46 -0700 In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1023816636.595.323.camel@error-messages.mit.edu> Mime-Version: 1.0 Subject: Re: IESG feedback on dnsext-ad-is-secure From: Greg Hudson To: Erik Nordmark Cc: namedroppers@ops.ietf.org Date: 11 Jun 2002 13:30:35 -0400 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] I am not personally aware of applications which want to know the signedness of a DNS record, but it does seem like a reasonable thing to want. I'll leave it up to others (like the draft authors) to provide more concrete details. On Tue, 2002-06-11 at 03:27, Erik Nordmark wrote: > > There is one common case where that trust is perfectly justified: the > > recursive resolver runs on the same machine as the application. > But in that case, isn't this an API question more than a protocol question? Uh, just because the recursive resolver is running on the same machine doesn't mean that the application is magically using some rich, RPC-like interface to talk to it. The stub resolver still communicates with the recursive resolver using the DNS protocol, just as if it were on a different host. So it's still a protocol question. > I could speculate that in this case a richer interface might make sense Possibly, but it would be a lot of work to design this richer interface, no one has a proposal on the table, and AD-is-secure does not damage our ability to achieve a richer interface in the future. -- to unsubscribe send a message to namedroppers-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 Jun 12 01:32:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24941 for ; Wed, 12 Jun 2002 01:32:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17I0cs-000IFj-00 for namedroppers-data@psg.com; Tue, 11 Jun 2002 22:24:58 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17I0cp-000IFW-00 for namedroppers@ops.ietf.org; Tue, 11 Jun 2002 22:24:55 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17I0cp-000MKu-00; Tue, 11 Jun 2002 22:24:55 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Erik Nordmark Cc: "Hallam-Baker, Phillip" , Paul Vixie , namedroppers Subject: RE: What are the opt-in issues References: <2F3EC696EAEED311BB2D009027C3F4F405869B03@vhqpostal.verisign.com> Message-Id: Date: Tue, 11 Jun 2002 22:24:55 -0700 X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Only after the document goes to the AD is it appropriate for the AD to >> consult the DNS directorate. this is drivel. i can ask whomever i want for any advice i want any time i want. jeezus! -- to unsubscribe send a message to namedroppers-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 Jun 12 05:07:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20877 for ; Wed, 12 Jun 2002 05:07:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17I3ub-000NNL-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 01:55:29 -0700 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=delta.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.36 #1) id 17I3uP-000NN8-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 01:55:24 -0700 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5C6bN718500; Wed, 12 Jun 2002 13:37:40 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Rob Austein cc: namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: <20020611161857.8B8EA1BFA@thrintun.hactrn.net> References: <20020611161857.8B8EA1BFA@thrintun.hactrn.net> <20020611154927.F0C4528B6C@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Jun 2002 13:37:23 +0700 Message-ID: <18498.1023863843@munnari.OZ.AU> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 11 Jun 2002 12:18:57 -0400 From: Rob Austein Message-ID: <20020611161857.8B8EA1BFA@thrintun.hactrn.net> | A resolver which only issues queries with RD=1 may still have a cache. Of course, and this is part of the issue here. | I don't care whether one calls such a thing a "stub resolver" or not. But for the purposes of this discussion, resolvers that have no cache are what is relevant. It is useful to have a name for such things, and "stub resolver" seems to be that. Other resolvers that issue RD=1 queries (there was a time, probably still is, when all resolvers issued RD=1 always - the only question was whether the server had RA=1 and would process the recursion) certainly exist, but are less relevant. It seems likely that a stub resolver (as defined 2 paragraphs ago) would like to know whether or not its (presumably trusted) back end has validated signatures or not. Since the back end has no way of knowing whether or not the stub resolver only wants validated answers, it can't just not reply if the signature checks fail. Hence the AD bit seems to be useful. Now for resolvers that want to check signatures themselves, the AD bit can simply be ignored. Having it there, either set or clear, cannot possibly prevent the SIGS being fetched, and validated. So, all this discussion seems to me to be pretty pointless. I am pretty sure the draft already says that the AD bit shouldn't be trusted unless the resolver receiving it has some other way of trusting the resolver that sent it. Note that the back end resolver (the one that received Rd=1, has RA=1, and actually sets the AD bit) has no method to know what kind of resolver is talking to it - it doesn't know whether the back end trusts it or not (it may know that it is going to use TSIG to communicate with its client, but presence of TSIG does not guarantee trust, nor does its absence prohibit it), so it just sets the AD bit (or doesn't) on all queries it processes, regardless of whether the value will end up being used or not. While space in DNS packets is limited, I thing we can afford that one bit... kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 12 08:50:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25951 for ; Wed, 12 Jun 2002 08:50:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17I7PW-0000fL-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 05:39:38 -0700 Received: from open.nlnetlabs.nl ([213.53.69.1]) by psg.com with esmtp (Exim 3.36 #1) id 17I7PS-0000ew-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 05:39:34 -0700 Received: (from alexis@localhost) by open.nlnetlabs.nl (8.11.6/8.11.6) id g5CCdUH05468; Wed, 12 Jun 2002 14:39:30 +0200 (CEST) (envelope-from alexis) Message-Id: <200206121239.g5CCdUH05468@open.nlnetlabs.nl> Subject: Re: wildcards and CNAMEs In-Reply-To: <200206120339.g5C3dvm0010053@drugs.dv.isc.org> "from Mark.Andrews@isc.org at Jun 12, 2002 01:39:57 pm" To: Mark.Andrews@isc.org Date: Wed, 12 Jun 2002 14:39:30 +0200 (CEST) CC: namedroppers@ops.ietf.org From: Alexis Yushin Reply-To: alexis@NLnetLabs.nl X-Mailer: ELM [version 2.4ME+ PL87 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark, Once Mark.Andrews@isc.org wrote: > I suspect no one though people would want to use a CNAME > wildcard record when RFC 1034 was written. > > The problem is that CNAMEs are not illegal with wildcard > records and depending upon how you interperet RFC 1034 > Section 4.3.2 Step 3 and the query type you can get wildcard > CNAMES records being honored or ignored. > > If you make a query with a type CNAME quite clearly they > are supposed to match. If you make a query with type != > CNAME there is ambiguity. If you don't match you then get > the situation where a cache will return different results > depending upon whether there was a cached CNAME record or > not. It is not clear to me where you base your conclusion upon that wildcard CNAMEs can be ignored? Once you matched the wildcard for whatever query type and found a CNAME, I would expect the implementation to restart the query. Are you trying to point out at the flow ambiguity where 3.a implicitly states that a whole QNAME has to be matched in order to restart the query with CNAME and that 3.a preceeds 3.c? Common sense tells me that once a query resolved to CNAME it should be restarted with the QNAME in the CNAME whether the CNAME owner name was wildcard or not. Is there some problem I'm missing here? Alexis -- to unsubscribe send a message to namedroppers-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 Jun 12 10:51:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00230 for ; Wed, 12 Jun 2002 10:51:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17I9DQ-0002mU-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 07:35:16 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17I9DF-0002ld-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 07:35:06 -0700 Received: from drugs.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.12.3/8.12.3) with ESMTP id g5CEYtm0013001; Thu, 13 Jun 2002 00:34:55 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200206121434.g5CEYtm0013001@drugs.dv.isc.org> To: alexis@NLnetLabs.nl Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: wildcards and CNAMEs In-reply-to: Your message of "Wed, 12 Jun 2002 14:39:30 +0200." <200206121239.g5CCdUH05468@open.nlnetlabs.nl> Date: Thu, 13 Jun 2002 00:34:54 +1000 X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark, > > Once Mark.Andrews@isc.org wrote: > > I suspect no one though people would want to use a CNAME > > wildcard record when RFC 1034 was written. > > > > The problem is that CNAMEs are not illegal with wildcard > > records and depending upon how you interperet RFC 1034 > > Section 4.3.2 Step 3 and the query type you can get wildcard > > CNAMES records being honored or ignored. > > > > If you make a query with a type CNAME quite clearly they > > are supposed to match. If you make a query with type != > > CNAME there is ambiguity. If you don't match you then get > > the situation where a cache will return different results > > depending upon whether there was a cached CNAME record or > > not. > > It is not clear to me where you base your conclusion upon that > wildcard CNAMEs can be ignored? Once you matched the wildcard for > whatever query type and found a CNAME, I would expect the implementation > to restart the query. > > Are you trying to point out at the flow ambiguity where 3.a implicitly > states that a whole QNAME has to be matched in order to restart the > query with CNAME and that 3.a preceeds 3.c? > > Common sense tells me that once a query resolved to CNAME it should be > restarted with the QNAME in the CNAME whether the CNAME owner name > was wildcard or not. Is there some problem I'm missing here? > > Alexis If the "*" label does exist, match RRs at that node against QTYPE. If any match, copy them into the answer section, but set the owner of the RR to be QNAME, and not the node with the "*" label. Go to step 6. The question is does "match RRs at that node against QTYPE" match the CNAME record when QTYPE != CNAME. When read in conjuction with the description earlier in the section it has been argued that it doesn't as CNAME is explicitly mentioned to be looked for when a match fails. If the data at the node is a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, and go back to step 1. There is atleast one implementation where the match is not made so this is not a academic issue. The same zone produces different results in different implementations. Mark -- Mark Andrews, Internet Software Consortium 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 Jun 12 10:59:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00452 for ; Wed, 12 Jun 2002 10:59:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17I9Qn-0002yU-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 07:49:05 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17I9Qh-0002yB-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 07:48:59 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA06169; Wed, 12 Jun 2002 10:48:58 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA02644; Wed, 12 Jun 2002 10:45:49 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id KAA02474; Wed, 12 Jun 2002 10:45:48 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id KAA19670; Wed, 12 Jun 2002 10:45:46 -0400 Subject: Re: IESG feedback on dnsext-ad-is-secure From: Greg Hudson To: Robert Elz Cc: namedroppers@ops.ietf.org In-Reply-To: <18498.1023863843@munnari.OZ.AU> References: <20020611161857.8B8EA1BFA@thrintun.hactrn.net> <20020611154927.F0C4528B6C@as.vix.com> <18498.1023863843@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 12 Jun 2002 10:45:46 -0400 Message-Id: <1023893146.594.386.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,OPT_IN,RCVD_IN_RELAYS_ORDB_ORG version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2002-06-12 at 02:37, Robert Elz wrote: > It seems likely that a stub resolver (as defined 2 paragraphs ago) would > like to know whether or not its (presumably trusted) back end has validated > signatures or not. Uh, I'm not quite sure what you're saying here, but this statement makes me a little nervous. AD=1 means the back end has validated signatures, *and* all the required signatures were present and valid. AD=0 means the back end has not validated signatures, *or* the required signatures were absent or invalid. AD doesn't give you a way to determine if the back end is DNSSEC-aware or not, unless you happen to know of a record with a valid signature. It's important that everyone be on the same page here, so that we don't get AD-is-confused. People (including area directors) in the opt-in discussion have already raised the possibility that a query for an unsigned record in an opt-in zone might come back with the AD bit set, which could only happen with a completely different meaning for the AD bit. Sure, you can cryptographically determine that the requested record wouldn't be signed if it does exist, but the record clearly fails the test: "The AD bit MUST NOT be set on a response unless all of the RRsets in the answer and authority sections of the response are Authenticated." -- to unsubscribe send a message to namedroppers-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 Jun 12 11:08:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00671 for ; Wed, 12 Jun 2002 11:08:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17I9Yt-00036t-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 07:57:27 -0700 Received: from open.nlnetlabs.nl ([213.53.69.1]) by psg.com with esmtp (Exim 3.36 #1) id 17I9Yn-00036d-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 07:57:22 -0700 Received: (from alexis@localhost) by open.nlnetlabs.nl (8.11.6/8.11.6) id g5CEvHa06370; Wed, 12 Jun 2002 16:57:17 +0200 (CEST) (envelope-from alexis) Message-Id: <200206121457.g5CEvHa06370@open.nlnetlabs.nl> Subject: Re: wildcards and CNAMEs In-Reply-To: <200206121434.g5CEYtm0013001@drugs.dv.isc.org> "from Mark.Andrews@isc.org at Jun 13, 2002 00:34:54 am" To: Mark.Andrews@isc.org Date: Wed, 12 Jun 2002 16:57:17 +0200 (CEST) CC: alexis@NLnetLabs.nl, namedroppers@ops.ietf.org From: Alexis Yushin Reply-To: alexis@NLnetLabs.nl X-Mailer: ELM [version 2.4ME+ PL87 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I see what you mean. Common sense tells me that the If the "*" label does exist, match RRs at that node against QTYPE. If any match, copy them into the answer section, but set the owner of the RR to be QNAME, and not the node with the "*" label. Go to step 6. needs to be extended with 3.a: if the match fails and... If the data at the node is a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, and go back to step 1. My arguement is that wildcards have to do with matching the domain name and CNAME's with matching the query type and should not affect each other. Once a wildcard was found it should be resolved exactly the same way as if a whole domain name was found. Side issue, is using wildcards with referrals specifically forbidden? I believe so but cant find the reference. Alexis -- to unsubscribe send a message to namedroppers-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 Jun 12 11:27:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01339 for ; Wed, 12 Jun 2002 11:27:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17I9rS-0003Qw-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 08:16:38 -0700 Received: from [202.28.96.5] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17I9rL-0003Ql-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 08:16:33 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5CFGSM04355; Wed, 12 Jun 2002 22:16:28 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5CFDvs20902; Wed, 12 Jun 2002 22:13:58 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Greg Hudson cc: namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: <1023893146.594.386.camel@error-messages.mit.edu> References: <1023893146.594.386.camel@error-messages.mit.edu> <20020611161857.8B8EA1BFA@thrintun.hactrn.net> <20020611154927.F0C4528B6C@as.vix.com> <18498.1023863843@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Jun 2002 22:13:57 +0700 Message-ID: <20900.1023894837@munnari.OZ.AU> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 12 Jun 2002 10:45:46 -0400 From: Greg Hudson Message-ID: <1023893146.594.386.camel@error-messages.mit.edu> | Uh, I'm not quite sure what you're saying here, Most likely I wasn't being very clear, but I disagree with nothing that you said, so I don't think we have any problem... My point was more along the lines that receiving a reply with AD=1 set does not commit the recipient to trust the thing - it can go and do its own validation if it feels the need. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 12 11:32:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01480 for ; Wed, 12 Jun 2002 11:32:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17I9xn-0003Xt-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 08:23:11 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17I9xg-0003XT-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 08:23:05 -0700 Received: from drugs.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.12.3/8.12.3) with ESMTP id g5CFMxm0013321; Thu, 13 Jun 2002 01:22:59 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200206121522.g5CFMxm0013321@drugs.dv.isc.org> To: alexis@NLnetLabs.nl Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: wildcards and CNAMEs In-reply-to: Your message of "Wed, 12 Jun 2002 16:57:17 +0200." <200206121457.g5CEvHa06370@open.nlnetlabs.nl> Date: Thu, 13 Jun 2002 01:22:59 +1000 X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I see what you mean. Common sense tells me that the > > If the "*" label does exist, match RRs at that node > against QTYPE. If any match, copy them into the answer > section, but set the owner of the RR to be QNAME, and > not the node with the "*" label. Go to step 6. > > needs to be extended with 3.a: > > if the match fails and... > > If the data at the node is a CNAME, and QTYPE doesn't > match CNAME, copy the CNAME RR into the answer section > of the response, change QNAME to the canonical name in > the CNAME RR, and go back to step 1. > > My arguement is that wildcards have to do with matching the domain > name and CNAME's with matching the query type and should not affect > each other. Once a wildcard was found it should be resolved exactly > the same way as if a whole domain name was found. Which is what named does. > Side issue, is using wildcards with referrals specifically forbidden? > I believe so but cant find the reference. > > > Alexis -- Mark Andrews, Internet Software Consortium 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 Jun 12 11:34:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01545 for ; Wed, 12 Jun 2002 11:34:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IA20-0003fj-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 08:27:32 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17IA1u-0003fN-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 08:27:26 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id A8B6528B6C for ; Wed, 12 Jun 2002 08:27:25 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: wildcards and CNAMEs In-Reply-To: Message from Alexis Yushin of "Wed, 12 Jun 2002 16:57:17 +0200." <200206121457.g5CEvHa06370@open.nlnetlabs.nl> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 12 Jun 2002 08:27:25 -0700 Message-Id: <20020612152725.A8B6528B6C@as.vix.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > My arguement is that wildcards have to do with matching the domain > name and CNAME's with matching the query type and should not affect > each other. ... CNAME affects name lookup, as does wildcard processing, and they interact. > Side issue, is using wildcards with referrals specifically forbidden? > I believe so but cant find the reference. NS also affects name lookup, and occurs "earlier than" wildcard processing such that you don't check for the presence of wildcards until after you know what zone you're in. [RFC2181 6] clarifies this somewhat -- a "*" label would be inside the zone and below the zone cut, and would not be seen in the parent zone even if present, and would thus have no meaning. -- to unsubscribe send a message to namedroppers-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 Jun 12 12:00:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02777 for ; Wed, 12 Jun 2002 12:00:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IALx-00046w-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 08:48:09 -0700 Received: from open.nlnetlabs.nl ([213.53.69.1]) by psg.com with esmtp (Exim 3.36 #1) id 17IALs-00046i-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 08:48:04 -0700 Received: (from alexis@localhost) by open.nlnetlabs.nl (8.11.6/8.11.6) id g5CFm1c06532; Wed, 12 Jun 2002 17:48:01 +0200 (CEST) (envelope-from alexis) Message-Id: <200206121548.g5CFm1c06532@open.nlnetlabs.nl> Subject: Re: wildcards and CNAMEs In-Reply-To: <20020612152725.A8B6528B6C@as.vix.com> "from Paul Vixie at Jun 12, 2002 08:27:25 am" To: Paul Vixie Date: Wed, 12 Jun 2002 17:48:01 +0200 (CEST) CC: namedroppers@ops.ietf.org From: Alexis Yushin Reply-To: alexis@NLnetLabs.nl X-Mailer: ELM [version 2.4ME+ PL87 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Once Paul Vixie wrote: >> My arguement is that wildcards have to do with matching the domain >> name and CNAME's with matching the query type and should not affect >> each other. ... > >CNAME affects name lookup, as does wildcard processing, and they interact. Really? Just kidding. What I meant is that either not clearly explained in 1034 the lookup algorithm is in fact consist of (at least) two major steps: 1) search for the queried domain name: either complete match, referral, wildcard or authoratively not found. 2) search for the queried type: either not found (empty answer section), found or cname. It always happens in the same order. Once you resolved the domain name you have an answer, either of listed in 2. If you resolved it to cname, dname or God knows what else the followup standards may come up with you may have to restart the query, but once again you will be doing first step 1 and then step 2. >> Side issue, is using wildcards with referrals specifically forbidden? >> I believe so but cant find the reference. > >NS also affects name lookup, and occurs "earlier than" wildcard processing >such that you don't check for the presence of wildcards until after you >know what zone you're in. [RFC2181 6] clarifies this somewhat -- a "*" >label would be inside the zone and below the zone cut, and would not be >seen in the parent zone even if present, and would thus have no meaning. What I meant was if it is implicitly forbidden to: *.customers.com. IN NS ns1.servers.net. It doesnt make sense to me but we're talking about RFC's here. Alexis -- to unsubscribe send a message to namedroppers-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 Jun 12 12:01:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02853 for ; Wed, 12 Jun 2002 12:01:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IAS5-0004ES-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 08:54:29 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17IAS0-0004EF-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 08:54:24 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17IAS0-000Dta-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 08:54:24 -0700 Message-ID: <000001c2121e$9e15e8b0$8000a8c0@DILBERT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: "Phill" To: Subject: RE: What are the opt-in issues Date: Wed, 12 Jun 2002 10:37:02 -0400 X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] >this is drivel. i can ask whomever i want for any advice i want any >time i want. jeezus! NOT if you are telling the group that you won't talk to them until secret deliberations are complete. There is no impediment whatsoever to your telling the group your decision on consensus. Your refusal to do so is holding up the group. Since the AD has given his opinion of what the consensus of the group is should we simply bypass Randy and proceed on that basis? Phill -- to unsubscribe send a message to namedroppers-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 Jun 12 12:35:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03999 for ; Wed, 12 Jun 2002 12:35:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IAzI-0004lz-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 09:28:48 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17IAz8-0004lg-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 09:28:38 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id JAA11169; Wed, 12 Jun 2002 09:32:29 -0700 Message-Id: <5.1.1.2.2.20020612091617.091399f8@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Wed, 12 Jun 2002 09:20:37 -0700 To: "Phill" From: Dave Crocker Subject: RE: What are the opt-in issues Cc: In-Reply-To: <000001c2121e$9e15e8b0$8000a8c0@DILBERT> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.8 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,OPT_IN,NO_MX_FOR_FROM version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:37 AM 6/12/2002 -0400, Phill wrote: >[ post by non-subscriber. with the massive amount of spam, it is easy to > miss and therefore delete mis-posts. so fix subscription addresses! ] > > >this is drivel. i can ask whomever i want for any advice i want any > >time i want. jeezus! >NOT NOT if you are telling the group that you won't talk to them until >secret deliberations are complete. Phill, You are nit-picking a discussion sequencing issue and are thereby entirely missing the point that is critical. So, you need to stop this line of debate. Anyone may talk with anyone at any time. It can be an open discussion. It can be closed. It can be with a group or it can be with an individual. They may talk with folk in any sequence they wish. What is NOT allowed is making a working group decision without collaborating with the working group and reaching rough consensus. So, has the working group chair (or AD) asserted a decision without the requisite collaboration with, and rough consensus from, the working group? If the answer is no, then this whole thread is a complete waste. If the answer is yes, then there is a serious problem. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 -- to unsubscribe send a message to namedroppers-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 Jun 12 12:48:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04446 for ; Wed, 12 Jun 2002 12:48:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IBAF-0004x3-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 09:40:07 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17IBA9-0004wR-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 09:40:01 -0700 Received: by as.vix.com (Postfix, from userid 716) id 1741A28B6C; Wed, 12 Jun 2002 09:40:00 -0700 (PDT) To: namedroppers@ops.ietf.org Subject: Re: What are the opt-in issues References: <5.1.1.2.2.20020612091617.091399f8@jay.songbird.com> From: Paul Vixie Date: 12 Jun 2002 09:40:00 -0700 In-Reply-To: <5.1.1.2.2.20020612091617.091399f8@jay.songbird.com> Message-ID: Lines: 18 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dave wrote, in response to Phill: > You are nit-picking a discussion sequencing issue and are thereby entirely > missing the point that is critical. I want to make sure that *my* real point doesn't get lost amongst all of these other threads. DNSSEC standardization has been horribly bungled, both in the opt-in issue and at every significant previous juncture. What passes for "management" in the IETF has completely failed here, and is failing now. And that's without even counting the horrible A6/DNAME screwups. Phill and I have not seen eye to eye on many things, but we're singing from the same song book on this issue: THROW THE BUMS OUT. -- Paul Vixie -- to unsubscribe send a message to namedroppers-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 Jun 12 13:11:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05292 for ; Wed, 12 Jun 2002 13:11:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IBUn-0005Gz-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 10:01:21 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17IBUe-0005Gl-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 10:01:12 -0700 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 92D431C81 for ; Wed, 12 Jun 2002 13:01:11 -0400 (EDT) Date: Wed, 12 Jun 2002 13:01:11 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: <18498.1023863843@munnari.OZ.AU> References: <20020611161857.8B8EA1BFA@thrintun.hactrn.net> <20020611154927.F0C4528B6C@as.vix.com> <18498.1023863843@munnari.OZ.AU> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020612170111.92D431C81@thrintun.hactrn.net> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 12 Jun 2002 13:37:23 +0700, Robert Elz wrote: > > But for the purposes of this discussion, resolvers that have no cache are > what is relevant. Sorry, but I don't agree that only resolvers with no cache are relevant. A resolver for a PDA might include both a small cache and DNSSEC signature verification code but still be recursive-mode-only, simply because the iterative resolver function is something that really doesn't need to be on the PDA if it's readily available from the environment du jour. Farming out signature verification to the environment du jour is a very different proposition. I'm not saying that there won't be dumb little boxes that support neither iterative resolution nor signature verification (there almost certainly will). I am saying, however, that if I were writing code for a device with constrained resources, I'd put signature verification much higher on my priority list than iterative resolution, particularly since the bulkiest part of the signature verification code is likely to be crypto functions that I might well have loaded anyway to support IPsec, TLS, or something like that. -- to unsubscribe send a message to namedroppers-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 Jun 12 13:21:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05675 for ; Wed, 12 Jun 2002 13:21:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IBjJ-0005YQ-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 10:16:21 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17IBjB-0005Y7-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 10:16:13 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id KAA13127; Wed, 12 Jun 2002 10:20:05 -0700 Message-Id: <5.1.1.2.2.20020612101018.09312800@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Wed, 12 Jun 2002 10:11:24 -0700 To: Paul Vixie From: Dave Crocker Subject: Re: What are the opt-in issues Cc: namedroppers@ops.ietf.org In-Reply-To: References: <5.1.1.2.2.20020612091617.091399f8@jay.songbird.com> <5.1.1.2.2.20020612091617.091399f8@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.8 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,OPT_IN,NO_MX_FOR_FROM version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 09:40 AM 6/12/2002 -0700, Paul Vixie wrote: >Phill and I have not seen eye to eye on many things, but we're singing from >the same song book on this issue: THROW THE BUMS OUT. Paul, The IETF has procedures for challenging management actions. The procedures seem to work pretty well, except when they are not used. The procedures do not include calling for management changes on the working group mailing list. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 -- to unsubscribe send a message to namedroppers-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 Jun 12 13:26:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05843 for ; Wed, 12 Jun 2002 13:26:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IBnT-0005da-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 10:20:39 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17IBnP-0005dA-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 10:20:35 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 8023928ED7 for ; Wed, 12 Jun 2002 10:20:25 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: What are the opt-in issues In-Reply-To: Message from Dave Crocker of "Wed, 12 Jun 2002 10:11:24 PDT." <5.1.1.2.2.20020612101018.09312800@jay.songbird.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 12 Jun 2002 10:20:25 -0700 Message-Id: <20020612172025.8023928ED7@as.vix.com> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The IETF has procedures for challenging management actions. The procedures > seem to work pretty well, except when they are not used. as you know, i take your word as "gospel" on such matters, oh poised man. > The procedures do not include calling for management changes on the working > group mailing list. then a simple redirect to the proper process is all you need to send us. (i.e., engaging phill in a debate here on namedroppers may not help much.) -- to unsubscribe send a message to namedroppers-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 Jun 12 13:35:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06236 for ; Wed, 12 Jun 2002 13:35:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IBs1-0005kS-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 10:25:21 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17IBry-0005kE-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 10:25:18 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17IBry-000GQl-00; Wed, 12 Jun 2002 10:25:18 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Dave Crocker Cc: "Phill" , Subject: RE: What are the opt-in issues References: <000001c2121e$9e15e8b0$8000a8c0@DILBERT> <5.1.1.2.2.20020612091617.091399f8@jay.songbird.com> Message-Id: Date: Wed, 12 Jun 2002 10:25:18 -0700 X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > So, has the working group chair (or AD) asserted a decision without the > requisite collaboration with, and rough consensus from, the working group? nope. for the fourth time To: "Matt Larson" Subject: Re: Opt-in Decission day: Postponed From: Randy Bush Date: Thu, 06 Jun 2002 12:19:38 -0700 Cc: "Olafur Gudmundsson" , "DNSEXT mailing list" > Could the chairs please give an update regarding Opt-in? major pushback from the dns directorate. we've been talking with roy to try and get more comfortable with it. roy and rob are working on documenting an analysis. patience. randy -- to unsubscribe send a message to namedroppers-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 Jun 12 14:28:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08052 for ; Wed, 12 Jun 2002 14:28:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IChh-0006ia-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 11:18:45 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17IChY-0006iB-00; Wed, 12 Jun 2002 11:18:36 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id LAA16164; Wed, 12 Jun 2002 11:22:29 -0700 Message-Id: <5.1.1.2.2.20020612102856.02aea118@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Wed, 12 Jun 2002 11:13:50 -0700 To: Randy Bush From: Dave Crocker Subject: RE: What are the opt-in issues Cc: "Phill" , In-Reply-To: References: <000001c2121e$9e15e8b0$8000a8c0@DILBERT> <5.1.1.2.2.20020612091617.091399f8@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.8 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,OPT_IN,NO_MX_FOR_FROM version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:25 AM 6/12/2002 -0700, Randy Bush wrote: > > So, has the working group chair (or AD) asserted a decision without the > > requisite collaboration with, and rough consensus from, the working group? > >nope. for the fourth time excellent. Are there issues beyond what Roy posted on Monday in "Please state the 'attacks' in public"? Seems like it would be helpful for the chairs to summarize the pending issues and what process is needed to resolve them. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 -- to unsubscribe send a message to namedroppers-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 Jun 12 14:57:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09425 for ; Wed, 12 Jun 2002 14:57:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ID9c-0007W6-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 11:47:36 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17ID9Z-0007Vv-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 11:47:33 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id B700B28ED7 for ; Wed, 12 Jun 2002 11:47:32 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: confession X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 12 Jun 2002 11:47:32 -0700 Message-Id: <20020612184732.B700B28ED7@as.vix.com> X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk because the events of my day have led me to ruminate on the probability that when someone makes an accusation it will ultimately turn out that the accuser is also somehow guilty of the same behaviour, i wanted to confess a process violation i took part in a few months ago. there was this concall. randy and olafur and markk and myself and some other folks whose names escape me got together on a concall and talked about DS and opt-in. the long and the short of it were (a) drafts were to be updated, (b) schedules were agreed to, and (c) a very short summary was sent to namedroppers, showing conclusions but not the paths untaken nor the precise reasoning which had led to those conclusions. no notice was given on namedroppers@ that interested parties were going to meet outside the ietf's meeting halls and mailing lists. yet the course of the wg's affairs was dramatically shifted by the meeting. my understanding of ietf is probably naive, but by that understanding, we did not follow the official process in several ways. number one, a meeting consisting of the wg chairs and the document authors should've been announced so that other interested parties could observe or attend, and number two, detailed notes about who said what and who convinced whom ought to have been published. number three, the results should have been a series of recommendations to be discussed/debated on the mailing list, rather than a series of decisions adopted by the wg chairs and doc authors, and sending a summary of those decisions was an unacceptable substitute. i apologize for my part in this, and i assure you all, i won't do it again. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 12 15:11:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10055 for ; Wed, 12 Jun 2002 15:11:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IDNj-0007yp-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 12:02:11 -0700 Received: from smtp1.zocalo.net ([157.22.1.67]) by psg.com with esmtp (Exim 3.36 #1) id 17IDNe-0007yc-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 12:02:06 -0700 Received: from woody.zocalo.net (woody.zocalo.net [157.22.1.3]) by smtp1.zocalo.net (8.9.1/8.9.1) with ESMTP id MAA06175; Wed, 12 Jun 2002 12:02:03 -0700 (PDT) Date: Wed, 12 Jun 2002 12:02:04 -0700 (PDT) From: Bill Woodcock To: Paul Vixie cc: Subject: Re: confession In-Reply-To: <20020612184732.B700B28ED7@as.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > i want to confess a process violation i took part in a few months ago. > there was this concall... > i apologize for my part in this, and i assure you all, i won't do it again. Okay, that's it! Turn in the keys to your black helicopter! -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 Jun 12 15:27:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10485 for ; Wed, 12 Jun 2002 15:27:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IDdr-0008dg-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 12:18:51 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17IDde-0008dL-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 12:18:38 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id MAA18506; Wed, 12 Jun 2002 12:22:31 -0700 Message-Id: <5.1.1.2.2.20020612121002.092a9c60@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Wed, 12 Jun 2002 12:13:48 -0700 To: Paul Vixie From: Dave Crocker Subject: Re: confession Cc: namedroppers@ops.ietf.org In-Reply-To: <20020612184732.B700B28ED7@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,NO_MX_FOR_FROM version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:47 AM 6/12/2002 -0700, Paul Vixie wrote: >my understanding of ietf is probably naive, but by that understanding, >we did not follow the official process in several ways. number one, a >meeting consisting of the wg chairs and the document authors should've >been announced so that other interested parties could observe or attend, >and number two, detailed notes about who said what and who convinced whom >ought to have been published. number three, the results should have been >a series of recommendations to be discussed/debated on the mailing list, >rather than a series of decisions adopted by the wg chairs and doc authors Paul, for IETF situations that get to this stage of tension, your note is unusual and refreshing. Perhaps it is your claimed naivete about the IETF that permits you to take such a helpful step. In any event many thanks for your posting. I'll reiterate that I think that numbers one and two were not at all problematic. Number three is easily heeded and ought to permit the wg to move forward. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 -- to unsubscribe send a message to namedroppers-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 Jun 12 16:20:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11955 for ; Wed, 12 Jun 2002 16:20:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IEQu-000Aeq-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 13:09:32 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17IEQr-000Aee-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 13:09:29 -0700 Received: from randy by rip.psg.com with local (Exim 4.04) id 17IEQr-0000iM-00; Wed, 12 Jun 2002 13:09:29 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Dave Crocker Cc: namedroppers Subject: RE: What are the opt-in issues References: <000001c2121e$9e15e8b0$8000a8c0@DILBERT> <5.1.1.2.2.20020612091617.091399f8@jay.songbird.com> <5.1.1.2.2.20020612102856.02aea118@jay.songbird.com> Message-Id: Date: Wed, 12 Jun 2002 13:09:29 -0700 X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.20 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Are there issues beyond what Roy posted on Monday in "Please state the > 'attacks' in public"? > > Seems like it would be helpful for the chairs to summarize the pending > issues and what process is needed to resolve them. sadly, i am old and stupid, no where near as smart as most folk posting here seem to be. i don't have all the answers. heck, i am not sure i have all the questions. as i just said to my co-chair > focus on trying to understand the technical issues (i don't > completely understand the ones i have heard so far, and am not > sure i have heard them all. i am surprised you are so sure of > yourself), and the rest will follow. which is why i too am waiting to see what roy and rob say and using my delete key liberally. but, as i said before, that new questions / issues keep arising is part of what scares the heck out of me. rob mentioned this as worrying him as well. randy -- to unsubscribe send a message to namedroppers-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 Jun 12 21:39:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18690 for ; Wed, 12 Jun 2002 21:39:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IJKO-000HRZ-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 18:23:08 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17IJKK-000HRO-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 18:23:04 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 1C1DA28B6C for ; Wed, 12 Jun 2002 18:23:04 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: confession In-Reply-To: Message from Dave Crocker of "Wed, 12 Jun 2002 12:13:48 PDT." <5.1.1.2.2.20020612121002.092a9c60@jay.songbird.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 12 Jun 2002 18:23:04 -0700 Message-Id: <20020613012304.1C1DA28B6C@as.vix.com> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >... we did not follow the official process in several ways. number one, > >meeting ... should've been announced ...; number two, detailed notes ...; > >number three, ... should have been ... recommendations rather than ... > >decisions adopted by the wg chairs and doc authors > > ... I'll reiterate that I think that numbers one and two were not at all > problematic. > > Number three is easily heeded and ought to permit the wg to move forward. i disagree, since goal number three was explicitly stated, and methods one and two were explicitly adopted in the furtherence of number three. we did a bad thing, and we did it on purpose, and we knew in advance that it was bad. come to find out that's the same way a6/dname was dealt with, and now opt-in. this isn't just sour grapes on my part as in "it's fine to break the rules as long as you get my complicity in advance, which wasn't done for a6/dname and this recent opt-in thing." it's a simpler case of "i thought the chairs both knew what the heck they were doing and it now turns out otherwise." (i guess that'll be the last time anybody hands ME a secret decoder ring!) -- to unsubscribe send a message to namedroppers-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 Jun 12 22:24:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19539 for ; Wed, 12 Jun 2002 22:24:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IK2e-000IGu-00 for namedroppers-data@psg.com; Wed, 12 Jun 2002 19:08:52 -0700 Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com) by psg.com with esmtp (Exim 3.36 #1) id 17IK2V-000IGf-00 for namedroppers@ops.ietf.org; Wed, 12 Jun 2002 19:08:44 -0700 Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id TAA02481; Wed, 12 Jun 2002 19:12:38 -0700 Message-Id: <5.1.1.2.2.20020612185940.027686f0@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Wed, 12 Jun 2002 19:03:46 -0700 To: Paul Vixie From: Dave Crocker Subject: Re: confession Cc: namedroppers@ops.ietf.org In-Reply-To: <20020613012304.1C1DA28B6C@as.vix.com> References: <5.1.1.2.2.20020612121002.092a9c60@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,NO_MX_FOR_FROM version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 06:23 PM 6/12/2002 -0700, Paul Vixie wrote: >i disagree, since goal number three was explicitly stated, and methods one >and two were explicitly adopted in the furtherence of number three. we did >a bad thing, and we did it on purpose, and we knew in advance that it was bad. Paul, Indeed there might be an interesting discussion to have over in the poised world. Your suggestion of a multi-working group pattern will be worth exploring there. However I was not so much misunderstanding your previous point about a true conspiracy as I was (and am) suggesting that we can get the Right Thing done now and move one, at least for the current effort. That said, we are still left with no management guidance as to when the pending issues will be summarized for the working group, thought it has been a week since the group was told one would be produced. For that matter, we do not know whether the RobRoy summary will be the full set of pending items. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 -- to unsubscribe send a message to namedroppers-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 Jun 13 06:29:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06297 for ; Thu, 13 Jun 2002 06:29:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IRdD-00005Z-00 for namedroppers-data@psg.com; Thu, 13 Jun 2002 03:15:07 -0700 Received: from [202.28.96.5] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17IRd9-00004e-00 for namedroppers@ops.ietf.org; Thu, 13 Jun 2002 03:15:03 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5DAElM20359; Thu, 13 Jun 2002 17:14:47 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5DACEs23482; Thu, 13 Jun 2002 17:12:21 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Rob Austein cc: namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: <20020612170111.92D431C81@thrintun.hactrn.net> References: <20020612170111.92D431C81@thrintun.hactrn.net> <20020611161857.8B8EA1BFA@thrintun.hactrn.net> <20020611154927.F0C4528B6C@as.vix.com> <18498.1023863843@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Jun 2002 17:12:14 +0700 Message-ID: <23480.1023963134@munnari.OZ.AU> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 12 Jun 2002 13:01:11 -0400 From: Rob Austein Message-ID: <20020612170111.92D431C81@thrintun.hactrn.net> | I'm not saying that there won't be dumb little boxes that support | neither iterative resolution nor signature verification (there almost | certainly will). But surely these are the boxes for which the AD bit is relevant? Your (slightly) smarter boxes can just ignore the bit, however it is set, can't they? How can the state of this one bit possibly alter how your smarter resolver works, assuming it isn't interested in the information provided (however little or much that may be) ? kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 13 07:42:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08004 for ; Thu, 13 Jun 2002 07:42:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ISjM-0001KI-00 for namedroppers-data@psg.com; Thu, 13 Jun 2002 04:25:32 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17ISjI-0001K6-00 for namedroppers@ops.ietf.org; Thu, 13 Jun 2002 04:25:28 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07296; Thu, 13 Jun 2002 07:24:52 -0400 (EDT) Message-Id: <200206131124.HAA07296@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-ipv6-dns-tradeoffs-02.txt Date: Thu, 13 Jun 2002 07:24:51 -0400 X-Spam-Status: No, hits=0.8 required=5.0 tests=NO_REAL_NAME,TO_MALFORMED,EXCUSE_6 version=2.20 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 : Tradeoffs in DNS support for IPv6 Author(s) : R. Austein Filename : draft-ietf-dnsext-ipv6-dns-tradeoffs-02.txt Pages : 10 Date : 12-Jun-02 The IETF has two different proposals on the table for how to do DNS support for IPv6, and has thus far failed to reach a clear consensus on which approach is better. This note attempts to examine the pros and cons of each approach, in the hope of clarifying the debate so that we can reach closure and move on. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-dns-tradeoffs-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipv6-dns-tradeoffs-02.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-ipv6-dns-tradeoffs-02.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: <20020612145258.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ipv6-dns-tradeoffs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ipv6-dns-tradeoffs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020612145258.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 13 08:01:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08526 for ; Thu, 13 Jun 2002 08:01:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ITAp-0001oI-00 for namedroppers-data@psg.com; Thu, 13 Jun 2002 04:53:55 -0700 Received: from rs1.arin.net ([192.149.252.21]) by psg.com with esmtp (Exim 3.36 #1) id 17ITAl-0001o5-00 for namedroppers@ops.ietf.org; Thu, 13 Jun 2002 04:53:51 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id HAA00772 for ; Thu, 13 Jun 2002 07:53:50 -0400 (EDT) Received: from [208.58.216.80] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id HAA28293 for ; Thu, 13 Jun 2002 07:53:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <23480.1023963134@munnari.OZ.AU> References: <20020612170111.92D431C81@thrintun.hactrn.net> <20020611161857.8B8EA1BFA@thrintun.hactrn.net> <20020611154927.F0C4528B6C@as.vix.com> <18498.1023863843@munnari.OZ.AU> <23480.1023963134@munnari.OZ.AU> Date: Thu, 13 Jun 2002 07:53:32 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: IESG feedback on dnsext-ad-is-secure Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.4 required=5.0 tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 5:12 PM +0700 6/13/02, Robert Elz wrote: >But surely these are the boxes for which the AD bit is relevant? I've objected strongly to this draft for some time now. There is no new content here that hasn't already been presented to the AD, chairs, and authors during the last call. My reasons boil down to: 1) Name servers are already instructed to return only valid answers (unless the CD bit was set on query). Absent TSIG/SIG(0), if the resolver is going to trust an unprotected bit (the AD is in the header), the resolver might as well trust the operation of the protocol. (I.e., what does the bit add?) 2) The bit is defined to indicate if the answers were checked in accordance to the name server's local policy (e.g., the trusted keys used, who it feels is authorized to sign the data). As there is no means in the protocol to ask a name server what it's policy is (nor even what trusted key was used), the usefulness of know that the server followed its policy is of questionable value. (I.e., this relates to the "middleboxes" - opaque entities in the network that do not yield sufficient information when it is needed for troubleshooting.) 2a) The "danger" is that a server is using an incorrect trusted key and is passing off data as AD'd. Although this is correctable easily, without the ability to ask for the trusted key used, a "victim" can't easily determine that the problem is the incorrect key. 3) The only case in which the bit comes into play is when data arrives that is signed. A setting of 1 means that the signature is germane and has been sufficiently checked. A 0 means that the name server deemed the signature immaterial and did not check it. I don't see that distinguishing between the two cases is of use to a stub resolver. 4) The need to redefine the bit is rooted in the DNSSEC workshops. Prior to the addition of logging to the software we tested (BIND), there was no way to determine if the name server's verification code kicked in. We looked for the AD bit to indicate whether the trusted key statements and the zone signing was being performed correctly. Now, with logs available, this can be watched at the server. I.e., the AD bit really is best used as a debugging tool at the server - but that role has been overcome by events (the addition of logging). 5) This is a speculative objection...What if the data srrives with the AD bit set to 0? Is the resolver going to try and get a different answer? What will the user (presuming the bit's setting bubbles up to the GUI) do? Basically, somewhere along the line, a different name server is needed to find a better answer, will this happen in stub resolver situations? Yes, I realize that in #2 I say that troubleshooting is a problem, and in #4 troubleshooting was helped. In #2 I an talking about end-to-end troubleshooting, in which the shooter has no access to the server in question. In #4 I am talking about troubleshooting of one's own server. In summary - I don't see how this bit improves upon a correctly running DNS(SEC) protocol. (If you're going to trust the server to tell you it followed the protocol, trust the server to follow the protocol!) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-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 Jun 13 08:53:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10182 for ; Thu, 13 Jun 2002 08:53:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ITyQ-0002nq-00 for namedroppers-data@psg.com; Thu, 13 Jun 2002 05:45:10 -0700 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 17ITyM-0002nf-00 for namedroppers@ops.ietf.org; Thu, 13 Jun 2002 05:45:06 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14481; Thu, 13 Jun 2002 05:45:04 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5DCj3K06688; Thu, 13 Jun 2002 14:45:03 +0200 (MEST) Date: Thu, 13 Jun 2002 14:43:48 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IESG feedback on dnsext-ad-is-secure To: Greg Hudson Cc: Robert Elz , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <1023893146.594.386.camel@error-messages.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Uh, I'm not quite sure what you're saying here, but this statement makes > me a little nervous. AD=1 means the back end has validated signatures, > *and* all the required signatures were present and valid. AD=0 means > the back end has not validated signatures, *or* the required signatures > were absent or invalid. AD doesn't give you a way to determine if the > back end is DNSSEC-aware or not, unless you happen to know of a record > with a valid signature. I've been assuming that 'some of the required signatures are invalid' would mean that the data wouldn't be returned to the client. Section 6 in 2535 might mean this by "not retained" below but this is far from obvious: Data stored at a security aware server needs to be internally categorized as Authenticated, Pending, or Insecure. There is also a fourth transient state of Bad which indicates that all SIG checks have explicitly failed on the data. Such Bad data is not retained at a security aware server. Authenticated means that the data has a My concern is that it seems really broken if the client can't easily tell the difference between Insecure and Bad. So what should a recursive resolver do whith Bad data? Erik -- to unsubscribe send a message to namedroppers-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 Jun 13 09:13:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10689 for ; Thu, 13 Jun 2002 09:13:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IUIz-0003DI-00 for namedroppers-data@psg.com; Thu, 13 Jun 2002 06:06:25 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 17IUIu-0003Co-00; Thu, 13 Jun 2002 06:06:20 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23970; Thu, 13 Jun 2002 07:06:18 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5DD6GK08628; Thu, 13 Jun 2002 15:06:16 +0200 (MEST) Date: Thu, 13 Jun 2002 15:05:02 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: What are the opt-in issues To: Dave Crocker Cc: Randy Bush , Phill , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <5.1.1.2.2.20020612102856.02aea118@jay.songbird.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Are there issues beyond what Roy posted on Monday in "Please state the > 'attacks' in public"? Disclaimer: I'm far from an expert in the technical issues here. As far as I can tell Roy's note summarizes the known technical issues that were discussed in Holland. I (and I think others) have meta-concerns which are a lot harder to deal with. They relate to handling the unknown; folks seem to be discovering new techncial corner cases at some rate. Is this rate increasing or decreasing over time? If it isn't quickly decreasing then there is a significant risk that folks might discover a corner case which is a lot tricker to handle than the ones discovered so far. My personal feeling (see disclaimer above) is that the opt-in document describes the behavior of the server and what goes over the wire. But there isn't a detailed description of what a resolver (whether caching or not) needs to do to verify, cache, and correlate things that I can look at it and feel comfortable that folks have been looking for holes in such a description and found none. I don't know how hard it would be to produce such a description, and how useful it would be to the folks that understand this better. Erik -- to unsubscribe send a message to namedroppers-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 Jun 13 10:52:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15900 for ; Thu, 13 Jun 2002 10:52:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IVlE-00054N-00 for namedroppers-data@psg.com; Thu, 13 Jun 2002 07:39:40 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17IVl8-000546-00 for namedroppers@ops.ietf.org; Thu, 13 Jun 2002 07:39:34 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA28586; Thu, 13 Jun 2002 10:39:33 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA07652; Thu, 13 Jun 2002 10:39:29 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id KAA20365; Thu, 13 Jun 2002 10:39:28 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id KAA26757; Thu, 13 Jun 2002 10:39:26 -0400 Subject: RE: What are the opt-in issues From: Greg Hudson To: Erik Nordmark Cc: namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 13 Jun 2002 10:39:26 -0400 Message-Id: <1023979166.590.455.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,OPT_IN,RCVD_IN_RELAYS_ORDB_ORG version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2002-06-13 at 09:05, Erik Nordmark wrote: > I (and I think others) have meta-concerns which are a lot harder to deal with. > They relate to handling the unknown; folks seem to be discovering > new techncial corner cases at some rate. This can't be treated purely as a meta-issue. If I raised the question "How will opt-in affect the care and feeding of my dog?", then it wouldn't be appropriate for the ADs to use it as justification for worrying about opt-in. (Especially since I don't have a dog.) You have to actually look at the questions raised and ask whether they cast any significant doubt on opt-in. How opt-in affects AD-is-secure is a complete non-issue. Unsigned records in an opt-in zone aren't secure data, so AD=0. Nobody should be confused about this unless they havent't read the AD-is-secure draft recently, and those people aren't going to be helped by explicit statements, so there's nothing to worry about here. Roy also raised the question of whether a caching resolver might have to do weird, error-prone TTL calculations in order to cache one copy of a NXT record for both positive and negative replies. I don't think this is a significant issue because: * Any security issues it might raise would at worst be of the denial of service type, since TTLs do not affect the cryptographic authenticaticity of records. * It's quite easy for a cache to avoid this issue by not making the stated optimization. * I doubt that the required TTL calculations are any more complicated than they are for other sorts of answer synthesis. -- to unsubscribe send a message to namedroppers-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 Jun 13 11:01:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16282 for ; Thu, 13 Jun 2002 11:01:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IVxY-0005KU-00 for namedroppers-data@psg.com; Thu, 13 Jun 2002 07:52:24 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17IVxT-0005K2-00 for namedroppers@ops.ietf.org; Thu, 13 Jun 2002 07:52:20 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA24677; Thu, 13 Jun 2002 10:52:18 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA00794; Thu, 13 Jun 2002 10:50:00 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA16765; Thu, 13 Jun 2002 10:49:59 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id KAA26866; Thu, 13 Jun 2002 10:49:57 -0400 Subject: Re: IESG feedback on dnsext-ad-is-secure From: Greg Hudson To: Erik Nordmark Cc: namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 13 Jun 2002 10:49:57 -0400 Message-Id: <1023979797.590.460.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=-2.4 required=5.0 tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2002-06-13 at 08:43, Erik Nordmark wrote: > > > Uh, I'm not quite sure what you're saying here, but this statement makes > > me a little nervous. AD=1 means the back end has validated signatures, > > *and* all the required signatures were present and valid. AD=0 means > > the back end has not validated signatures, *or* the required signatures > > were absent or invalid. AD doesn't give you a way to determine if the > > back end is DNSSEC-aware or not, unless you happen to know of a record > > with a valid signature. > I've been assuming that 'some of the required signatures are invalid' > would mean that the data wouldn't be returned to the client. Er, yes, presumably, since that's what you see if someone tries to spoof a signed record. So I should have written: AD=0 means the back end has not validated signatures, *or* the required signatures were absent. Whether a recursive resolver should ever be forgiving with Bad data is perhaps a debatable question, but I don't think it has much to do with whether the AD bit is a good idea. The same problem exists even if we don't give any meaning to AD. -- to unsubscribe send a message to namedroppers-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 Jun 13 11:48:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18244 for ; Thu, 13 Jun 2002 11:48:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IWdP-0006Si-00 for namedroppers-data@psg.com; Thu, 13 Jun 2002 08:35:39 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17IWdL-0006SU-00 for namedroppers@ops.ietf.org; Thu, 13 Jun 2002 08:35:36 -0700 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id D0F311C60 for ; Thu, 13 Jun 2002 11:35:34 -0400 (EDT) Date: Thu, 13 Jun 2002 11:35:34 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-dns-tradeoffs-02.txt In-Reply-To: <200206131124.HAA07296@ietf.org> References: <200206131124.HAA07296@ietf.org> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: multipart/mixed; boundary="Multipart_Thu_Jun_13_11:35:34_2002-1" Message-Id: <20020613153534.D0F311C60@thrintun.hactrn.net> X-Spam-Status: No, hits=-9.4 required=5.0 tests=IN_REP_TO,UNIFIED_PATCH version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Multipart_Thu_Jun_13_11:35:34_2002-1 Content-Type: text/plain; charset=US-ASCII Non-cosmetic subset of the diffs since -01 attached for those who want to know what changed without having to read the whole document yet again. Thanks to Ed Lewis for proofreading -01. --Multipart_Thu_Jun_13_11:35:34_2002-1 Content-Type: text/plain; charset=US-ASCII --- draft-ietf-dnsext-ipv6-dns-tradeoffs.ms 2002/05/10 18:29:51 1.3 +++ draft-ietf-dnsext-ipv6-dns-tradeoffs.ms 2002/06/07 03:30:43 1.5 @@ -344,22 +344,22 @@ building the reverse mapping tree (the IPv6 equivalent of IPv4's IN-ADDR.ARPA tree). -[Tweedledee] proposes a mechanism very similar to the IN-ADDR.ARPA +[RFC1886] proposes a mechanism very similar to the IN-ADDR.ARPA mechanism used for IPv4 addresses: the RR name is the hexadecimal representation of the IPv6 address, reversed and concatenated with a well-known suffix, broken up with a dot between each hexadecimal digit. The resulting DNS names are somewhat tedious for humans to type, but are very easy for programs to generate. Making each hexadecimal digit a separate label means that delegation on arbitrary -bit boundaries will result in a maximum of 16 NS RRs per label; again, -the mechanism is somewhat tedious for humans, but is very easy to -program. As with IPv4's IN-ADDR.ARPA tree, the one place where this -scheme is weak is in handling delegations in the least significant -label; however, since there appears to be no real need to delegate the -least significant four bits of an IPv6 address, this does not appear -to be a serious restriction. +bit boundaries will result in a maximum of 16 NS RRsets per label +level; again, the mechanism is somewhat tedious for humans, but is +very easy to program. As with IPv4's IN-ADDR.ARPA tree, the one place +where this scheme is weak is in handling delegations in the least +significant label; however, since there appears to be no real need to +delegate the least significant four bits of an IPv6 address, this does +not appear to be a serious restriction. -[Tweedledum] proposed a radically different way of naming entries in +[RFC2874] proposed a radically different way of naming entries in the reverse mapping tree: rather than using textual representations of addresses, it proposes to use a new kind of DNS label (a "bit label") to represent binary addresses directly in the DNS. This has the @@ -520,6 +520,16 @@ Private message to the author from Bill Sommerfeld dated 21 March 2001, summarizing the result of experiments he performed on a copy of the MIT.EDU zone. + +.ne 2 +.ti 3 +[GSE] +"GSE" was an evolution of the so-called "8+8" proposal discussed by +the IPng working group in 1996 and 1997. The GSE proposal itself was +written up as an Internet-Draft, which has long since expired. +Readers interested in the details and history of GSE should review the +IPng working group's mailing list archives and minutes from that +period. .in 6 .ti 0 --Multipart_Thu_Jun_13_11:35:34_2002-1-- -- to unsubscribe send a message to namedroppers-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 Jun 13 13:14:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22416 for ; Thu, 13 Jun 2002 13:14:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IY0X-0008MN-00 for namedroppers-data@psg.com; Thu, 13 Jun 2002 10:03:37 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 17IY0T-0008M9-00 for namedroppers@ops.ietf.org; Thu, 13 Jun 2002 10:03:33 -0700 From: Masataka Ohta Message-Id: <200206131652.BAA07981@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id BAA07981; Fri, 14 Jun 2002 01:52:32 +0900 Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-dns-tradeoffs-02.txt In-Reply-To: <20020613153534.D0F311C60@thrintun.hactrn.net> from Rob Austein at "Jun 13, 2002 11:35:34 am" To: Rob Austein Date: Fri, 14 Jun 2002 01:52:31 +0859 () CC: namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Rob Austein; > -[Tweedledum] proposed a radically different way of naming entries in > +[RFC2874] proposed a radically different way of naming entries in > the reverse mapping tree: rather than using textual representations of > addresses, it proposes to use a new kind of DNS label (a "bit label") > to represent binary addresses directly in the DNS. This has the > @@ -520,6 +520,16 @@ > Private message to the author from Bill Sommerfeld dated 21 March > 2001, summarizing the result of experiments he performed on a copy of > the MIT.EDU zone. > + > +.ne 2 > +.ti 3 > +[GSE] > +"GSE" was an evolution of the so-called "8+8" proposal discussed by > +the IPng working group in 1996 and 1997. The GSE proposal itself was > +written up as an Internet-Draft, which has long since expired. > +Readers interested in the details and history of GSE should review the > +IPng working group's mailing list archives and minutes from that > +period. GSE has nothing to do with the so-called "8+8" proposal ignoring all the important points discussed in BigI or IPng ML and is a complete nonsense. Readers interested in the details and history of GSE should learn to ignore it. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 13 13:17:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22475 for ; Thu, 13 Jun 2002 13:17:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IY7B-0008W9-00 for namedroppers-data@psg.com; Thu, 13 Jun 2002 10:10:29 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17IY76-0008VW-00 for namedroppers@ops.ietf.org; Thu, 13 Jun 2002 10:10:24 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 141572 for namedroppers@ops.ietf.org; Thu, 13 Jun 2002 12:08:23 -0500 Message-ID: <3D08D1FD.3060802@ehsco.com> Date: Thu, 13 Jun 2002 12:10:21 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 CC: namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure References: <20020611161857.8B8EA1BFA@thrintun.hactrn.net> <20020611154927.F0C4528B6C@as.vix.com> <18498.1023863843@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/12/2002 1:37 AM Robert Elz wrote: > Note that the back end resolver (the one that received Rd=1, has RA=1, > and actually sets the AD bit) has no method to know what kind of > resolver is talking to it - it doesn't know whether the back end trusts > it or not (it may know that it is going to use TSIG to communicate with > its client, but presence of TSIG does not guarantee trust, nor does its > absence prohibit it), so it just sets the AD bit (or doesn't) on all > queries it processes, regardless of whether the value will end up being > used or not. First a disclaimer that I haven't fully internalized all of the DNSSEC stuff so this has the potential to be a really stupid question. It seems to me that there are a couple of problems that can be solved by providing a way for the stub resolver to indicate whether or not the calling application and/or the stub resolver is going to perform validation, at which point there is only a question of how this desire should be signalled. I would think that using a flag in a psuedo OPT RR would handle this nicely. On the one hand this tells the back-end resolver what kind of data it needs to return (if the calling application or stub resolver is opaque about DNSSEC then it only has to return the normal stuff). Secondarily, the use of the OPT RR tells the back-end resolver that the stub resolver is capable of accepting large messages containing all of the crap that the stub and/or application needs. Would this work? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-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 Jun 14 03:10:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21872 for ; Fri, 14 Jun 2002 03:10:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IkvX-00095d-00 for namedroppers-data@psg.com; Thu, 13 Jun 2002 23:51:19 -0700 Received: from [202.28.96.5] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17IkvN-00094k-00 for namedroppers@ops.ietf.org; Thu, 13 Jun 2002 23:51:11 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5E6ovM16825 for ; Fri, 14 Jun 2002 13:50:57 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5E6d5202554 for ; Fri, 14 Jun 2002 13:39:06 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jun 2002 13:39:05 +0700 Message-ID: <2552.1024036745@munnari.OZ.AU> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 13 Jun 2002 14:43:48 +0200 (CEST) From: Erik Nordmark Message-ID: | I've been assuming that 'some of the required signatures are invalid' | would mean that the data wouldn't be returned to the client. Maybe it does, but I would certainly hope that's not the expected interpretation (by default). That is, back end resolvers should (CD bit interpretation excepted) always return answers to clients. If the resolver has some way of determining that the data is "bad" (including signature verification failing) then it can certainly not "retain" the data (and most probably should not) - that is, it should not cache it to give to some other unsuspecting client later, as doing so would mean that it would have no chance of fetching correct data until the TTL has expired (and that might be a very long time sometimes - servers aren't required to place upper bounds on TTLs they will accept). But not returning data to the client means the client has no way of figuring out what is going on - it can't tell the difference between "I got an answer for you, but I didn't like the smell of it" from "I never saw your query in the first place, sorry". The right thing to do is to send the answer to the client, certainly not indicating that the answer is trustworthy in any way at all, and allow the client to decide what to do. Then we get to Ed Lewis' comments ... 1) Name servers are already instructed to return only valid answers (unless the CD bit was set on query) OK, let's assume that we drop AD because if we care about what its value would be, we will just leave CD clear, and if AD would have been 0 in the reply, then the reply will never be sent anyway (or won't contain any answers anyway). Then let's assume that the back end resolver has never heard of DNSSEC or SIG validation, or CD bits (or AD bits). It will go out, discover the answer, not even attempt to validate it, and return the answer to the stub resolver. Now, if you're one of Rob Austein's "smarter" resolvers, this is fine, you just go do the SIG validation yourself, and all is OK (or not). But if you're not, and there's no AD bit, how do you distinguish this case from the one where the back end resolver is up to date, and did the SIG validation for you, and all was OK? Note that it is possible that the link between stub and back end is using TSIG, and absolutely trusts the back end, in both of those cases. The rest of Ed's concerns seem to boil down to 2) what does it mean for the back end to be trusted? His points 2 and 2a were both relevant to that. Certainly that's an important question, but it isn't one that can be solved at this level. The only solution to doubts at this level amounts to requiring all stub resolvers, and everyone else, to do their own security checking. And while from a very strict security viewpoint, that's probably the best solution, it is also totally unrealistic. 3) seems to forget the case where the nameserver never heard of signatures, and so returned AD=0 simply because it was one of the MBZ bits... 4) I don't follow at all. Maybe I'm missing something, as I was never at one of the DNSSEC workshops, but how on earth is logging at the server (back end resolver I assume you mean) going to possibly provide any information at all to the stub resolver? Nor can I imagine how anyone could ever have believed that a bit in the packet would be useful as a debugging tool for anyone, surely that was never why it was created? 5) What does the stub resolver do? Whatever it likes - if for some reason it wants a verified answer, and doesn't get one, then simply ignoring the answer would seem to be right, just treat it as if no answer had ever been received. Typically that is going to cause it to go on to the next back end resolver in its config list (even the dumbest stub resolvers need to be able to handle more than one back end - just in case the one they usually use is down when it is needed). The response with AD==0 might trigger a quicker retry than waiting upon a timeout. Back to Erik again ... | My concern is that it seems really broken if the client can't easily | tell the difference between Insecure and Bad. That's what it seems that AD (with CD) allows to happen. If the client sent to a security aware back end, then it won't get an answer back, so it isn't going to get known bad data. If the back end didn't know about DNSSEC, then the answer will have AD==0, and so the client will know it is insecure - may be bad, or might not be (most probably will be OK, just as are all DNS answers now). | So what should a recursive resolver do whith Bad data? Send it back (unless the client has expressly said not to) and then throw it away. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 14 09:50:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29475 for ; Fri, 14 Jun 2002 09:50:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IrF3-000HHa-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 06:35:53 -0700 Received: from rs1.arin.net ([192.149.252.21]) by psg.com with esmtp (Exim 3.36 #1) id 17IrF0-000HHN-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 06:35:50 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id JAA12667; Fri, 14 Jun 2002 09:35:45 -0400 (EDT) Received: from [192.149.252.173] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA02877; Fri, 14 Jun 2002 09:35:44 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <2552.1024036745@munnari.OZ.AU> References: <2552.1024036745@munnari.OZ.AU> Date: Fri, 14 Jun 2002 09:34:20 -0400 To: Robert Elz , namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: IESG feedback on dnsext-ad-is-secure Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 1:39 PM +0700 6/14/02, Robert Elz wrote: >Then we get to Ed Lewis' comments ... Hmmm[0], okay, so you are saying the AD bit could be useful in the case in which the stub resolver doesn't know if the back end is "old code", "new code without keys", or "new code with keys". In this case, perhaps the bit should be a sign that the back end is doing 'DNSSEC' or not. (But this still leaves open the possibility that a "new code with keys" server has incorrect keys in it.) In any case, I feel that it should be up to the configuration process to only admit servers (eg to /etc/resolv.conf) that are known/detected to be properly configured to return satisfactory answers. A sneaking suspicion of mine is that building a "stub resolver hunting for a better answer" feature really gets us away from the spirit of the DNS protocol. (Sneaking suspicions are always open to debate.) >4) I don't follow at all. Maybe I'm missing something, as I was never >at one of the DNSSEC workshops, but how on earth is logging at the server >(back end resolver I assume you mean) going to possibly provide any >information at all to the stub resolver? Nor can I imagine how anyone >could ever have believed that a bit in the packet would be useful as >a debugging tool for anyone, surely that was never why it was created? I should clarify. The AD bit, showing up in dig was examined not for the benefit of the stub resolver, but to see if the back end did its job. This is why the logging is a suitable replacement. The AD bit wasn't intended for debugging, but that has become the bit's only use - and was the impetus for the new definition. [0] - As in, ah, I see your point. I hadn't really thought that case through. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-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 Jun 14 11:02:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02338 for ; Fri, 14 Jun 2002 11:02:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IsQI-000JB7-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 07:51:34 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17IsQF-000JAr-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 07:51:31 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.04) id 17IsQE-000CA9-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 07:51:30 -0700 Message-Id: <200206141129.HAA24769@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hardie-out-rr-00.txt Date: Fri, 14 Jun 2002 07:29:41 -0400 X-Spam-Status: No, hits=0.8 required=5.0 tests=NO_REAL_NAME,TO_MALFORMED,EXCUSE_6 version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A DNS RR for Pointers to RRs outside class IN Author(s) : T. Hardie Filename : draft-hardie-out-rr-00.txt Pages : Date : 13-Jun-02 The Domain Name System is a global distributed lookup system with delegation. In the original specification of the DNS [RFC 1035], CLASSes were described as parallel data structures within a single namespace but with potentially different delegations of authority. [BCP 42] defines a different vision, in which different CLASSes represent fundamentally different namespaces. Though [BCP 42] includes procedures for assignment of CLASSes, there has been little use of this axis of extensibility; in practice, CLASS IN is the only widely deployed CLASS in the DNS. The ubiquity of CLASS IN for name to IP address mapping has caused a vicious cycle in which extensions are placed within that CLASS to take advantage of its global deployment, with each addition further increasing its gravitational attraction. This document describes a Resource Record for use within CLASS IN that contains a pointer to a CLASS outside of IN. This mechanism is intended to allow administrators to indicate that a named resource identified within CLASS IN is also present in a different namespace, potentially under a different name. This cross-class pointer will allow the DNS to handle new namespaces with mechanisms appropriate to those namespaces while providing a connection to the globally deployed CLASS IN namespace. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hardie-out-rr-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-hardie-out-rr-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-hardie-out-rr-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: <20020613142901.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hardie-out-rr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hardie-out-rr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020613142901.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 Jun 14 11:32:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03697 for ; Fri, 14 Jun 2002 11:32:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IsvC-000JlG-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 08:23:30 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17Isv9-000Jl0-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 08:23:27 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17Isv9-000E4y-00; Fri, 14 Jun 2002 08:23:27 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Edward Lewis Cc: Robert Elz , namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure References: <2552.1024036745@munnari.OZ.AU> Message-Id: Date: Fri, 14 Jun 2002 08:23:27 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Hmmm[0], okay, so you are saying the AD bit could be useful in the > case in which the stub resolver doesn't know if the back end is "old > code", "new code without keys", or "new code with keys". In this > case, perhaps the bit should be a sign that the back end is doing > 'DNSSEC' or not. (But this still leaves open the possibility that a > "new code with keys" server has incorrect keys in it.) and what will they do with that knowledge? > In any case, I feel that it should be up to the configuration process > to only admit servers (eg to /etc/resolv.conf) that are > known/detected to be properly configured to return satisfactory > answers. this is really the only decision point a stub has today. and it does not have the information necessary to make the decision. randy -- to unsubscribe send a message to namedroppers-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 Jun 14 11:43:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03931 for ; Fri, 14 Jun 2002 11:43:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17It88-000Jzd-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 08:36:52 -0700 Received: from [202.28.96.5] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17It82-000Jz3-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 08:36:49 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5EFacM07935; Fri, 14 Jun 2002 22:36:39 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5EFaQ209980; Fri, 14 Jun 2002 22:36:29 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: References: <2552.1024036745@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jun 2002 22:36:26 +0700 Message-ID: <9978.1024068986@munnari.OZ.AU> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 14 Jun 2002 09:34:20 -0400 From: Edward Lewis Message-ID: | In any case, I feel that it should be up to the configuration process | to only admit servers (eg to /etc/resolv.conf) that are | known/detected to be properly configured to return satisfactory | answers. Like I turn up to an IETF meeting and my laptop somehow (how?) determines that the DNS back ends that the DHCP server tells me to use are inappropriate, and throws them away? How? And what does it replace them with? And worse, how does all this work with the still yet to be determined IPv6 stateless DNS back end discovery algorithm? Especially if the "just use an anycast address" advocates manage to get their way. How can one possibly tell if the server that will happen to respond to a particular anycast address right now is one of the "properly configured" ones or not? | I should clarify. The AD bit, showing up in dig was examined not for | the benefit of the stub resolver, but to see if the back end did its | job. Ah, OK, yes, I certainly agree that if that turned out to be the only possible use of the thing, then deleting it would be the right thing to do (and that would be true, even if logging hadn't improved...) kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 14 11:58:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04346 for ; Fri, 14 Jun 2002 11:58:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ItLo-000KGC-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 08:51:00 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17ItLj-000KG0-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 08:50:55 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA09766; Fri, 14 Jun 2002 11:50:54 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA02097; Fri, 14 Jun 2002 11:50:53 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id LAA29360; Fri, 14 Jun 2002 11:50:52 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id LAA02219; Fri, 14 Jun 2002 11:50:50 -0400 Subject: Re: IESG feedback on dnsext-ad-is-secure From: Greg Hudson To: Robert Elz Cc: namedroppers@ops.ietf.org In-Reply-To: <2552.1024036745@munnari.OZ.AU> References: <2552.1024036745@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 14 Jun 2002 11:50:50 -0400 Message-Id: <1024069850.29470.7.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2002-06-14 at 02:39, Robert Elz wrote: > | I've been assuming that 'some of the required signatures are invalid' > | would mean that the data wouldn't be returned to the client. > Maybe it does, but I would certainly hope that's not the expected > interpretation (by default). It has to be, or the major benefit of DNSSEC is lost. If caches will return signed-but-invalid data to stub resolvers, then attackers will be able to spoof signed records, and only the people who do SIG checking in their stub resolvers will be immune. > The right thing to do is to send the answer to the client, certainly > not indicating that the answer is trustworthy in any way at all, and > allow the client to decide what to do. In practice, stub resolvers do not "decide what to do" with answers from the recursive resolver; they just take them. Even if stub resolvers were to get smarter, they don't have any information to make this decision; without or without AD-is-secure, they can't distinguish between an invalid signed record and an unsigned record. And nobody is going to configure their stub resolver to reject all unsigned records any time soon. Of course, as long as stub resolvers remain too stupid to at least use TSIG, people can attack the path between the stub resolver and the caching resolver. But that path might be behind a firewall or within a single machine, rendering it more difficult or impossible to attack. -- to unsubscribe send a message to namedroppers-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 Jun 14 12:08:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04623 for ; Fri, 14 Jun 2002 12:08:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ItTW-000KQ5-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 08:58:58 -0700 Received: from rs1.arin.net ([192.149.252.21]) by psg.com with esmtp (Exim 3.36 #1) id 17ItTS-000KPt-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 08:58:55 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id LAA20007; Fri, 14 Jun 2002 11:58:53 -0400 (EDT) Received: from [192.149.252.173] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA06383; Fri, 14 Jun 2002 11:58:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <9978.1024068986@munnari.OZ.AU> References: <2552.1024036745@munnari.OZ.AU> <9978.1024068986@munnari.OZ.AU> Date: Fri, 14 Jun 2002 11:56:56 -0400 To: Robert Elz , Edward Lewis From: Edward Lewis Subject: Re: IESG feedback on dnsext-ad-is-secure Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:36 PM +0700 6/14/02, Robert Elz wrote: >Like I turn up to an IETF meeting and my laptop somehow (how?) >determines that the DNS back ends that the DHCP server tells me to >use are inappropriate, and throws them away? > >How? And what does it replace them with? How - that *is* the question! That's exactly why I am against the AD bit - it only lets you know that the back end followed local policy, but there's no way to learn the local policy. For now, I would replace the DHCP-suggested back ends with the servers "back home" in my /etc/resolve.conf. Especially when I an testing TSIG protected activities. >How can one possibly tell if the server that will happen to respond to >a particular anycast address right now is one of the "properly configured" >ones or not? Bingo again! Before I'd agree with any statement about a back end's policy, I want to be able to retrieve the policy (eg trusted key set). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-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 Jun 14 13:13:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06817 for ; Fri, 14 Jun 2002 13:13:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IuQg-000LVV-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 10:00:06 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17IuQd-000LVG-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 10:00:03 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17IuQd-00052h-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 10:00:03 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) In-Reply-To: Message-Id: <81C11FBB-7FB7-11D6-9A23-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit Date: Fri, 14 Jun 2002 11:55:18 -0500 Subject: Re: IESG feedback on dnsext-ad-is-secure Cc: namedroppers@ops.ietf.org, Robert Elz To: Edward Lewis From: Ted Lemon X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] I must confess to being a bit surprised that anybody would even consider accepting an AD-is-secure bit from a name server with which their only relationship is that they saw its IP address in a DHCP packet. Of course not. You're going to run a local caching name server on your host that you know is configured the right way because you (or Microsoft, or Apple) configured it. If your objection is that there's no way in the protocol to ensure that this has been done, I think it's not a good real-world objection. In the real world, there are two classes of DNS users - those who consider it a black box, and those who care enough to mess with it. Neither of these is a customer for a way of representing the secure resolver's security policy in the wire protocol. The first group doesn't care - they want their vendor or sysadmin to set it up right, and if it's not set up right, they' ll find out when they're defrauded. The second group is going to administratively verify every part of their resolver system. Where is the third group that you're talking about that needs a verification system that operates in the wire protocol? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 14 13:16:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06943 for ; Fri, 14 Jun 2002 13:16:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IuaS-000LhE-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 10:10:12 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17IuaH-000LgX-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 10:10:01 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17IuaH-0009dZ-00; Fri, 14 Jun 2002 10:10:01 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ted Lemon Cc: namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure References: <81C11FBB-7FB7-11D6-9A23-00039367340A@nominum.com> Message-Id: Date: Fri, 14 Jun 2002 10:10:01 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I must confess to being a bit surprised that anybody would even > consider accepting an AD-is-secure bit from a name server with > which their only relationship is that they saw its IP address in > a DHCP packet. "accepting an AD-is-secure bit" is a bit difficult, as there is no way or suggestion of what to do with the bit. it is defined, but there is no current way to pass it up through an API to an app, and no guidance on what an app might do with that information if we ever got it there. i have visions of yet another ignored indicator icon in the status line of one's fave browser. and, for the vast majority of hosts, getting the address of the dns server(s) to use via dhcp is the way of life. and your implication is right, dhcp is not known for its security. > Of course not. You're going to run a local caching name server > on your host that you know is configured the right way because > you (or Microsoft, or Apple) configured it. does my win98 machine have a local caching nameserver? [i mean the question seriously] i know macs now have freebsd under them (yes!), so it really could be a validating cacher underneath in that case. randy -- to unsubscribe send a message to namedroppers-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 Jun 14 13:21:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07088 for ; Fri, 14 Jun 2002 13:21:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IueZ-000Lml-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 10:14:27 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17IueW-000LmY-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 10:14:24 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 501A528ED7 for ; Fri, 14 Jun 2002 10:14:23 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: Message from Greg Hudson of "14 Jun 2002 11:50:50 EDT." <1024069850.29470.7.camel@error-messages.mit.edu> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Fri, 14 Jun 2002 10:14:23 -0700 Message-Id: <20020614171423.501A528ED7@as.vix.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > | I've been assuming that 'some of the required signatures are invalid' > > | would mean that the data wouldn't be returned to the client. > > > Maybe it does, but I would certainly hope that's not the expected > > interpretation (by default). > > It has to be, or the major benefit of DNSSEC is lost. [...] So, six++ years into the experiment, we still don't agree on what problem DNSSEC is supposed to solve, and what the underlying security model will be? -- to unsubscribe send a message to namedroppers-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 Jun 14 13:36:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07515 for ; Fri, 14 Jun 2002 13:36:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IusK-000M5h-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 10:28:40 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17IusH-000M5W-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 10:28:37 -0700 Received: by shell.nominum.com (Postfix, from userid 11089) id C233731920; Fri, 14 Jun 2002 10:28:36 -0700 (PDT) Date: Fri, 14 Jun 2002 10:28:36 -0700 From: Ted Hardie To: namedroppers@ops.ietf.org Subject: [Internet-Drafts@ietf.org: I-D ACTION:draft-hardie-out-rr-00.txt] Message-ID: <20020614102836.D50086@shell.nominum.com> Reply-To: Ted.Hardie@nominum.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Spam-Status: No, hits=-0.1 required=5.0 tests=EXCUSE_6 version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Howdy, I would appreciate comments on the document referenced below, either to me or to the list. As you'll note in the abstract, it describes a proposed RR that acts as a cross-class pointer, gives some use cases, and proposes some limitations to its use. best regards, Ted Hardie ----- Forwarded message from Internet-Drafts@ietf.org ----- To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hardie-out-rr-00.txt Date: Fri, 14 Jun 2002 07:29:41 -0400 X-Sorted: Bulk A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A DNS RR for Pointers to RRs outside class IN Author(s) : T. Hardie Filename : draft-hardie-out-rr-00.txt Pages : Date : 13-Jun-02 The Domain Name System is a global distributed lookup system with delegation. In the original specification of the DNS [RFC 1035], CLASSes were described as parallel data structures within a single namespace but with potentially different delegations of authority. [BCP 42] defines a different vision, in which different CLASSes represent fundamentally different namespaces. Though [BCP 42] includes procedures for assignment of CLASSes, there has been little use of this axis of extensibility; in practice, CLASS IN is the only widely deployed CLASS in the DNS. The ubiquity of CLASS IN for name to IP address mapping has caused a vicious cycle in which extensions are placed within that CLASS to take advantage of its global deployment, with each addition further increasing its gravitational attraction. This document describes a Resource Record for use within CLASS IN that contains a pointer to a CLASS outside of IN. This mechanism is intended to allow administrators to indicate that a named resource identified within CLASS IN is also present in a different namespace, potentially under a different name. This cross-class pointer will allow the DNS to handle new namespaces with mechanisms appropriate to those namespaces while providing a connection to the globally deployed CLASS IN namespace. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hardie-out-rr-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-hardie-out-rr-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-hardie-out-rr-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. ----- End forwarded message ----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 14 13:39:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07660 for ; Fri, 14 Jun 2002 13:39:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Iuu5-000M9o-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 10:30:29 -0700 Received: from [202.28.96.5] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17Iuts-000M8x-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 10:30:16 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5EHU9M11232; Sat, 15 Jun 2002 00:30:09 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5EHU4213898; Sat, 15 Jun 2002 00:30:05 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Ted Lemon cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: <81C11FBB-7FB7-11D6-9A23-00039367340A@nominum.com> References: <81C11FBB-7FB7-11D6-9A23-00039367340A@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Jun 2002 00:30:04 +0700 Message-ID: <13896.1024075804@munnari.OZ.AU> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 14 Jun 2002 11:55:18 -0500 From: Ted Lemon Message-ID: <81C11FBB-7FB7-11D6-9A23-00039367340A@nominum.com> | You're going to run a local caching name server on your host that | you know is configured the right way because you (or Microsoft, or Apple) | configured it. You're thinking about the wrong kind of host. Sure I could (but as it happens, mostly don't) do that with PC/mac class systems, but am I really going to be running a caching resolver in my mobile (cell) phone? Or in my wristwatch for when it looks up the address of its NTP server? Or in my light bulb for when it verifies the identity of the switch? These are the kinds of things that really want to use stub resolvers. They might also want to know that the answers have been verified (at least that someone with whom they have some kind of relationship is claiming that they're verified). Code to do all of this lives in roms, and moderately large amounts of that are feasible, easily. A nameserver cache lives in ram, and that means power to keep it running all the time. That's not so easy. It is also only effective if the host is doing more than one lookup a week... kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 14 13:40:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07676 for ; Fri, 14 Jun 2002 13:40:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Iutv-000M9N-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 10:30:19 -0700 Received: from rs1.arin.net ([192.149.252.21]) by psg.com with esmtp (Exim 3.36 #1) id 17Iutr-000M90-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 10:30:16 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id NAA09478; Fri, 14 Jun 2002 13:26:49 -0400 (EDT) Received: from [192.149.252.173] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA17406; Fri, 14 Jun 2002 13:26:49 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <81C11FBB-7FB7-11D6-9A23-00039367340A@nominum.com> References: <81C11FBB-7FB7-11D6-9A23-00039367340A@nominum.com> Date: Fri, 14 Jun 2002 13:20:51 -0400 To: Ted Lemon , Edward Lewis From: Edward Lewis Subject: Re: IESG feedback on dnsext-ad-is-secure Cc: namedroppers@ops.ietf.org, Robert Elz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Assuming "you" is me (I'm in the To: field). I agree with Ted's assessment. One group won't care, the other will check themselves. This is in roughly in line with my objection to defining the AD bit (or bothering to redefine it). When I mention that the DNS protocol lacks the ability to transfer the "policy" of the server (keys), I am stating this as a reason why the AD bit is of dubious value. I am not advocating extending the DNS protocol to transfer policy. I should also say that in my arguements I have been trying to tie the reasons I object to the draft to technical issues (I understand). For this reason I have stayed away from stating "what users/applications will want" because I no expert there. I see that the DNS protocol lacked what I mentioned before and rationalized that "if I can't see your rules, I don't care whether you followed them." At 11:55 AM -0500 6/14/02, Ted Lemon wrote: >If your objection is that there's no way in the protocol to ensure that this >has been done, I think it's not a good real-world objection. I'm assuming that by the above you mean that the lacking a means to get the policy isn't a sufficient reason to kill the AD bit. You're right, it isn't. But it is one of the reasons why I dislike the AD bit. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-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 Jun 14 13:53:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08014 for ; Fri, 14 Jun 2002 13:53:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Iv9W-000MZU-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 10:46:26 -0700 Received: from [202.28.96.5] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17Iv9S-000MZF-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 10:46:22 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g5EHkHM11707 for ; Sat, 15 Jun 2002 00:46:17 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g5EHkD214511 for ; Sat, 15 Jun 2002 00:46:13 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: References: <81C11FBB-7FB7-11D6-9A23-00039367340A@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Jun 2002 00:46:13 +0700 Message-ID: <14509.1024076773@munnari.OZ.AU> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 14 Jun 2002 13:20:51 -0400 From: Edward Lewis Message-ID: | One group won't care, the other will check themselves. This translates into "if you aren't able to check, then you're not allowed to care". Certainly from a pure security viewpoint, where all that matters is perfect validation, that's not unreasonable. But almost no-one needs that - remember that all security is a trade off between the costs, and the benefits (as is almost everything else). It is perfectly acceptable for people (hosts, ...) to agree to permit some increased risk, in return for some lower cost. That's a tradeoff that everyone has to be permitted to make - and it is not acceptable to simply write off anyone unable to get absolute proof of correctness (nor to relegate them to "anything goes"). Eg: for many systems, simply trusting what the local resolver says (without requiring it to be on the same net, and probably without any special security measures) will be just fine. If that resolver has given me false information, then I know who to go and blame. That, or the answer has been spoofed, and if my net is even half way reasonably protected, I can usually limit the source of that spoofing to somewhere local (filtering inbound source addresses, etc). So, if there's spoofing, it is coming from somewhere local, and whoever is responsible, either for spoofing, or leaving a system open enough to allow it to be taken over, can be deal with. Similarly, if the DHCP server gives me a bogus address as to where I should query for my DNS answers. For many users, that level of security is all that is required. Don't demand that everyone have provably correct security, just because you have been focused on that kind of issue (perhaps for others who do need it) for so long, that everything else seems hopeless. By all means make sure the mechanisms are in place to allow good security for those who need it - but don't then simply ignore everything which isn't necessary in that perfect world. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 14 13:53:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08037 for ; Fri, 14 Jun 2002 13:53:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Iv6y-000MUU-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 10:43:48 -0700 Received: from h140.s251.netsol.com ([216.168.251.140] helo=twister.rgy.netsol.com) by psg.com with esmtp (Exim 3.36 #1) id 17Iv6v-000MUD-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 10:43:45 -0700 Received: from typhoon (unknown [10.131.128.57]) by twister.rgy.netsol.com (Postfix) with SMTP id 79DF93D261F for ; Fri, 14 Jun 2002 13:43:44 -0400 (EDT) Message-ID: <0fda01c213cb$07834f10$3980830a@typhoon> Reply-To: "Matt Larson" From: "Matt Larson" To: References: <81C11FBB-7FB7-11D6-9A23-00039367340A@nominum.com> Subject: Re: IESG feedback on dnsext-ad-is-secure Date: Fri, 14 Jun 2002 13:43:44 -0400 Organization: VeriSign Global Registry Services MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > "accepting an AD-is-secure bit" is a bit difficult, as there is no > way or suggestion of what to do with the bit. it is defined, but > there is no current way to pass it up through an API to an app, and > no guidance on what an app might do with that information if we > ever got it there. i have visions of yet another ignored indicator > icon in the status line of one's fave browser. What good is DNSSEC going to do for anyone if an answer's security status isn't conveyed to the user (in a manner appropriate to the particular application)? Why bother securing a zone at all if no applications do anything with it? > does my win98 machine have a local caching nameserver? [i mean the > question seriously] Nope. Only W2K Server or better. Matt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 14 14:03:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08329 for ; Fri, 14 Jun 2002 14:03:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IvHt-000Moo-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 10:55:05 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17IvHo-000MoC-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 10:55:00 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17IvHo-00059z-00; Fri, 14 Jun 2002 10:55:00 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure References: <1024069850.29470.7.camel@error-messages.mit.edu> <20020614171423.501A528ED7@as.vix.com> Message-Id: Date: Fri, 14 Jun 2002 10:55:00 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > So, six++ years into the experiment, we still don't agree on what problem > DNSSEC is supposed to solve, and what the underlying security model will > be? you may find draft-ietf-dnsext-dns-threats-01.txt useful in this regard randy -- to unsubscribe send a message to namedroppers-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 Jun 14 14:14:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08821 for ; Fri, 14 Jun 2002 14:14:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IvUC-000NCU-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 11:07:48 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17IvU9-000NCB-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 11:07:45 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA01928; Fri, 14 Jun 2002 14:01:58 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA20461; Fri, 14 Jun 2002 13:58:20 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id NAA17803; Fri, 14 Jun 2002 13:52:28 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id NAA02828; Fri, 14 Jun 2002 13:52:28 -0400 Subject: Re: IESG feedback on dnsext-ad-is-secure From: Greg Hudson To: Edward Lewis Cc: namedroppers@ops.ietf.org In-Reply-To: References: <81C11FBB-7FB7-11D6-9A23-00039367340A@nominum.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 14 Jun 2002 13:52:28 -0400 Message-Id: <1024077148.2223.21.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2002-06-14 at 13:20, Edward Lewis wrote: > I should also say that in my arguements I have been trying to tie the > reasons I object to the draft to technical issues (I understand). > For this reason I have stayed away from stating "what > users/applications will want" because I no expert there. I see that > the DNS protocol lacked what I mentioned before and rationalized that > "if I can't see your rules, I don't care whether you followed them." I take issue with your terminology. First, AD does not mean "I followed my rules." It means "this record is signed and valid." We have already seen some confusion on this point. Second, the phrase "local policy" only applies to the AD bit when data is being served from a zone file. For data retrieved from other DNS servers, the only relevant "local policy" is the preconfigured keys used by the caching resolver, and it is very confusing to refer to the preconfigured keys using the general term "local policy" when the AD-is-secure draft uses that phrase to mean something else. AD-is-secure applies to the case where you know enough about your recursive resolver to trust it, and want to know whether records you've asked for were signed or not. It has nothing to do with discovering information about a resolver you've just heard 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 Fri Jun 14 14:14:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08838 for ; Fri, 14 Jun 2002 14:14:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IvVt-000NG9-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 11:09:33 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17IvVq-000NFu-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 11:09:30 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA04288; Fri, 14 Jun 2002 14:09:29 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA21421; Fri, 14 Jun 2002 14:09:29 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA19470; Fri, 14 Jun 2002 14:05:33 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id OAA02924; Fri, 14 Jun 2002 14:05:32 -0400 Subject: Re: IESG feedback on dnsext-ad-is-secure From: Greg Hudson To: Matt Larson Cc: namedroppers@ops.ietf.org In-Reply-To: <0fda01c213cb$07834f10$3980830a@typhoon> References: <81C11FBB-7FB7-11D6-9A23-0003936734 0A@nominum.com> <0fda01c213cb$07834f10$3980830a@typhoon> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 14 Jun 2002 14:05:32 -0400 Message-Id: <1024077932.2222.34.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2002-06-14 at 13:43, Matt Larson wrote: > > "accepting an AD-is-secure bit" is a bit difficult, as there is no > > way or suggestion of what to do with the bit. it is defined, but > > there is no current way to pass it up through an API to an app I don't think this is true; Jakob Schlyter mentioned the getrrsetbyname() API a few days ago. > What good is DNSSEC going to do for anyone if an answer's security > status isn't conveyed to the user (in a manner appropriate to the > particular application)? Why bother securing a zone at all if no > applications do anything with it? The major benefit of DNSSEC is: signed records cannot be spoofed to resolvers who do verification. In order to realize that benefit, the resolver which performs verification has to throw out records which fail verification, but pass through records which can be verified to be unsigned. But applications don't have to do anything special. Paul Vixie wrote: > So, six++ years into the experiment, we still don't agree on what > problem DNSSEC is supposed to solve, and what the underlying security > model will be? Evidently not. (Which doesn't mean the model isn't well-documented.) -- to unsubscribe send a message to namedroppers-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 Jun 14 14:14:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08881 for ; Fri, 14 Jun 2002 14:14:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IvVf-000NFZ-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 11:09:19 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17IvVc-000NFL-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 11:09:16 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 0201528B6C for ; Fri, 14 Jun 2002 11:09:16 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: Message from Randy Bush of "Fri, 14 Jun 2002 10:55:00 PDT." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Fri, 14 Jun 2002 11:09:15 -0700 Message-Id: <20020614180916.0201528B6C@as.vix.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > So, six++ years into the experiment, we still don't agree on what problem > > DNSSEC is supposed to solve, and what the underlying security model will > > be? > > you may find draft-ietf-dnsext-dns-threats-01.txt useful in this regard i don't. because there's no way to point the debaters on the AD thread to it and say "if you don't like the security model, propose changes to the language of that draft, otherwise shut up and let the ad-is-secure thing go through, because it's a finishing touch to the model we've all previously adopted." -- to unsubscribe send a message to namedroppers-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 Jun 14 14:17:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09037 for ; Fri, 14 Jun 2002 14:17:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IvXr-000NLW-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 11:11:35 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17IvXo-000NLK-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 11:11:32 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17IvXo-00074X-00; Fri, 14 Jun 2002 11:11:32 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Matt Larson" Cc: Subject: Re: IESG feedback on dnsext-ad-is-secure References: <81C11FBB-7FB7-11D6-9A23-00039367340A@nominum.com> <0fda01c213cb$07834f10$3980830a@typhoon> Message-Id: Date: Fri, 14 Jun 2002 11:11:32 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> "accepting an AD-is-secure bit" is a bit difficult, as there is no >> way or suggestion of what to do with the bit. it is defined, but >> there is no current way to pass it up through an API to an app, and >> no guidance on what an app might do with that information if we >> ever got it there. i have visions of yet another ignored indicator >> icon in the status line of one's fave browser. > What good is DNSSEC going to do for anyone if an answer's security > status isn't conveyed to the user (in a manner appropriate to the > particular application)? while i agree, i fear a very long security discussion of flavors of secure and what an app would think about them. [ i prefer mocha ] > Why bother securing a zone at all if no applications do anything with it? warm fuzzies when most of the dns data have been signed? i can sign my part of the tree, but i can not force you to validate the signatures. so this may be a long-term game. i suspect this is why some folk focus on how things will act/scale when most of the data are signed some years out. randy -- to unsubscribe send a message to namedroppers-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 Jun 14 14:29:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09479 for ; Fri, 14 Jun 2002 14:29:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IvjP-000Njf-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 11:23:31 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17IvjL-000NjP-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 11:23:27 -0700 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id A03311C60 for ; Fri, 14 Jun 2002 14:23:26 -0400 (EDT) Date: Fri, 14 Jun 2002 14:23:26 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: <13896.1024075804@munnari.OZ.AU> References: <81C11FBB-7FB7-11D6-9A23-00039367340A@nominum.com> <13896.1024075804@munnari.OZ.AU> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020614182326.A03311C60@thrintun.hactrn.net> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Sat, 15 Jun 2002 00:30:04 +0700, Robert Elz wrote: > > You're thinking about the wrong kind of host. Sure I could (but as it > happens, mostly don't) do that with PC/mac class systems, but am I > really going to be running a caching resolver in my mobile (cell) phone? > Or in my wristwatch for when it looks up the address of its NTP server? > Or in my light bulb for when it verifies the identity of the switch? Yes, if doing so is the least painful way to accomplish the task for which the device in question was created using security services appropriate for the task at hand (I'm dubious about DNS-using light switches, but let that pass). > These are the kinds of things that really want to use stub resolvers. > They might also want to know that the answers have been verified (at > least that someone with whom they have some kind of relationship is > claiming that they're verified). If they're part of an environment with stable and well-understood trust relationships, I agree. A light switch might fit this model. I doubt that a wrist watch or cell phone fits. > Code to do all of this lives in roms, and moderately large amounts of > that are feasible, easily. A nameserver cache lives in ram, and that > means power to keep it running all the time. That's not so easy. It is > also only effective if the host is doing more than one lookup a week... Please see the previous discussion of caching recursive almost-stubs. Long term caching is a service that the environment can provide. The device itself may only need to cache a small number of records, may only need to do so for a fairly short period of time, or may be able to tolerate a brief interval of less than complete functionality when first powering up. With all due respect, I think that this whole caching issue is largely orthogonal to the security model discussion, and the latter is, I think, the discussion that the WG really needs to have. -- to unsubscribe send a message to namedroppers-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 Jun 14 14:38:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09922 for ; Fri, 14 Jun 2002 14:38:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IvoW-000Nvc-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 11:28:48 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17IvoT-000NvO-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 11:28:45 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 141807 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 13:26:41 -0500 Message-ID: <3D0A35D6.7080200@ehsco.com> Date: Fri, 14 Jun 2002 13:28:38 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure References: <81C11FBB-7FB7-11D6-9A23-00039367340A@nominum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [sorry for the dupe if you get one] on 6/14/2002 12:10 PM Randy Bush wrote: > does my win98 machine have a local caching nameserver? [i mean the > question seriously] i know macs now have freebsd under them (yes!), > so it really could be a validating cacher underneath in that case. winsock2 systems have per-process caches, meaning that a lookup will be cached for the TTL, but it doesn't have support for iterative queries The MacOS resolver in 8.5 actually has iterative support, but it still requires a local server to get the process started (if it only gets delegation information but no answer, then it will go ask the delegation target itself). I don't know what's in OS X but my guess would be that it is the typical braindead stub in all other UNIXes. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-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 Jun 14 14:39:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09974 for ; Fri, 14 Jun 2002 14:39:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ivqq-000O0B-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 11:31:12 -0700 Received: from rs1.arin.net ([192.149.252.21]) by psg.com with esmtp (Exim 3.36 #1) id 17Ivqn-000Nzu-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 11:31:09 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id OAA26258; Fri, 14 Jun 2002 14:31:08 -0400 (EDT) Received: from [192.149.252.173] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA28819; Fri, 14 Jun 2002 14:31:07 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <1024077148.2223.21.camel@error-messages.mit.edu> References: <81C11FBB-7FB7-11D6-9A23-00039367340A@nominum.com> <1024077148.2223.21.camel@error-messages.mit.edu> Date: Fri, 14 Jun 2002 14:31:04 -0400 To: Greg Hudson , Edward Lewis From: Edward Lewis Subject: Re: IESG feedback on dnsext-ad-is-secure Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 1:52 PM -0400 6/14/02, Greg Hudson wrote: >I take issue with your terminology. First, AD does not mean "I followed >my rules." It means "this record is signed and valid." ... For intance, look at RFC 3008: 1 - Introduction This document defines additional restrictions on DNSSEC signatures (SIG) records relating to their authority to sign associated data. The intent is to establish a standard policy followed by a secure resolver; this policy can be augmented by local rules. This builds upon [RFC2535], updating section 2.3.6 of that document. Note "local rules." Whenever any validation is done in DNS, it is subject to local rules. (This is a point of the DNSSEC protocol that is often overlooked.) Whether a record is signed is an objective statement. Whether the signature is valid is subjective. I am short handing trusted keys and local policy. The reason is that the trusted key set is the only part of local policy that has become concrete enough to use in an example. Expressing authorization rules (what key is trusted to sign what data) has not been attempted. >AD-is-secure applies to the case where you know enough about your >recursive resolver to trust it, and want to know whether records you've >asked for were signed or not. It has nothing to do with discovering >information about a resolver you've just heard of. If you trust the recursive resolver, then trust it to follow the protocol rules. No where in the protocol is a compliant recursive resolve allowed to send onward bad data - pending data than may be proven bad in a moment, but not bad data. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-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 Jun 14 14:49:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10298 for ; Fri, 14 Jun 2002 14:49:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IvuU-000O85-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 11:34:58 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17IvuS-000O7p-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 11:34:56 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17IvuR-000AjG-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 11:34:56 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit Date: Fri, 14 Jun 2002 13:31:24 -0500 Subject: Re: IESG feedback on dnsext-ad-is-secure Cc: namedroppers@ops.ietf.org To: Randy Bush From: Ted Lemon X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] > "accepting an AD-is-secure bit" is a bit difficult, as there is no > way or suggestion of what to do with the bit. it is defined, but > there is no current way to pass it up through an API to an app, and > no guidance on what an app might do with that information if we > ever got it there. i have visions of yet another ignored indicator > icon in the status line of one's fave browser. AFAIK, there isn't a standard that defines the resolver API, so this is a bit of a red herring. If an application cares about the AD-is-secure bit, it will find a way to use it. And I think it's plausible that an application might care about it - for example, I wouldn't mind a bit if my web browser were smart enough to stop me from sending a credit card number to a site the browser had reached in an insecure manner. It's too early in the life of secure DNS for this to happen now, but I think it's reasonable to say that secure DNS might be part of a security validation process like this in the future. > and, for the vast majority of hosts, getting the address of the dns > server(s) to use via dhcp is the way of life. and your implication > is right, dhcp is not known for its security. A host that implements AD-is-secure can't use the DNS server listed in the DHCP packet as its resolver - it's that simple. Even if DHCP were secure, that would still be true, because secure DHCP just means that you know which DHCP server you're talking to - it says nothing about the security policy at the site you happen to be connected to, as Ed has pointed out. > does my win98 machine have a local caching nameserver? [i mean the > question seriously] i know macs now have freebsd under them (yes!), > so it really could be a validating cacher underneath in that case. You can install a local caching nameserver on your Win98 machine, but by default it doesn't. We are talking about the future, here, though. If DNSSEC becomes something for which there is a market, Microsoft is neither stupid nor lazy - they will implement a secure DNS caching nameserver or something like it on Windows YO, or in .OFU (the next version of .NET). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 14 14:51:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10359 for ; Fri, 14 Jun 2002 14:51:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ivz9-000OGO-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 11:39:47 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17Ivz5-000OG8-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 11:39:43 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17Ivz5-000BAt-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 11:39:43 -0700 Message-Id: <4.2.0.58.20020614112538.0233dff8@127.0.0.1> In-Reply-To: <20020614102836.D50086@shell.nominum.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3762510==_.ALT" Date: Fri, 14 Jun 2002 11:35:42 -0700 To: Ted.Hardie@nominum.com, namedroppers@ops.ietf.org From: "Paul V. Mockapetris" Subject: Re: [Internet-Drafts@ietf.org: I-D ACTION:draft-hardie-out-rr-00.txt] X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,BIG_FONT version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --=====================_3762510==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] At 10:28 AM 6/14/2002 -0700, Ted Hardie wrote: >Howdy, > I would appreciate comments on the document referenced below, >either to me or to the list. As you'll note in the abstract, it >describes a proposed RR that acts as a cross-class pointer, gives some >use cases, and proposes some limitations to its use. > best regards, > Ted Hardie I talked to Ted after several drafts of this, but wanted to write down my thoughts on this. I was so taken by Ted's precompensating spin and finesse (to avoid IDN and other current DNS debates), I decided to use a style that has all of the finesse of Roger Clemens. --- I would rewrite the abstract/info/mission to say: The CLASS mechanism in the DNS was created to be a mechanism that added an additional dimension to the DNS database. In the original specification [RFC 1035] classes were parallel data structures with: - identical name spaces - potentially different delegations of authority - TYPE formats which could either be identical across all classes (class invariant) or different So that for example, we might have had the OSI class, and a host www.nominum.com might have a class IN format address of 10.0.0.1 in the IN class and its NSAP equivalent in the OSI class. The IETF could continue control of the IN class for as long as it was necessary for backward compatibility and the ITU might regulate the OSI class. BCP42 partially defines a different vision: - different classes having fundamentally different name spaces - the same view on delegation - the same view on TYPES(?) Given the need for new functions in the DNS, and given the fortunate absence of non-IN CLASS usage and hence the absence of compatibility issues, we propose a modest extension to the DNS called the cross-class pointer (CCPTR), and revisit once again the differences between classes of DNS data. The new RR is CCPTR Basically this RR is typically used to point from a location in the DNS database to a different location, where the classes are typically different. Multiple pointers may exist at the same name. This RR is meant to facilitate early research in multiple classes. But in reality, this is merely one small step toward defining a DNS class mechanism that could solve problems that are difficult to solve in the curent DNS. A partial cut at the issues =========================== We suggest the following: Classes MAY have different name spaces. This allows both the original type of usage envisioned in RFC 1035 and that seen in BCP42. TYPES continue to be defined as either class-invariant or class-independent. Delegations and control are class specific. Case insensitive behaviour and matching rules be defined to be class-sensitive. The IANA reserve CLASS.ARPA, where names such as 1.class.arpa and in.class.arpa would hold TXT or other RRs that define the behaviour of classes. (Note that there are some original requirements, such that TYPE and CLASS mnemonics be disjoint, which may need to be modified/restated). [Note that this assumes DNSSec could be ready to go to securely distribute the data. If this should not be the case a signed zone file would suffice] A new DNS WG DCLASS, WG will define the rules for multiple class behaviour and for the data stored in CLASS.ARPA, with the objective that the classes may be delegated, and that cryptographically-signed data at CLASS.ARPA would be sufficient to configure DNS servers, resolvers, and support software to operate in a new class. [Of course the correct steps for forming the WG would be a prelude] DCLASS will attempt for provide the diversity that might be required by DNSEXT, IDNA, et al. But the charter is to provide flexibility rather than a single set of rules compatible with the IN class. We recognize that behavior other than those announced above may need to be codified. For example - CNAMEs. ============================================================================ ================ I have various presentation suggestions for Ted's examples, but nothing major. --=====================_3762510==_.ALT Content-Type: text/html; charset="us-ascii" At 10:28 AM 6/14/2002 -0700, Ted Hardie wrote:
Howdy,
        I would appreciate comments on the document referenced below,
either to me or to the list.  As you'll note in the abstract, it
describes a proposed RR that acts as a cross-class pointer, gives some
use cases, and proposes some limitations to its use. 
                        best regards,
                                Ted Hardie


I talked to Ted after several drafts of this, but wanted to write down my thoughts on this.  I was so taken by Ted's precompensating spin and finesse (to avoid IDN and other current DNS debates), I decided to use a style that has all of the finesse of Roger Clemens.

---

I would rewrite the abstract/info/mission to say:

The CLASS mechanism in the DNS was created to be a mechanism that added an additional dimension to the DNS database.

In the original specification [RFC 1035] classes were parallel data structures with:
- identical name spaces
- potentially different delegations of authority
- TYPE formats which could either be identical across all classes (class invariant) or different

So that for example, we might have had the OSI class, and a host www.nominum.com might have a class IN format address of 10.0.0.1 in the IN class and its NSAP equivalent in the OSI class.  The IETF could continue control of the IN class for as long as it was necessary for backward compatibility and the ITU might regulate the OSI class.

BCP42 partially defines a different vision:

- different classes having fundamentally different name spaces
- the same view on delegation
- the same view on TYPES(?)

Given the need for new functions in the DNS, and given the fortunate absence of non-IN CLASS usage and hence the absence of compatibility issues, we propose a modest extension to the DNS called the cross-class pointer (CCPTR), and revisit once again the differences between classes of DNS data.

The new RR is

<name> <class> <TTL> CCPTR <other-class> <other-domain-name>

Basically this RR is typically used to point from a location in the DNS database to a different location, where the classes are typically different.  Multiple pointers may exist at the same name.

This RR is meant to facilitate early research in multiple classes.

But in reality, this is merely one small step toward defining a DNS class mechanism that could solve problems that are difficult to solve in the curent DNS.

A partial cut at the issues
===========================

We suggest the following:

Classes MAY have different name spaces.  This allows both the original type of usage envisioned in RFC 1035 and that seen in BCP42.

TYPES continue to be defined as either class-invariant or class-independent.

Delegations and control are class specific.

Case insensitive behaviour and matching rules be defined to be class-sensitive.

The IANA reserve CLASS.ARPA, where names such as 1.class.arpa and in.class.arpa
would hold TXT or other RRs that define the behaviour of classes.  (Note that there are some original requirements, such that TYPE and CLASS mnemonics be disjoint, which may need to be modified/restated).  [Note that this assumes DNSSec could be ready to go to securely distribute the data.  If this should not be the case a signed zone file would suffice]

A new DNS WG DCLASS, WG will define the rules for multiple class behaviour and for the data stored in CLASS.ARPA, with the objective that the classes may be delegated, and that cryptographically-signed data at CLASS.ARPA would be sufficient to configure DNS servers, resolvers, and support software to operate in a new class.  [Of course the correct steps for forming the WG would be a prelude]

DCLASS will attempt for provide the diversity that might be required by DNSEXT, IDNA, et al.  But the charter is to provide flexibility rather than a single set of rules compatible with the IN class.

We recognize that behavior other than those announced above may need to be codified.  For example - CNAMEs.

============================================================================================

I have various presentation suggestions for Ted's examples, but nothing major.
 --=====================_3762510==_.ALT-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 14 14:58:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10577 for ; Fri, 14 Jun 2002 14:58:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Iw78-000OTU-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 11:48:02 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17Iw75-000OTH-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 11:47:59 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17Iw75-000FiQ-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 11:47:59 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit Date: Fri, 14 Jun 2002 13:44:01 -0500 Subject: Re: IESG feedback on dnsext-ad-is-secure Cc: namedroppers@ops.ietf.org, Robert Elz To: Edward Lewis From: Ted Lemon X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] > I agree with Ted's assessment. One group won't care, the other will check > themselves. This is in roughly in line with my objection to defining the > AD bit (or bothering to redefine it). I think you missed part of my point, though. On some level, some system somewhere has to tell the application "I was able to validate this data," or "this data was not signed." I would say that there is no need for this system to be able to say "this data failed validation," because in that case it should just discard the data. Whether that validation is something that needs to be set in the protocol, with a bit, is something that I have to admit I am not qualified to say, but if applications use stub resolvers, it seems clear that it would be necessary. > I see that the DNS protocol lacked what I mentioned before and > rationalized that "if I can't see your rules, I don't care whether you > followed them." You have to be careful to identify who "I" is in this case. In the case of the black box user, "I" is not the user - it is the author of the application that the black box user trusts. And "your rules" are rules that are probably guaranteed by the operating system - this is why it's important whether there's a caching resolver on the system that's setting the ADis bit. If you are an under-the-hood kind of guy, then "I" is the user - you. And "your rules" are also the user's rules - your rules - because you set up the caching resolver that's doing the verification. So in both cases, *if* the application cares about ADis, and *if* the application isn't going to do the name resolution process itself, the ADis bit is useful. -- to unsubscribe send a message to namedroppers-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 Jun 14 15:03:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10932 for ; Fri, 14 Jun 2002 15:03:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17IwF3-000Ohp-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 11:56:13 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17IwF0-000Ohc-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 11:56:10 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17IwF0-000JLG-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 11:56:10 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) In-Reply-To: <13896.1024075804@munnari.OZ.AU> Message-Id: <97703914-7FC7-11D6-9A23-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit Date: Fri, 14 Jun 2002 13:50:26 -0500 Subject: Re: IESG feedback on dnsext-ad-is-secure Cc: namedroppers@ops.ietf.org, Edward Lewis To: Robert Elz From: Ted Lemon X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] > You're thinking about the wrong kind of host. Sure I could (but as it > happens, mostly don't) do that with PC/mac class systems, but am I > really going to be running a caching resolver in my mobile (cell) phone? > Or in my wristwatch for when it looks up the address of its NTP server? > Or in my light bulb for when it verifies the identity of the switch? If you can believe that there's going to be a network connection to your light bulb, I don't see why thinking that the light bulb will have a caching resolver is any more of a stretch. At this point the computer in my cell phone is a lot mobier than my first PC, and I'm quite sure I could have gotten a caching resolver running on my first PC if I'd cared to do so. > Code to do all of this lives in roms, and moderately large amounts of > that are feasible, easily. A nameserver cache lives in ram, and that > means power to keep it running all the time. That's not so easy. It is > also only effective if the host is doing more than one lookup a week... Then maybe this is a case where you don't need the ADis bit, because the application would just do the lookup and verify the signatures itself. -- to unsubscribe send a message to namedroppers-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 Jun 14 21:48:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21358 for ; Fri, 14 Jun 2002 21:48:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17J2Vb-0007Ur-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 18:37:43 -0700 Received: from adsl-63-196-7-183.dsl.snfc21.pacbell.net ([63.196.7.183] helo=blade.unixpeople.internal) by psg.com with esmtp (Exim 3.36 #1) id 17J2VY-0007Ue-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 18:37:40 -0700 Received: from unixpeople.com (quake.unixpeople.internal [192.168.37.210]) by blade.unixpeople.internal (8.12.2/8.12.2) with ESMTP id g5F1bboW010924 for ; Fri, 14 Jun 2002 18:37:38 -0700 (PDT) Message-ID: <3D0A9A7E.6090705@unixpeople.com> Date: Fri, 14 Jun 2002 18:38:06 -0700 From: "Andy W. Barclay" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: General comments on DNSSEC References: <20020612170111.92D431C81@thrintun.hactrn.net> <20020611161857.8B8EA1BFA@thrintun.hactrn.net> <20020611154927.F0C4528B6C@as.vix.com> <18498.1023863843@munnari.OZ.AU> <23480.1023963134@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit After reading draft-ietf-dnsext-dns-threats-01.txt, it has occurred to me that DNSSEC may be a waste of time. It seems that applications are capable of the same security that we can provide with DNSSEC. (I realize that if we could get a global deployment, we could increase security on legacy protocols). For example, the draft referenced above says: "The resulting list of desired security services was 1) data integrity, and 2) data origin authentication." Any application that uses certificates has those capabilities. Legacy applications that require security are being upgraded to support certificates/keys (ntp). Can someone convince me that DNSSEC still makes sense? (One argument that I won't buy into is that my phone/PIM or whatever doesn't have the horsepower to do certificates. By the time we get dnssec deployed, they will have that horsepower.) -- Regards, Andy W. Barclay. abarclay@unixpeople.com fax (781) 823-8276 Always a UNIX Evangelist (and sometimes a system and network architect) "Money, not morality, is the principle commerce of civilized nations" -- Thomas Jefferson -- to unsubscribe send a message to namedroppers-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 Jun 14 22:18:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21770 for ; Fri, 14 Jun 2002 22:18:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17J31W-0008LV-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 19:10:42 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17J31S-0008LC-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 19:10:38 -0700 Received: from drugs.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.12.3/8.12.3) with ESMTP id g5F2AZm0033389; Sat, 15 Jun 2002 12:10:35 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200206150210.g5F2AZm0033389@drugs.dv.isc.org> To: "Andy W. Barclay" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: General comments on DNSSEC In-reply-to: Your message of "Fri, 14 Jun 2002 18:38:06 MST." <3D0A9A7E.6090705@unixpeople.com> Date: Sat, 15 Jun 2002 12:10:35 +1000 X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > After reading draft-ietf-dnsext-dns-threats-01.txt, it has occurred to > me that DNSSEC may be a waste of time. > > It seems that applications are capable of the same security that we can > provide with DNSSEC. (I realize that if we could get a global > deployment, we could increase security on legacy protocols). > > For example, the draft referenced above says: > "The resulting list of desired security services was > 1) data integrity, and > 2) data origin authentication." > > Any application that uses certificates has those capabilities. Legacy > applications that require security are being upgraded to support > certificates/keys (ntp). > > Can someone convince me that DNSSEC still makes sense? > (One argument that I won't buy into is that my phone/PIM or whatever > doesn't have the horsepower to do certificates. By the time we get > dnssec deployed, they will have that horsepower.) > > -- > Regards, > Andy W. Barclay. abarclay@unixpeople.com > fax (781) 823-8276 > Always a UNIX Evangelist (and sometimes a system and network architect) > > "Money, not morality, is the principle commerce of > civilized nations" > -- Thomas Jefferson DNS is just another application trying to secure its own transactions using cryptography. You have no problem with NTP using cryptography to secure its transactions. What's your problem with DNS using cryptography to secure its transactions. Mark -- Mark Andrews, Internet Software Consortium 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 Jun 14 22:25:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21857 for ; Fri, 14 Jun 2002 22:25:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17J39K-0008Y2-00 for namedroppers-data@psg.com; Fri, 14 Jun 2002 19:18:46 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17J39G-0008Xp-00 for namedroppers@ops.ietf.org; Fri, 14 Jun 2002 19:18:43 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id WAA10476; Fri, 14 Jun 2002 22:18:41 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA07491; Fri, 14 Jun 2002 22:18:41 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id WAA05358; Fri, 14 Jun 2002 22:18:39 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id WAA05387; Fri, 14 Jun 2002 22:18:38 -0400 Subject: Re: General comments on DNSSEC From: Greg Hudson To: "Andy W. Barclay" Cc: namedroppers@ops.ietf.org In-Reply-To: <3D0A9A7E.6090705@unixpeople.com> References: <20020612170111.92D431C81@thrintun.hactrn.net> <20020611161857.8B8EA1BFA@thrintun.hactrn.net> <20020611154927.F0C4528B6C@as.vix.com> <18498.1023863843@munnari.OZ.AU> <23480.1023963134@munnari.OZ.AU> <3D0A9A7E.6090705@unixpeople.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 14 Jun 2002 22:18:38 -0400 Message-Id: <1024107518.29440.50.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The primary purpose of DNSSEC is to protect the DNS infrastructure, which is mostly name-to-address and address-to-name mappings, not to provide security for applications. There are those of us who wouldn't mind being able to use DNSSEC to protect application keys, perhaps because of a dislike of X.509 certificates or the certificate model in general, but that's a separate problem. You could argue that protecting infrastructure is pointless; that everyone should use secure application protocols instead. I wouldn't agree, though: Defense in depth is a fine thing. For instance, right now, if you want to attack www.amazon.com, you can simply spoof its DNS record to some set of clients to point to your own web server, which is a replica of www.amazon.com except it never uses SSL. The vast majority of users are unlikely to notice. You'll be detected eventually, but not before you steal some large number of credit card numbers and/or sales. With DNSSEC deployment to the www.amazon.com record and the resolvers of most users, this attack gets harder. You can't spoof the DNS record, so you have to hijack TCP connections or do something similarly difficult. -- to unsubscribe send a message to namedroppers-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 Jun 15 09:54:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08089 for ; Sat, 15 Jun 2002 09:54:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JDb5-000OeL-00 for namedroppers-data@psg.com; Sat, 15 Jun 2002 06:28:07 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17JDb1-000Oe3-00 for namedroppers@ops.ietf.org; Sat, 15 Jun 2002 06:28:03 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17JDb1-000Alt-00 for namedroppers@ops.ietf.org; Sat, 15 Jun 2002 06:28:03 -0700 References: <20020612170111.92D431C81@thrintun.hactrn.net> <20020611161857.8B8EA1BFA@thrintun.hactrn.net> <20020611154927.F0C4528B6C@as.vix.com> <18498.1023863843@munnari.OZ.AU> <23480.1023963134@munnari.OZ.AU> <3D0A9A7E.6090705@unixpeople.com> In-Reply-To: <3D0A9A7E.6090705@unixpeople.com> ("Andy W. Barclay"'s message of "Fri, 14 Jun 2002 18:38:06 -0700") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: "Andy W. Barclay" Cc: namedroppers@ops.ietf.org Subject: Re: General comments on DNSSEC From: Simon Josefsson Date: Sat, 15 Jun 2002 11:56:09 +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] "Andy W. Barclay" writes: > After reading draft-ietf-dnsext-dns-threats-01.txt, it has occurred to > me that DNSSEC may be a waste of time. > > It seems that applications are capable of the same security that we > can provide with DNSSEC. (I realize that if we could get a global > deployment, we could increase security on legacy protocols). > > For example, the draft referenced above says: > "The resulting list of desired security services was > 1) data integrity, and > 2) data origin authentication." > > Any application that uses certificates has those capabilities. Legacy > applications that require security are being upgraded to support > certificates/keys (ntp). > > Can someone convince me that DNSSEC still makes sense? One of the design goals with DNSSEC was to distribute keys used not only for securing the DNSSEC infrastructure, but also for use by applications in general. This is still not commonly implemented, but is IMHO the main feature of DNSSEC. The RFC 2535 abstract is refreshlingly clear about this being on of the goals: ,---- | The extensions provide for the storage of authenticated public keys | in the DNS. This storage of keys can support general public key | distribution services as well as DNS security. The stored keys | enable security aware resolvers to learn the authenticating key of | zones in addition to those for which they are initially configured. | Keys associated with DNS names can be retrieved to support other | protocols. Provision is made for a variety of key types and | algorithms. `---- -- to unsubscribe send a message to namedroppers-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 Jun 15 23:47:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19347 for ; Sat, 15 Jun 2002 23:47:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JQkV-0008ZC-00 for namedroppers-data@psg.com; Sat, 15 Jun 2002 20:30:43 -0700 Received: from rs1.arin.net ([192.149.252.21]) by psg.com with esmtp (Exim 3.36 #1) id 17JQkS-0008Z1-00 for namedroppers@ops.ietf.org; Sat, 15 Jun 2002 20:30:40 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id XAA08366 for ; Sat, 15 Jun 2002 23:30:39 -0400 (EDT) Received: from [208.58.216.115] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id XAA09673; Sat, 15 Jun 2002 23:30:34 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <97703914-7FC7-11D6-9A23-00039367340A@nominum.com> References: <97703914-7FC7-11D6-9A23-00039367340A@nominum.com> Date: Sat, 15 Jun 2002 23:30:29 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: IESG feedback on dnsext-ad-is-secure Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I should report on a meeting[0] of a pair of black helicopters near I-495[1]. Olafur pointed out to me that the purpose (perhaps one of many, but this was our discussion) of the AD bit is for applications to see that certain processing was performed on the answer. The AD bit is supposed to only be used when the "last hop" was secure, e.g., (e.g.!) TSIG-covered. While I began to feel a little guilty for holding this draft up given this discussion, I began to rethink recent discussions... Robert Elz pointed out that the AD bit could be used to determine if the resolver is capable of doing DNSSEC (and did DNSSEC). I can see this, but if the AD bit should only be consulted if the back end is reached in a trusted manner (TSIG/SIG(0)/or "whatever"), then just being able to establish a trusted message exchange should do the trick. I.e., if you went to the trouble to configure a secure association with a server, then you trust the server did its best to get the answer. My objection is still based upon the fact that the AD bit can mislead a resolver - given the case of bad keys at a trusted server (eg one I share a TSIG with). I don't think the AD bit adds much to the protocol[2] - a stub resolver could just tell an application that the answer came from a server it trusts. My intent is to state this misgiving of mine. If folks think I'm just being obstinate, then declare consensus despite my objection. It's not like I'll turn in my helicopter keys if the draft "passes." [0] Attendees: Olafur Gudmundsson (Helicopter call sign DNS Force One) and myself (call sing DNS 10738). Agenda: How he was doing, how his wife is doing, how his kids are, and some DNS stuff. I hope folks forgive me for not covering the results of the first 3 agenda discussions. [1] A cheesy reference to the beltway on the west side of Washington DC. [2] Maybe if a stub resolver has trust relationships with multiple servers, it will want to ask them all until it find an answer with the AD bit set. If folks think defining the AD bit for this case is worth it, in spite of what I see as the downside. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-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 Jun 16 00:40:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19665 for ; Sun, 16 Jun 2002 00:40:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JReg-0009Q5-00 for namedroppers-data@psg.com; Sat, 15 Jun 2002 21:28:46 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17JRed-0009Pt-00 for namedroppers@ops.ietf.org; Sat, 15 Jun 2002 21:28:43 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA22892; Sun, 16 Jun 2002 00:28:42 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA11010; Sun, 16 Jun 2002 00:28:41 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id AAA27405; Sun, 16 Jun 2002 00:28:40 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id AAA13212; Sun, 16 Jun 2002 00:28:40 -0400 Subject: Re: IESG feedback on dnsext-ad-is-secure From: Greg Hudson To: Edward Lewis Cc: namedroppers@ops.ietf.org In-Reply-To: References: <97703914-7FC7-11D6-9A23-00039367340A@nominum.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 16 Jun 2002 00:28:40 -0400 Message-Id: <1024201720.29440.67.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2002-06-15 at 23:30, Edward Lewis wrote: > I.e., if you went to the trouble to configure a secure > association with a server, then you trust the server did its best to > get the answer. Okay, the server did its best to get the answer. Now, was the record I asked for signed, or not? I'm not sure quite where the misunderstanding is here. Your criticisms almost seem to be based on the old RFC2535 definition of the AD bit (quoting from draft-ad-is-secure): As specified in RFC 2535 (section 6.1), the AD bit indicates in a response that all data included in the answer and authority sections of the response have been authenticated by the server according to the policies of that server. This is not especially useful in practice, since a conformant server should never reply with data that failed its security policy. Whereas the new definition would be (again quoting the draft): This draft proposes to redefine the AD bit such that it is only set if all data in the response has been cryptographically verified or otherwise meets the server's local security policy. Thus, a response containing properly delegated insecure data will not have AD set, nor will a response from a server configured without DNSSEC keys. As before, data which failed to verify will not be returned. (Where the "otherwise meets the server's local security policy" is, I think, only intended to handle exceptional situations, such as when the recursive resolver is for some reason using out-of-band information to authenticate the origin of the data. Or when the data is authoritative, which is a case that shouldn't matter very often.) If a recursive resolver has the wrong preconfigured keys, then yes, it will behave improperly (it will discard good records and potentially pass on bad records). The same could happen for a stub resolver which does its own verification and has the wrong keys. I'm not sure why this matters. The AD bit isn't supposed to mean "I'm a more trustworthy resolver"; by the new definition, it means "the record you asked for was signed and checks out okay." -- to unsubscribe send a message to namedroppers-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 Jun 16 00:55:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19848 for ; Sun, 16 Jun 2002 00:55:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JRvR-0009iD-00 for namedroppers-data@psg.com; Sat, 15 Jun 2002 21:46:05 -0700 Received: from rs1.arin.net ([192.149.252.21]) by psg.com with esmtp (Exim 3.36 #1) id 17JRvO-0009i2-00 for namedroppers@ops.ietf.org; Sat, 15 Jun 2002 21:46:02 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id AAA15972; Sun, 16 Jun 2002 00:46:01 -0400 (EDT) Received: from [208.58.216.115] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id AAA12270; Sun, 16 Jun 2002 00:45:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <1024201720.29440.67.camel@error-messages.mit.edu> References: <97703914-7FC7-11D6-9A23-00039367340A@nominum.com> <1024201720.29440.67.camel@error-messages.mit.edu> Date: Sun, 16 Jun 2002 00:45:57 -0400 To: Greg Hudson , Edward Lewis From: Edward Lewis Subject: Re: IESG feedback on dnsext-ad-is-secure Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:28 AM -0400 6/16/02, Greg Hudson wrote: >On Sat, 2002-06-15 at 23:30, Edward Lewis wrote: >> I.e., if you went to the trouble to configure a secure >> association with a server, then you trust the server did its best to >> get the answer. > >Okay, the server did its best to get the answer. Now, was the record I >asked for signed, or not? > 1) There is no SIG record - no checking, but the server did verify that the answer should not be signed. 2) There is a SIG record - the server did check the answer and either found that the SIG validated the answer or that the SIG was immaterial because the answer didn't require a signature. Maybe the application wants to distinguish between the two cases. If that case, the application should have the validation done locally. Perhaps the argument should be that API's need to be able to convey whether the validation was done (locally, e.g., by lwresd). I really don't see why the AD bit is in the protocol. The AD bit isn't something one server gets from another server, each server willing to do DNSSEC processing should be setting the CD bit on query. The information in the AD bit matters just to the end user, and if the AD bit is important, the work should be done locally and the results made available in the API. But not the protocol. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-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 Jun 16 00:57:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19869 for ; Sun, 16 Jun 2002 00:57:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JRsQ-0009eC-00 for namedroppers-data@psg.com; Sat, 15 Jun 2002 21:42:58 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17JRsN-0009e0-00 for namedroppers@ops.ietf.org; Sat, 15 Jun 2002 21:42:55 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g5G4eOS01207; Sat, 15 Jun 2002 21:40:24 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g5G4gqgF004343; Sat, 15 Jun 2002 23:42:52 -0500 (CDT) Date: Sat, 15 Jun 2002 23:42:52 -0500 Subject: Re: IESG feedback on dnsext-ad-is-secure Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: namedroppers@ops.ietf.org To: Edward Lewis From: Ted Lemon In-Reply-To: Message-Id: <8470B817-80E3-11D6-9A23-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think the point of the AD bit is that the *application* would *do something different* with the data depending on whether or not it was set. This is similar to the present case with, e.g., Mozilla, where depending on your configuration, it may pop up a "Warning, data transmitted is not private" box if the connection isn't encrypted - here, it might pop up a warning saying "warning: I cannot verify that the address I have for www.amazon.com is actually an address at amazon.com, because the DNS record wasn't signed." This is a useful thing, and I'd like it if, in the future, Mozilla would do this. There are two ways for Mozilla to do this. One is to do the signature verification itself. The other is to trust its resolving name server to do it. Which is better, I will not venture to say, since my own opinion on this is divided, but it definitely does not match what you are saying: > My objection is still based upon the fact that the AD bit can mislead a > resolver - given the case of bad keys at a trusted server (eg one I share > a TSIG with). I don't think the AD bit adds much to the protocol[2] - a > stub resolver could just tell an application that the answer came from a > server it trusts. This isn't what the ad-is-secure draft says the AD bit does. The AD-is-secure draft says the AD bit means the data was definitely signed, and either the signature was verified by the resolving name server, or, that the resolving name server is authoritative for that data, and thus can assert that it is correct. The draft seems pretty clear on this point. So "a stub resolver could just tell an application that the answer came from a server it trusts" isn't good enough, because the question that the AD bit answers is not about the resolving server - it is about the data. A trusted server may say to the stub resolver, "here's the data, but I can' t verify it, so good luck." It says this by not setting the AD bit. Does this make any sense to you, or am I making a mistake about this somewhere? I don't understand your point about bad keys, so maybe I'm missing something. -- to unsubscribe send a message to namedroppers-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 Jun 16 01:03:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19930 for ; Sun, 16 Jun 2002 01:03:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JS4Z-0009vw-00 for namedroppers-data@psg.com; Sat, 15 Jun 2002 21:55:31 -0700 Received: from rs1.arin.net ([192.149.252.21]) by psg.com with esmtp (Exim 3.36 #1) id 17JS4R-0009vf-00 for namedroppers@ops.ietf.org; Sat, 15 Jun 2002 21:55:28 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id AAA16660; Sun, 16 Jun 2002 00:55:22 -0400 (EDT) Received: from [208.58.216.115] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id AAA12538; Sun, 16 Jun 2002 00:55:15 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <8470B817-80E3-11D6-9A23-00039367340A@nominum.com> References: <8470B817-80E3-11D6-9A23-00039367340A@nominum.com> Date: Sun, 16 Jun 2002 00:55:13 -0400 To: Ted Lemon , Edward Lewis From: Edward Lewis Subject: Re: IESG feedback on dnsext-ad-is-secure Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:42 PM -0500 6/15/02, Ted Lemon wrote: >Does this make any sense to you, or am I making a mistake about this >somewhere? I don't understand your point about bad keys, so maybe >I'm missing something. You and Greg are hitting on the same point - that the information conveyed by the AD bit is important to the application. My response now is that this is an API issue, not a protocol issue. Perhaps there is a benefit there, but I certainly didn't get it from the draft. I usually think in terms of server to server to stub interactions, but I rarely consider what happens at the application level. Quoting the message that started this all, at 3:54 PM +0200 6/10/02, by Erik Nordmark I see that my failure to grasp that this was an application API issue may lay in comments already leveled against the draft: >The document doesn't explain the expected usage of the AD bit >by the receiver. This makes it hard to evaluate the benefits. >Is the intent that the application be notified? If so, what are some >examples of what the application will do based on the value of the bit? > >The applicability of the document isn't clear. If the document is >going to move forward it would need a "safe" applicability statement. >For example, while the blind trust in a resolver might make sense e.g. in >an enterprise network, it doesn't seem to make sense in the home/ISP >setting where the ISP would run the resolver. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-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 Jun 16 10:12:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03525 for ; Sun, 16 Jun 2002 10:12:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JaOt-000Fiz-00 for namedroppers-data@psg.com; Sun, 16 Jun 2002 06:49:03 -0700 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.36 #1) id 17JaOq-000Fio-00 for namedroppers@ops.ietf.org; Sun, 16 Jun 2002 06:49:00 -0700 Received: from randy by roam.psg.com with local (Exim 4.05) id 17JZP3-0008Wm-00; Sun, 16 Jun 2002 05:45:09 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Paul V. Mockapetris" Cc: namedroppers@ops.ietf.org Subject: Re: [Internet-Drafts@ietf.org: I-D ACTION:draft-hardie-out-rr-00.txt] References: <20020614102836.D50086@shell.nominum.com> <4.2.0.58.20020614112538.0233dff8@127.0.0.1> Message-Id: Date: Sun, 16 Jun 2002 05:45:09 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit while we're solving problems using this approach, is there a reason that you did not mention that classes could be rooted differently? e.g. the IN class could remain with the IANA roots, and the ITU class could be controlled by the itu with its own set of root servers. let a thousand roots bloom. randy -- to unsubscribe send a message to namedroppers-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 Jun 16 11:15:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04380 for ; Sun, 16 Jun 2002 11:15:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Jbb0-000Ga2-00 for namedroppers-data@psg.com; Sun, 16 Jun 2002 08:05:38 -0700 Received: from adsl-63-196-7-183.dsl.snfc21.pacbell.net ([63.196.7.183] helo=blade.unixpeople.internal) by psg.com with esmtp (Exim 3.36 #1) id 17Jbaw-000GZr-00 for namedroppers@ops.ietf.org; Sun, 16 Jun 2002 08:05:35 -0700 Received: from unixpeople.com (localhost [127.0.0.1]) by blade.unixpeople.internal (8.12.2/8.12.2) with ESMTP id g5GF5UoW014210 for ; Sun, 16 Jun 2002 08:05:30 -0700 (PDT) Message-ID: <3D0CA8CF.1070606@unixpeople.com> Date: Sun, 16 Jun 2002 08:03:43 -0700 From: "Andy W. Barclay" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: General comments on DNSSEC References: <200206150210.g5F2AZm0033389@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit But DNS is not just another application. I can't think of any case where the application is just DNS. Its always another application that uses the data in DNS (like mozilla, xntp, ssh, sendmail, etc.) Many people are talking about modifying the application to deal with the AD bit. I'm becoming even more convinced now, that if I'm modifying the application, I might as well modify it to simply use certificates. Mark.Andrews@isc.org wrote: >>After reading draft-ietf-dnsext-dns-threats-01.txt, it has occurred to >>me that DNSSEC may be a waste of time. >> >>It seems that applications are capable of the same security that we can >>provide with DNSSEC. (I realize that if we could get a global >>deployment, we could increase security on legacy protocols). >> >>For example, the draft referenced above says: >>"The resulting list of desired security services was >> 1) data integrity, and >> 2) data origin authentication." >> >>Any application that uses certificates has those capabilities. Legacy >>applications that require security are being upgraded to support >>certificates/keys (ntp). >> >>Can someone convince me that DNSSEC still makes sense? >>(One argument that I won't buy into is that my phone/PIM or whatever >>doesn't have the horsepower to do certificates. By the time we get >>dnssec deployed, they will have that horsepower.) >> >>-- >>Regards, >>Andy W. Barclay. abarclay@unixpeople.com >>fax (781) 823-8276 >>Always a UNIX Evangelist (and sometimes a system and network architect) >> >>"Money, not morality, is the principle commerce of >>civilized nations" >> -- Thomas Jefferson > > > DNS is just another application trying to secure its own > transactions using cryptography. You have no problem with > NTP using cryptography to secure its transactions. What's > your problem with DNS using cryptography to secure its > transactions. > > Mark > -- > Mark Andrews, Internet Software Consortium > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- Regards, Andy W. Barclay. abarclay@unixpeople.com fax (781) 823-8276 Always a UNIX Evangelist (and sometimes a system and network architect) It takes a long time to understand nothing. --EDWARD DAHLBERG -- to unsubscribe send a message to namedroppers-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 Jun 16 11:26:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04536 for ; Sun, 16 Jun 2002 11:26:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Jboc-000GkY-00 for namedroppers-data@psg.com; Sun, 16 Jun 2002 08:19:42 -0700 Received: from adsl-63-196-7-183.dsl.snfc21.pacbell.net ([63.196.7.183] helo=blade.unixpeople.internal) by psg.com with esmtp (Exim 3.36 #1) id 17JboY-000GkM-00 for namedroppers@ops.ietf.org; Sun, 16 Jun 2002 08:19:38 -0700 Received: from unixpeople.com (localhost [127.0.0.1]) by blade.unixpeople.internal (8.12.2/8.12.2) with ESMTP id g5GFJYoW014235 for ; Sun, 16 Jun 2002 08:19:34 -0700 (PDT) Message-ID: <3D0CAC1B.3070000@unixpeople.com> Date: Sun, 16 Jun 2002 08:17:47 -0700 From: "Andy W. Barclay" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: General comments on DNSSEC References: <20020612170111.92D431C81@thrintun.hactrn.net> <20020611161857.8B8EA1BFA@thrintun.hactrn.net> <20020611154927.F0C4528B6C@as.vix.com> <18498.1023863843@munnari.OZ.AU> <23480.1023963134@munnari.OZ.AU> <3D0A9A7E.6090705@unixpeople.com> <1024107518.29440.50.camel@error-messages.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Greg Hudson wrote: > The primary purpose of DNSSEC is to protect the DNS infrastructure, > which is mostly name-to-address and address-to-name mappings, not to > provide security for applications. There are those of us who wouldn't > mind being able to use DNSSEC to protect application keys, perhaps > because of a dislike of X.509 certificates or the certificate model in > general, but that's a separate problem. I am one of those people. > > You could argue that protecting infrastructure is pointless; that > everyone should use secure application protocols instead. This is precisely my point. I'm arguing that protecting DNS maybe pointless, and I'm looking to be convinced that it makes sense. > I wouldn't > agree, though: Defense in depth is a fine thing. > > For instance, right now, if you want to attack www.amazon.com, you can > simply spoof its DNS record to some set of clients to point to your own > web server, which is a replica of www.amazon.com except it never uses > SSL. The vast majority of users are unlikely to notice. You'll be > detected eventually, but not before you steal some large number of > credit card numbers and/or sales. Ok, so your argument is that its worthwhile to protect legacy protocols. My argument is that if we are modifying the applications anyway, why not have the "default" protocol of the web browser be https? In this way, if someone has spoofed the address, then the user will get a dialog box indicating a certificate mismatch. I realize that there is still a class of users that will simply dismiss this dialog box, and continue to use the site, but that same class of users would probably also dismiss the box that says "the DNS name could not be authenticated". Actually, its probably worse, because there is a larger class of users that, during deployement, would get so annoyed at this warning, that they would check the "don't tell me this again" box. > > With DNSSEC deployment to the www.amazon.com record and the resolvers of > most users, this attack gets harder. You can't spoof the DNS record, so > you have to hijack TCP connections or do something similarly difficult. yes, you are correct, assuming that the application or resolver has been modified to check signatures, or if the application trusts its local nameserver. -- Regards, Andy W. Barclay. abarclay@unixpeople.com fax (781) 823-8276 Always a UNIX Evangelist (and sometimes a system and network architect) It takes a long time to understand nothing. --EDWARD DAHLBERG -- to unsubscribe send a message to namedroppers-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 Jun 16 12:00:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04920 for ; Sun, 16 Jun 2002 12:00:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JcKp-000HBQ-00 for namedroppers-data@psg.com; Sun, 16 Jun 2002 08:52:59 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17JcKl-000HBC-00 for namedroppers@ops.ietf.org; Sun, 16 Jun 2002 08:52:56 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 141912 for namedroppers@ops.ietf.org; Sun, 16 Jun 2002 10:50:56 -0500 Message-ID: <3D0CB455.3070303@ehsco.com> Date: Sun, 16 Jun 2002 10:52:53 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 CC: namedroppers@ops.ietf.org Subject: Re: General comments on DNSSEC References: <200206150210.g5F2AZm0033389@drugs.dv.isc.org> <3D0CA8CF.1070606@unixpeople.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/16/2002 10:03 AM Andy W. Barclay wrote: > But DNS is not just another application. I can't think of any case > where the application is just DNS. Its always another application > that uses the data in DNS (like mozilla, xntp, ssh, sendmail, etc.) This should not be taken as an endorsement of Andy's argument, but it is worth pointing out that if the application isn't part of the security chain then attacks can be moved to some other naming service that the application or resolver implicitly trusts. Hacking into /etc/hosts on a few thousand boxes is impractical but using a virus to infect a few thousand PCs isn't. Changing an NIS or LDAP naming service would also be productive for redirecting traffic at least within a local administrative domain. The only way that the e2e argument holds up is if the application which is issuing the lookups does the validation; the application is the participating end-point, not the resolver. Of course, the local security policies of any given opsys are probably well beyond the scope of this WG. It might be worth mentioning some of these issues in a security considerations section of an update though, especially the requirement for applications to participate. Also of course, if there's some switch that needs to be defined in order for an application to actively and effeciently participate then that is in scope, and the switch should be defined somewhere. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-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 Jun 16 12:12:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05010 for ; Sun, 16 Jun 2002 12:12:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JcV1-000HKT-00 for namedroppers-data@psg.com; Sun, 16 Jun 2002 09:03:31 -0700 Received: from adsl-63-196-7-183.dsl.snfc21.pacbell.net ([63.196.7.183] helo=blade.unixpeople.internal) by psg.com with esmtp (Exim 3.36 #1) id 17JcUx-000HKI-00 for namedroppers@ops.ietf.org; Sun, 16 Jun 2002 09:03:27 -0700 Received: from unixpeople.com (localhost [127.0.0.1]) by blade.unixpeople.internal (8.12.2/8.12.2) with ESMTP id g5GG3NoW014312 for ; Sun, 16 Jun 2002 09:03:24 -0700 (PDT) Message-ID: <3D0CB660.5030808@unixpeople.com> Date: Sun, 16 Jun 2002 09:01:36 -0700 From: "Andy W. Barclay" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: General comments on DNSSEC References: <20020612170111.92D431C81@thrintun.hactrn.net> <20020611161857.8B8EA1BFA@thrintun.hactrn.net> <20020611154927.F0C4528B6C@as.vix.com> <18498.1023863843@munnari.OZ.AU> <23480.1023963134@munnari.OZ.AU> <3D0A9A7E.6090705@unixpeople.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree about using DNS to distribute keys, and that would convince me that DNSSEC is still worthwhile, however, with the draft suggestion to limit the KEY RR, and with DNSSEC taking so long to be deployed, I feel that people requiring secure key-based protocols won't wait for DNSsec. I've checked the working group drafts, and I can't find any that are working on storing application keys in the DNS. Is anyone aware of work being done in this area - possibly outside the WG? Simon Josefsson wrote: > [ post by non-subscriber. with the massive amount of spam, it is easy to > miss and therefore delete mis-posts. so fix subscription addresses! ] > > "Andy W. Barclay" writes: > > >>After reading draft-ietf-dnsext-dns-threats-01.txt, it has occurred to >>me that DNSSEC may be a waste of time. >> >>It seems that applications are capable of the same security that we >>can provide with DNSSEC. (I realize that if we could get a global >>deployment, we could increase security on legacy protocols). >> >>For example, the draft referenced above says: >>"The resulting list of desired security services was >> 1) data integrity, and >> 2) data origin authentication." >> >>Any application that uses certificates has those capabilities. Legacy >>applications that require security are being upgraded to support >>certificates/keys (ntp). >> >>Can someone convince me that DNSSEC still makes sense? > > > One of the design goals with DNSSEC was to distribute keys used not > only for securing the DNSSEC infrastructure, but also for use by > applications in general. This is still not commonly implemented, but > is IMHO the main feature of DNSSEC. The RFC 2535 abstract is > refreshlingly clear about this being on of the goals: > > ,---- > | The extensions provide for the storage of authenticated public keys > | in the DNS. This storage of keys can support general public key > | distribution services as well as DNS security. The stored keys > | enable security aware resolvers to learn the authenticating key of > | zones in addition to those for which they are initially configured. > | Keys associated with DNS names can be retrieved to support other > | protocols. Provision is made for a variety of key types and > | algorithms. > `---- > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Regards, Andy W. Barclay. abarclay@unixpeople.com fax (781) 823-8276 Always a UNIX Evangelist (and sometimes a system and network architect) It takes a long time to understand nothing. --EDWARD DAHLBERG -- to unsubscribe send a message to namedroppers-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 Jun 16 12:25:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05090 for ; Sun, 16 Jun 2002 12:25:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JcgF-000HVm-00 for namedroppers-data@psg.com; Sun, 16 Jun 2002 09:15:07 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17JcgB-000HVP-00 for namedroppers@ops.ietf.org; Sun, 16 Jun 2002 09:15:03 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA05788; Sun, 16 Jun 2002 12:15:02 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA14128; Sun, 16 Jun 2002 12:15:01 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA17974; Sun, 16 Jun 2002 12:14:59 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id MAA23146; Sun, 16 Jun 2002 12:14:58 -0400 Subject: Re: General comments on DNSSEC From: Greg Hudson To: "Andy W. Barclay" Cc: namedroppers@ops.ietf.org In-Reply-To: <3D0CB660.5030808@unixpeople.com> References: <20020612170111.92D431C81@thrintun.hactrn.net> <20020611161857.8B8EA1BFA@thr intun.hactrn.net> <20020611154927.F0C4528B6C@as.vix.com> <18498.1023863843@munnari.OZ.AU> <23480.1023963134@munnari.OZ.AU> <3D0 A9A7E.6090705@unixpeople.com> <3D0CB660.5030808@unixpeople.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 16 Jun 2002 12:14:57 -0400 Message-Id: <1024244097.29470.88.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2002-06-16 at 12:01, Andy W. Barclay wrote: > I agree about using DNS to distribute keys, and that would convince me > that DNSSEC is still worthwhile, however, with the draft suggestion to > limit the KEY RR, and with DNSSEC taking so long to be deployed, I feel > that people requiring secure key-based protocols won't wait for > DNSsec. I've checked the working group drafts, and I can't find any > that are working on storing application keys in the DNS. Is anyone aware > of work being done in this area - possibly outside the WG? I think there are some people experimenting with doing this for ssh and possibly for IPsec. Both of those applications already have their own specialized security protocol which merely needs to be seeded with a private key. Most applications are not in that situation, and no one in an application working group wants to invent a new security protocol just to get a particular key management behavior. Perhaps the easiest way to gain acceptance would be to define SASL and/or GSSAPI mechanisms which use keys or key fingerprints in DNS, protected by DNSSEC, to bootstrap a security association. (People who don't want to trust the DNS authority chain could use other mechanisms, so Keith's objection would be covered, I think.) Still a difficult road, though. -- to unsubscribe send a message to namedroppers-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 Jun 16 12:34:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05158 for ; Sun, 16 Jun 2002 12:34:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JcoN-000Hey-00 for namedroppers-data@psg.com; Sun, 16 Jun 2002 09:23:31 -0700 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #1) id 17JcoJ-000Hei-00 for namedroppers@ops.ietf.org; Sun, 16 Jun 2002 09:23:28 -0700 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 022EE52A9; Sun, 16 Jun 2002 18:23:26 +0200 (MEST) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id 5757E1DF6; Sun, 16 Jun 2002 18:23:05 +0200 (MEST) Date: Sun, 16 Jun 2002 18:23:05 +0200 (CEST) From: Jakob Schlyter To: "Andy W. Barclay" Cc: namedroppers@ops.ietf.org Subject: Re: General comments on DNSSEC In-Reply-To: <3D0CB660.5030808@unixpeople.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 16 Jun 2002, Andy W. Barclay wrote: > I've checked the working group drafts, and I can't find any that are > working on storing application keys in the DNS. Is anyone aware of work > being done in this area - possibly outside the WG? draft-schlyter-appkey-02.txt draft-schlyter-pkix-dns-02.txt jakob -- to unsubscribe send a message to namedroppers-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 Jun 16 13:59:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06115 for ; Sun, 16 Jun 2002 13:59:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JeBs-000Is1-00 for namedroppers-data@psg.com; Sun, 16 Jun 2002 10:51:52 -0700 Received: from rs1.arin.net ([192.149.252.21]) by psg.com with esmtp (Exim 3.36 #1) id 17JeBo-000Irp-00 for namedroppers@ops.ietf.org; Sun, 16 Jun 2002 10:51:49 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id NAA21049 for ; Sun, 16 Jun 2002 13:51:39 -0400 (EDT) Received: from [208.58.216.8] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA04254; Sun, 16 Jun 2002 13:51:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <8470B817-80E3-11D6-9A23-00039367340A@nominum.com> Date: Sun, 16 Jun 2002 13:51:24 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: IESG feedback on dnsext-ad-is-secure Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At the urging of some off-list messages, I was urged to re-read the draft and figure out why I'm running so contrary to the consensus. I still find the draft lacking, as was noted in Eric's message, but after considering the post-IESG feedback mail thread, the AD bit makes more sense. The problem is that I have been afraid of putting the bit into "general use." Perhaps it is the specification style of the draft, but it is not until the last paragraph of the Security Considerations is the crucial text: Resolvers (full or stub) that blindly trust the AD bit without knowing the security policy of the server generating the answer can not be considered security aware. So, the authors assume that there is no need to transfer policy because the receiver already know the sender's policy. And I take "knowing" to include "I know the administrator of that server and if I get burned, I can ask her to update the keys." In addition, this passage, which I *have been* aware of, doesn't appear until the last paragraph of section 3. This should be brought forward in the document. A resolver MUST NOT blindly trust the AD bit unless it communicates with the server over a secure transport mechanism or using message authentication such as TSIG [RFC2845] or SIG(0) [RFC2931] and is configured to trust the server. So, if the AD bit constricted to be meaningful only between mutually consenting resolver and server, defining it to mean that the server followed the DNSSEC policy makes sense. The up shot for me is that I would support this redefinition of the bit if the authors make the restrictions "buried" late in the document are promoted to the introduction. Perhaps buried is a strong term, but I really dislike any specification or constraint language in the "* considerations" that hasn't appeared earlier. I prefer to just put analysis in those sections, e.g., listing the consequences of voiding parts of the specifications. In this instance, the security considerations should mention that blindly trusting the AD bit may result in trusting an unverifiable (even out of band) server, etc. Finally - if the intent of the AD is to enable applications to report the use of validated data, then this ought to be mentioned in the introduction. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-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 Jun 16 17:06:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08106 for ; Sun, 16 Jun 2002 17:06:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Jh1P-000L9C-00 for namedroppers-data@psg.com; Sun, 16 Jun 2002 13:53:15 -0700 Received: from ip68-100-182-21.nv.nv.cox.net ([68.100.182.21] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17Jh1L-000L8y-00 for namedroppers@ops.ietf.org; Sun, 16 Jun 2002 13:53:11 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17Jh1K-0008g7-00 for namedroppers@ops.ietf.org; Sun, 16 Jun 2002 13:53:11 -0700 Message-Id: <4.2.0.58.20020616090618.033d1758@127.0.0.1> In-Reply-To: References: <20020614102836.D50086@shell.nominum.com> <4.2.0.58.20020614112538.0233dff8@127.0.0.1> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_4825138==_.ALT" Date: Sun, 16 Jun 2002 09:16:19 -0700 To: Randy Bush From: "Paul V. Mockapetris" Subject: Re: [Internet-Drafts@ietf.org: I-D ACTION:draft-hardie-out-rr-00.txt] Cc: namedroppers@ops.ietf.org X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,BIG_FONT version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --=====================_4825138==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] At 05:45 AM 6/16/2002 -0700, you wrote: >while we're solving problems using this approach, is there a reason >that you did not mention that classes could be rooted differently? >e.g. the IN class could remain with the IANA roots, and the ITU >class could be controlled by the itu with its own set of root >servers. let a thousand roots bloom. > >randy > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: I think my message mentioned it three times, but in any case, I said: >Delegations and control are class specific. so it was mentioned (different delegation at the root may mean different rooting/ownership). Of course, this isn't anything like the proposals to have separate roots for class=IN, which generates so much fear of cataclysmic consequences. There's no threat to the status quo here. --=====================_4825138==_.ALT Content-Type: text/html; charset="us-ascii" At 05:45 AM 6/16/2002 -0700, you wrote:
while we're solving problems using this approach, is there a reason
that you did not mention that classes could be rooted differently?
e.g. the IN class could remain with the IANA roots, and the ITU
class could be controlled by the itu with its own set of root
servers.  let a thousand roots bloom.

randy

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

I think my message mentioned it three times, but in any case, I said:

Delegations and control are class specific.

so it was mentioned (different delegation at the root may mean different rooting/ownership).

Of course, this isn't anything like the proposals to have separate roots for class=IN, which generates so much fear of cataclysmic consequences.  There's no threat to the status quo here.



 --=====================_4825138==_.ALT-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 16 17:17:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08218 for ; Sun, 16 Jun 2002 17:17:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JhGH-000LOE-00 for namedroppers-data@psg.com; Sun, 16 Jun 2002 14:08:37 -0700 Received: from rs1.arin.net ([192.149.252.21]) by psg.com with esmtp (Exim 3.36 #1) id 17JhGE-000LO2-00 for namedroppers@ops.ietf.org; Sun, 16 Jun 2002 14:08:34 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id RAA14366 for ; Sun, 16 Jun 2002 17:08:32 -0400 (EDT) Received: from [208.58.216.108] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA10082; Sun, 16 Jun 2002 17:08:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <8470B817-80E3-11D6-9A23-00039367340A@nominum.com> Date: Sun, 16 Jun 2002 17:07:31 -0400 To: Edward Lewis , namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: IESG feedback on dnsext-ad-is-secure Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I can't even let myself have the last word. Given the following passage, I would urge the addition of this in section 2: "The AD bit SHOULD NOT be set unless TSIG/SIG(0) is being used to protect the response." "SHOULD" appears because local policy might dictate otherwise. This is would reinforce the notion below. At 1:51 PM -0400 6/16/02, Edward Lewis wrote: >The problem is that I have been afraid of putting the bit into >"general use." Perhaps it is the specification style of the draft, >but it is not until the last paragraph of the Security >Considerations is the crucial text: > > Resolvers (full or stub) that blindly trust the AD bit without > knowing the security policy of the server generating the answer can > not be considered security aware. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-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 Jun 16 20:19:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09592 for ; Sun, 16 Jun 2002 20:19:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Jk4J-000Nim-00 for namedroppers-data@psg.com; Sun, 16 Jun 2002 17:08:27 -0700 Received: from netbusters.com ([207.8.219.204] helo=www.netbusters.com) by psg.com with esmtp (Exim 3.36 #1) id 17Jk4F-000NiF-00 for namedroppers@ops.ietf.org; Sun, 16 Jun 2002 17:08:23 -0700 Received: by www.netbusters.com (Postfix, from userid 513) id 0065417D9; Mon, 17 Jun 2002 00:08:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by www.netbusters.com (Postfix) with ESMTP id F3A3D372C for ; Sun, 16 Jun 2002 20:08:22 -0400 (EDT) Date: Sun, 16 Jun 2002 20:08:22 -0400 (EDT) From: Donald Eastlake 3rd X-X-Sender: dee3@netbusters.com To: namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 16 Jun 2002, Edward Lewis wrote: > Date: Sun, 16 Jun 2002 13:51:24 -0400 > From: Edward Lewis > To: namedroppers@ops.ietf.org > Cc: edlewis@arin.net > Subject: Re: IESG feedback on dnsext-ad-is-secure > > ... > > The problem is that I have been afraid of putting the bit into > "general use." Perhaps it is the specification style of the draft, > but it is not until the last paragraph of the Security Considerations > is the crucial text: > > Resolvers (full or stub) that blindly trust the AD bit without > knowing the security policy of the server generating the answer can > not be considered security aware. > > So, the authors assume that there is no need to transfer policy > because the receiver already know the sender's policy. And I take > "knowing" to include "I know the administrator of that server and if > I get burned, I can ask her to update the keys." > > ... > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer It is common for their to be resolvers, such as those on machines within a company, that are more or less required to follow the resolution/security policies of corporate level or border recursive servers, whether they know, like, or approve of such resolution/security policies. 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 Sun Jun 16 20:42:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09855 for ; Sun, 16 Jun 2002 20:42:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JkTr-000O6R-00 for namedroppers-data@psg.com; Sun, 16 Jun 2002 17:34:51 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17JkTn-000O6C-00 for namedroppers@ops.ietf.org; Sun, 16 Jun 2002 17:34:48 -0700 Received: from drugs.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.12.3/8.12.3) with ESMTP id g5H0Yfm0038450; Mon, 17 Jun 2002 10:34:44 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200206170034.g5H0Yfm0038450@drugs.dv.isc.org> To: "Andy W. Barclay" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: General comments on DNSSEC In-reply-to: Your message of "Sun, 16 Jun 2002 08:03:43 MST." <3D0CA8CF.1070606@unixpeople.com> Date: Mon, 17 Jun 2002 10:34:41 +1000 X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > But DNS is not just another application. I can't think of any case > where the application is just DNS. Its always another application > that uses the data in DNS (like mozilla, xntp, ssh, sendmail, etc.) > Many people are talking about modifying the application to deal with > the AD bit. I'm becoming even more convinced now, that if I'm modifying > the application, I might as well modify it to simply use certificates. While certificates will *detect* that you have the *wrong* address they won't help you *get* the *right* address. DNSSEC will do that by allowing the nameserver to reject the bogus data and wait for the good data to arrive. DNSSEC reduces the attack at the DNS level to a DoS attack not a insertion attack. The DoS attacks come in (at least) two forms. 1. computation attack 2. blocking the valid answers being received which requires that the attacker is controlling equipment on the path between the nameservers involved. Mark -- Mark Andrews, Internet Software Consortium 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 Jun 16 20:50:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09964 for ; Sun, 16 Jun 2002 20:50:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Jkbq-000OFz-00 for namedroppers-data@psg.com; Sun, 16 Jun 2002 17:43:06 -0700 Received: from rs1.arin.net ([192.149.252.21]) by psg.com with esmtp (Exim 3.36 #1) id 17Jkbm-000OFm-00 for namedroppers@ops.ietf.org; Sun, 16 Jun 2002 17:43:02 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id UAA07127; Sun, 16 Jun 2002 20:43:01 -0400 (EDT) Received: from [208.58.208.98] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id UAA16513; Sun, 16 Jun 2002 20:42:56 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Sun, 16 Jun 2002 20:42:38 -0400 To: Donald Eastlake 3rd , namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: IESG feedback on dnsext-ad-is-secure Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I had this in mind when I wrote what I did. I.e., when working on company business, if that business is hosed by faulty DNS security, I "know" how to complain to the IT department (or whoever is running the DNS). And when I later posted that perhaps "SHOULD NOT set the bit w/o TSIG/SIG(0)", the SHOULD NOT was just that for a case like this (as opposed to "MUST NOT"). Security is relative - you can only be as secure as your environs allow. When I have worked in the clutches of less-than-optimum bureaucracies, I just learned to go with the flow. When corporations lay down such a requirement on employees, there isn't much to fight. (This applies to the work assets, not the personal assets, of the employees.) At 8:08 PM -0400 6/16/02, Donald Eastlake 3rd wrote: >It is common for their to be resolvers, such as those on machines within >a company, that are more or less required to follow the >resolution/security policies of corporate level or border recursive >servers, whether they know, like, or approve of such resolution/security >policies. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-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 Jun 17 00:40:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13195 for ; Mon, 17 Jun 2002 00:40:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Jo6z-0001mY-00 for namedroppers-data@psg.com; Sun, 16 Jun 2002 21:27:29 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17Jo6v-0001lu-00 for namedroppers@ops.ietf.org; Sun, 16 Jun 2002 21:27:25 -0700 Received: from engill.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g5H4RwD00809; Mon, 17 Jun 2002 00:28:00 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020617000439.02c862c0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 17 Jun 2002 00:24:18 -0400 To: Edward Lewis , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: IESG feedback on dnsext-ad-is-secure Cc: edlewis@arin.net In-Reply-To: References: <8470B817-80E3-11D6-9A23-00039367340A@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 01:51 PM 6/16/2002, Edward Lewis wrote: >At the urging of some off-list messages, I was urged to re-read the draft >and figure out why I'm running so contrary to the consensus. > >I still find the draft lacking, as was noted in Eric's message, but after >considering the post-IESG feedback mail thread, the AD bit makes more sense. Finally a constructive comments on the draft from Ed, I guess the unreported yelling and cursing at him at the Black Helicopter meeting helped :-) >The problem is that I have been afraid of putting the bit into "general >use." Perhaps it is the specification style of the draft, but it is not >until the last paragraph of the Security Considerations is the crucial text: > > Resolvers (full or stub) that blindly trust the AD bit without > knowing the security policy of the server generating the answer can > not be considered security aware. > >So, the authors assume that there is no need to transfer policy because >the receiver already know the sender's policy. And I take "knowing" to >include "I know the administrator of that server and if I get burned, I >can ask her to update the keys." > >In addition, this passage, which I *have been* aware of, doesn't appear >until the last paragraph of section 3. This should be brought forward in >the document. > > A resolver MUST NOT blindly trust the AD bit unless it communicates > with the server over a secure transport mechanism or using message > authentication such as TSIG [RFC2845] or SIG(0) [RFC2931] and is > configured to trust the server. > >So, if the AD bit constricted to be meaningful only between mutually >consenting resolver and server, defining it to mean that the server >followed the DNSSEC policy makes sense. > >The up shot for me is that I would support this redefinition of the bit if >the authors make the restrictions "buried" late in the document are >promoted to the introduction. Will gladly do this, >Perhaps buried is a strong term, but I really dislike any specification or >constraint language in the "* considerations" that hasn't appeared >earlier. I prefer to just put analysis in those sections, e.g., listing >the consequences of voiding parts of the specifications. In this >instance, the security considerations should mention that blindly trusting >the AD bit may result in trusting an unverifiable (even out of band) >server, etc. > >Finally - if the intent of the AD is to enable applications to report the >use of validated data, then this ought to be mentioned in the introduction. s/application to report/stub resolvers to report to applications/ The original motivation for this draft was to enable REMOTE TRUSTED recursive resolvers to signal validation status to local stub resolver, thus enabling it to pass this information on to the application. The use of this bit by protocol elements (read resolvers) was limited to policy directives by applications such as: accept only validated KEY records accept any CERT records These issues are API issues and well outside DNS protocol, but it is important that DNS protocol carry this information to leaf notes that depend on "servers" to do the heavy lifting of DNSSEC. Olafur Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 17 02:25:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22895 for ; Mon, 17 Jun 2002 02:25:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JpeE-0003Q9-00 for namedroppers-data@psg.com; Sun, 16 Jun 2002 23:05:54 -0700 Received: from mx05.gis.net ([208.218.130.13] helo=gis.net) by psg.com with esmtp (Exim 3.36 #1) id 17JpeB-0003Py-00 for namedroppers@ops.ietf.org; Sun, 16 Jun 2002 23:05:51 -0700 Received: from tecotoo.www.gis.net ([216.41.48.65]) by mx05.gis.net; Mon, 17 Jun 2002 02:05:49 -0400 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id da027485 for ; Sun, 16 Jun 2002 22:18:55 -0400 Message-Id: <4.3.1.2.20020616221831.00e66ef0@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 16 Jun 2002 22:18:44 -0400 To: "Matt Larson" , From: Danny Mayer Subject: Re: IESG feedback on dnsext-ad-is-secure Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 01:43 PM 6/14/02, Matt Larson wrote: > > does my win98 machine have a local caching nameserver? [i mean the > > question seriously] > >Nope. Only W2K Server or better. W2K Pro and Server have a DNS Client Service that caches responses. If you're running DNS such as BIND, you really have to turn it off to prevent it interfering with the DNS server for lookups on the local machine. I have no idea whether or not any of the Win9x O/S's cache responses but then I find Win9x scarier than the NT/2K O/S's since it has no security at all. Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 17 08:46:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29187 for ; Mon, 17 Jun 2002 08:46:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Jvfn-0008dd-00 for namedroppers-data@psg.com; Mon, 17 Jun 2002 05:31:55 -0700 Received: from teletubbie.het.net.je ([192.87.110.29]) by psg.com with esmtp (Exim 3.36 #1) id 17Jvfj-0008dP-00 for namedroppers@ops.ietf.org; Mon, 17 Jun 2002 05:31:51 -0700 Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by teletubbie.het.net.je (Postfix) with ESMTP id 0C47A1B20C; Mon, 17 Jun 2002 14:31:50 +0200 (CEST) Date: Mon, 17 Jun 2002 14:31:50 +0200 (CEST) From: Roy Arends To: Greg Hudson Cc: Robert Elz , namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: <1023893146.594.386.camel@error-messages.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 12 Jun 2002, Greg Hudson wrote: > It's important that everyone be on the same page here, so that we don't > get AD-is-confused. People (including area directors) in the opt-in > discussion have already raised the possibility that a query for an > unsigned record in an opt-in zone might come back with the AD bit set, > which could only happen with a completely different meaning for the AD > bit. Sure, you can cryptographically determine that the requested > record wouldn't be signed if it does exist, but the record clearly fails > the test: > > "The AD bit MUST NOT be set on a response unless all of the RRsets in > the answer and authority sections of the response are Authenticated." A negative response, containing opt-in NXT records do not fail that test. Setting AD on a response for a query (regardless where from) indicates that all RRsets present in answer and authority section have been validated. This does not mean that QNAME and or QTYPE do not exist. This implies that the entity receiving the response can interpret the difference between 2535-NXT and opt-in-NXT. This intelligence is nowhere implied, and thus there is ambiguity. 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 Jun 17 08:47:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29207 for ; Mon, 17 Jun 2002 08:47:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JviF-0008fZ-00 for namedroppers-data@psg.com; Mon, 17 Jun 2002 05:34:27 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17JviC-0008fN-00 for namedroppers@ops.ietf.org; Mon, 17 Jun 2002 05:34:25 -0700 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 3981A3190D; Mon, 17 Jun 2002 05:34:23 -0700 (PDT) Date: Mon, 17 Jun 2002 14:51:12 +0200 (CEST) From: Roy Arends X-X-Sender: To: Greg Hudson Cc: Robert Elz , Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: <1023893146.594.386.camel@error-messages.mit.edu> Message-ID: <20020617145038.F10819-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 12 Jun 2002, Greg Hudson wrote: > It's important that everyone be on the same page here, so that we don't > get AD-is-confused. People (including area directors) in the opt-in > discussion have already raised the possibility that a query for an > unsigned record in an opt-in zone might come back with the AD bit set, > which could only happen with a completely different meaning for the AD > bit. Sure, you can cryptographically determine that the requested > record wouldn't be signed if it does exist, but the record clearly fails > the test: > > "The AD bit MUST NOT be set on a response unless all of the RRsets in > the answer and authority sections of the response are Authenticated." A negative response, containing opt-in NXT records do not fail that test. Setting AD on a response for a query (regardless where from) indicates that all RRsets present in answer and authority section have been validated. This does not mean that QNAME and or QTYPE do not exist. This implies that the entity receiving the response can interpret the difference between 2535-NXT and opt-in-NXT. This intelligence is nowhere implied, and thus there is ambiguity. 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 Jun 17 09:18:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01232 for ; Mon, 17 Jun 2002 09:18:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17JwCu-0009G7-00 for namedroppers-data@psg.com; Mon, 17 Jun 2002 06:06:08 -0700 Received: from rs1.arin.net ([192.149.252.21]) by psg.com with esmtp (Exim 3.36 #1) id 17JwCq-0009FY-00 for namedroppers@ops.ietf.org; Mon, 17 Jun 2002 06:06:05 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id JAA02142; Mon, 17 Jun 2002 09:05:59 -0400 (EDT) Received: from [208.58.217.43] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA13972; Mon, 17 Jun 2002 09:05:41 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <8470B817-80E3-11D6-9A23-00039367340A@nominum.com> Date: Mon, 17 Jun 2002 08:47:48 -0400 To: Simon Josefsson , Edward Lewis From: Edward Lewis Subject: Re: IESG feedback on dnsext-ad-is-secure Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 9:14 AM +0200 6/17/02, Simon Josefsson wrote: > >Should it really restrict it to TSIG/SIG(0) only? What if I run IPSEC >to my local DNS cache, and the DNS cache understands this? Yeah - I wasn't about to exhaust the run of possibilities. And that's why I used "SHOULD NOT." 'Course the question is how to implement the choice. It could be a run-time option, with the default to clear the bit unless the in-bad protections are used. I don't think it would be proper to delve into whether one implementation or another can or can not detect the IPsec security associations in use. ...But the spirit of the comment should account for your suggestion. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-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 Jun 17 13:38:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12975 for ; Mon, 17 Jun 2002 13:38:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17K0Fx-000E0c-00 for namedroppers-data@psg.com; Mon, 17 Jun 2002 10:25:33 -0700 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 17K0Fu-000E0Q-00 for namedroppers@ops.ietf.org; Mon, 17 Jun 2002 10:25:30 -0700 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g5HHLRK15747 for ; Mon, 17 Jun 2002 10:21:27 -0700 (PDT) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 08:49:34 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869B0F@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: namedroppers@ops.ietf.org Subject: RE: General comments on DNSSEC Date: Mon, 17 Jun 2002 08:49:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The current mandate for DNSSEC is 'too secure the Domain Name System'. That is it. Given the difficulty the group has discussing the security and operational issues of DNS it is not time to consider going beyond that scope. The DNSSEC spec essentially uses a certificate that is formed from a DNS record, just as X.509 certificates were originally created by signing X.500 records. This is essentially a direct crib from the '78 Kohnfelder paper. X.509v3 Certificates are not an appropriate mechanism to secure DNS for many reasons, not the least of which being the relative complexity of the ASN.1 format used by X.509 certificates. While it may be the case that X.509 is no more complex than ASN.1 everyone knows that if they tell a programmer to do ASN.1 they are most likely to give notice while people beg to be allowed to do XML projects. X.509 certificates do not in general fit into an ethernet MTU so using certificates would force DNS to use TCP. PGP Web of trust is not an appropriate match to the DNS architecture, Pretty Good Privacy is not designed to provide integrity of orgiin bound to a fixed hierarchical namespace. Neither has a trust model that is a particularly good match to DNS at this point. The PKIX model is now way more flexible than one would want to deal with. Using DNS records as certificates has several positives and some negatives. The negatives are basically a consequence of trying to retrofit security into a pre-existing directory (name) protocol. Sure you can do better than DNSSEC if you decide to ditch backwards compatibility with DNS, only your working group will never terminate and if by some miracle it did terminate the product would never be used. The objection to storing application keys in the DNS system itself has been repeatedly stated. In general the party that manages the DNS system for an enterprise does not have responsibility for managing users or applications. It is impossible for a majority of large enterprises to use DNS as a general directory for their users. DNS is not designed to support that use and as Klensen and others have said for some time now we have to get out of considering DNS as the first recourse for fixing every problem. Clearly there is a need for a lookup mechanism for public keys that is bound to the DNS system, so that for example one can lookup a key for alice@alicecorp.test using the DNS system as the starting point. Applications only want to have to deal with at most one such mechanism. In the XKMS protocol we consider exactly this issue, how to discover the key corresponding to alice@alicecorp.test, starting from the DNS system. Essentially we look up the SRV record for _xkms_soap_http._tcp.alicecorp.test which directs us to an XKMS service which supports the location service for the key we need. Note that this process does not result in a trusted key, for that we have to perform some form of validation (which may also be delegated to an XKMS service but must be one we have an a-priori trust relationship with). XKMS is currently being standardised in the W3C and has the support of all the principal PKI vendors. The same physical machine could be used to host XKMS and DNS servers but this is not required so a company with hosted DNS could point their SRV record at their separately hosted XKMS service. The separation also makes a lot of sense at the protocol level since the design of the key management system does not need to consider the complexity of DNS. The killer app for DNSSEC is that it provides a means of authenticating the DNS SRV record that directs queries to the relevant XKMS service. Phill -- to unsubscribe send a message to namedroppers-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 Jun 17 14:58:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16417 for ; Mon, 17 Jun 2002 14:58:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17K1Y6-000FZa-00 for namedroppers-data@psg.com; Mon, 17 Jun 2002 11:48:22 -0700 Received: from h-135-207-4-118.research.att.com ([135.207.4.118] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17K1Y3-000FZP-00 for namedroppers@ops.ietf.org; Mon, 17 Jun 2002 11:48:20 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17K1Xz-0008xi-00 for namedroppers@ops.ietf.org; Mon, 17 Jun 2002 11:48:15 -0700 References: <8470B817-80E3-11D6-9A23-00039367340A@nominum.com> In-Reply-To: (Edward Lewis's message of "Sun, 16 Jun 2002 17:07:31 -0400") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: IESG feedback on dnsext-ad-is-secure From: Simon Josefsson Date: Mon, 17 Jun 2002 09:14:56 +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Edward Lewis writes: > I can't even let myself have the last word. Given the following > passage, I would urge the addition of this in section 2: > > "The AD bit SHOULD NOT be set unless TSIG/SIG(0) is being used to > protect the response." "SHOULD" appears because local policy might > dictate otherwise. This is would reinforce the notion below. Should it really restrict it to TSIG/SIG(0) only? What if I run IPSEC to my local DNS cache, and the DNS cache understands this? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 17 14:59:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16467 for ; Mon, 17 Jun 2002 14:59:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17K1Va-000FXE-00 for namedroppers-data@psg.com; Mon, 17 Jun 2002 11:45:46 -0700 Received: from adsl-63-196-7-183.dsl.snfc21.pacbell.net ([63.196.7.183] helo=blade.unixpeople.internal) by psg.com with esmtp (Exim 3.36 #1) id 17K1VW-000FX2-00 for namedroppers@ops.ietf.org; Mon, 17 Jun 2002 11:45:42 -0700 Received: from unixpeople.com (localhost [127.0.0.1]) by blade.unixpeople.internal (8.12.2/8.12.2) with ESMTP id g5HIjboW017006 for ; Mon, 17 Jun 2002 11:45:37 -0700 (PDT) Message-ID: <3D0E2DE3.8020500@unixpeople.com> Date: Mon, 17 Jun 2002 11:43:47 -0700 From: "Andy W. Barclay" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: General comments on DNSSEC References: <2F3EC696EAEED311BB2D009027C3F4F405869B0F@vhqpostal.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I fully agree with everything you say here, except for the first paragraph. According to the draft, draft-ietf-dnsext-dns-threats-01.txt, the current mandate for DNSSEC is: 1) data integrity, and 2) data origin authentication. "to secure the DNS" is a little too vague. If we were to implement a solution that did not protect against DoS attacks (as is very likely), then we could be deemed to have failed "to secure the DNS". Thanks for the pointer to XKMS. I will read up on it. Hallam-Baker, Phillip wrote: > The current mandate for DNSSEC is 'too secure the Domain Name System'. That > is it. Given the difficulty the group has discussing the security and > operational issues of DNS it is not time to consider going beyond that > scope. > > > The DNSSEC spec essentially uses a certificate that is formed from a DNS > record, just as X.509 certificates were originally created by signing X.500 > records. This is essentially a direct crib from the '78 Kohnfelder paper. > > X.509v3 Certificates are not an appropriate mechanism to secure DNS for many > reasons, not the least of which being the relative complexity of the ASN.1 > format used by X.509 certificates. While it may be the case that X.509 is no > more complex than ASN.1 everyone knows that if they tell a programmer to do > ASN.1 they are most likely to give notice while people beg to be allowed to > do XML projects. > > X.509 certificates do not in general fit into an ethernet MTU so using > certificates would force DNS to use TCP. PGP Web of trust is not an > appropriate match to the DNS architecture, Pretty Good Privacy is not > designed to provide integrity of orgiin bound to a fixed hierarchical > namespace. Neither has a trust model that is a particularly good match to > DNS at this point. The PKIX model is now way more flexible than one would > want to deal with. > > > Using DNS records as certificates has several positives and some negatives. > The negatives are basically a consequence of trying to retrofit security > into a pre-existing directory (name) protocol. Sure you can do better than > DNSSEC if you decide to ditch backwards compatibility with DNS, only your > working group will never terminate and if by some miracle it did terminate > the product would never be used. > > > The objection to storing application keys in the DNS system itself has been > repeatedly stated. In general the party that manages the DNS system for an > enterprise does not have responsibility for managing users or applications. > > It is impossible for a majority of large enterprises to use DNS as a general > directory for their users. DNS is not designed to support that use and as > Klensen and others have said for some time now we have to get out of > considering DNS as the first recourse for fixing every problem. > > Clearly there is a need for a lookup mechanism for public keys that is bound > to the DNS system, so that for example one can lookup a key for > alice@alicecorp.test using the DNS system as the starting point. > Applications only want to have to deal with at most one such mechanism. > > > In the XKMS protocol we consider exactly this issue, how to discover the key > corresponding to alice@alicecorp.test, starting from the DNS system. > Essentially we look up the SRV record for > _xkms_soap_http._tcp.alicecorp.test which directs us to an XKMS service > which supports the location service for the key we need. > > Note that this process does not result in a trusted key, for that we have to > perform some form of validation (which may also be delegated to an XKMS > service but must be one we have an a-priori trust relationship with). > > > XKMS is currently being standardised in the W3C and has the support of all > the principal PKI vendors. The same physical machine could be used to host > XKMS and DNS servers but this is not required so a company with hosted DNS > could point their SRV record at their separately hosted XKMS service. The > separation also makes a lot of sense at the protocol level since the design > of the key management system does not need to consider the complexity of > DNS. > > > The killer app for DNSSEC is that it provides a means of authenticating the > DNS SRV record that directs queries to the relevant XKMS service. > > > Phill > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Regards, Andy W. Barclay. abarclay@unixpeople.com fax (781) 823-8276 Always a UNIX Evangelist (and sometimes a system and network architect) As soon as one freezes a design, it becomes obsolete in terms of its concepts. --Brooks, p.9 -- to unsubscribe send a message to namedroppers-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 Jun 17 15:54:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18212 for ; Mon, 17 Jun 2002 15:54:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17K2SF-000GnL-00 for namedroppers-data@psg.com; Mon, 17 Jun 2002 12:46:23 -0700 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 17K2SD-000Gn9-00 for namedroppers@ops.ietf.org; Mon, 17 Jun 2002 12:46:21 -0700 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g5HJgFK19256; Mon, 17 Jun 2002 12:42:15 -0700 (PDT) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Jun 2002 12:47:53 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869B14@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Andy W. Barclay'" , namedroppers@ops.ietf.org Subject: RE: General comments on DNSSEC Date: Mon, 17 Jun 2002 12:47:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I was actually attempting to address the limit of scope. The point illustrates the difference between a security analysts perspective and a cryptographer's perspective. It is never possible to control for every possible risk. Security is therefore risk control and not risk elimination. Cryptography allows for a deceptively thorough control of a certain subset of risk types. The risk of DoS through physical means can never be entirely eliminated, viz nuclear strike against all replicas of the facilities, in the extreeme it is expected that the sun will turn into a red giant at some point in the future but no control is proposed against that risk. So when it is said that a system is 'secure' it is always with repect to a set of risks. The lawyers have a quite specific formula to determine when a control should be applied: cost of control < probaility of harm x cost of harm. Bruce S. goes into this at some length in his latest book 'secrets and lies'. The insufferable part being that he wrote the whole damn book as if it was a sudden revalation that only he was privy to rather than something that is taught in every good computer security 101 course. Phill > > I fully agree with everything you say here, except for the > first paragraph. > > According to the draft, draft-ietf-dnsext-dns-threats-01.txt, > the current mandate for DNSSEC is: > 1) data integrity, and > 2) data origin authentication. > > "to secure the DNS" is a little too vague. If we were to implement > a solution that did not protect against DoS attacks (as is > very likely), > then we could be deemed to have failed "to secure the DNS". > -- to unsubscribe send a message to namedroppers-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 Jun 17 18:51:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22400 for ; Mon, 17 Jun 2002 18:51:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17K57J-000KPW-00 for namedroppers-data@psg.com; Mon, 17 Jun 2002 15:36:57 -0700 Received: from spratly.wl.nominum.com ([128.177.195.135] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 17K57G-000KPL-00 for namedroppers@ops.ietf.org; Mon, 17 Jun 2002 15:36:54 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g5HMaFm01419; Mon, 17 Jun 2002 15:36:16 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Mon, 17 Jun 2002 15:36:15 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: Simon Josefsson cc: Edward Lewis , Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 17 Jun 2002, Simon Josefsson wrote: > > "The AD bit SHOULD NOT be set unless TSIG/SIG(0) is being used to > > protect the response." "SHOULD" appears because local policy might > > dictate otherwise. This is would reinforce the notion below. > > Should it really restrict it to TSIG/SIG(0) only? What if I run IPSEC > to my local DNS cache, and the DNS cache understands this? Or if the client and cache are on the same machine. I think I trust the loopback interface without crypto. Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 18 12:29:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25768 for ; Tue, 18 Jun 2002 12:29:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17KLbK-000P0O-00 for namedroppers-data@psg.com; Tue, 18 Jun 2002 09:13:02 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17KLb8-000Ozi-00 for namedroppers@ops.ietf.org; Tue, 18 Jun 2002 09:12:51 -0700 Received: from engill.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g5IGDKD04585 for ; Tue, 18 Jun 2002 12:13:20 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020618120507.02fd2030@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 18 Jun 2002 12:10:04 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Discuss: TKEY renewal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a major update to the old version and I encourage people to read this document and comment on the direction this document should take, options Limit to DH exchange Expand to include other keyexchanges GSSAPI, Server assigned ... Not standardize. This version reflects all input that authors have got from members of the working group. http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-01.txt Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 18 12:29:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25783 for ; Tue, 18 Jun 2002 12:29:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17KLbC-000P05-00 for namedroppers-data@psg.com; Tue, 18 Jun 2002 09:12:54 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17KLb8-000Ozg-00 for namedroppers@ops.ietf.org; Tue, 18 Jun 2002 09:12:50 -0700 Received: from engill.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g5IGDJD04582 for ; Tue, 18 Jun 2002 12:13:19 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020618115711.02fd0e50@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 18 Jun 2002 12:05:06 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Discuss: draft-dnsext-opcode-discover-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The authors of this draft would like feedback on the technical description of this proposal. This work is indented for EXPERIMENTAL status mainly to get a IANA assigned opcode, if there is no feedback we will start working group last call in 2 weeks or so. http://www.ietf.org/internet-drafts/draft-dnsext-opcode-discover-00.txt thanks. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 18 12:59:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26562 for ; Tue, 18 Jun 2002 12:59:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17KMA7-000PnL-00 for namedroppers-data@psg.com; Tue, 18 Jun 2002 09:48:59 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17KMA4-000PnA-00 for namedroppers@ops.ietf.org; Tue, 18 Jun 2002 09:48:56 -0700 Received: from engill.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g5IGnOD04663; Tue, 18 Jun 2002 12:49:24 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020618121118.02b50db0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 18 Jun 2002 12:21:33 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: IETF-54 DNSEXT agenda requests Cc: Rob Austein Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk It is that time again, if you have anything that you want considered for the agenda please send that in soon. I will not be at the meeting, Rob Austein has agreed to step in and run the meeting, so please send agenda requests to both of us. DNSEXT currently has a one hour time slot on Tuesday afternoon. Thanks Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 19 09:08:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16801 for ; Wed, 19 Jun 2002 09:08:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17KevO-000KPc-00 for namedroppers-data@psg.com; Wed, 19 Jun 2002 05:51:02 -0700 Received: from outpost.ds9a.nl ([213.244.168.210]) by psg.com with esmtp (Exim 3.36 #1) id 17KevL-000KPN-00 for namedroppers@ops.ietf.org; Wed, 19 Jun 2002 05:50:59 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 17D5945F0; Wed, 19 Jun 2002 14:50:57 +0200 (CEST) Date: Wed, 19 Jun 2002 14:50:57 +0200 From: bert hubert To: namedroppers@ops.ietf.org Subject: wildcards & cnames revisited Message-ID: <20020619125057.GA9135@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark Andrews recently stated in the wildcards & cnames discussion: There is atleast one implementation where the match is not made so this is not a academic issue. The same zone produces different results in different implementations. Well, we are that implementation. Wildcard CNAMEs do not work in PowerDNS. The main reason we haven't bothered is this earlier statement by Mark in comp.protocols.dns.bind : By *strict* interpretation you can have caching servers return *different* answers depending upon whether there was or was not a previous query for a CNAME record that matched the wildcard record. This is *bad* and really requires protocol work to clarify the situation. Adding support for wildcard CNAMEs entails an additional (possibly database) lookup, which combined with the doubts voiced above have led us to not support wildcard CNAMEs so far. We're interested in the thoughts here on the actual risks of using wildcard CNAMEs - would anybody ever notice? If the risk, unlike the current non-portability of wildcard CNAMEs, is academic, then we will fall in line, but make a 'no-wildcard-cnames' switch for performance sensitive customers. Regards, bert hubert PowerDNS -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO -- to unsubscribe send a message to namedroppers-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 Jun 19 20:08:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06532 for ; Wed, 19 Jun 2002 20:08:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17KpAa-0003mq-00 for namedroppers-data@psg.com; Wed, 19 Jun 2002 16:47:24 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17KpAW-0003mW-00 for namedroppers@ops.ietf.org; Wed, 19 Jun 2002 16:47:21 -0700 Received: from drugs.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.12.3/8.12.3) with ESMTP id g5JNlCm0016658; Thu, 20 Jun 2002 09:47:13 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200206192347.g5JNlCm0016658@drugs.dv.isc.org> To: namedroppers@ops.ietf.org, bind-workers@isc.org, bind9-users@isc.org From: Mark.Andrews@isc.org Subject: DS support is now available in the latest snapshot Date: Thu, 20 Jun 2002 09:47:12 +1000 X-Spam-Status: No, hits=0.6 required=5.0 tests=NO_REAL_NAME version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk ftp://ftp.isc.org/isc/bind9/snapshots/bind-9.3.0s20020618.tar.gz -- Mark Andrews, Internet Software Consortium 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 Jun 20 01:54:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11886 for ; Thu, 20 Jun 2002 01:54:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17KueJ-0008tH-00 for namedroppers-data@psg.com; Wed, 19 Jun 2002 22:38:27 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17KueD-0008t5-00 for namedroppers@ops.ietf.org; Wed, 19 Jun 2002 22:38:22 -0700 Received: from drugs.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.12.3/8.12.3) with ESMTP id g5K5arm0019861; Thu, 20 Jun 2002 15:36:55 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200206200536.g5K5arm0019861@drugs.dv.isc.org> To: bert hubert Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: wildcards & cnames revisited In-reply-to: Your message of "Wed, 19 Jun 2002 14:50:57 +0200." <20020619125057.GA9135@outpost.ds9a.nl> Date: Thu, 20 Jun 2002 15:36:53 +1000 X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark Andrews recently stated in the wildcards & cnames discussion: > > There is atleast one implementation where the match is not > made so this is not a academic issue. The same zone produces > different results in different implementations. > > Well, we are that implementation. Wildcard CNAMEs do not work in PowerDNS. > The main reason we haven't bothered is this earlier statement by Mark in > comp.protocols.dns.bind : > > By *strict* interpretation you can have caching servers return > *different* answers depending upon whether there was or was not > a previous query for a CNAME record that matched the wildcard > record. > > This is *bad* and really requires protocol work to clarify the > situation. > > Adding support for wildcard CNAMEs entails an additional (possibly database) > lookup, which combined with the doubts voiced above have led us to not > support wildcard CNAMEs so far. > > We're interested in the thoughts here on the actual risks of using wildcard > CNAMEs - would anybody ever notice? If the risk, unlike the current > non-portability of wildcard CNAMEs, is academic, then we will fall in line, > but make a 'no-wildcard-cnames' switch for performance sensitive customers. The risk is in *not* matching against the wildcard CNAME. Take: *.example.com. CNAME foo.example.net. foo.example.net A 10.0.0.1 No Match: Cache1 asks for lll.example.com/CNAME then lll.example.com/A lll.example.com CNAME foo.example.net foo.example.net A 10.0.0.1 Cache2 asks for just lll.example.com/A NODATA lll.example.com/A Different answers dependent on the query history. This bad. Match: Cache3 asks for just lll.example.com/A lll.example.com CNAME foo.example.net foo.example.net A 10.0.0.1 Mark > > Regards, > > bert hubert > PowerDNS > > -- > http://www.PowerDNS.com Versatile DNS Software & Services > http://www.tk the dot in .tk > http://lartc.org Linux Advanced Routing & Traffic Control HOWTO > > -- > to 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, Internet Software Consortium 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 Jun 20 04:13:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22025 for ; Thu, 20 Jun 2002 04:13:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Kwmt-000AvC-00 for namedroppers-data@psg.com; Thu, 20 Jun 2002 00:55:27 -0700 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 17Kwmj-000AuX-00 for namedroppers@ops.ietf.org; Thu, 20 Jun 2002 00:55:17 -0700 Received: from x50 (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.11.6/8.11.6) with SMTP id g5K7tFA13008; Thu, 20 Jun 2002 09:55:15 +0200 Date: Thu, 20 Jun 2002 09:55:14 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org, bind-workers@isc.org, bind9-users@isc.org Subject: Net::DNS::SEC Message-Id: <20020620095514.50e9d2c5.olaf@ripe.net> In-Reply-To: <200206192347.g5JNlCm0016658@drugs.dv.isc.org> References: <200206192347.g5JNlCm0016658@drugs.dv.isc.org> Organization: RIPE NCC X-Mailer: Sylpheed version 0.7.5 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark just announced: > ftp://ftp.isc.org/isc/bind9/snapshots/bind-9.3.0s20020618.tar.gz Here follows a shameless plug. For those that want to write tools; the DNSSEC security extensions to the Net::DNS perl module have just been published on CPAN as Net::DNS::SEC. There is support for NXT, SIG, KEY and DS RRs and there are methods for signing and verifying data. http://search.cpan.org/search?mode=module&query=Net%3A%3ADNS%3A%3ASEC also via http://www.ripe.net/disi --Olaf (Who will be spending the rest of his day with bind-9.3.0s20020618.tar.gz and DS) --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-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 Jun 20 08:57:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28099 for ; Thu, 20 Jun 2002 08:57:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17L1GB-000Dys-00 for namedroppers-data@psg.com; Thu, 20 Jun 2002 05:41:59 -0700 Received: from is1-50.antd.nist.gov ([129.6.50.251]) by psg.com with esmtp (Exim 3.36 #1) id 17L1G6-000Dyh-00 for namedroppers@ops.ietf.org; Thu, 20 Jun 2002 05:41:54 -0700 Received: from BARNACLE (barnacle.antd.nist.gov [129.6.55.185]) by is1-50.antd.nist.gov (8.9.3/8.9.3) with SMTP id IAA01530 for ; Thu, 20 Jun 2002 08:41:51 -0400 (EDT) Message-ID: <008901c21857$1b08d420$b9370681@BARNACLE> From: "Scott Rose" To: "DNSEXT WG Mailing list" References: <5.1.1.6.2.20020618120507.02fd2030@localhost> Subject: Re: Discuss: TKEY renewal Date: Thu, 20 Jun 2002 08:36:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Limiting this to just DH is a bit worrisome to me. TKEY operations are not so limited (in the spec), but I know most implementations would do DH only anyway. If multiple key exchange algorithms are to be supported, DH should be considered for MANDATORY status. Some way of indicating which algorithm is used would also be assigned. (KEY or TKEY RDATA field). I am assuming this is for supporting primary-secondary interactions, correct? Since only two parties can be involved. Scott ----- Original Message ----- From: "lafur Gumundsson" To: Sent: Tuesday, June 18, 2002 12:10 PM Subject: Discuss: TKEY renewal > > This is a major update to the old version and I encourage people to > read this document and comment on the direction this document should > take, options > Limit to DH exchange > Expand to include other keyexchanges GSSAPI, Server assigned ... > Not standardize. > > This version reflects all input that authors have got from members of > the working group. > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-01.t xt > > 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: -- to unsubscribe send a message to namedroppers-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 Jun 20 09:38:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29591 for ; Thu, 20 Jun 2002 09:38:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17L1tO-000Edm-00 for namedroppers-data@psg.com; Thu, 20 Jun 2002 06:22:30 -0700 Received: from [159.226.6.187] (helo=whale.cnnic.net.cn) by psg.com with esmtp (Exim 3.36 #1) id 17L1tI-000EdW-00 for namedroppers@ops.ietf.org; Thu, 20 Jun 2002 06:22:25 -0700 Received: from Dell8100 ([159.226.7.98]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id GY0AIM00.PYB for ; Thu, 20 Jun 2002 21:23:10 +0800 Message-ID: <004c01c2185d$59591270$4107e29f@Dell8100> Reply-To: "Bill@CNNIC" From: "bill" To: Subject: DNSSEC and NAPTR RRsets Date: Thu, 20 Jun 2002 21:21:12 +0800 Organization: CNNIC MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.4 required=5.0 tests=BASE64_ENC_TEXT version=2.20 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA29591 Hi, folks: I want to use DNSSEC to encrypt the NAPTR (type=35) RRset. Can I do that? Best Regards Bill 2002/06/20 h{.n+zwZ,jvy覗ު笷) "a{ +wr{jȧWw^,j{!m_Xjgiz? From owner-namedroppers@ops.ietf.org Thu Jun 20 09:58:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00170 for ; Thu, 20 Jun 2002 09:58:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17L2JK-000F1h-00 for namedroppers-data@psg.com; Thu, 20 Jun 2002 06:49:18 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17L2JF-000F1H-00 for namedroppers@ops.ietf.org; Thu, 20 Jun 2002 06:49:13 -0700 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 3A1F83190D; Thu, 20 Jun 2002 06:49:12 -0700 (PDT) Date: Thu, 20 Jun 2002 16:06:47 +0200 (CEST) From: Roy Arends X-X-Sender: To: bill Cc: Subject: Re: DNSSEC and NAPTR RRsets In-Reply-To: <004c01c2185d$59591270$4107e29f@Dell8100> Message-ID: <20020620160443.V17357-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 20 Jun 2002, bill wrote: > Hi, folks: > > > I want to use DNSSEC to encrypt the NAPTR (type=35) RRset. Can I do that? No, you are currently not able to encrypt RRsets. The DNSSEC standards only have a solution for Signing RRsets. If you mean signing a NAPTR RRset, I see no reason why not. 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 Thu Jun 20 09:58:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00169 for ; Thu, 20 Jun 2002 09:58:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17L2IM-000F0x-00 for namedroppers-data@psg.com; Thu, 20 Jun 2002 06:48:18 -0700 Received: from rs1.arin.net ([192.149.252.21]) by psg.com with esmtp (Exim 3.36 #1) id 17L2IG-000F0V-00 for namedroppers@ops.ietf.org; Thu, 20 Jun 2002 06:48:12 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id JAA15676; Thu, 20 Jun 2002 09:48:10 -0400 (EDT) Received: from [192.149.252.148] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA11807; Thu, 20 Jun 2002 09:48:07 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <004c01c2185d$59591270$4107e29f@Dell8100> References: <004c01c2185d$59591270$4107e29f@Dell8100> Date: Thu, 20 Jun 2002 09:48:06 -0400 To: "Bill@CNNIC" , From: Edward Lewis Subject: Re: DNSSEC and NAPTR RRsets Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA00169 From RFC 2535 (DNSSEC base spec): 2.1 Services Not Provided ... No effort has been made to provide for any confidentiality for queries or responses. (This service may be available via IPSEC [RFC 2401], TLS, or other security protocols.) ... At 9:21 PM +0800 6/20/02, bill wrote: > Hi, folks: > > > I want to use DNSSEC to encrypt the NAPTR (type=35) RRset. Can I do that? > > Best Regards > > Bill > > 2002/06/20 >h{.n+ⅨzwZ,jvy˶󴄙ށ) "a{ >+w߾r{jWw^,j{[Нj!䗝mߝ_Xjgiz? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-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 Jun 20 09:58:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00196 for ; Thu, 20 Jun 2002 09:58:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17L2Hq-000F0D-00 for namedroppers-data@psg.com; Thu, 20 Jun 2002 06:47:46 -0700 Received: from netbusters.com ([207.8.219.204] helo=www.netbusters.com) by psg.com with esmtp (Exim 3.36 #1) id 17L2Hm-000Ezw-00 for namedroppers@ops.ietf.org; Thu, 20 Jun 2002 06:47:42 -0700 Received: by www.netbusters.com (Postfix, from userid 513) id F41E517D3; Thu, 20 Jun 2002 13:47:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by www.netbusters.com (Postfix) with ESMTP id F1A33372D; Thu, 20 Jun 2002 09:47:38 -0400 (EDT) Date: Thu, 20 Jun 2002 09:47:38 -0400 (EDT) From: Donald Eastlake 3rd X-X-Sender: dee3@netbusters.com To: bill Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEC and NAPTR RRsets In-Reply-To: <004c01c2185d$59591270$4107e29f@Dell8100> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id JAA00196 DNSSEC has nothing to do with encryption or confidentiality. It is designed to provide only authentication and integrity. Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Thu, 20 Jun 2002, bill wrote: > Date: Thu, 20 Jun 2002 21:21:12 +0800 > From: bill > To: namedroppers@ops.ietf.org > Subject: DNSSEC and NAPTR RRsets > > Hi, folks: > > > I want to use DNSSEC to encrypt the NAPTR (type=35) RRset. Can I do that? > > Best Regards > > Bill > > 2002/06/20 > rzǧuƠz'jgiz+z)'~+an˛mjȧWw^,j{[ܚb~)'~Xjgiz? -- to unsubscribe send a message to namedroppers-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 Jun 20 10:06:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00571 for ; Thu, 20 Jun 2002 10:05:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17L2R6-000FBz-00 for namedroppers-data@psg.com; Thu, 20 Jun 2002 06:57:20 -0700 Received: from [159.226.6.187] (helo=whale.cnnic.net.cn) by psg.com with esmtp (Exim 3.36 #1) id 17L2R0-000FBS-00 for namedroppers@ops.ietf.org; Thu, 20 Jun 2002 06:57:15 -0700 Received: from Dell8100 ([159.226.7.98]) by whale.cnnic.net.cn (Netscape Messaging Server 4.15) with SMTP id GY0C4N00.6XV; Thu, 20 Jun 2002 21:57:59 +0800 Message-ID: <007801c21862$370ee5a0$4107e29f@Dell8100> Reply-To: "Bill@CNNIC" From: "bill" To: "Roy Arends" Cc: References: <20020620160443.V17357-100000@node10c4d.a2000.nl> Subject: Re: DNSSEC and NAPTR RRsets Date: Thu, 20 Jun 2002 21:56:02 +0800 Organization: CNNIC MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.4 required=5.0 tests=BASE64_ENC_TEXT version=2.20 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id KAA00571 ----- Original Message ----- From: "Roy Arends" To: "bill" Cc: Sent: Thursday, June 20, 2002 10:06 PM Subject: Re: DNSSEC and NAPTR RRsets > On Thu, 20 Jun 2002, bill wrote: > > > Hi, folks: > > > > > > I want to use DNSSEC to encrypt the NAPTR (type=35) RRset. Can I do that? > > No, you are currently not able to encrypt RRsets. The DNSSEC standards > only have a solution for Signing RRsets. > > If you mean signing a NAPTR RRset, I see no reason why not. Yes, I mean signing a NAPTR RRset. I am a freshman at the DNSSEC, and what the different between encrypting and signing. Thanks Best Regards Bill 2002/06/20 h{.n+zwZ,jvy覗ު笷) "a{ +wr{jȧWw^,j{!m_Xjgiz? From owner-namedroppers@ops.ietf.org Thu Jun 20 10:14:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00887 for ; Thu, 20 Jun 2002 10:14:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17L2Z5-000FNA-00 for namedroppers-data@psg.com; Thu, 20 Jun 2002 07:05:35 -0700 Received: from padda.telia.net ([195.198.164.130]) by psg.com with esmtp (Exim 3.36 #1) id 17L2Z0-000FMq-00 for namedroppers@ops.ietf.org; Thu, 20 Jun 2002 07:05:30 -0700 Received: from localhost (dufberg@localhost) by padda.telia.net (8.11.6/8.11.6) with ESMTP id g5KE5Gb01561; Thu, 20 Jun 2002 16:05:16 +0200 (CEST) (envelope-from dufberg@telia.net) X-Authentication-Warning: padda.telia.net: dufberg owned process doing -bs Date: Thu, 20 Jun 2002 16:05:16 +0200 (CEST) From: Mats Dufberg To: bill cc: Subject: Re: DNSSEC and NAPTR RRsets In-Reply-To: <004c01c2185d$59591270$4107e29f@Dell8100> Message-ID: <20020620160154.K785-100000@padda.telia.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Jun 20, 2002, 21:21 (+0800) bill wrote: > I want to use DNSSEC to encrypt the NAPTR (type=35) RRset. Can I do > that? If you by encryting mean hiding the data for unauthorized persons, the answer is no. DNSsec is not for encryption, but for protecting data from unauthorized changes through signing with the use of ecryption technology. Mats ---------------------------------------------------------------------- Mats Dufberg Registry TeliaNet dufberg@telia.net Skanova/AO Networks +46 8 456 7274 Box 10707 +46 70 258 2588 SE-121 29 Stockholm ---------------------------------------------------------------------- -- to unsubscribe send a message to namedroppers-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 Jun 21 00:04:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21116 for ; Fri, 21 Jun 2002 00:04:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17LFKi-00011d-00 for namedroppers-data@psg.com; Thu, 20 Jun 2002 20:43:36 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17LFKd-00011P-00 for namedroppers@ops.ietf.org; Thu, 20 Jun 2002 20:43:31 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17LFKd-000DSS-00 for namedroppers@ops.ietf.org; Thu, 20 Jun 2002 20:43:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Thu, 20 Jun 2002 23:38:48 -0400 (EDT) From: Sam Weiler To: Subject: DS code & testing day (fwd) X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Date: Thu, 20 Jun 2002 02:38:05 -0400 (EDT) From: Sam Weiler To: dnssec@cafax.se Cc: dnssec@ISI.EDU Subject: DS code & testing day I'm pleased to announce the availability of Nominum's BIND DS implementation. I'll try to send some documentation in the next few days. ftp://ftp.isc.org/isc/bind9/snapshots/bind-9.3.0s20020618.tar.gz We (Network Associates Laboratories) have done some testing of this code, and I think it's ready for more widespread testing. In particular, I'd like to hold a one (or maybe two) day mini-workshop before the IETF at our offices in Rockville, Maryland. I understand that many who would otherwise attend a workshop may be unable to do so on such short notice and so close to the IETF, but I think there's much to be gained even if we can't get the usual broad participation. To repeat: -- July 3rd (and/or 2nd) -- Rockville, Maryland (near Washington, DC) -- bring-your-own-laptop and network card -- primarily testing with Nominum's DS code, announced above If you're interested in attending, please let me know the following: -- would you prefer a one or two day event? -- which of July 2nd and 3rd are you available? -- do you have some other DS implementation (server or resolver) or tools that you'd like to test? -- do you need hotel information? Based on the feedback I receive, I'll try to send a real announcement no later than Monday. -- 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 Jun 21 05:19:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05244 for ; Fri, 21 Jun 2002 05:19:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17LKGh-0007Xa-00 for namedroppers-data@psg.com; Fri, 21 Jun 2002 01:59:47 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 17LKGe-0007XP-00 for namedroppers@ops.ietf.org; Fri, 21 Jun 2002 01:59:44 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15587; Fri, 21 Jun 2002 02:59:28 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5L8xRb29246; Fri, 21 Jun 2002 10:59:27 +0200 (MEST) Date: Fri, 21 Jun 2002 10:58:12 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IESG feedback on dnsext-ad-is-secure To: Ted Lemon Cc: Edward Lewis , namedroppers@ops.ietf.org, Robert Elz In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I think you missed part of my point, though. On some level, some system > somewhere has to tell the application "I was able to validate this data," > or "this data was not signed." I would say that there is no need for this > system to be able to say "this data failed validation," because in that > case it should just discard the data. "this data failed validation" could mean two different things: 1. the SIGs didn't verify correctly 2. unable to verify the SIGs because the necessary keys were not available 2A. because the resolver timed out trying to retrieve one or more of them 2B. because some SIGs/KEYs are not present higher up in the tree and the resolver is not configured with keys for zones below this "gap" Add to that the cases of 3. No SIG for the RRset (DNSsec not used). Presumably upper parts of the tree could use DNSsec. Would the client care that . and .com was verified with DNSSEC when example.com did not use DNSSEC? 4. DNSSEC and everything verifies correctly. The question I have is what of these cases need to be communicated to the stub and how that is done. AD can easily distiguish between 3 and 4. If #1 means that the recursive resolver should not pass the RRset at all to the stub (but there seems to be different opinions here) then what remains is case 2. Erik -- to unsubscribe send a message to namedroppers-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 Jun 21 12:00:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19045 for ; Fri, 21 Jun 2002 12:00:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17LQaC-000D5t-00 for namedroppers-data@psg.com; Fri, 21 Jun 2002 08:44:20 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17LQa9-000D5i-00 for namedroppers@ops.ietf.org; Fri, 21 Jun 2002 08:44:17 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g5LFfWS21090; Fri, 21 Jun 2002 08:41:32 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g5LFiDrc004094; Fri, 21 Jun 2002 10:44:13 -0500 (CDT) Date: Fri, 21 Jun 2002 10:44:12 -0500 Subject: Re: IESG feedback on dnsext-ad-is-secure Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: Robert Elz , namedroppers@ops.ietf.org, Edward Lewis To: Erik Nordmark From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 2. unable to verify the SIGs because the necessary keys were not available > 2A. because the resolver timed out trying to retrieve one or more of > them > 2B. because some SIGs/KEYs are not present higher up in the tree and > the resolver is not configured with keys for zones below this "gap" If the resolver was able to get the data, but not the keys that sign the data, I would say that this is indicative of something worrisome, and one could argue that the data should be discarded, just as when the SIGs don't verify. If the resolver can't verify the data because *it* is not configured to do so, then it can't really make any assertions about the correctness of the data, so AD should be zero and the data should be passed to the application. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 24 08:06:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02022 for ; Mon, 24 Jun 2002 08:06:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17MSJR-0003P6-00 for namedroppers-data@psg.com; Mon, 24 Jun 2002 04:47:17 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17MSJE-0003Og-00 for namedroppers@ops.ietf.org; Mon, 24 Jun 2002 04:47:04 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29933; Mon, 24 Jun 2002 07:46:20 -0400 (EDT) Message-Id: <200206241146.HAA29933@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dhcid-rr-05.txt Date: Mon, 24 Jun 2002 07:46:20 -0400 X-Spam-Status: No, hits=1.4 required=5.0 tests=X_NOT_PRESENT,NO_REAL_NAME,TO_MALFORMED,DOUBLE_CAPSWORD, EXCUSE_6 version=2.30 X-Spam-Level: * 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 : A DNS RR for encoding DHCP information (DHCID RR) Author(s) : M. Stapp, T. Lemon, A. Gustafsson Filename : draft-ietf-dnsext-dhcid-rr-05.txt Pages : 9 Date : 21-Jun-02 It is possible for multiple DHCP clients to attempt to update the same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. 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. This memo defines a distinct RR type for this purpose for use by DHCP clients and servers, the 'DHCID' RR. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-dhcid-rr-05.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-dhcid-rr-05.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: <20020621121530.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dhcid-rr-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020621121530.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 Mon Jun 24 21:07:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08709 for ; Mon, 24 Jun 2002 21:07:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17MeU9-000JXJ-00 for namedroppers-data@psg.com; Mon, 24 Jun 2002 17:47:09 -0700 Received: from mail3.noc.ntt.co.jp ([210.163.32.58]) by psg.com with esmtp (Exim 3.36 #1) id 17MeU4-000JX8-00 for namedroppers@ops.ietf.org; Mon, 24 Jun 2002 17:47:04 -0700 Received: from ms1-gw.noc.ntt.com (ms1-gw.noc.ntt.com) by mail3.noc.ntt.co.jp (8.9.3/NOC-MAIL3) id JAA13921; Tue, 25 Jun 2002 09:46:51 +0900 (JST) Received: from mr1-gw.noc.ntt.com by ms1-gw.noc.ntt.com (8.9.3/3.7W) id JAA26731; Tue, 25 Jun 2002 09:46:48 +0900 (JST) Received: from mail1.noc.ntt.com by mr1-gw.noc.ntt.com (8.9.3/3.7W) id JAA26718; Tue, 25 Jun 2002 09:46:47 +0900 (JST) Received: from KAMITE2 by mail1.noc.ntt.com (8.9.3/3.7W) id JAA15842; Tue, 25 Jun 2002 09:46:47 +0900 (JST) From: "Yuji KAMITE" To: "Scott Rose" , Cc: Subject: RE: Discuss: TKEY renewal Date: Tue, 25 Jun 2002 09:48:00 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <008901c21857$1b08d420$b9370681@BARNACLE> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-MIME-Autoconverted: from 8bit to quoted-printable by ms1-gw.noc.ntt.com id JAA26731 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA08709 > If multiple key exchange algorithms are to be supported, DH should >be considered for MANDATORY status. I think so, too. > I am assuming this is for supporting primary-secondary interactions, > correct? Since only two parties can be involved. Basically correct. TKEY is a protocol for two entities -- server and client. So, primary-secondary authentication ( zone transfer) would be a typical and major target. However, TKEY Renewal can also be used in other areas, such as server and client over Dynamic Update, as long as they agree to make use of it, too. > Expand to include other keyexchanges GSSAPI, Server assigned ... It would be meaningful to expand to other algorithm. Now I guess it is not so difficult to modify the current draft. However, I still have one concern here; As for TKEY Renewal, how to deal with GSS-TSIG algorithm? (or, should we take it into consideration?) My understanding is, "security context" established via GSS is virtually equivalent to shared secret used in normal TSIG. Because TKEY Renewal procedure is usually invoked by server's Partial Revoke notification to client, probably client can make new "security context" only if it sends a Renewal requet with indication that hopes gss-tsig algorithm, and then starts rekeying based on GSS-TSIG method. But, on the other hand, I have several questions. For example, how can we interprete security context's lifetime in GSS, and map it into TKEY Renwal Mode's definition, and how can we revoke unnecessary security context over GSS-API ?, and so on. If TKEY Renewal is expanded to include GSSAPI, ample studies are needed, which is due to GSS's peculiarity and abstractness compared with other algorithms like DH. If it is ensured that using GSSAPI does not need so much complicated surgery to current basic Renewal Mode's framework, it will be sufficient to add some sentences to current draft. If not, possibly it might be good to do in the same way as TKEY RFC and GSS-TSIG draft are proposed separatedly. (i.e, Renewal Mode's proposal only refers to the existence of GSS-TSIG method; meanwhile, its actual details are expected in the other document, if necessary.)... Now, I appreciate comments and advice from GSS-API -familiar people. -- Kamite --- Yuji Kamite (E-mail y.kamite@ntt.com) NTT Communications Corporation TEL: +81-3-6800-3261 FAX: +81-3-5365-2990 > -----Original Message----- > From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Scott Rose > Sent: Thursday, June 20, 2002 9:37 PM > To: DNSEXT WG Mailing list > Subject: Re: Discuss: TKEY renewal > > > Limiting this to just DH is a bit worrisome to me. TKEY operations are not > so limited (in the spec), but I know most implementations would do DH only > anyway. If multiple key exchange algorithms are to be supported, DH should > be considered for MANDATORY status. Some way of indicating which algorithm > is used would also be assigned. (KEY or TKEY RDATA field). > > I am assuming this is for supporting primary-secondary interactions, > correct? Since only two parties can be involved. > > Scott > > ----- Original Message ----- > From: "lafur Gumundsson" > To: > Sent: Tuesday, June 18, 2002 12:10 PM > Subject: Discuss: TKEY renewal > > > > > > This is a major update to the old version and I encourage people to > > read this document and comment on the direction this document should > > take, options > > Limit to DH exchange > > Expand to include other keyexchanges GSSAPI, Server assigned ... > > Not standardize. > > > > This version reflects all input that authors have got from members of > > the working group. > > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-01.t > xt > > > > 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: > > > -- > to 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 Jun 25 03:06:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24759 for ; Tue, 25 Jun 2002 03:06:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Mk8Z-0001k8-00 for namedroppers-data@psg.com; Mon, 24 Jun 2002 23:49:15 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17Mk8U-0001jq-00; Mon, 24 Jun 2002 23:49:10 -0700 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g5P6mhO19855; Tue, 25 Jun 2002 02:48:44 -0400 (EDT) (envelope-from ogud@ogud.com) Date: Tue, 25 Jun 2002 02:48:43 -0400 (EDT) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: Erik Nordmark cc: Randy Bush , DNSEXT mailing list Subject: Re: IESG feedback on dnsext-ad-is-secure In-Reply-To: Message-ID: <20020625005040.G19695-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 10 Jun 2002, Erik Nordmark wrote: > Folks, > > The IESG reviewed draft-ietf-dnsext-ad-is-secure-05.txt and has > some significant concerns. While the document just tries to make > the definition of the AD bit more clear and perhaps more useful than it > is today, the document raises the issue of having stub resolvers place > blind trust on a (recursive) resolver. To the extent that the document > implicitly or explicitly encourages this, it isn't clear that > the document is a good idea. This is not the intent of the document and this behavior is outlawed in the security consideration, by classifying such resolvers as "not security aware". Next version will contain more explicit text. > > The document doesn't explain the expected usage of the AD bit > by the receiver. This makes it hard to evaluate the benefits. > Is the intent that the application be notified? If so, what are some > examples of what the application will do based on the value of the bit? The main motivation is to allow in-protocol transfer of security status of answer, from a full function DNSSEC resolver to a trusting (possibly less capable) one. I know of at least one API that transfers this information. But that is not the point, by not providing the AD bit (functionality) we require full function DNSSEC resolver on every host. This breaks the current DNS resolver deployment model more than the designers of DNSSEC where willing/allowed to go. Example: SSH client can report: do you want to connect to: client with (DNSSEC protected) and has key footprint (DNSSEC protected) If this is the first time you are connecting, this message is gives you more confidence that you are actually connecting to the right host. Or the SSH client may have a configuration parameters that do not allow connecting to a host unless the key for the host is in the known-keys file or some information about the key is DNSSEC protected (say foot print or APPKEY). Another option is that resolver get directions from application such as: "Only reture Secure data" There are two ways to get this information between two resolvers via the AD bit, or via some new (unspecified) EDNS option. I (speaking as half of the authors of this document) belive that AD is sufficient, as in most cases application will only care if the answer "secure or not". As pointed out in a later e-mail by Ed Lewis some applications may care about how the answer was reached, for example is the security status verified by a chain leading to the ROOT or to a configured trusted key lower in the tree. AD bit does not help here, ENDS option may. Similary ENDS option may allow the return of both validated and not validated data in the answer and authority sections. > > The applicability of the document isn't clear. If the document is > going to move forward it would need a "safe" applicability statement. > For example, while the blind trust in a resolver might make sense e.g. in > an enterprise network, it doesn't seem to make sense in the home/ISP > setting where the ISP would run the resolver. Agreed, will add some text to this effect. > > The document is not in synch with the dns-threats I-D, which > says: > It is difficult to escape the conclusion that a properly paranoid > resolver must always perform its own signature checking, and that > this rule even applies to stub resolvers. > > That brings us to the motivation for delegating signature verification > to some other entity. Is there an argument that stub resolver signature > checking is too expensive? Are there numbers to back this up? > Or is there a problem that one can't easily get stub resolver to verify > all the signatures while using a recursive resolver to do the recursion? > Thus, apart from the fact that the RFC 2535 definition isn't useful > as it stands, what problem are we trying to solve by making the > definition more useful? The draft version I have right now contains the background on why this work was started: (something like this will be in the next version). - Stub resolvers may not be able to do this work - The local cache is going to do the work anyway so why repeat it? - In the islands of security model maintaining current list of trusted roots for each island in every resolver inside an organization it is simpler to maintain few servers and have all the resolvers trust them. > > Smaller issues > -------------- > > The document doesn't say what "AD" stands for. It makes sense making this > clear early on (e.g. in the abstract and/or introduction). Fixed. > > In section 2 it isn't clear what is the old vs. new behavior. > For example, I think section 2.0 is unchanged behavior, but it could be > new behavior. Is section 2.2 unmodified or new behavior? Both, this is a clarification of what RFC2535 is trying to say. > > The abstract says "current behavior" which is a bit odd since > the document redefines the current behavior. Assuming the > AD bit semantics are defined in RFC 2535, it would make sense > to instead say "the definition of the Authentic Data (AD) bit in RFC 2535 ...". Fixed. > The final paragraph of the Security Considerations is written > in a way that obscures meaning, in contrast to the related > final paragraph of Section 3. > > > Resolvers (full or stub) that blindly trust the AD bit without > > knowing the security policy of the server generating the answer can > > not be considered security aware. > > It isn't clear what "security aware" means here and that using > that undefined term adds any clarity. Security aware is a term from RFC2535 (and RFC2065). Reworded this paragraph to make it more explicit what the intent is. > > I think the point is that the blind trust in the AD bit MUST > only be used in an environment in which configuration somehow ensures > that the security policy of the server is appropriate. > Thus it doesn't make sense to use this, even is a secure channel > with TSIG or SIG(0) is used, when the client might not trust the > recursive resolver, or it doesn't trust how it discovered the > IP address of the recursive resolver. (e.g. using DHCP). Agreed, AD is only for consenting adults to use :-). > > Please split the references into normative and non-normative per > the rfc-editor's instructions. Done. > > > Nits > ---- > > > application running on a host that has trust relationship with the > > s/has/has a/ Fixed. > > The presence of the CD (checking disabled) bit in a query does not > affect the setting of the AD bit in the response. If the CD bit is > set, the server will not perform checking, but SHOULD still set the > AD bit if the data has already been checked or complies with local > policy. The AD bit MUST only be set if DNSSEC records have been > requested [RFC3225] and relevant SIG records are returned. > > wouldn't hurt to better define "checked". I assume this means crypto > sigs verified, or server is authoritative. s/checked/cryptographically verified/ > > This document redefines a bit in the DNS header. If a resolver > trusts the value of the AD bit, it must be sure that the server is > using the updated definition, which is any server supporting the OK > bit. > > reference to OK bit? it was in there but, I added the "OK bit" to be explicit. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 25 04:33:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26484 for ; Tue, 25 Jun 2002 04:33:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17MlcV-0003U6-00 for namedroppers-data@psg.com; Tue, 25 Jun 2002 01:24:15 -0700 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 17MlcR-0003Tu-00; Tue, 25 Jun 2002 01:24:12 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11673; Tue, 25 Jun 2002 01:24:10 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5P8O9b11037; Tue, 25 Jun 2002 10:24:09 +0200 (MEST) Date: Tue, 25 Jun 2002 10:22:50 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IESG feedback on dnsext-ad-is-secure To: Olafur Gudmundsson Cc: Erik Nordmark , Randy Bush , DNSEXT mailing list In-Reply-To: "Your message with ID" <20020625005040.G19695-100000@hlid.dc.ogud.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > In section 2 it isn't clear what is the old vs. new behavior. > > For example, I think section 2.0 is unchanged behavior, but it could be > > new behavior. Is section 2.2 unmodified or new behavior? > > Both, this is a clarification of what RFC2535 is trying to say. It would be more clear if it says e.g. Replace section X.Y in 2535 with blah blah blah or The paragraph in section X.Y in 2535 which says foobar ... is replaced by this document with blah blah blah Erik -- to unsubscribe send a message to namedroppers-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 Jun 26 00:34:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10170 for ; Wed, 26 Jun 2002 00:34:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17N4Cl-0003aW-00 for namedroppers-data@psg.com; Tue, 25 Jun 2002 21:14:55 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17N4Cf-0003aK-00 for namedroppers@ops.ietf.org; Tue, 25 Jun 2002 21:14:49 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17N4Cf-00019n-00 for namedroppers@ops.ietf.org; Tue, 25 Jun 2002 21:14:49 -0700 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Tue, 25 Jun 2002 22:41:36 -0400 (EDT) From: Sam Weiler To: , cc: , Subject: Re: DS code & testing day X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Many thanks to those who sent feedback. We'll be hosting a one-day DS workshop on Wednesday, July 3rd in Rockville, Maryland starting at 9:45AM. The main purpose is to get people working with Nominum's DS code and doing routine zone operations. Some participants will have other implementations and tools, so there'll be a bit of interoperability testing. Please drop a note to dstest@tislabs.com if you'd like to attend. I'll send out trusted keys, delegations, IP assignments, and directions in advance -- let me know if you need any additional information or accomodations. -- Sam On Thu, 20 Jun 2002, Sam Weiler wrote: > I'm pleased to announce the availability of Nominum's BIND DS > implementation. I'll try to send some documentation in the next few > days. > > ftp://ftp.isc.org/isc/bind9/snapshots/bind-9.3.0s20020618.tar.gz > > We (Network Associates Laboratories) have done some testing of this > code, and I think it's ready for more widespread testing. In > particular, I'd like to hold a one (or maybe two) day mini-workshop > before the IETF at our offices in Rockville, Maryland. I understand > that many who would otherwise attend a workshop may be unable to do so > on such short notice and so close to the IETF, but I think there's > much to be gained even if we can't get the usual broad participation. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: