From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Olaf Kolkman Subject: DNSEXT list policy Date: Thu, 1 Apr 2004 08:35:01 +0200 Lines: 190 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Apr 01 08:47:10 2004 Return-path: To: namedroppers@ops.ietf.org X-RIPE-Spam-Level: X-RIPE-Spam-Status: U 0.494479 / 0.0 / 0.0 / disabled X-RIPE-Signature: 925db9d6aa472e94682fd0f2728bccbb Precedence: bulk - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". 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 - Issue Tracker As of October 2003 this group will use an issue tracker. This is to better organize the work-flow, maintain overview over, and focus the discussions to the working group documents. Please stick to the following procedure when discussing working group work documents. == The system The issue tracker can be found at: https://roundup.machshav.com/dnsext/index The chairs are responsible for maintaining the data in the issue tracker. That task may be delegated to document editors. If a document editor prefers other tracking systems they are free to coordinate that with the chairs. == Creating a new issue. New Issue tickets are only created for working group document. If you have an issue a document please sent in a mail with a subject header of the following format ISSUE: Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.4 2003/09/25 08:26:13 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: David Fort <david.fort@irisa.fr> Subject: KROd 1.0rc2 Date: Fri, 02 Apr 2004 15:37:30 +0200 Lines: 24 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-From: owner-namedroppers@ops.ietf.org Fri Apr 02 15:49:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040216 X-Accept-Language: en-us, en To: namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu X-Virus-Scanned: by amavisd-new at irisa.fr Precedence: bulk The IDsA project (http://idsa.irisa.fr/index.php?lang=en) has just the second release candidate for KROd 1.0. KROd is a daemon that automate the keyrollover in DNSSEC. KROd can also be used to "DNSSECify" normal DNS zones. KROd is still an experimental product and as such shouldn't be used in production environment. More informations/downloads can be found here: http://idsa.irisa.fr/index.php?page=kro&lang=en -- Fort David, Projet IDsA IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France Tél: +33 (0) 2 99 84 71 33 -- to 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/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: bmanning@vacation.karoshi.com Subject: Re: KROd 1.0rc2 Date: Fri, 2 Apr 2004 22:04:02 +0000 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <406D6C9A.6070103@irisa.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu X-From: owner-namedroppers@ops.ietf.org Sat Apr 03 00:14:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: David Fort <david.fort@irisa.fr> Content-Disposition: inline In-Reply-To: <406D6C9A.6070103@irisa.fr> User-Agent: Mutt/1.4.1i Precedence: bulk On Fri, Apr 02, 2004 at 03:37:30PM +0200, David Fort wrote: > The IDsA project (http://idsa.irisa.fr/index.php?lang=en) has just the > second release candidate > for KROd 1.0. > KROd is a daemon that automate the keyrollover in DNSSEC. KROd can also be > used to "DNSSECify" normal DNS zones. > KROd is still an experimental product and as such shouldn't be used in > production > environment. > > More informations/downloads can be found here: > http://idsa.irisa.fr/index.php?page=kro&lang=en > > -- > Fort David, Projet IDsA > IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France > Tél: +33 (0) 2 99 84 71 33 very experimental.... "... unable to find the file or directory named /local/idsa/code/kro/KROd-1.0tc2.tar.bz2 Check the name and try again." --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: bmanning@vacation.karoshi.com Subject: Re: KROd 1.0rc2 Date: Fri, 2 Apr 2004 22:11:32 +0000 Lines: 46 Sender: owner-namedroppers@ops.ietf.org References: <406D6C9A.6070103@irisa.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu X-From: owner-namedroppers@ops.ietf.org Sat Apr 03 00:20:54 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: David Fort <david.fort@irisa.fr> Content-Disposition: inline In-Reply-To: <406D6C9A.6070103@irisa.fr> User-Agent: Mutt/1.4.1i Precedence: bulk On Fri, Apr 02, 2004 at 03:37:30PM +0200, David Fort wrote: > KROd is a daemon that automate the keyrollover in DNSSEC. KROd can also be > used to "DNSSECify" normal DNS zones. > KROd is still an experimental product and as such shouldn't be used in > production > environment. > > More informations/downloads can be found here: > http://idsa.irisa.fr/index.php?page=kro&lang=en > > -- > Fort David, Projet IDsA Ah... reverting to the more primative (but in many ways, more flexable) native FTP.... ftp> ls 227 Entering Passive Mode (131,254,254,10,179,49) 150 Opening ASCII mode data connection for /bin/ls. total 2656 drwxr-xr-x 2 4779 29016 8192 Mar 11 16:36 . drwxr-xr-x 10 4779 29016 8192 Feb 16 12:48 .. -rw-r--r-- 1 4779 29016 127417 Feb 16 12:49 DNSsecToolkit-1.0-rc1.tar.gz -rw-r--r-- 1 4779 29016 237854 Feb 23 13:58 DNSsecToolkit-1.0-rc2.tar.gz -rw-r--r-- 1 4779 29016 325688 Mar 1 16:21 DNSsecToolkit-1.0-rc3.tar.gz -rw-r--r-- 1 4779 29016 325963 Mar 11 09:55 DNSsecToolkit-1.0-rc4.tar.gz -rw-r--r-- 1 4779 29016 176701 Feb 16 12:49 KROd-1.0rc1.tar.gz -rw-r----- 1 4779 29016 129864 Mar 11 16:37 KROd-1.0rc2.tar.bz2 226 Transfer complete. ftp> get KROd-1.0rc2.tar.bz2 local: KROd-1.0rc2.tar.bz2 remote: KROd-1.0rc2.tar.bz2 227 Entering Passive Mode (131,254,254,10,112,150) 550 KROd-1.0rc2.tar.bz2: Permission denied. ftp> Please correct the file permissions... and using gzip (like everying else in the directory) would be a nod to consistancy. :) --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: David Fort <david.fort@irisa.fr> Subject: Re: KROd 1.0rc2 Date: Mon, 05 Apr 2004 18:23:48 +0200 Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <406D6C9A.6070103@irisa.fr> <20040402221132.GF13109@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu X-From: owner-namedroppers@ops.ietf.org Mon Apr 05 18:37:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040216 X-Accept-Language: en-us, en In-Reply-To: <20040402221132.GF13109@vacation.karoshi.com.> X-Virus-Scanned: by amavisd-new at irisa.fr Precedence: bulk bmanning@vacation.karoshi.com wrote: >On Fri, Apr 02, 2004 at 03:37:30PM +0200, David Fort wrote: > > >>KROd is a daemon that automate the keyrollover in DNSSEC. KROd can also be >> >> > > [...] >-rw-r--r-- 1 4779 29016 176701 Feb 16 12:49 KROd-1.0rc1.tar.gz >-rw-r----- 1 4779 29016 129864 Mar 11 16:37 KROd-1.0rc2.tar.bz2 >226 Transfer complete. >ftp> get KROd-1.0rc2.tar.bz2 >local: KROd-1.0rc2.tar.bz2 remote: KROd-1.0rc2.tar.bz2 >227 Entering Passive Mode (131,254,254,10,112,150) >550 KROd-1.0rc2.tar.bz2: Permission denied. > > Corrected -- Fort David, Projet IDsA IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France Tél: +33 (0) 2 99 84 71 33 -- to 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/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt Date: Tue, 06 Apr 2004 10:31:11 -0400 Lines: 97 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Apr 06 16:40:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: i-d-announce@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 : Threat Analysis Of The Domain Name System Author(s) : D. Atkins, R. Austein Filename : draft-ietf-dnsext-dns-threats-07.txt Pages : 16 Date : 2004-4-5 Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dns-threats-07.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-dns-threats-07.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: <2004-4-6105221.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dns-threats-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dns-threats-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-6105221.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Scott Rose" <scottr@nist.gov> Subject: Q31: Validator behavior for islands of security Date: Tue, 6 Apr 2004 12:10:18 -0400 Lines: 48 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Tue Apr 06 18:21:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Precedence: bulk Question: What is default behavior when a validator cannot get a secure entry point into an island of security? In proto-05 section 5.1, there is the discussion on the resolution process and islands of security (or self-signed zones with no secure delegation). The last sentence in the first paragraph reads: If a validator cannot obtain such a key, it will have to choose whether to accept the unvalidated responses or not based on local policy. The suggested change: If a validator cannot obtain such a key, it SHOULD switch to operating as if the zones in the island of security are unsigned. Background: RFC 2535 mentions islands of security, but gives no specific handling instructions. RFC 3090 (DNS Security Extensions on Zone Status) section 1.2 states that "The only way in which a DNSSEC resolver will come to trust any data from this island is if the resolver is pre-configured with the zone key(s)... Other resolvers (not so configured) will recognize this island as unsecured." This change attempts to bring the spec in line (and strengthen) with RFC 3090. This question is not an attempt to raise the same topics as DNSSECbis Q28 on how a validator and resolver should act with regards to unsigned or invalid signatures. This has not be explicitly discussed on namedroppers (to my knowledge). Section 5.1 does not go into detail how a validator treats unsigned zones, but that was to be discussed in another section on classifying responses. Simply put, Section 5.1 should only state that the data should be treated as unsigned. How unsigned data is handled by the validator and the info given back to the resolver are discussed in other sections. Deadline: If there is no specific reason not to change this paragraph in Section 5.1, the change will be made by April 19. -- to 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/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Rob Austein <sra@isc.org> Subject: Re: I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt Date: Tue, 06 Apr 2004 12:47:48 -0400 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <200404061431.KAA22469@ietf.org> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Tue Apr 06 18:55:16 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <200404061431.KAA22469@ietf.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Precedence: bulk For those who have not been following the exciting details in the draft tracker: this is the final version of this draft, which addresses the last of the issues that came up during IETF last call and IESG review. As far as the authors know, we are done, and we expect formal IESG publication approval within a few days. We don't think any of the recent changes are controversial, but: a) If anyone thinks there's a show-stopping problem with the changes, speak up now; b) No new issues, please, it's past time to ship this puppy. Change logs available at http://www.hactrn.net/ietf/dns/threats/ --Rob and Derek -- to 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/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt Date: Wed, 07 Apr 2004 20:16:20 +0900 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <200404061431.KAA22469@ietf.org> <20040406164748.1E2C4198D@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Apr 07 13:28:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en To: Rob Austein <sra@isc.org> In-Reply-To: <20040406164748.1E2C4198D@thrintun.hactrn.net> Precedence: bulk Rob Austein wrote: > For those who have not been following the exciting details in the > draft tracker: this is the final version of this draft, which > addresses the last of the issues that came up during IETF last call > and IESG review. As far as the authors know, we are done, and we > expect formal IESG publication approval within a few days. Can someone explain why "Name Chaining attacks" are harmful? As far as I understand, name chaining is, first, to let the victim access a name of attackers choice and, secondly, to let the victim access names of attackers choice. So, if the attacker can control the first name, why it is more harmful that the attacker can control the subsequent accesses? If the attacker can control the first name and the victim is not protected from cache poisoning, the attacker can inject a lot of false information with the first access that I can see no point of chaining. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Scott Rose" <scottr@nist.gov> Subject: RE: I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt Date: Wed, 7 Apr 2004 14:36:25 -0400 Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <20040406164748.1E2C4198D@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Apr 07 20:51:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20040406164748.1E2C4198D@thrintun.hactrn.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Precedence: bulk I think the new version is good. From my reading of the draft "name chaining" sounds like a slightly better term for that class of attacks. I do not see any show-stopper problems. Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Rob Austein > Sent: Tuesday, April 06, 2004 12:48 PM > To: namedroppers@ops.ietf.org > Subject: Re: I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt > > > For those who have not been following the exciting details in the > draft tracker: this is the final version of this draft, which > addresses the last of the issues that came up during IETF last call > and IESG review. As far as the authors know, we are done, and we > expect formal IESG publication approval within a few days. > > We don't think any of the recent changes are controversial, but: > > a) If anyone thinks there's a show-stopping problem with the changes, > speak up now; > > b) No new issues, please, it's past time to ship this puppy. > > Change logs available at http://www.hactrn.net/ietf/dns/threats/ > > --Rob and Derek > > -- > to 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/> > -- to 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/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Scott Rose" <scottr@nist.gov> Subject: DNSSECbis editors' comment on caching TTL Date: Wed, 7 Apr 2004 15:11:36 -0400 Lines: 20 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Apr 07 21:22:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Precedence: bulk Correcting RRSIG expiration time and TTL for caching. In RFC 2535, the TTL for caching an RRset was given as the minimum value of the TTL vs. the value (RRSIG expiration time - current time). However, the current DNSSECbis protocol draft Section 5.3.3, which states how to calculate the TTL based on the DNSSEC records, inadvertently dropped this requirement. Therefore, this requirement for limiting the TTL based on the RRSIG expiry time will be corrected in Section 5.3.3 of the protocol draft. This will bring the protocol draft in line with the original RFC 2535. Thank you, DNSSEC editors group -- to 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/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Rob Austein <sra@isc.org> Subject: Re: I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt Date: Wed, 07 Apr 2004 19:51:44 -0400 Lines: 45 Sender: owner-namedroppers@ops.ietf.org References: <200404061431.KAA22469@ietf.org> <20040406164748.1E2C4198D@thrintun.hactrn.net> <4073E304.40003@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Apr 08 02:10:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <4073E304.40003@necom830.hpcl.titech.ac.jp> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Precedence: bulk At Wed, 07 Apr 2004 20:16:20 +0900, Masataka Ohta wrote: > > Can someone explain why "Name Chaining attacks" are harmful? > > As far as I understand, name chaining is, first, to let the victim > access a name of attackers choice and, secondly, to let the victim > access names of attackers choice. > > So, if the attacker can control the first name, why it is more > harmful that the attacker can control the subsequent accesses? > > If the attacker can control the first name and the victim is not > protected from cache poisoning, the attacker can inject a lot of > false information with the first access that I can see no point of > chaining. Relevance checks can protect against many forms of name-based attacks, but not against name-chaining attacks. Eg, pretend (for purposes of discussion, no insult intended) that you're silly enough to run an HTML-vulnerable MUA, an attacker sends you a web bug linking to http://very.evil.example, and your MUA duely generates a query for very.evil.example. If the name server for evil.example replies to your query for very.evil.example by telling you that important.example.org is at some random IP address (presumably controlled by the attacker), your resolver's relevance checks will reject this response because an answer about important.example.org isn't relevant to a query for very.evil.example. If, however, the name server for evil.example tells you that very.evil.example is served by important.example.org and oh, by the way, here's the address of important.example.org, your resolver will think that the address of important.example.org is relevant, will probably believe it, and will probably cache it. Oops. There are other variants (eg, long CNAME chains), but that's the basic idea. The important characteristic of this class of attacks is that they allow the attacker to introduce a new name into the protocol exchange as a side effect of what looks like a normal protocol operation. -- to 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/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Scott Rose" <scottr@nist.gov> Subject: Q32: Adding the DNSKEY TTL as a factor when determining RRset TTL Date: Thu, 8 Apr 2004 07:25:09 -0400 Lines: 49 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-From: owner-namedroppers@ops.ietf.org Thu Apr 08 13:40:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Precedence: bulk Q32: Adding the DNSKEY TTL as a factor when determining RRset TTL Section 5.3.3 of the protocol document discusses how a cache should calculate the TTL value for a RRset based on a number of factors: - The RRset's TTL as received in the response - The RRSIG RR's TTL as received in the response - The value in the RRSIG RR's Original TTL field - The difference between RRSIG expiration time and the current time. The last being corrected from a previous error on the editors' part. The comment given to the editors group was to add the follow constraint to that list: - The validating DNSKEY’s TTL Discussion: The case for this constraint is that if the DNSKEY has expired, then the RRSIGs it has validated should also expire. The DNSKEY may have rolled over during the time period and the RRSIGs may no longer be valid. It is possibly out of date information. The case against this constraint is that if the DNSKEY is purged from the cache, it does not necessarily mean the RRSIGs have expired (they possibly have not reached their expiration time). The RRSIGs and DNSKEY may still be in use by the authoritative zone. It is the editors' opinion is that this additional constraint is not necessary. If WG members think that it is necessary, please state so and supply text for Section 5.3.3 cache value recommendation. Deadline for discussion is April 19th Default action is to NOT ADD the suggested constraint. Otherwise, please state reason why the constraint is useful and suggest text. Thanks, The DNSSEC editors group -- to 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/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt Date: Mon, 12 Apr 2004 06:56:02 +0900 Lines: 68 Sender: owner-namedroppers@ops.ietf.org References: <200404061431.KAA22469@ietf.org> <20040406164748.1E2C4198D@thrintun.hactrn.net> <4073E304.40003@necom830.hpcl.titech.ac.jp> <20040407235144.A02A818C9@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Apr 12 00:06:42 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en To: Rob Austein <sra@isc.org> In-Reply-To: <20040407235144.A02A818C9@thrintun.hactrn.net> Precedence: bulk Rob Austein; Thank you for the explanation. >>Can someone explain why "Name Chaining attacks" are harmful? >> >>As far as I understand, name chaining is, first, to let the victim >>access a name of attackers choice and, secondly, to let the victim >>access names of attackers choice. >> >>So, if the attacker can control the first name, why it is more >>harmful that the attacker can control the subsequent accesses? >> >>If the attacker can control the first name and the victim is not >>protected from cache poisoning, the attacker can inject a lot of >>false information with the first access that I can see no point of >>chaining. > Relevance checks can protect against many forms of name-based attacks, > but not against name-chaining attacks. That is a result of improper relevance checks, I think. The only meaningful relevance check MUST be (save that for glues) that the names are at or below the zone served by the current server, which is not affected by chaining. If implementations are doing otherwise, they are poor, I believe. > If, however, the name server for evil.example tells you that > very.evil.example is served by important.example.org and oh, by the > way, here's the address of important.example.org, your resolver will > think that the address of important.example.org is relevant, will > probably believe it, and will probably cache it. For a glue, it is necessary to check the dereference point is at or below the zone of the current server and to tag the cache entry of glues with the corresponding dereference points so that the entries are not used for other purposes (normal As or glue As of other dereferences). > There are other variants (eg, long CNAME chains), but that's > the basic idea. It should also be noted that RFC 1035 says: CNAME RRs cause no additional section processing though it is not prohibitted. > The important characteristic of this class of attacks is that they > allow the attacker to introduce a new name into the protocol exchange > as a side effect of what looks like a normal protocol operation. So, I think the threat is essentially that of redirection, protection against which automatically protects against chaining. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: RFC 3363, Section 4. Date: Mon, 19 Apr 2004 07:36:07 +1000 Lines: 38 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Apr 19 07:27:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-RIPE-Spam-Level: X-RIPE-Spam-Status: U 0.275274 / 0.0 / 0.0 / disabled X-RIPE-Signature: 83766425a2964eab0d5b45a3ef9c2597 Precedence: bulk 4. DNAME in IPv6 Reverse Tree The issues for DNAME in the reverse mapping tree appears to be closely tied to the need to use fragmented A6 in the main tree: if one is necessary, so is the other, and if one isn't necessary, the other isn't either. Therefore, in moving RFC 2874 to experimental, the intent of this document is that use of DNAME RRs in the reverse tree be deprecated. I think we should get RFC 3363 re-issued without Section 4. The reasons for this are: 1. The opening premise of Section 4 is clearly invalid. 2. There is a lot of confusion of what is the extent of Section 4. Some people see it as killing DNAME completely which is false. This has come up in nanog, ipv6 and even dnsext communities. 3. We shouldn't be restricting where we can use DNAME in the first place. DNAME was allowed to be use *everywhere* in the DNS namespace before RFC 2874. 4. There are currently two drafts in progress that attempted to overstate what was ment by Section 5. We won't be able to catch them all. If RFC 3363 is re-issued, we can just refer them to this document. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From ietf-announce-admin@ietf.org Fri Dec 29 10:45:51 2006 From: The IESG <iesg-secretary@ietf.org> Subject: Document Action: 'Threat Analysis Of The Domain Name System' to Informational RFC Date: Thu, 22 Apr 2004 12:59:02 -0400 Lines: 34 Sender: ietf-announce-admin@ietf.org Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>, dnsext mailing list <namedroppers@ops.ietf.org>, dnsext chair <ogud@ogud.com>, dnsext chair <okolkman@ripe.net> X-From: ietf-announce-admin@ietf.org Thu Apr 22 21:39:06 2004 Return-path: <ietf-announce-admin@ietf.org> X-test-idtracker: no To: IETF-Announce:; X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Errors-To: ietf-announce-admin@ietf.org X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe> List-Id: <ietf-announce.ietf.org> List-Post: <mailto:ietf-announce@ietf.org> List-Help: <mailto:ietf-announce-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe> The IESG has approved the following document: - 'Threat Analysis Of The Domain Name System ' <draft-ietf-dnsext-dns-threats-07.txt> as an Informational RFC This document is the product of the DNS Extensions Working Group. The IESG contact persons are Thomas Narten and Margaret Wasserman. Technical Summary Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. Working Group Summary Protocol Quality This document has been reviewed for the IESG by Thomas Narten. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Olaf Kolkman <olaf@ripe.net> Subject: DNSEXT list policy Date: Thu, 1 Apr 2004 08:35:01 +0200 Lines: 190 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Apr 01 08:47:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-RIPE-Spam-Level: X-RIPE-Spam-Status: U 0.494479 / 0.0 / 0.0 / disabled X-RIPE-Signature: 925db9d6aa472e94682fd0f2728bccbb Precedence: bulk - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See <http://www.ietf.org/html.charters/dnsext-charter.html> for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at <http://www.ietf.org/html.charters/dnsop-charter.html>. Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". 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 - Issue Tracker As of October 2003 this group will use an issue tracker. This is to better organize the work-flow, maintain overview over, and focus the discussions to the working group documents. Please stick to the following procedure when discussing working group work documents. == The system The issue tracker can be found at: https://roundup.machshav.com/dnsext/index The chairs are responsible for maintaining the data in the issue tracker. That task may be delegated to document editors. If a document editor prefers other tracking systems they are free to coordinate that with the chairs. == Creating a new issue. New Issue tickets are only created for working group document. If you have an issue a document please sent in a mail with a subject header of the following format <NAME> ISSUE: <title> Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.4 2003/09/25 08:26:13 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: David Fort <david.fort@irisa.fr> Subject: KROd 1.0rc2 Date: Fri, 02 Apr 2004 15:37:30 +0200 Lines: 24 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-From: owner-namedroppers@ops.ietf.org Fri Apr 02 15:49:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040216 X-Accept-Language: en-us, en To: namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu X-Virus-Scanned: by amavisd-new at irisa.fr Precedence: bulk The IDsA project (http://idsa.irisa.fr/index.php?lang=en) has just the second release candidate for KROd 1.0. KROd is a daemon that automate the keyrollover in DNSSEC. KROd can also be used to "DNSSECify" normal DNS zones. KROd is still an experimental product and as such shouldn't be used in production environment. More informations/downloads can be found here: http://idsa.irisa.fr/index.php?page=kro&lang=en -- Fort David, Projet IDsA IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France Tél: +33 (0) 2 99 84 71 33 -- to 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/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: bmanning@vacation.karoshi.com Subject: Re: KROd 1.0rc2 Date: Fri, 2 Apr 2004 22:04:02 +0000 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <406D6C9A.6070103@irisa.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu X-From: owner-namedroppers@ops.ietf.org Sat Apr 03 00:14:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: David Fort <david.fort@irisa.fr> Content-Disposition: inline In-Reply-To: <406D6C9A.6070103@irisa.fr> User-Agent: Mutt/1.4.1i Precedence: bulk On Fri, Apr 02, 2004 at 03:37:30PM +0200, David Fort wrote: > The IDsA project (http://idsa.irisa.fr/index.php?lang=en) has just the > second release candidate > for KROd 1.0. > KROd is a daemon that automate the keyrollover in DNSSEC. KROd can also be > used to "DNSSECify" normal DNS zones. > KROd is still an experimental product and as such shouldn't be used in > production > environment. > > More informations/downloads can be found here: > http://idsa.irisa.fr/index.php?page=kro&lang=en > > -- > Fort David, Projet IDsA > IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France > Tél: +33 (0) 2 99 84 71 33 very experimental.... "... unable to find the file or directory named /local/idsa/code/kro/KROd-1.0tc2.tar.bz2 Check the name and try again." --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: bmanning@vacation.karoshi.com Subject: Re: KROd 1.0rc2 Date: Fri, 2 Apr 2004 22:11:32 +0000 Lines: 46 Sender: owner-namedroppers@ops.ietf.org References: <406D6C9A.6070103@irisa.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu X-From: owner-namedroppers@ops.ietf.org Sat Apr 03 00:20:54 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: David Fort <david.fort@irisa.fr> Content-Disposition: inline In-Reply-To: <406D6C9A.6070103@irisa.fr> User-Agent: Mutt/1.4.1i Precedence: bulk On Fri, Apr 02, 2004 at 03:37:30PM +0200, David Fort wrote: > KROd is a daemon that automate the keyrollover in DNSSEC. KROd can also be > used to "DNSSECify" normal DNS zones. > KROd is still an experimental product and as such shouldn't be used in > production > environment. > > More informations/downloads can be found here: > http://idsa.irisa.fr/index.php?page=kro&lang=en > > -- > Fort David, Projet IDsA Ah... reverting to the more primative (but in many ways, more flexable) native FTP.... ftp> ls 227 Entering Passive Mode (131,254,254,10,179,49) 150 Opening ASCII mode data connection for /bin/ls. total 2656 drwxr-xr-x 2 4779 29016 8192 Mar 11 16:36 . drwxr-xr-x 10 4779 29016 8192 Feb 16 12:48 .. -rw-r--r-- 1 4779 29016 127417 Feb 16 12:49 DNSsecToolkit-1.0-rc1.tar.gz -rw-r--r-- 1 4779 29016 237854 Feb 23 13:58 DNSsecToolkit-1.0-rc2.tar.gz -rw-r--r-- 1 4779 29016 325688 Mar 1 16:21 DNSsecToolkit-1.0-rc3.tar.gz -rw-r--r-- 1 4779 29016 325963 Mar 11 09:55 DNSsecToolkit-1.0-rc4.tar.gz -rw-r--r-- 1 4779 29016 176701 Feb 16 12:49 KROd-1.0rc1.tar.gz -rw-r----- 1 4779 29016 129864 Mar 11 16:37 KROd-1.0rc2.tar.bz2 226 Transfer complete. ftp> get KROd-1.0rc2.tar.bz2 local: KROd-1.0rc2.tar.bz2 remote: KROd-1.0rc2.tar.bz2 227 Entering Passive Mode (131,254,254,10,112,150) 550 KROd-1.0rc2.tar.bz2: Permission denied. ftp> Please correct the file permissions... and using gzip (like everying else in the directory) would be a nod to consistancy. :) --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: David Fort <david.fort@irisa.fr> Subject: Re: KROd 1.0rc2 Date: Mon, 05 Apr 2004 18:23:48 +0200 Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <406D6C9A.6070103@irisa.fr> <20040402221132.GF13109@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu X-From: owner-namedroppers@ops.ietf.org Mon Apr 05 18:37:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040216 X-Accept-Language: en-us, en In-Reply-To: <20040402221132.GF13109@vacation.karoshi.com.> X-Virus-Scanned: by amavisd-new at irisa.fr Precedence: bulk bmanning@vacation.karoshi.com wrote: >On Fri, Apr 02, 2004 at 03:37:30PM +0200, David Fort wrote: > > >>KROd is a daemon that automate the keyrollover in DNSSEC. KROd can also be >> >> > > [...] >-rw-r--r-- 1 4779 29016 176701 Feb 16 12:49 KROd-1.0rc1.tar.gz >-rw-r----- 1 4779 29016 129864 Mar 11 16:37 KROd-1.0rc2.tar.bz2 >226 Transfer complete. >ftp> get KROd-1.0rc2.tar.bz2 >local: KROd-1.0rc2.tar.bz2 remote: KROd-1.0rc2.tar.bz2 >227 Entering Passive Mode (131,254,254,10,112,150) >550 KROd-1.0rc2.tar.bz2: Permission denied. > > Corrected -- Fort David, Projet IDsA IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France Tél: +33 (0) 2 99 84 71 33 -- to 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/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt Date: Tue, 06 Apr 2004 10:31:11 -0400 Lines: 97 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Apr 06 16:40:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: i-d-announce@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 : Threat Analysis Of The Domain Name System Author(s) : D. Atkins, R. Austein Filename : draft-ietf-dnsext-dns-threats-07.txt Pages : 16 Date : 2004-4-5 Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dns-threats-07.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-dns-threats-07.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: <2004-4-6105221.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dns-threats-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dns-threats-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-6105221.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Scott Rose" <scottr@nist.gov> Subject: Q31: Validator behavior for islands of security Date: Tue, 6 Apr 2004 12:10:18 -0400 Lines: 48 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Tue Apr 06 18:21:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Precedence: bulk Question: What is default behavior when a validator cannot get a secure entry point into an island of security? In proto-05 section 5.1, there is the discussion on the resolution process and islands of security (or self-signed zones with no secure delegation). The last sentence in the first paragraph reads: If a validator cannot obtain such a key, it will have to choose whether to accept the unvalidated responses or not based on local policy. The suggested change: If a validator cannot obtain such a key, it SHOULD switch to operating as if the zones in the island of security are unsigned. Background: RFC 2535 mentions islands of security, but gives no specific handling instructions. RFC 3090 (DNS Security Extensions on Zone Status) section 1.2 states that "The only way in which a DNSSEC resolver will come to trust any data from this island is if the resolver is pre-configured with the zone key(s)... Other resolvers (not so configured) will recognize this island as unsecured." This change attempts to bring the spec in line (and strengthen) with RFC 3090. This question is not an attempt to raise the same topics as DNSSECbis Q28 on how a validator and resolver should act with regards to unsigned or invalid signatures. This has not be explicitly discussed on namedroppers (to my knowledge). Section 5.1 does not go into detail how a validator treats unsigned zones, but that was to be discussed in another section on classifying responses. Simply put, Section 5.1 should only state that the data should be treated as unsigned. How unsigned data is handled by the validator and the info given back to the resolver are discussed in other sections. Deadline: If there is no specific reason not to change this paragraph in Section 5.1, the change will be made by April 19. -- to 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/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Rob Austein <sra@isc.org> Subject: Re: I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt Date: Tue, 06 Apr 2004 12:47:48 -0400 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <200404061431.KAA22469@ietf.org> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Tue Apr 06 18:55:16 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <200404061431.KAA22469@ietf.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Precedence: bulk For those who have not been following the exciting details in the draft tracker: this is the final version of this draft, which addresses the last of the issues that came up during IETF last call and IESG review. As far as the authors know, we are done, and we expect formal IESG publication approval within a few days. We don't think any of the recent changes are controversial, but: a) If anyone thinks there's a show-stopping problem with the changes, speak up now; b) No new issues, please, it's past time to ship this puppy. Change logs available at http://www.hactrn.net/ietf/dns/threats/ --Rob and Derek -- to 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/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt Date: Wed, 07 Apr 2004 20:16:20 +0900 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <200404061431.KAA22469@ietf.org> <20040406164748.1E2C4198D@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Apr 07 13:28:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en To: Rob Austein <sra@isc.org> In-Reply-To: <20040406164748.1E2C4198D@thrintun.hactrn.net> Precedence: bulk Rob Austein wrote: > For those who have not been following the exciting details in the > draft tracker: this is the final version of this draft, which > addresses the last of the issues that came up during IETF last call > and IESG review. As far as the authors know, we are done, and we > expect formal IESG publication approval within a few days. Can someone explain why "Name Chaining attacks" are harmful? As far as I understand, name chaining is, first, to let the victim access a name of attackers choice and, secondly, to let the victim access names of attackers choice. So, if the attacker can control the first name, why it is more harmful that the attacker can control the subsequent accesses? If the attacker can control the first name and the victim is not protected from cache poisoning, the attacker can inject a lot of false information with the first access that I can see no point of chaining. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Scott Rose" <scottr@nist.gov> Subject: RE: I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt Date: Wed, 7 Apr 2004 14:36:25 -0400 Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <20040406164748.1E2C4198D@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Apr 07 20:51:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20040406164748.1E2C4198D@thrintun.hactrn.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Precedence: bulk I think the new version is good. From my reading of the draft "name chaining" sounds like a slightly better term for that class of attacks. I do not see any show-stopper problems. Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Rob Austein > Sent: Tuesday, April 06, 2004 12:48 PM > To: namedroppers@ops.ietf.org > Subject: Re: I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt > > > For those who have not been following the exciting details in the > draft tracker: this is the final version of this draft, which > addresses the last of the issues that came up during IETF last call > and IESG review. As far as the authors know, we are done, and we > expect formal IESG publication approval within a few days. > > We don't think any of the recent changes are controversial, but: > > a) If anyone thinks there's a show-stopping problem with the changes, > speak up now; > > b) No new issues, please, it's past time to ship this puppy. > > Change logs available at http://www.hactrn.net/ietf/dns/threats/ > > --Rob and Derek > > -- > to 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/> > -- to 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/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Scott Rose" <scottr@nist.gov> Subject: DNSSECbis editors' comment on caching TTL Date: Wed, 7 Apr 2004 15:11:36 -0400 Lines: 20 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Apr 07 21:22:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Precedence: bulk Correcting RRSIG expiration time and TTL for caching. In RFC 2535, the TTL for caching an RRset was given as the minimum value of the TTL vs. the value (RRSIG expiration time - current time). However, the current DNSSECbis protocol draft Section 5.3.3, which states how to calculate the TTL based on the DNSSEC records, inadvertently dropped this requirement. Therefore, this requirement for limiting the TTL based on the RRSIG expiry time will be corrected in Section 5.3.3 of the protocol draft. This will bring the protocol draft in line with the original RFC 2535. Thank you, DNSSEC editors group -- to 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/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Rob Austein <sra@isc.org> Subject: Re: I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt Date: Wed, 07 Apr 2004 19:51:44 -0400 Lines: 45 Sender: owner-namedroppers@ops.ietf.org References: <200404061431.KAA22469@ietf.org> <20040406164748.1E2C4198D@thrintun.hactrn.net> <4073E304.40003@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Apr 08 02:10:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <4073E304.40003@necom830.hpcl.titech.ac.jp> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Precedence: bulk At Wed, 07 Apr 2004 20:16:20 +0900, Masataka Ohta wrote: > > Can someone explain why "Name Chaining attacks" are harmful? > > As far as I understand, name chaining is, first, to let the victim > access a name of attackers choice and, secondly, to let the victim > access names of attackers choice. > > So, if the attacker can control the first name, why it is more > harmful that the attacker can control the subsequent accesses? > > If the attacker can control the first name and the victim is not > protected from cache poisoning, the attacker can inject a lot of > false information with the first access that I can see no point of > chaining. Relevance checks can protect against many forms of name-based attacks, but not against name-chaining attacks. Eg, pretend (for purposes of discussion, no insult intended) that you're silly enough to run an HTML-vulnerable MUA, an attacker sends you a web bug linking to http://very.evil.example, and your MUA duely generates a query for very.evil.example. If the name server for evil.example replies to your query for very.evil.example by telling you that important.example.org is at some random IP address (presumably controlled by the attacker), your resolver's relevance checks will reject this response because an answer about important.example.org isn't relevant to a query for very.evil.example. If, however, the name server for evil.example tells you that very.evil.example is served by important.example.org and oh, by the way, here's the address of important.example.org, your resolver will think that the address of important.example.org is relevant, will probably believe it, and will probably cache it. Oops. There are other variants (eg, long CNAME chains), but that's the basic idea. The important characteristic of this class of attacks is that they allow the attacker to introduce a new name into the protocol exchange as a side effect of what looks like a normal protocol operation. -- to 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/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Scott Rose" <scottr@nist.gov> Subject: Q32: Adding the DNSKEY TTL as a factor when determining RRset TTL Date: Thu, 8 Apr 2004 07:25:09 -0400 Lines: 49 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-From: owner-namedroppers@ops.ietf.org Thu Apr 08 13:40:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Precedence: bulk Q32: Adding the DNSKEY TTL as a factor when determining RRset TTL Section 5.3.3 of the protocol document discusses how a cache should calculate the TTL value for a RRset based on a number of factors: - The RRset's TTL as received in the response - The RRSIG RR's TTL as received in the response - The value in the RRSIG RR's Original TTL field - The difference between RRSIG expiration time and the current time. The last being corrected from a previous error on the editors' part. The comment given to the editors group was to add the follow constraint to that list: - The validating DNSKEY’s TTL Discussion: The case for this constraint is that if the DNSKEY has expired, then the RRSIGs it has validated should also expire. The DNSKEY may have rolled over during the time period and the RRSIGs may no longer be valid. It is possibly out of date information. The case against this constraint is that if the DNSKEY is purged from the cache, it does not necessarily mean the RRSIGs have expired (they possibly have not reached their expiration time). The RRSIGs and DNSKEY may still be in use by the authoritative zone. It is the editors' opinion is that this additional constraint is not necessary. If WG members think that it is necessary, please state so and supply text for Section 5.3.3 cache value recommendation. Deadline for discussion is April 19th Default action is to NOT ADD the suggested constraint. Otherwise, please state reason why the constraint is useful and suggest text. Thanks, The DNSSEC editors group -- to 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/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: I-D ACTION:draft-ietf-dnsext-dns-threats-07.txt Date: Mon, 12 Apr 2004 06:56:02 +0900 Lines: 68 Sender: owner-namedroppers@ops.ietf.org References: <200404061431.KAA22469@ietf.org> <20040406164748.1E2C4198D@thrintun.hactrn.net> <4073E304.40003@necom830.hpcl.titech.ac.jp> <20040407235144.A02A818C9@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Apr 12 00:06:42 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en To: Rob Austein <sra@isc.org> In-Reply-To: <20040407235144.A02A818C9@thrintun.hactrn.net> Precedence: bulk Rob Austein; Thank you for the explanation. >>Can someone explain why "Name Chaining attacks" are harmful? >> >>As far as I understand, name chaining is, first, to let the victim >>access a name of attackers choice and, secondly, to let the victim >>access names of attackers choice. >> >>So, if the attacker can control the first name, why it is more >>harmful that the attacker can control the subsequent accesses? >> >>If the attacker can control the first name and the victim is not >>protected from cache poisoning, the attacker can inject a lot of >>false information with the first access that I can see no point of >>chaining. > Relevance checks can protect against many forms of name-based attacks, > but not against name-chaining attacks. That is a result of improper relevance checks, I think. The only meaningful relevance check MUST be (save that for glues) that the names are at or below the zone served by the current server, which is not affected by chaining. If implementations are doing otherwise, they are poor, I believe. > If, however, the name server for evil.example tells you that > very.evil.example is served by important.example.org and oh, by the > way, here's the address of important.example.org, your resolver will > think that the address of important.example.org is relevant, will > probably believe it, and will probably cache it. For a glue, it is necessary to check the dereference point is at or below the zone of the current server and to tag the cache entry of glues with the corresponding dereference points so that the entries are not used for other purposes (normal As or glue As of other dereferences). > There are other variants (eg, long CNAME chains), but that's > the basic idea. It should also be noted that RFC 1035 says: CNAME RRs cause no additional section processing though it is not prohibitted. > The important characteristic of this class of attacks is that they > allow the attacker to introduce a new name into the protocol exchange > as a side effect of what looks like a normal protocol operation. So, I think the threat is essentially that of redirection, protection against which automatically protects against chaining. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: RFC 3363, Section 4. Date: Mon, 19 Apr 2004 07:36:07 +1000 Lines: 38 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Apr 19 07:27:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-RIPE-Spam-Level: X-RIPE-Spam-Status: U 0.275274 / 0.0 / 0.0 / disabled X-RIPE-Signature: 83766425a2964eab0d5b45a3ef9c2597 Precedence: bulk 4. DNAME in IPv6 Reverse Tree The issues for DNAME in the reverse mapping tree appears to be closely tied to the need to use fragmented A6 in the main tree: if one is necessary, so is the other, and if one isn't necessary, the other isn't either. Therefore, in moving RFC 2874 to experimental, the intent of this document is that use of DNAME RRs in the reverse tree be deprecated. I think we should get RFC 3363 re-issued without Section 4. The reasons for this are: 1. The opening premise of Section 4 is clearly invalid. 2. There is a lot of confusion of what is the extent of Section 4. Some people see it as killing DNAME completely which is false. This has come up in nanog, ipv6 and even dnsext communities. 3. We shouldn't be restricting where we can use DNAME in the first place. DNAME was allowed to be use *everywhere* in the DNS namespace before RFC 2874. 4. There are currently two drafts in progress that attempted to overstate what was ment by Section 5. We won't be able to catch them all. If RFC 3363 is re-issued, we can just refer them to this document. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From ietf-announce-admin@ietf.org Fri Dec 29 10:45:51 2006 From: The IESG <iesg-secretary@ietf.org> Subject: Document Action: 'Threat Analysis Of The Domain Name System' to Informational RFC Date: Thu, 22 Apr 2004 12:59:02 -0400 Lines: 34 Sender: ietf-announce-admin@ietf.org Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>, dnsext mailing list <namedroppers@ops.ietf.org>, dnsext chair <ogud@ogud.com>, dnsext chair <okolkman@ripe.net> X-From: ietf-announce-admin@ietf.org Thu Apr 22 21:39:06 2004 Return-path: <ietf-announce-admin@ietf.org> X-test-idtracker: no To: IETF-Announce:; X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Errors-To: ietf-announce-admin@ietf.org X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe> List-Id: <ietf-announce.ietf.org> List-Post: <mailto:ietf-announce@ietf.org> List-Help: <mailto:ietf-announce-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe> The IESG has approved the following document: - 'Threat Analysis Of The Domain Name System ' <draft-ietf-dnsext-dns-threats-07.txt> as an Informational RFC This document is the product of the DNS Extensions Working Group. The IESG contact persons are Thomas Narten and Margaret Wasserman. Technical Summary Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. Working Group Summary Protocol Quality This document has been reviewed for the IESG by Thomas Narten. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce