From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:42 2006 From: Nobumichi Ozoe Subject: DNS conformance test Date: Fri, 30 Sep 2005 23:45:01 +0900 Lines: 28 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri Sep 30 17:00:49 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: ja, en-us, en To: namedroppers@ops.ietf.org X-OriginalArrivalTime: 30 Sep 2005 14:45:01.0862 (UTC) FILETIME=[89AB9C60:01C5C5CD] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi all, The TAHI project wants to inform you of advancing the test development though only gradually. We are now writing test specification for DNS. Please see the following URL if you are interested. http://www.tahi.org/dns/ http://www.tahi.org/dns/spec/ Bes regards, PS. ETSI plugtests still accept application:-) -- Nobumichi Ozoe IPv6 Business Network & Software Development Dept. Yokogawa Electric Corporation E-mail: Nobumichi.Ozoe@jp.yokogawa.com URL: http://www.yokogawa.com/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:42 2006 From: Olaf Kolkman Subject: DNSEXT list policy Date: Sat, 1 Oct 2005 08:35:00 +0200 (CEST) Lines: 83 X-From: owner-namedroppers@ops.ietf.org Sat Oct 01 08:46:23 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". To counter a certain class of spam mails messages over 20000 characters, originating from list subscribers, will be held for moderations. Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e. follup with area directors, then iesg, etc.). There is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.8 2005/01/12 15:54:51 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:42 2006 From: bert hubert Subject: DNSSEC explanation, comments? Date: Sat, 1 Oct 2005 14:55:14 +0200 Lines: 37 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sat Oct 01 15:06:57 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 To: namedroppers@ops.ietf.org Content-Disposition: inline User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi everybody, After talking to people at the DENIC Technical Meeting this week I've decided to take another look at DNSSEC(-bis) for possible inclusion in PowerDNS. For me the way to understand things is to document them somewhat and to this end I've written http://ds9a.nl/dnssec/ (source: http://ds9a.nl/dnssec/dnssec.xml should you be inclined to send patches) I'm fully aware I know little about DNSSEC so there are bound to be technical mistakes in the document above, and I'm interested in hearing about them. If after a while it turns out that the page above has become technically correct, I can give it some wider dissemination. I think it makes good prior-reading material for Olaf's HOWTO. I'd also like to request that we do not turn this into a discussion on my personal ideas about DNSSEC (which are that I'm not sure if it is useful), if at all possible. Thanks! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:42 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-44.txt Date: Mon, 03 Oct 2005 15:50:02 -0400 Lines: 93 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Oct 03 22:03:40 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 To: i-d-announce@ietf.org 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 : Linklocal Multicast Name Resolution (LLMNR) Author(s) : B. Aboba, et al. Filename : draft-ietf-dnsext-mdns-44.txt Pages : 30 Date : 2005-10-3 The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-44.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-mdns-44.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-mdns-44.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-3122351.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-44.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-44.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-3122351.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 Dec 29 11:36:42 2006 From: "Olaf M. Kolkman" Subject: Re: comments on p-s Date: Tue, 4 Oct 2005 15:32:43 +0200 Lines: 45 References: <200509220808.j8M88Q2K018623@staff.nominet.org.uk> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Oct 04 15:45:37 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 In-Reply-To: <200509220808.j8M88Q2K018623@staff.nominet.org.uk> To: Geoffrey Sisson X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > Thanks for the thorough review; A revised (pre-submitted) draft is > available at: > > http://www.panix.com/~geoff/draft-ietf-dnsext-dns-name-p- > s-01pre1.txt > > An rfcdiff of -00 to -01pre1 is available at: > > http://www.panix.com/~geoff/draft-ietf-dnsext-dns-name-p- > s-01pre1-from-00.diff.html > > Comments inline: Discussion seemed to have died. Could you please submit 01 so the white lies documents can be forwarded. Thanks, - --Olaf - ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ We have employment opportunities, see the website. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDQoR7tN/ca3YJIocRAlUZAKCWPjDaLNVdv57umQVLWjm/XqJCuACg3vgR hpitNXh+QXOk2cGmd9ML9Jw= =534N -----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 Fri Dec 29 11:36:42 2006 From: "Olaf M. Kolkman" Subject: Rollover pointed questions. Date: Wed, 5 Oct 2005 10:09:02 +0200 Lines: 96 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Oct 05 10:19:19 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Namedroppers X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Colleagues, We would like to get some forward motion on key management. With reference to http://ops.ietf.org/lists/namedroppers/namedroppers. 2005/msg01280.html. I am opening a new thread and ask variations of the pointed questions that Paul suggested. For the purpose of this mail there are two angles on the key- management issue: - Initial distribution of trust-anchors - Maintenance of existing trust-anchors, or automatic rollovers. = Can DNSSEC be deployed without key management protocols? * Is either angle of the key-management issue a tools issue only or do we need to standardize the behavior on both sides of the wire. * Do we need one unique solution? = Is the trustupdate-timers draft [1] a proposal that provides sufficient basis for a rollover protocol * What essential parts seem to be missing, if any. * The requirements for this work have never been spelled out. Do you requirements that are not being addressed in the draft? * Are there competing proposals that provide better solutions? * Either because they have no IPR claims or have non- restrictive licensing [*] * They are better engineered * Is [2] an alternative that needs to be kept alive? If so do we have a volunteer editor? = Should the work on initial distribution of trust anchors be continued in this group. * Are the requirements for this work clear enough? ... huh.. which requirements :-) * Are the proposals available now (in parts of [2] and in [3]) sufficient basis for continued work? * Is there sufficient commitment to do this work in DNSEXT? + Should we spawn off a BOF/WG in order to do this work? If there is not further discussion we will last call the trust update timers draft (shortly after the Vancouver IETF) and propose that no further work in DNSEXT is done on the initial distribution of trust anchors. - - --Olaf Kolkman DNSEXT co chair. [1] http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-trustupdate- timers/ [2] http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-trustupdate- threshold/draft-ietf-dnsext-trustupdate-threshold-00.txt [3] http://ietfreport.isoc.org/idref/draft-laurie-dnssec-key- distribution/ [*] The IPR claim itself is not something we want to discuss. We want to avoid rat holing on licensing discussions so please carefully state your arguments and state them only once. - ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDQ4oetN/ca3YJIocRAn1UAJ4yT29BoLum9tkIbAoWuILcHssrfgCfaAiS mZXdwk6aNlEDvfzazln6udY= =DXYI -----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 Fri Dec 29 11:36:42 2006 From: Mike StJohns Subject: Re: Rollover pointed questions. Date: Wed, 05 Oct 2005 13:47:32 -0400 Lines: 65 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Wed Oct 05 19:58:18 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 To: "Olaf M. Kolkman" , Namedroppers In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 04:09 AM 10/5/2005, Olaf M. Kolkman wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >Dear Colleagues, > >We would like to get some forward motion on key management. > >With reference to http://ops.ietf.org/lists/namedroppers/namedroppers. >2005/msg01280.html. >I am opening a new thread and ask variations of the pointed >questions that Paul suggested. > >For the purpose of this mail there are two angles on the key- management >issue: > - Initial distribution of trust-anchors > - Maintenance of existing trust-anchors, or automatic rollovers. > >= Can DNSSEC be deployed without key management protocols? Yes, but.... For keys that aren't trust anchors, the management protocols exist already. We can deploy a system where we don't have a way of rolling a trust anchor, but a compromise of the anchor could have some interesting consequences if DNSSEC became relied upon. > * Is either angle of the key-management issue a tools issue only >or do we > need to standardize the behavior on both sides of the wire. I don't quite understand this question, but let me try to parse it. The possible engineering approaches here basically resolve to one of two paths - either we do this inband with DNS or we do it out of band with another protocol. In some ways that may be a more appropriate approach. An out-of-band (from DNS) approach isn't part of either proposal. If we do it with DNS we have some limitations. Since DNSSEC is a one-way data protocol (e.g. the client can't interact directly with the publisher of the data (publisher != server)) what needs to be standardized is the behavior of the client to the receipt of data. Think of it this way - what would you do if you approached a stop light in the US and the light turned from green to yellow then back to green? You can't send a query back to the stop light asking what it meant, you have to understand the meaning from what you saw. So with DNSSEC the client can only take actions based on what it sees. So its more of a client behavior problem than anything else. > * Do we need one unique solution? This question also has at least one branch which further complicates the engineering. E.g. Do we need one unique solution at any given trust point? If so, how does the client determine which applies to which trust point? I think the answer to the question is probably yes. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:42 2006 From: "Olaf M. Kolkman" Subject: WGLC: Name Server Identifier Option Date: Wed, 5 Oct 2005 20:04:14 +0200 Lines: 64 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Oct 05 20:14:59 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Namedroppers X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear colleagues, In Paris we promised to process the NSID draft as soon as possible after it appeared. Its been around for a month, so we are late with this working group last call for: DNS Name Server Identifier Option (NSID) draft-ietf-dnsext-nsid-00 Abstract With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. While existing ad-hoc mechanism allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server which responded is to have the name server include this information in the response itself. This note defines a protocol extension to support this functionality. Please review your draft and state your support. Technical content should be addressed on the list editorial nits can be send to the document editor with a CC to the chairs. If there is little or no feedback the default action will be to forward this document to the IESG to be published on the standards track. The last call terminates Saturday the 22nd of October. - - --Olaf and Olafur DNSEXT Chairs. - ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ We have employment opportunities, see the website. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDRBWjtN/ca3YJIocRAsegAKDJmDbrkCpzcRFFAL4oJVnLthEEWwCfbsvz dUrISZ4GDIxLVWusw0WKmVo= =S3bu -----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 Fri Dec 29 11:36:42 2006 From: bmanning@vacation.karoshi.com Subject: Re: Fwd: Summary of the LLMNR Last Call Date: Wed, 5 Oct 2005 18:14:09 +0000 Lines: 14 References: <20050921171259.9F0EF11449@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Oct 05 20:22:16 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 To: Paul Vixie Content-Disposition: inline In-Reply-To: <20050921171259.9F0EF11449@sa.vix.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > 1. the right way to do multicast DNS is draft-manning-opcode-discover-01, > and while apple and microsoft both call their approaches "multicast dns" > they are really "overloading dns to carry service discovery in multicast". this ID is in the RFC-ed queue after -six- years of bouncing btwn IETF wg and IESG concerns. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:42 2006 From: Ben Laurie Subject: Re: Rollover pointed questions. Date: Thu, 06 Oct 2005 07:17:08 +0100 Lines: 57 References: <6.2.1.2.2.20051005132115.08449740@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Olaf M. Kolkman" , Namedroppers X-From: owner-namedroppers@ops.ietf.org Thu Oct 06 08:31:07 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: Mike StJohns In-Reply-To: <6.2.1.2.2.20051005132115.08449740@localhost> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mike StJohns wrote: > At 04:09 AM 10/5/2005, Olaf M. Kolkman wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> Dear Colleagues, >> >> We would like to get some forward motion on key management. >> >> With reference to http://ops.ietf.org/lists/namedroppers/namedroppers. >> 2005/msg01280.html. >> I am opening a new thread and ask variations of the pointed >> questions that Paul suggested. >> >> For the purpose of this mail there are two angles on the key- >> management issue: >> - Initial distribution of trust-anchors >> - Maintenance of existing trust-anchors, or automatic rollovers. >> >> = Can DNSSEC be deployed without key management protocols? > > > Yes, but.... For keys that aren't trust anchors, the management > protocols exist already. We can deploy a system where we don't have a > way of rolling a trust anchor, but a compromise of the anchor could have > some interesting consequences if DNSSEC became relied upon. > >> * Is either angle of the key-management issue a tools issue only >> or do we >> need to standardize the behavior on both sides of the wire. > > > I don't quite understand this question, but let me try to parse it. > > The possible engineering approaches here basically resolve to one of two > paths - either we do this inband with DNS or we do it out of band with > another protocol. In some ways that may be a more appropriate > approach. An out-of-band (from DNS) approach isn't part of either > proposal. However, http://ietfreport.isoc.org/idref/draft-laurie-dnssec-key- distribution/ is out-of-band and could just as easily be used for rollover as it is for initial distribution. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From dhcwg-bounces@ietf.org Fri Dec 29 11:36:42 2006 From: Ralph Droms Subject: DDNS-DHCP documents through WG last call Date: Thu, 06 Oct 2005 06:59:05 -0400 Lines: 13 Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-From: dhcwg-bounces@ietf.org Thu Oct 06 13:00:32 2005 Return-path: X-IronPort-AV: i="3.97,181,1125903600"; d="scan'208"; a="663874630:sNHT3980912188" To: dhcwg@ietf.org, namedroppers@ops.ietf.org X-Mailer: Evolution 2.0.4 (2.0.4-6) X-OriginalArrivalTime: 06 Oct 2005 10:58:54.0160 (UTC) FILETIME=[F12B1500:01C5CA64] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The following documents have been revised based on comments received during WG last call, and will now be submitted to the IESG as a package: draft-ietf-dnsext-dhcid-rr-10.txt draft-ietf-dhc-fqdn-option-11.txt draft-ietf-dhc-dhcpv6-fqdn-03.txt draft-ietf-dhc-ddns-resolution-10.txt Please review the final versions of these documents and respond to the mailing lists with any comments. The WG chairs plan to submit the documents on 10/10/2005. - Ralph From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:42 2006 From: Margaret Wasserman Subject: Re: Response to LLMNR Last Call Comments Date: Thu, 6 Oct 2005 07:48:09 -0400 Lines: 37 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 06 13:56:56 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 In-Reply-To: To: Bernard Aboba Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi Bernard, At 11:10 AM -0700 9/22/05, Bernard Aboba wrote: >However, that is really an orthogonal issue as far as LLMNR is concerned. >At this point, LLMNR has also shipped in multiple implementations, and >given the past history of IETF activity, I doubt there is anyone interested >in working on a "merger" effort. > >The only reasonable thing to do is to address the LC comments, publish >(as Experimental or Informational, probably) and move on. Just FYI -- I support the course of action that Bernard has suggested above, and I would be happy to bring this draft to the IESG for publication as an Informational RFC once the technical issues raised in IETF LC have been addressed. I think that it would be valuable to have a published specification for this mechanism, as it is clearly implemented. (I don't think that Experimental publication would be best, as this is not really an experiment). Is this a path that the rest of the WG supports? Or would the WG prefer to continue efforts to get this document published as a Proposed Standard? Margaret -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:42 2006 From: Bernard Aboba Subject: Re: Response to LLMNR Last Call Comments Date: Thu, 6 Oct 2005 06:14:16 -0700 (PDT) Lines: 18 References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 06 15:24:37 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_HELO_PASS autolearn=ham version=3.1.0 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba To: Margaret Wasserman In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Just FYI -- > > I support the course of action that Bernard has suggested above, and I would > be happy to bring this draft to the IESG for publication as an Informational > RFC once the technical issues raised in IETF LC have been addressed. Draft -44 clarifies the protocol issues that were raised in IETF LC. However, it does not address the issues (APIs, DNS resolver behavior) which did not relate to LLMNR and constituted the bulk of the comments. The DNSEXT WG will need to address these issues separately. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From dhcwg-bounces@ietf.org Fri Dec 29 11:36:42 2006 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: DDNS-DHCP documents through WG last call Date: Thu, 06 Oct 2005 10:00:53 -0400 Lines: 20 References: <1128596345.7223.88.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: dhcwg-bounces@ietf.org Thu Oct 06 16:06:40 2005 Return-path: X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 To: Ralph Droms , dhcwg@ietf.org, namedroppers@ops.ietf.org In-Reply-To: <1128596345.7223.88.camel@localhost.localdomain> References: <1128596345.7223.88.camel@localhost.localdomain> X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org At 06:59 06/10/2005, Ralph Droms wrote: >The following documents have been revised based on comments received >during WG last call, and will now be submitted to the IESG as a package: > >draft-ietf-dnsext-dhcid-rr-10.txt >draft-ietf-dhc-fqdn-option-11.txt >draft-ietf-dhc-dhcpv6-fqdn-03.txt >draft-ietf-dhc-ddns-resolution-10.txt > >Please review the final versions of these documents and respond to the >mailing lists with any comments. The WG chairs plan to submit the >documents on 10/10/2005. For the record: I have read latest version of all the documents and think they are ready to be advanced. Please speak up so your WG chairs can advance the documents with confidence. Olafur From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:42 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-45.txt Date: Thu, 06 Oct 2005 15:50:02 -0400 Lines: 93 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 06 21:59:43 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 To: i-d-announce@ietf.org 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 : Linklocal Multicast Name Resolution (LLMNR) Author(s) : B. Aboba, et al. Filename : draft-ietf-dnsext-mdns-45.txt Pages : 30 Date : 2005-10-6 The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-45.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-mdns-45.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-mdns-45.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-6124840.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-45.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-45.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-6124840.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 Dec 29 11:36:42 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dns-name-p-s-01.txt Date: Thu, 06 Oct 2005 15:50:01 -0400 Lines: 93 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 06 21:59:53 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 To: i-d-announce@ietf.org 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 : Derivation of DNS Name Predecessor and Successor Author(s) : G. Sisson, B. Laurie Filename : draft-ietf-dnsext-dns-name-p-s-01.txt Pages : 26 Date : 2005-10-6 This document describes two methods for deriving the canonically- ordered predecessor and successor of a DNS name. These methods may be used for dynamic NSEC resource record synthesis, enabling security-aware name servers to provide authenticated denial of existence without disclosing other owner names in a DNSSEC-secured zone. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-name-p-s-01.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-name-p-s-01.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-name-p-s-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-6121752.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dns-name-p-s-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dns-name-p-s-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-6121752.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 Dec 29 11:36:42 2006 From: David Conrad Subject: Re: WGLC: Name Server Identifier Option Date: Thu, 6 Oct 2005 14:22:49 -0700 Lines: 57 References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Cc: Namedroppers X-From: owner-namedroppers@ops.ietf.org Thu Oct 06 23:30:06 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 In-Reply-To: To: Olaf M.Kolkman X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Oct 5, 2005, at 11:04 AM, Olaf M. Kolkman wrote: > Please review your draft and state your support. Technical content > should be addressed on the list editorial nits can be send to the > document editor with a CC to the chairs. Just two comments: #1: 2.2 The NSID Option The OPTION-DATA for the NSID option is an opaque byte string the semantics of which are deliberately left outside the protocol. See Section 3.1 for discussion. Should there be an explicit maximum limit on the length instead of relying on the OPTION-LENGTH field? I'd also note that treating the OPTION-DATA field as opaque implicitly violates the assumption of 2671 that OPTION-DATA be comprised of attribute/value pairs. Might make this explicit. #2: 2.3 Presentation Format User interfaces MUST read and write the content of the NSID option as a sequence of hexadecimal digits, two digits per payload octet. While I understand the intent, I don't believe protocol definitions should get into user interface issues, particularly as MUSTs. I might suggest: 2.3 Presentation Format As the data returned in the NSID payload is explicitly not specified, care should be taken to not assume the data is displayable in a raw form. One potential approach would be to read and write the content of the NSID option as a sequence of hexadecimal digits, two digits per payload octet. as well as removing section 3.3 entirely. 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 Fri Dec 29 11:36:42 2006 From: Samuel Weiler Subject: Re: WGLC: Name Server Identifier Option Date: Thu, 6 Oct 2005 21:20:52 -0400 (EDT) Lines: 29 References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Fri Oct 07 03:34:27 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-X-Sender: weiler@filbert To: Namedroppers In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 5 Oct 2005, Olaf M. Kolkman wrote: > Please review your draft and state your support. I have read this draft (again) and support its publication on the standards track as-is. As to DRC's comments: > #1 ... Should there be an explicit maximum limit on the length > instead of relying on the OPTION-LENGTH field? No opinion. > #2 ... I don't believe protocol definitions should get into user > interface issues, particularly as MUSTs. Historically, the IETF has specified presentation formats for RRs, and I think section 3.3 adequately justifies the need for a standardized one in this case. I suggest leaving this text as-is. -- 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 Dec 29 11:36:42 2006 From: Mike StJohns Subject: Re: WGLC: Name Server Identifier Option Date: Thu, 06 Oct 2005 22:13:38 -0400 Lines: 114 References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_112862467==.ALT" X-From: owner-namedroppers@ops.ietf.org Fri Oct 07 04:20:48 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 To: Samuel Weiler , Namedroppers In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --=====================_112862467==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 09:20 PM 10/6/2005, Samuel Weiler wrote: >On Wed, 5 Oct 2005, Olaf M. Kolkman wrote: > > > Please review your draft and state your support. > >I have read this draft (again) and support its publication on >the standards track as-is. I apologize for this being my first read-through on this draft. Mostly OK, but I believe the length issue raised by DRC needs correction. See below. >As to DRC's comments: > > > #1 ... Should there be an explicit maximum limit on the length > > instead of relying on the OPTION-LENGTH field? > >No opinion. I agree with DRC. Pick a length so that folks who want to build tight code can do at least minimal validation. Also, DNS is being used as transport for DDOS communication traffic. Providing an unlimited length field with no semantics that can be tacked on to any DNS packet seems a bit like a gift to those trying to evade firewalls. Pick a length - 16 octets to cover v6 addresses? > > #2 ... I don't believe protocol definitions should get into user > > interface issues, particularly as MUSTs. > >Historically, the IETF has specified presentation formats for RRs, 1) This isn't an RR, its part of an existing RR 2) Pseudo-RRs generally don't get presentation formats. This is part of the OPT Pseudo RR. > and >I think section 3.3 adequately justifies the need for a standardized >one in this case. "It is much more important for the NSID payload data to be passed unambiguously from server administrator to user" This text should be "from user to server administrator" instead (section 3.3 that is) as its clear this is what's meant in the rest of the paragraph. And the requirement is no better than a "SHOULD" since its not critical for proper operation of the protocol. Also, the "SHOULD" should only be with respect to at least form of presentation - e.g. its OK to print out the ASCII or local character set equiv in addition to hex. --=====================_112862467==.ALT Content-Type: text/html; charset="us-ascii" At 09:20 PM 10/6/2005, Samuel Weiler wrote:
On Wed, 5 Oct 2005, Olaf M. Kolkman wrote:

> Please review your draft and state your support.

I have read this draft (again) and support its publication on
the standards track as-is.

I apologize for this being my first read-through on this draft.  Mostly OK, but I believe the length issue raised by DRC needs correction.  See below.


As to DRC's comments:

> #1 ...  Should there be an explicit maximum limit on the length
> instead of relying on the OPTION-LENGTH field?

No opinion.

I agree with DRC.  Pick a length so that folks who want to build tight code can do at least minimal validation.  Also, DNS is being used as transport for DDOS communication traffic.  Providing an unlimited length field with no semantics that can be tacked on to any DNS packet seems a bit like a gift to those trying to evade firewalls.  Pick a length - 16 octets to cover v6 addresses?

> #2 ...  I don't believe protocol definitions should get into user
> interface issues, particularly as MUSTs.

Historically, the IETF has specified presentation formats for RRs,

1) This isn't an RR, its part of an existing RR
2) Pseudo-RRs generally don't get presentation formats.  This is part of the OPT Pseudo RR.

 and
I think section 3.3 adequately justifies the need for a standardized
one in this case.

"
It is much more important for the NSID payload data to be
passed
   unambiguously from server administrator to user"
This text should be "from user to server administrator" instead (section 3.3 that is) as its clear this is what's meant in the rest of the paragraph.  And the requirement is no better than a "SHOULD" since its not critical for proper operation of the protocol.  Also, the "SHOULD" should only be with respect to at least form of presentation - e.g. its OK to print out the ASCII or local character set equiv in addition to hex.

 --=====================_112862467==.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 Dec 29 11:36:42 2006 From: Mark Andrews Subject: Re: WGLC: Name Server Identifier Option Date: Fri, 07 Oct 2005 16:25:08 +1000 Lines: 63 References: <6.2.1.2.2.20051006215313.07134950@localhost> Cc: Samuel Weiler , Namedroppers X-From: owner-namedroppers@ops.ietf.org Fri Oct 07 08:37:23 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Mike StJohns In-reply-to: Your message of "Thu, 06 Oct 2005 22:13:38 -0400." <6.2.1.2.2.20051006215313.07134950@localhost> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > --=====================_112862467==.ALT > Content-Type: text/plain; charset="us-ascii"; format=flowed > > At 09:20 PM 10/6/2005, Samuel Weiler wrote: > >On Wed, 5 Oct 2005, Olaf M. Kolkman wrote: > > > > > Please review your draft and state your support. > > > >I have read this draft (again) and support its publication on > >the standards track as-is. > > I apologize for this being my first read-through on this draft. Mostly OK, > but I believe the length issue raised by DRC needs correction. See below. > > > >As to DRC's comments: > > > > > #1 ... Should there be an explicit maximum limit on the length > > > instead of relying on the OPTION-LENGTH field? > > > >No opinion. > > I agree with DRC. Pick a length so that folks who want to build tight code > can do at least minimal validation. Also, DNS is being used as transport > for DDOS communication traffic. Providing an unlimited length field with > no semantics that can be tacked on to any DNS packet seems a bit like a > gift to those trying to evade firewalls. Pick a length - 16 octets to > cover v6 addresses? This does not need a arbitary length constraint. DDoS is complete FUD. You already can get maximal responses today without this option. Firewall evading is also complete FUD. It is already easy enough to use the DNS as a covert channel. For what it is worth 16 is way too short. I'd atleast make it big enough to hold a domain name. > > > #2 ... I don't believe protocol definitions should get into user > > > interface issues, particularly as MUSTs. > > > >Historically, the IETF has specified presentation formats for RRs, > > 1) This isn't an RR, its part of an existing RR > 2) Pseudo-RRs generally don't get presentation formats. This is part of > the OPT Pseudo RR. Which just makes it harder for those writing packet dumpers. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:42 2006 From: Rob Austein Subject: Re: WGLC: Name Server Identifier Option Date: Fri, 07 Oct 2005 02:46:20 -0400 Lines: 22 References: <6.2.1.2.2.20051006215313.07134950@localhost> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Fri Oct 07 08:57:02 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 To: Namedroppers In-Reply-To: <6.2.1.2.2.20051006215313.07134950@localhost> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Thu, 06 Oct 2005 22:13:38 -0400, Michael StJohns wrote: > > "It is much more important for the NSID payload data to be passed > unambiguously from server administrator to user" > > This text should be "from user to server administrator" instead (section > 3.3 that is) as its clear this is what's meant in the rest of the > paragraph. Yes and no. The point is that the NSID payload needs to survive a round trip from server admin through DNS protocol to client user then all the way back again via protocols unknown (email, web form, two tin cans and a piece of wet string...) to the server admin. I was focusing on the outbound trip, Mike is focusing on the return. This could probably be clearer. Good catch. -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:42 2006 From: Rob Austein Subject: Re: WGLC: Name Server Identifier Option Date: Fri, 07 Oct 2005 02:49:56 -0400 Lines: 20 References: <6.2.1.2.2.20051006215313.07134950@localhost> <200510070625.j976P8jL064256@drugs.dv.isc.org> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Fri Oct 07 08:58:43 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Namedroppers In-Reply-To: <200510070625.j976P8jL064256@drugs.dv.isc.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Fri, 07 Oct 2005 16:25:08 +1000, Mark Andrews wrote: > > > I agree with DRC. Pick a length so that folks who want to build tight code > > can do at least minimal validation. Also, DNS is being used as transport > > for DDOS communication traffic. Providing an unlimited length field with > > no semantics that can be tacked on to any DNS packet seems a bit like a > > gift to those trying to evade firewalls. Pick a length - 16 octets to > > cover v6 addresses? > > For what it is worth 16 is way too short. I'd atleast > make it big enough to hold a domain name. Mark is correct that the design is intended to allow DNS names to be used as the NSID payload. -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:42 2006 From: David Conrad Subject: Re: WGLC: Name Server Identifier Option Date: Fri, 7 Oct 2005 00:01:12 -0700 Lines: 43 References: <6.2.1.2.2.20051006215313.07134950@localhost> <200510070625.j976P8jL064256@drugs.dv.isc.org> <20051007064956.8563941A7@thrintun.hactrn.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Cc: Namedroppers X-From: owner-namedroppers@ops.ietf.org Fri Oct 07 09:07:22 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 In-Reply-To: <20051007064956.8563941A7@thrintun.hactrn.net> To: Rob Austein X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I personally dislike dealing with undefined maximums when writing variable length field parsers (that should probably be in the past tense, sigh). I'll start the bidding at 256 bytes... On Oct 6, 2005, at 11:49 PM, Rob Austein wrote: > At Fri, 07 Oct 2005 16:25:08 +1000, Mark Andrews wrote: > >> >> >>> I agree with DRC. Pick a length so that folks who want to build >>> tight code >>> can do at least minimal validation. Also, DNS is being used as >>> transport >>> for DDOS communication traffic. Providing an unlimited length >>> field with >>> no semantics that can be tacked on to any DNS packet seems a bit >>> like a >>> gift to those trying to evade firewalls. Pick a length - 16 >>> octets to >>> cover v6 addresses? >>> >> >> For what it is worth 16 is way too short. I'd atleast >> make it big enough to hold a domain name. >> > > Mark is correct that the design is intended to allow DNS names to be > used as the NSID payload. > > -- > to 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 Dec 29 11:36:42 2006 From: David Conrad Subject: Re: WGLC: Name Server Identifier Option Date: Fri, 7 Oct 2005 00:07:55 -0700 Lines: 29 References: <200510070625.j976P8jL064256@drugs.dv.isc.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike StJohns , Samuel Weiler , Namedroppers X-From: owner-namedroppers@ops.ietf.org Fri Oct 07 09:13:06 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 In-Reply-To: <200510070625.j976P8jL064256@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Oct 6, 2005, at 11:25 PM, Mark Andrews wrote: > This does not need a arbitary length constraint. No, it doesn't _need_ it. It just makes doing the parser a teensy bit less likely to screw up and lead to buffer overflow exploits. This isn't a big issue, I just thought it'd be nice to provide an explicit limit. >>> Historically, the IETF has specified presentation formats for RRs, Which many people argue was a bad idea and has led to many people writing broken RR parsers that don't deal with escaping properly, makes invalid assumptions about what can and cannot be in a label or rtype or rdata, etc. > Which just makes it harder for those writing packet dumpers. If you're writing a packet dumper, I suspect you already have code to deal with arbitrary binary data. 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 Fri Dec 29 11:36:42 2006 From: Francis Dupont Subject: Re: WGLC: Name Server Identifier Option Date: Fri, 07 Oct 2005 10:58:41 +0200 Lines: 18 References: Cc: Namedroppers X-From: owner-namedroppers@ops.ietf.org Fri Oct 07 11:07:13 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 To: "Olaf M. Kolkman" In-reply-to: Your message of Wed, 05 Oct 2005 20:04:14 +0200. X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In your previous mail you wrote: DNS Name Server Identifier Option (NSID) draft-ietf-dnsext-nsid-00 => for the idea itself I believe it is very useful. I use it for instance to understand a problem with the F root server in Paris (TCP connections from some ISPs were reseted). Regards Francis.Dupont@enst-bretagne.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:42 2006 From: "Olaf M. Kolkman" Subject: Re: Survey of Rollover Mechanisms Date: Fri, 7 Oct 2005 11:22:37 +0200 Lines: 75 References: <43342DDE.60602@connotech.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-32-45902634" Content-Transfer-Encoding: 7bit Cc: Namedroppers X-From: owner-namedroppers@ops.ietf.org Fri Oct 07 11:29:13 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 In-Reply-To: <43342DDE.60602@connotech.com> To: Thierry Moreau X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-32-45902634 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Sep 23, 2005, at 18:31 , Thierry Moreau wrote: > Dear all: > > In order to assist the discussion, here is a survey of > trust anchor key mechanisms. Thanks Thierry, To my embarrassment I have to confess I had not seen your message until today. I think it is a useful addition to the pointed questions I mailed to the list the other day. You wrote: > 5. Out-of-band Validated Rollover > > Description: the "textbook" rollover method is to > distribute the key to DNS resolvers and use an out-of- > band channel to let the end-users validate the new key. > There isn't the slightest chance that this is > operationally feasible in any context. Why isn't there the slightest change? And what is exactly the between "Out of band Validated Rollover" difference to "The outside certification" option, isn't the latter one of the variations on the general theme of out-of-band validated rollovers --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-32-45902634 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDRj5otN/ca3YJIocRAoxDAJ9OUn5aX4N3EJqeiND4giCad28lKQCgtz6l 1nKY8TPWhGcQrwB8DbwyQPk= =dRqK -----END PGP SIGNATURE----- --Apple-Mail-32-45902634-- -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:42 2006 From: Peter Koch Subject: Re: WGLC: Name Server Identifier Option Date: Fri, 07 Oct 2005 14:44:59 +0200 Lines: 25 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Fri Oct 07 14:58:02 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: IETF DNSEXT WG In-reply-to: Your message of "Thu, 06 Oct 2005 14:22:49 PDT." Content-ID: <29.1128689094.1@tyrannia.TechFak.Uni-Bielefeld.DE> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David Conrad wrote: > OPTION-DATA field as opaque implicitly violates the assumption of > 2671 that OPTION-DATA be comprised of attribute/value pairs. Might > make this explicit. my reading of 2671 is that the (CODE/LEBGTH/DATA) container described in section 4.4 already *is* the "attribute,value" pair. Otherwise there's nothing said about the separator between attribute and value and the charset issues. Maybe a clarification to 2671 is needed when it goes to Draft. But as you mention the length: what is the responding server supposed to do if putting in the requested information would exceed either 512 octets or the maximum available payload size as "negotiated" between the requestor and itself? Will the EDNS version to be announced remain "0"? -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 Fri Dec 29 11:36:42 2006 From: Paul Vixie Subject: Re: WGLC: Name Server Identifier Option Date: Fri, 07 Oct 2005 13:37:50 +0000 Lines: 8 References: Cc: Namedroppers X-From: owner-namedroppers@ops.ietf.org Fri Oct 07 15:46:28 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: "Olaf M. Kolkman" In-Reply-To: Your message of "Wed, 05 Oct 2005 20:04:14 +0200." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk i still want this to be symmetric. that is, the client should be able to send an opaque identifier to the server, too. -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:42 2006 From: Paul Vixie Subject: Re: WGLC: Name Server Identifier Option Date: Fri, 07 Oct 2005 13:49:54 +0000 Lines: 29 References: <200510071244.j97Cix300034@tyrannia.TechFak.Uni-Bielefeld.DE> Cc: IETF DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Fri Oct 07 16:00:17 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Peter Koch In-Reply-To: Your message of "Fri, 07 Oct 2005 14:44:59 +0200." <200510071244.j97Cix300034@tyrannia.TechFak.Uni-Bielefeld.DE> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # > OPTION-DATA field as opaque implicitly violates the assumption of # > 2671 that OPTION-DATA be comprised of attribute/value pairs. Might # > make this explicit. # # my reading of 2671 is that the (CODE/LEBGTH/DATA) container described in # section 4.4 already *is* the "attribute,value" pair. yes. # Otherwise there's nothing said about the separator between attribute and # value and the charset issues. Maybe a clarification to 2671 is needed when # it goes to Draft. suggestions welcome. but i think drc wanted the NSID option to have its own interior attr:value segmentation structure, in which case the clarification should be in drc's proposal rather than in 2671. # Will the EDNS version to be announced remain "0"? yes. implementations of EDNS are expected to ignore options they don't recognize. THAT is something we can clarify when 2671 goes to draft. the version number is about the message format and message field meanings; it doesn't have to do with content like OPT options. -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:42 2006 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: DNSEXT WGLC summary: Wildcard Clarify Date: Fri, 07 Oct 2005 11:33:49 -0400 Lines: 24 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Fri Oct 07 17:44:36 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 To: namedroppers@ops.ietf.org X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This WG last has completed (a while ago). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-09.txt The document received number of comments during the last call and the editor has addressed all of them. The document received significant support and has been approved by the working group. The chairs will advance this document to the IESG in near future on standards track. Thanks to everyone that participate in this last call with in depth technical comments. Olafur and Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:42 2006 From: Rob Austein Subject: Re: WGLC: Name Server Identifier Option Date: Fri, 07 Oct 2005 12:26:11 -0400 Lines: 21 References: <20051007133750.8615A11424@sa.vix.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Fri Oct 07 18:34:43 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 To: Namedroppers In-Reply-To: <20051007133750.8615A11424@sa.vix.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Fri, 07 Oct 2005 13:37:50 +0000, Paul Vixie wrote: > > i still want this to be symmetric. that is, the client should be able to > send an opaque identifier to the server, too. Paul, we've discussed this. You're welcome to propose another option that does what you want, but (in my opinion -- WG chairs can speak for themselves) you have not justified tying your proposal to this one. It's a different problem space, probably with different constraints, and certainly with different protocol behavior. The discussion in Paris was pretty clear on wanting to get the NSID mechanism out the door as it stands, without further bells or whistles. The WG is of course free to revise that plan, but so far I have not heard anybody but Paul asking for this feature. -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:42 2006 From: David Conrad Subject: Re: WGLC: Name Server Identifier Option Date: Fri, 7 Oct 2005 10:20:38 -0700 Lines: 29 References: <200510071244.j97Cix300034@tyrannia.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Fri Oct 07 19:29:01 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 In-Reply-To: <200510071244.j97Cix300034@tyrannia.TechFak.Uni-Bielefeld.DE> To: Peter Koch X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Oct 7, 2005, at 5:44 AM, Peter Koch wrote: > my reading of 2671 is that the (CODE/LEBGTH/DATA) container > described in > section 4.4 already *is* the "attribute,value" pair. D'oh. Needed more caffeine. Apologies. > But as you mention the length: what is the responding server > supposed to do > if putting in the requested information would exceed either 512 octets > or the maximum available payload size as "negotiated" between the > requestor and itself? Set the truncate bit? > Will the EDNS version to be announced remain "0"? I'd wouldn't think there would be a need... 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 Fri Dec 29 11:36:42 2006 From: Paul Vixie Subject: Re: WGLC: Name Server Identifier Option Date: Fri, 07 Oct 2005 17:42:07 +0000 Lines: 10 References: <20051007133750.8615A11424@sa.vix.com> <20051007162611.20D6241A7@thrintun.hactrn.net> X-From: owner-namedroppers@ops.ietf.org Fri Oct 07 19:49:04 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Namedroppers In-Reply-To: Your message of "Fri, 07 Oct 2005 12:26:11 -0400." <20051007162611.20D6241A7@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # The WG is of course free to revise that plan, but so far I # have not heard anybody but Paul asking for this feature. it's last call, i'm just putting my position on the 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 Fri Dec 29 11:36:42 2006 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: IETF-64 Vancouver DNSEXT agenda items Date: Fri, 07 Oct 2005 13:50:12 -0400 Lines: 13 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Fri Oct 07 19:59:09 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 To: namedroppers@ops.ietf.org X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The chairs have requested a slot at the meeting, if you have items you want considered please send me a request before 2005/10/20. 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 Fri Dec 29 11:36:42 2006 From: David Conrad Subject: Re: WGLC: Name Server Identifier Option Date: Fri, 7 Oct 2005 11:36:11 -0700 Lines: 48 References: <20051007133750.8615A11424@sa.vix.com> <20051007162611.20D6241A7@thrintun.hactrn.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Cc: Namedroppers X-From: owner-namedroppers@ops.ietf.org Sat Oct 08 00:58:52 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=ham version=3.1.0 In-Reply-To: <20051007162611.20D6241A7@thrintun.hactrn.net> To: Rob Austein X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I have no opinion as to what Paul wants, not having been in Paris, but to make everybody happy (?), perhaps the document/option could be renamed "Name Service Identifier Option" and the document clarified to say something like "behavior of the server receiving a NSID OPT RR will be defined in a subsequent document"? Rgds, -drc On Oct 7, 2005, at 9:26 AM, Rob Austein wrote: > At Fri, 07 Oct 2005 13:37:50 +0000, Paul Vixie wrote: > > >> >> i still want this to be symmetric. that is, the client should be >> able to >> send an opaque identifier to the server, too. >> >> > > Paul, we've discussed this. You're welcome to propose another option > that does what you want, but (in my opinion -- WG chairs can speak for > themselves) you have not justified tying your proposal to this one. > It's a different problem space, probably with different constraints, > and certainly with different protocol behavior. > > The discussion in Paris was pretty clear on wanting to get the NSID > mechanism out the door as it stands, without further bells or > whistles. The WG is of course free to revise that plan, but so far I > have not heard anybody but Paul asking for this feature. > > -- > to 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 Dec 29 11:36:42 2006 From: Peter Koch Subject: Re: WGLC: Name Server Identifier Option Date: Mon, 10 Oct 2005 16:11:09 +0200 Lines: 18 References: <268E7A19-31C4-44F3-87B9-2E327BC1F583@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Mon Oct 10 16:23:33 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: IETF DNSEXT WG In-reply-to: Your message of "Fri, 07 Oct 2005 10:20:38 PDT." <268E7A19-31C4-44F3-87B9-2E327BC1F583@nominum.com> Content-ID: <2519.1128953461.1@zeder.TechFak.Uni-Bielefeld.DE> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David Conrad wrote: > > if putting in the requested information would exceed either 512 octets > > or the maximum available payload size as "negotiated" between the > > requestor and itself? > > Set the truncate bit? so, if options take precedence over responses/referrals that should be said somewhere, especially if we're discussing "long" NSID identifications. -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 Fri Dec 29 11:36:42 2006 From: Peter Koch Subject: Re: WGLC: Name Server Identifier Option Date: Mon, 10 Oct 2005 22:11:57 +0200 Lines: 70 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Mon Oct 10 22:21:37 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: IETF DNSEXT WG In-reply-to: Your message of "Wed, 05 Oct 2005 20:04:14 +0200." Content-ID: <4116.1128975112.1@zeder.TechFak.Uni-Bielefeld.DE> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > draft-ietf-dnsext-nsid-00 > Please review your draft and state your support. Technical content > should be addressed on the list editorial nits can be send to the I've read the document and generally support it going onto standards track. Some remarks and some responses to remarks made by fellow namedroppers: o length indication I do not see a need to further structure the OPTION-DATA to allow for an additional length indicator nor do I see the need to explicitly limit the maximum length to less than the natural limit of 64k (well, actually less due to RLEN restrictions). When speaking about DoS there are two opportunities: 1) Responding server DoSing querying client (as a revenge for invading its privacy ...) There are probably easier DoS measures already, including games with OPTION-LENGTH and so on. Limits won't help since the client would still have to deal with malicious violations of those limits. A caveat in the security considerations section might be useful. 2) DoS amplification by sending large responses upon small queries (using forged src addresses) One would need many servers with large NSID payload and the same might already be achieved today with just "root referrals". However, when it comes to length problems, the conflict between truncation and honoring the SI flag should be discussed. o Presentation format This needs to be defined and should be kept as is (modulo the change to emphasize the human part in the loop). Any deeper involvement of strings opens this to the i18n game, which to avoid seems a good idea. o NSID content The draft lists and discusses a variety of ways to fill NSID, all of which suggest a static mapping of server instance to NSID value. As I mentioned in Paris, I'd like to have the option of changing that value per query (keeping track internally). This is one way to avoid discovering the number of anycast nodes behind a load balancer and there might be other reasons. The person debugging then can't even tell whether subsequent responses originate from the same server, but it could hand over the info received to the server admin for further inspection. o SI/NSID non transitivity The message is clear, but can we expect implementations agnostic of SI/NSID to behave? (I know section 4.1 of 2671 forbids forwarding of OPT RRs). o "Symmetry" of NSID In Paris we agreed that for the sake of getting this out the door any extensions like end2end identification or client identification should be defined in separate drafts - if the need be. I'm just wondering why we "waste" both an option code and a flag bit (which is more precious) instead of requesting server identification by an NSID option (even an empty one) in the query. -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 Fri Dec 29 11:36:43 2006 From: Paul Vixie Subject: Re: WGLC: Name Server Identifier Option Date: Mon, 10 Oct 2005 21:44:26 +0000 Lines: 16 References: <200510102011.j9AKBvx04123@zeder.TechFak.Uni-Bielefeld.DE> X-From: owner-namedroppers@ops.ietf.org Mon Oct 10 23:52:05 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: IETF DNSEXT WG In-Reply-To: Your message of "Mon, 10 Oct 2005 22:11:57 +0200." <200510102011.j9AKBvx04123@zeder.TechFak.Uni-Bielefeld.DE> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # o "Symmetry" of NSID # # In Paris we agreed that for the sake of getting this out the door any # extensions like end2end identification or client identification should be # defined in separate drafts - if the need be. I'm just wondering why we # "waste" both an option code and a flag bit (which is more precious) # instead of requesting server identification by an NSID option (even an # empty one) in the query. i wonder the same. -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Paul Vixie Subject: Re: WGLC: Name Server Identifier Option Date: 10 Oct 2005 23:35:39 +0000 Lines: 26 References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Tue Oct 11 01:41:34 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 To: namedroppers@ops.ietf.org In-Reply-To: Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > if putting in the requested information would exceed either 512 > > > octets or the maximum available payload size as "negotiated" between > > > the requestor and itself? > > > > Set the truncate bit? > > so, if options take precedence over responses/referrals that should be > said somewhere, especially if we're discussing "long" NSID > identifications. this highlights a general failing of RFC 2671, and is not specific to NSID. i believe that the right behaviour is that if a requestor is considering adding an OPT RR that won't fit in the previously negotiated buffer size for the destination server, that a smaller OPT RR, or no OPT RR, be used; if a responder is considering adding an OPT RR that won't fit in the advertised buffer size of the requestor, that it should respond with RCODE=17, which the IANA should allocate to mean "optional truncation". -- 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 Fri Dec 29 11:36:43 2006 From: "Olaf M. Kolkman" Subject: Request to advance "white lies documents" Date: Thu, 6 Oct 2005 16:26:50 +0200 Lines: 180 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-26--22244683" Content-Transfer-Encoding: 7bit Cc: Mark Townsley , Namedroppers X-From: owner-namedroppers@ops.ietf.org Tue Oct 11 16:05:14 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 To: Margaret Wasserman X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-26--22244683 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Namedroppers CC-ed so they know that these documents have been processed. Dear Margaret, This is a request to publish two documents that describe a technique that also known by the name of "white lies" draft-ietf-dnsext-dnssec-online-signing-00 draft-ietf-dnsext-dns-name-p-s-01 Below is the evaluation sheet. I'll be the document shepherd for these documents. --------------------- 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the IESG for publication? Yes both chairs reviewed these documents. 2) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? This idea had several iterations as a personal submission draft and has been discussed and refined a number of times. An early version of the p-s draft was implemented as a proof of concept and experiences with that led to a refinement. 3) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? I do not have such concerns. 4) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or whether there really is a need for it, etc., but at the same time these issues have been discussed in the WG and the WG has indicated it wishes to advance the document anyway. 'White lies' is a technique to prevent the possibility of zone enumerations through NSEC walks. The basic principle (described in the online-signing draft) is that NSEC records that span the query name are automated on the fly. There has been some debate on the dynamics of the mechanism and the violation of some text in 4034 and 4035. There is consensus that this the online-singing document is to update the RFCbis specification. 5) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? As far as I can see all that care consent, the others are silent [I find it very hard to answer this question] 6) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize what are they upset about. No. 7) Have the chairs verified that the document adheres to _all_ of the ID nits? (see http://www.ietf.org/ID-nits.html). Yes - the documents contain some version history information which can obviously be stripped by the RFC editor, when the time comes) - It could be argued that the abstracts are 'versed in technology', that is a matter of taste. - There is an informative reference to in the p-s draft ( [I-D.ietf-dnsext-dnssec-trans]) that may or not be revived. We don't know currently. 8) For Standards Track and BCP documents, the IESG approval announcement includes a writeup section with the following sections: - Technical Summary - Working Group Summary - Protocol Quality Please provide such a writeup. (We will hopefully use it as is, but may make some changes.) For recent examples, have a look at the "protocol action" announcements for approved documents. Technical summary Deployment of DNSSEC would allow trivial zone enumeration by a process that is called NSEC walking (The NSECs link the names in a zone in canonical order). The online-signing draft describes the principle of what is popularly called "white lies": Whenever a negative answer of is to be supplied one can generate an NSEC on the fly that appropriately covers the requested record. The on-line signing document further describes the general requirements for algorithms that generate these records. The p-s draft describes one of these algorithms in detail; how can one find the neares possible predecessor and successor for a given query name. Although an update to 4034/4035 is needed, resolvers/validators will be able to parse and validate 'white lies' responses without any modification. Working Group Summary The working group consents that the online-signing draft is forwarded with the intention to be published on the standards track and that the p-s draft is to be published as experimental. Protocol Quality There has been a proof of concept implementation and there are some DNS registries that have expressed explicit interest in this technique. --Olaf Kolkman DNSEXT Co chair. --Apple-Mail-26--22244683 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDRTQqtN/ca3YJIocRAl8SAJ4tl3fpF2xzHcyd/81LF5Hq43GddQCg+3Qi fiAa2/j+ni6Fn5GLMSPQYgY= =Jnje -----END PGP SIGNATURE----- --Apple-Mail-26--22244683-- -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Rob Austein Subject: Re: WGLC: Name Server Identifier Option Date: Tue, 11 Oct 2005 15:03:14 -0400 Lines: 59 References: <200510102011.j9AKBvx04123@zeder.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Tue Oct 11 21:17:03 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: namedroppers@ops.ietf.org In-Reply-To: <200510102011.j9AKBvx04123@zeder.TechFak.Uni-Bielefeld.DE> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Mon, 10 Oct 2005 22:11:57 +0200, Peter Koch wrote: > > However, when it comes to length problems, the conflict between > truncation and honoring the SI flag should be discussed. Good catch, thanks. > o NSID content > > The draft lists and discusses a variety of ways to fill NSID, all > of which suggest a static mapping of server instance to NSID > value. > As I mentioned in Paris, I'd like to have the option of changing > that value per query (keeping track internally). This is one way > to avoid discovering the number of anycast nodes behind a load > balancer and there might be other reasons. The person debugging > then can't even tell whether subsequent responses originate from > the same server, but it could hand over the info received to the > server admin for further inspection. Thought I'd covered this: o It could be some sort of dynamicly generated identifier so that only the name server operator could tell whether or not any two queries had been answered by the same server. If that's not enough, send text. :) > o "Symmetry" of NSID > > In Paris we agreed that for the sake of getting this out the door > any extensions like end2end identification or client > identification should be defined in separate drafts - if the need > be. I'm just wondering why we "waste" both an option code and a > flag bit (which is more precious) instead of requesting server > identification by an NSID option (even an empty one) in the query. If the WG would prefer that we just use an empty NSID option rather than the SI flag bit, that's a simple change. Absent a specification for what non-empty NSID payload from client to server would mean, I think it should be empty (name server MUST ignore NSID payload, client MUST NOT/SHOULD NOT send NSID payload). If and when the WG specifies what client->server payload looks like, how it's supposed to work, etc, that specification can just update this one if the WG concludes that reusing the NSID option is appropriate. I still suspect that the client->server case is different enough that it should be a separate option, but hey, I could be wrong. My main concerns at this point are: (a) that this specification be complete rather than making forward references to specifications that might never be written, and (b) that we finish this promptly, per the discussion in Paris. -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Samuel Weiler Subject: Re: DNSSEC explanation, comments? Date: Thu, 13 Oct 2005 16:02:30 -0400 (EDT) Lines: 41 References: <20051001125513.GA6409@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 13 22:17:32 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-X-Sender: weiler@filbert To: bert hubert In-Reply-To: <20051001125513.GA6409@outpost.ds9a.nl> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > http://ds9a.nl/dnssec/ It's nice to have an outside perspective once and a while. Thank you for sharing this. And thank you for praising the working group's collective intelligence. :-) This is an interesting evaluation. I found it frustrating to not know where the doc was going from the beginning, but I did agree with the final conclusion's "biggest worry". I don't see packet amplification as a big problem, though it's good to call out that potential threat, too. Some minor corrections and suggestions: a.z.w.example: the second time is the RRSIG inception time, not the signing time. The label count is correct (see the sample zone in 4035). The DS section has bad (or, at least, very confusing) examples: DS and DNSKEY are at the zone-cut (DS on parent side, DNSKEY on child side), not a subdomain of the zone. It's worth noting that KSK/ZSK separation is OPTIONAL -- a zone may choose to have a SINGLE key or may choose not to use the SEP (KSK) flag. The validation process ignores it -- it's there only as a hint for key management tools and operators. Add a version and/or date, so it's easy to tell if the version I downloaded to read on a plane a week ago is still current. You might want to point readers to the working examples of .se and ripe.net, as signed zones running in the wild. -- 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 Dec 29 11:36:43 2006 From: Samuel Weiler Subject: Re: NSEC3 signalling mechanism Date: Thu, 13 Oct 2005 16:24:06 -0400 (EDT) Lines: 31 References: <430082DB.7090901@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 13 22:35:09 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-X-Sender: weiler@filbert To: Ben Laurie In-Reply-To: <430082DB.7090901@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 15 Aug 2005, Ben Laurie wrote: > I do not understand why it is necessary to signal that the child > zone is using NSEC3. With all due respect, this WG seemed to conclude that signalling was necessary well over a year ago. Unless you have some specific argument that we were wrong, I'd rather not revisit the topic. Most of the relevant messages can be found in the namedroppers archives between May 20th and June 2nd of 2004, specifically the discussion bounded by these two messages: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00489.html http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00824.html Notable specific messages include: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00672.html http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00594.html http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00656.html As well as: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00893.html -- 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 Dec 29 11:36:43 2006 From: Ben Laurie Subject: Re: NSEC3 signalling mechanism Date: Thu, 13 Oct 2005 21:59:36 +0100 Lines: 49 References: <430082DB.7090901@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 13 23:06:32 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: Samuel Weiler In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Samuel Weiler wrote: > On Mon, 15 Aug 2005, Ben Laurie wrote: > > >>I do not understand why it is necessary to signal that the child >>zone is using NSEC3. > > > With all due respect, this WG seemed to conclude that signalling was > necessary well over a year ago. Unless you have some specific > argument that we were wrong, I'd rather not revisit the topic. > > Most of the relevant messages can be found in the namedroppers > archives between May 20th and June 2nd of 2004, specifically the > discussion bounded by these two messages: > > http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00489.html > http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00824.html > > Notable specific messages include: > http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00672.html > http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00594.html > http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00656.html > > As well as: > http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00893.html With all due respect, discussion is not conclusion. Futhermore, the discussion isn't that illuminating - all I can work out from it is concerns that if you don't understand NSEC3 you can't work properly in an NSEC3 world. This is not surprising. If you want comment on a concrete proposal, then propose one. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: bert hubert Subject: Re: DNSSEC explanation, comments? Date: Thu, 13 Oct 2005 23:32:33 +0200 Lines: 30 References: <20051001125513.GA6409@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 13 23:41:14 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 To: Samuel Weiler Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Oct 13, 2005 at 04:02:30PM -0400, Samuel Weiler wrote: > a.z.w.example: the second time is the RRSIG inception time, not the > signing time. The label count is correct (see the sample zone in > 4035). Thanks, will investigate & rectify, same goes for your other suggestions. Much appreciated. I am happy that most (or all) suggestions so far have not been for fundamental problems - though they are important. > You might want to point readers to the working examples of .se and > ripe.net, as signed zones running in the wild. I've queried for real .se delegations but short of asking here or bothering the .se administrators nobody could point me to a real DS record 'in the wild'. But I'm very interested. My current feeling is that PowerDNS will start offering basic DNSSEC serving, but NSEC3 may be too different to fit in our database model. Thanks! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Simon Josefsson Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 00:04:34 +0200 Lines: 20 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org, Samuel Weiler X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 00:13:15 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 To: bert hubert OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051013:weiler@tislabs.com::7Z//FgC/lcIl/X85:2ifB X-Hashcash: 1:21:051013:bert.hubert@netherlabs.nl::jlsO9kqqPtCYN5bo:5au0 X-Hashcash: 1:21:051013:namedroppers@ops.ietf.org::unTsPXRKSCgulmbO:Cf5h In-Reply-To: <20051013213233.GC27170@outpost.ds9a.nl> (bert hubert's message of "Thu, 13 Oct 2005 23:32:33 +0200") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk bert hubert writes: >> You might want to point readers to the working examples of .se and >> ripe.net, as signed zones running in the wild. > > I've queried for real .se delegations but short of asking here or bothering > the .se administrators nobody could point me to a real DS record 'in the > wild'. But I'm very interested. Walking both zones doesn't produce any DS records, so I don't believe there are any. Cheers, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: David Blacka Subject: Re: NSEC3 signalling mechanism Date: Thu, 13 Oct 2005 18:09:50 -0400 Lines: 100 References: <430082DB.7090901@algroup.co.uk> <434ECAB8.8030600@algroup.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="=_cliffie-10090-1129241391-0001-2" X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 00:16:56 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 In-Reply-To: <434ECAB8.8030600@algroup.co.uk> To: DNSEXT WG X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_cliffie-10090-1129241391-0001-2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Oct 13, 2005, at 4:59 PM, Ben Laurie wrote: > Samuel Weiler wrote: > >> On Mon, 15 Aug 2005, Ben Laurie wrote: >> >>> I do not understand why it is necessary to signal that the child >>> zone is using NSEC3. >>> A Blast From The (not-so-distant) Past! I had to scroll back quite a ways in my mail client to find the genesis of this thread. > With all due respect, discussion is not conclusion. Futhermore, the > discussion isn't that illuminating - all I can work out from it is > concerns that if you don't understand NSEC3 you can't work properly > in an NSEC3 world. This is not surprising. No, it isn't surprising. Signaling is desired so we can have all the following conditions simultaneously true: 1. There are non-NSEC3-aware resolver/validators deployed. 2. They have trust anchors to zones above NSEC3 signed zones (like root) 3. NSEC3-aware validators have the same trust anchors (like root) 4. NSEC3-signed zones are not broken the to validators in group 2. Signaling is to protect the legacy validators. -- David Blacka Sr. Engineer VeriSign Applied Research --=_cliffie-10090-1129241391-0001-2 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFnjCCAlcw ggHAoAMCAQICAw+nGDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUxMDEzMTQzNjA4WhcNMDYxMDEzMTQzNjA4WjBJMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSYwJAYJKoZIhvcNAQkBFhdkYXZpZGJAdmVyaXNpZ25s YWJzLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyzP1izF46evByd+R5GlKx4j2Eo6a Z1xXLc/JhxagaNuUujieUyiHCHikbf8PF/tf2Z9GfIDe1ygCZTQfqRCFbb/vwt66KwGHtYH0yi+l mFx3ojdO8Xtnig4jK9KjkbuAbzz4ITZI/b3O1XW0suKWFAtqT9mA8DvDEAblRTFA09ECAwEAAaM0 MDIwIgYDVR0RBBswGYEXZGF2aWRiQHZlcmlzaWdubGFicy5jb20wDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQAm67tKl2ra+HsW023l6DNHq15uOgueAtSRx2PQD8hubg8BKMA8l56vN8KN iWExdIsi9+nlYVO5hV9A32EVu5CLpHx2+I83dylZY7f4aBSRbsCDAvSAD9WEfVOyNMG02Wi9X+gb 2LFgn6Lcj2NSFvPqdieL8CJ68AGf9D6hELF5rTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggJmMIICYgIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDD6cYMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MTAxMzIyMDk1MVowIwYJKoZIhvcNAQkEMRYEFNT1EXbefYxIBbQBvQeg xocqcjBvMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPpxgwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDD6cYMA0GCSqGSIb3DQEBAQUABIGAb6S2089+jrPg6OJegJSj 8lCcBcU4c5BY5cP+jxcoswzxF3Z51U5QKbrV4tMJ0h1WpZFZta+BU926hbE1JdVTynBEjlghZtLe OEGIKVMzayvtpqMsA4/kCnvkGVgcOlaE/O792O9h9fA155VOaE2sykiFEtDisxWJfTNvozsO6VEA AAAAAAA= --=_cliffie-10090-1129241391-0001-2-- -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: David Blacka Subject: Re: DNSSEC explanation, comments? Date: Thu, 13 Oct 2005 18:14:41 -0400 Lines: 78 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="=_cliffie-10593-1129241682-0001-2" Cc: DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 00:21:40 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 In-Reply-To: <20051013213233.GC27170@outpost.ds9a.nl> To: bert hubert X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_cliffie-10593-1129241682-0001-2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Oct 13, 2005, at 5:32 PM, bert hubert wrote: > My current feeling is that PowerDNS will start offering basic DNSSEC > serving, but NSEC3 may be too different to fit in our database model. bert, could you elaborate? Specifically, what about NSEC3 or your database model would make NSEC3 difficult? -- David Blacka Sr. Engineer VeriSign Applied Research --=_cliffie-10593-1129241682-0001-2 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFnjCCAlcw ggHAoAMCAQICAw+nGDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUxMDEzMTQzNjA4WhcNMDYxMDEzMTQzNjA4WjBJMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSYwJAYJKoZIhvcNAQkBFhdkYXZpZGJAdmVyaXNpZ25s YWJzLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyzP1izF46evByd+R5GlKx4j2Eo6a Z1xXLc/JhxagaNuUujieUyiHCHikbf8PF/tf2Z9GfIDe1ygCZTQfqRCFbb/vwt66KwGHtYH0yi+l mFx3ojdO8Xtnig4jK9KjkbuAbzz4ITZI/b3O1XW0suKWFAtqT9mA8DvDEAblRTFA09ECAwEAAaM0 MDIwIgYDVR0RBBswGYEXZGF2aWRiQHZlcmlzaWdubGFicy5jb20wDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQAm67tKl2ra+HsW023l6DNHq15uOgueAtSRx2PQD8hubg8BKMA8l56vN8KN iWExdIsi9+nlYVO5hV9A32EVu5CLpHx2+I83dylZY7f4aBSRbsCDAvSAD9WEfVOyNMG02Wi9X+gb 2LFgn6Lcj2NSFvPqdieL8CJ68AGf9D6hELF5rTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggJmMIICYgIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDD6cYMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MTAxMzIyMTQ0MVowIwYJKoZIhvcNAQkEMRYEFAUZdC/8KFPE7qT7Fl/n IITvUdOCMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPpxgwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDD6cYMA0GCSqGSIb3DQEBAQUABIGAsNqbowM0xHyemy2/lAkz xLRqTNiuEnKDY2kGzSA1SJl46s5JtQl6XHchAGkSceGxzrVcKP9SUkyjpdr4lICS5hjaWodlKzvp d7kT7ZOjGXC0Lm27QNCO5GDzamOoWzg8N2TnTpeAV/iI5xtl3mymVm/GSNzMePysg3yZ2/NAafkA AAAAAAA= --=_cliffie-10593-1129241682-0001-2-- -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: bert hubert Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 07:56:24 +0200 Lines: 40 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 08:06:02 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 To: David Blacka Content-Disposition: inline In-Reply-To: <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Oct 13, 2005 at 06:14:41PM -0400, David Blacka wrote: > >My current feeling is that PowerDNS will start offering basic DNSSEC > >serving, but NSEC3 may be too different to fit in our database model. > > bert, could you elaborate? Specifically, what about NSEC3 or your > database model would make NSEC3 difficult? Thinking out loud here, it appears DNSSEC and specifically NSEC requires us to add a way to ask the database 'get next canonical record' 'get previous canonical record'. PowerDNS can operate in modes in which it does not have access to the entire zone, except through well-defined queries. For NSEC3, if I understand things correctly, this does not work: The ownername for the NSEC3 RR is the base32 encoding of the hashed ownername. Which, if I understand things correctly, would mean that we have to track some other way which NSEC3 records to send. But I'm not as smart as Ben, Roy & al so I may not be understanding correctly :-) If I have one suggestion for draft-ietf-dnsext-nsec3 it would be spelling out: 1) an example zone 2) the steps an authoritative nameserver has to take Thanks. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Ben Laurie Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 09:47:46 +0100 Lines: 49 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> <20051014055623.GA10908@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Blacka , DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 10:59:50 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: bert hubert In-Reply-To: <20051014055623.GA10908@outpost.ds9a.nl> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk bert hubert wrote: > On Thu, Oct 13, 2005 at 06:14:41PM -0400, David Blacka wrote: > >>>My current feeling is that PowerDNS will start offering basic DNSSEC >>>serving, but NSEC3 may be too different to fit in our database model. >> >>bert, could you elaborate? Specifically, what about NSEC3 or your >>database model would make NSEC3 difficult? > > > Thinking out loud here, it appears DNSSEC and specifically NSEC requires us > to add a way to ask the database 'get next canonical record' 'get previous > canonical record'. PowerDNS can operate in modes in which it does not have > access to the entire zone, except through well-defined queries. > > For NSEC3, if I understand things correctly, this does not work: > > The ownername for the NSEC3 RR is the base32 encoding of the hashed > ownername. > > Which, if I understand things correctly, would mean that we have to track > some other way which NSEC3 records to send. I recently realised that base32 encoding plus our rule that NSEC3 records are ordered by their raw binary values means that they _aren't_ in canonical order. I suspect this is a mistake and should be fixed. > If I have one suggestion for draft-ietf-dnsext-nsec3 it would be spelling > out: > > 1) an example zone It has several examples! > 2) the steps an authoritative nameserver has to take I thought it did this, too - what is deficient? -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: bert hubert Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 12:30:22 +0200 Lines: 22 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> <20051014055623.GA10908@outpost.ds9a.nl> <434F70B2.40505@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Blacka , DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 12:36:00 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Ben Laurie Content-Disposition: inline In-Reply-To: <434F70B2.40505@algroup.co.uk> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Oct 14, 2005 at 09:47:46AM +0100, Ben Laurie wrote: > >1) an example zone > It has several examples! Oops - I'll remind myself not to post before coffee. Apologies. > >2) the steps an authoritative nameserver has to take > I thought it did this, too - what is deficient? How do I go from a record to its associated NSEC3 record? Is that the one 'above' in the physical zone layout on disk? -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Alex Bligh Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 11:26:27 +0100 Lines: 29 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> <20051014055623.GA10908@outpost.ds9a.nl> Reply-To: Alex Bligh Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: DNSEXT WG , Alex Bligh X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 12:36:06 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 To: bert hubert , David Blacka In-Reply-To: <20051014055623.GA10908@outpost.ds9a.nl> X-Mailer: Mulberry/4.0.4 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 14 October 2005 07:56 +0200 bert hubert wrote: > Thinking out loud here, it appears DNSSEC and specifically NSEC requires > us to add a way to ask the database 'get next canonical record' 'get > previous canonical record'. PowerDNS can operate in modes in which it > does not have access to the entire zone, except through well-defined > queries. That's an interesting take on it, and indeed how I read it when I first looked at it. However, the underlying assumption is that "something else" generates the zone, complete with all the NSEC (or NSEC3) records. After all, each record has got to be signed, and the signing key may not be on your server (you might be a secondary). You then can have limited access to /that/ (the complete signed copy). What is interesting about what you are saying is you see PowerDNS as being the thing that creates the zone, including the NSEC records, and presumably signs them? Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: bert hubert Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 12:37:31 +0200 Lines: 36 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> <20051014055623.GA10908@outpost.ds9a.nl> <8EE515D76E624D3802FA88AB@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Blacka , DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 12:43:34 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 To: Alex Bligh Content-Disposition: inline In-Reply-To: <8EE515D76E624D3802FA88AB@[192.168.100.25]> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Oct 14, 2005 at 11:26:27AM +0100, Alex Bligh wrote: > generates the zone, complete with all the NSEC (or NSEC3) records. After > all, each record has got to be signed, and the signing key may not be on > your server (you might be a secondary). You then can have limited access to > /that/ (the complete signed copy). Indeed. But for non-existence I need to query the database for the NSEC record that covers the non-existent record, and that requires me to ask the database for the next canonical and previous canonical records. > What is interesting about what you are saying is you see PowerDNS as being > the thing that creates the zone, including the NSEC records, and presumably > signs them? We're still pondering deeply on how (and *if*) to implement DNSSEC-bis. One way would be to do online lazy signing. This would obviously only be useful for small zones. We're also pondering online-remote signing where a different machine signs remotely. But offline signing is also considered. Thanks. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Ben Laurie Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 11:43:48 +0100 Lines: 38 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> <20051014055623.GA10908@outpost.ds9a.nl> <434F70B2.40505@algroup.co.uk> <20051014103021.GA16285@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Blacka , DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 12:50:20 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: bert hubert In-Reply-To: <20051014103021.GA16285@outpost.ds9a.nl> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk bert hubert wrote: > On Fri, Oct 14, 2005 at 09:47:46AM +0100, Ben Laurie wrote: > > >>>1) an example zone >> >>It has several examples! > > > Oops - I'll remind myself not to post before coffee. Apologies. > > >>>2) the steps an authoritative nameserver has to take >> >>I thought it did this, too - what is deficient? > > > How do I go from a record to its associated NSEC3 record? Is that the one > 'above' in the physical zone layout on disk? Well, there are up to three associated records, and how you find them is explained in the I-D. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Alex Bligh Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 11:45:47 +0100 Lines: 20 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> <20051014055623.GA10908@outpost.ds9a.nl> <8EE515D76E624D3802FA88AB@[192.168.100.25]> <20051014103731.GB16285@outpost.ds9a.nl> Reply-To: Alex Bligh Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: David Blacka , DNSEXT WG , Alex Bligh X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 12:52:56 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 To: bert hubert In-Reply-To: <20051014103731.GB16285@outpost.ds9a.nl> X-Mailer: Mulberry/4.0.4 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 14 October 2005 12:37 +0200 bert hubert wrote: > Indeed. But for non-existence I need to query the database for the NSEC > record that covers the non-existent record, and that requires me to ask > the database for the next canonical and previous canonical records. Oh I see. Out of interest, why is that hard (either for NSEC or NSEC-3)? I am presuming it's to do with the data structures you are using at the moment only being suitable for a single ordering. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: bert hubert Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 13:02:04 +0200 Lines: 23 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> <20051014055623.GA10908@outpost.ds9a.nl> <8EE515D76E624D3802FA88AB@[192.168.100.25]> <20051014103731.GB16285@outpost.ds9a.nl> <23B62ABDF3A0DC25AD424269@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Blacka , DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 13:07:59 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Alex Bligh Content-Disposition: inline In-Reply-To: <23B62ABDF3A0DC25AD424269@[192.168.100.25]> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Oct 14, 2005 at 11:45:47AM +0100, Alex Bligh wrote: > Oh I see. Out of interest, why is that hard (either for NSEC or NSEC-3)? > I am presuming it's to do with the data structures you are using at the > moment only being suitable for a single ordering. It is not hard for NSEC. For NSEC3 however the hashed owner-name can't be predicted so the nameserver needs to *know* which NSEC3 records belong to which unhashed name, which means additional complexity. Which was the root of my original message yesterday: NSEC3 might make things more complex for us, much more so than DNSSEC-bis. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Alex Bligh Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 12:09:37 +0100 Lines: 31 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> <20051014055623.GA10908@outpost.ds9a.nl> <8EE515D76E624D3802FA88AB@[192.168.100.25]> <20051014103731.GB16285@outpost.ds9a.nl> <23B62ABDF3A0DC25AD424269@[192.168.100.25]> <20051014110203.GC16285@outpost.ds9a.nl> Reply-To: Alex Bligh Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: David Blacka , DNSEXT WG , Alex Bligh X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 13:14:55 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 To: bert hubert In-Reply-To: <20051014110203.GC16285@outpost.ds9a.nl> X-Mailer: Mulberry/4.0.4 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 14 October 2005 13:02 +0200 bert hubert wrote: > For NSEC3 however the hashed owner-name can't be predicted so the > nameserver needs to *know* which NSEC3 records belong to which unhashed > name, which means additional complexity. I may be being very dumb here. I am assuming that you store the hashed value of each name in the database, and that you also maintain an index to the database (indexed by that hash), of course in addition to the normal name based index. Then when you get a requirement to prove non-existence, you hash that name, and it is then trivial to find the name whose hash is immediately before and/or after it. This requires that at some stage someone has gone and hashed all the RRs, and they've created an ordering by hash value to make an index, but I'm not sure why that's any harder than (say) signing unless there is an inherent difficulty in maintaining orderings by two distinct indices. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Ben Laurie Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 12:31:22 +0100 Lines: 27 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> <20051014055623.GA10908@outpost.ds9a.nl> <8EE515D76E624D3802FA88AB@[192.168.100.25]> <20051014103731.GB16285@outpost.ds9a.nl> <23B62ABDF3A0DC25AD424269@[192.168.100.25]> <20051014110203.GC16285@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh , David Blacka , DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 13:37:42 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: bert hubert In-Reply-To: <20051014110203.GC16285@outpost.ds9a.nl> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk bert hubert wrote: > On Fri, Oct 14, 2005 at 11:45:47AM +0100, Alex Bligh wrote: > >>Oh I see. Out of interest, why is that hard (either for NSEC or NSEC-3)? >>I am presuming it's to do with the data structures you are using at the >>moment only being suitable for a single ordering. > > > It is not hard for NSEC. > > For NSEC3 however the hashed owner-name can't be predicted so the nameserver > needs to *know* which NSEC3 records belong to which unhashed name, which > means additional complexity. No, you just need to hash the name before you do the lookup. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: bert hubert Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 13:36:21 +0200 Lines: 21 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> <20051014055623.GA10908@outpost.ds9a.nl> <8EE515D76E624D3802FA88AB@[192.168.100.25]> <20051014103731.GB16285@outpost.ds9a.nl> <23B62ABDF3A0DC25AD424269@[192.168.100.25]> <20051014110203.GC16285@outpost.ds9a.nl> <434F970A.5060305@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alex Bligh , David Blacka , DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 13:42:16 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Ben Laurie Content-Disposition: inline In-Reply-To: <434F970A.5060305@algroup.co.uk> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Oct 14, 2005 at 12:31:22PM +0100, Ben Laurie wrote: > No, you just need to hash the name before you do the lookup. Ok - I had disregarded that possibility because that means that an entire zone can have only 1 hash size, salt, iteration count and algorithm configured. I'll update http://ds9a.nl/dnssec with remarks made here earlier and with NSEC3. Thanks. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: "Scott Rose" Subject: RE: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 07:54:53 -0400 Lines: 48 References: <20051013213233.GC27170@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 14:03:28 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 To: "bert hubert" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20051013213233.GC27170@outpost.ds9a.nl> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of bert hubert ortant. > > > You might want to point readers to the working examples of .se and > > ripe.net, as signed zones running in the wild. > > I've queried for real .se delegations but short of asking here or > bothering > the .se administrators nobody could point me to a real DS record 'in the > wild'. But I'm very interested. > It isn't really "in the wild", but there is an example signed subzone to our signed zone: valid.antd.nist.gov. is signed (and has a DS RR) in antd.nist.gov. zone. Both are served from the same server to see it, do a dig @129.6.100.251 for valid.antd.nist.gov DS There isn't much to that zone, it's just used for demos. Scott > My current feeling is that PowerDNS will start offering basic DNSSEC > serving, but NSEC3 may be too different to fit in our database model. > > Thanks! > > -- > http://www.PowerDNS.com Open source, database driven DNS Software > http://netherlabs.nl Open and Closed source services > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Ben Laurie Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 12:56:50 +0100 Lines: 24 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> <20051014055623.GA10908@outpost.ds9a.nl> <8EE515D76E624D3802FA88AB@[192.168.100.25]> <20051014103731.GB16285@outpost.ds9a.nl> <23B62ABDF3A0DC25AD424269@[192.168.100.25]> <20051014110203.GC16285@outpost.ds9a.nl> <434F970A.5060305@algroup.co.uk> <20051014113621.GD16285@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh , David Blacka , DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 14:04:38 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: bert hubert In-Reply-To: <20051014113621.GD16285@outpost.ds9a.nl> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk bert hubert wrote: > On Fri, Oct 14, 2005 at 12:31:22PM +0100, Ben Laurie wrote: > >>No, you just need to hash the name before you do the lookup. > > > Ok - I had disregarded that possibility because that means that an entire > zone can have only 1 hash size, salt, iteration count and algorithm > configured. Its a requirement! Otherwise you cannot deny the existence of arbitrary domains. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Alex Bligh Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 13:05:33 +0100 Lines: 25 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> <20051014055623.GA10908@outpost.ds9a.nl> <8EE515D76E624D3802FA88AB@[192.168.100.25]> <20051014103731.GB16285@outpost.ds9a.nl> <23B62ABDF3A0DC25AD424269@[192.168.100.25]> <20051014110203.GC16285@outpost.ds9a.nl> <434F970A.5060305@algroup.co.uk> <20051014113621.GD16285@outpost.ds9a.nl> <434F9D02.3050106@algroup.co.uk> Reply-To: Alex Bligh Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: David Blacka , DNSEXT WG , Alex Bligh X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 14:12:37 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 To: Ben Laurie , bert hubert In-Reply-To: <434F9D02.3050106@algroup.co.uk> X-Mailer: Mulberry/4.0.4 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 14 October 2005 12:56 +0100 Ben Laurie wrote: >> Ok - I had disregarded that possibility because that means that an entire >> zone can have only 1 hash size, salt, iteration count and algorithm >> configured. > > Its a requirement! Otherwise you cannot deny the existence of arbitrary > domains. Well, speaking theoretically rather in respect of the particular implementation, the requirement is surely that the server has access to a zone file where there is AT LEAST ONE 4-tuple of {hash-size, salt, iteration count, and algorithm} which is present for each label. The presence of others hanging around shouldn't actually prevent denial of existence of arbitrary names (though might have other effects). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Roy Arends Subject: alg,salt,iter namespaces, was (Re: DNSSEC explanation, comments?) Date: Fri, 14 Oct 2005 14:08:08 +0200 (CEST) Lines: 45 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> <20051014055623.GA10908@outpost.ds9a.nl> <8EE515D76E624D3802FA88AB@[192.168.100.25]> <20051014103731.GB16285@outpost.ds9a.nl> <23B62ABDF3A0DC25AD424269@[192.168.100.25]> <20051014110203.GC16285@outpost.ds9a.nl> <434F970A.5060305@algroup.co.uk> <20051014113621.GD16285@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 14:14:24 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-X-Sender: roy@netinfo.corporate.telin.nl To: DNSEXT WG In-Reply-To: <20051014113621.GD16285@outpost.ds9a.nl> X-OriginalArrivalTime: 14 Oct 2005 12:08:08.0082 (UTC) FILETIME=[F0674720:01C5D0B7] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 14 Oct 2005, bert hubert wrote: > On Fri, Oct 14, 2005 at 12:31:22PM +0100, Ben Laurie wrote: >> No, you just need to hash the name before you do the lookup. > > Ok - I had disregarded that possibility because that means that an entire > zone can have only 1 hash size, salt, iteration count and algorithm > configured. Almost, There must be at least one complete for the entire zone. Complete means that every ownername must have a NSEC3 associated that has the same value for the entire zone. The defines a hash namespace (hash length is a property of the hash function used). Rolling this namespace (i.e. changing any parameter) required the whole zone to be rehashed and resigned at once. To be able to do a slow roll, gradually introducing the new (rolled) hashed namespace, while maintaining the current hashed namespace, we're thinking of using the apex' NSEC3 to indicate the namespace. Since the ownername of that record is hashed as well, there is a circular dependency. (When you want to find the current , hash the apex using .....). So, a way to locate the apex' NSEC3 is to keep track of that one NSEC3 record which has the SOA bit set. All in all, there can be multiple hashed namespaces, but only the complete ones must include the apex. Authoritative servers can use this method to know what to use when it needs to include (and thus find) an NSEC3 in the response. It is not possible to indicate the current namespace out of band (via configuration or otherwise), since the namespace needs to be signalled to secondary servers as well, in-band. Hope this helps, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Ben Laurie Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 13:12:01 +0100 Lines: 35 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> <20051014055623.GA10908@outpost.ds9a.nl> <8EE515D76E624D3802FA88AB@[192.168.100.25]> <20051014103731.GB16285@outpost.ds9a.nl> <23B62ABDF3A0DC25AD424269@[192.168.100.25]> <20051014110203.GC16285@outpost.ds9a.nl> <434F970A.5060305@algroup.co.uk> <20051014113621.GD16285@outpost.ds9a.nl> <434F9D02.3050106@algroup.co.uk> <86F457810B84849160970E1C@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bert hubert , David Blacka , DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 14:19:11 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: Alex Bligh In-Reply-To: <86F457810B84849160970E1C@[192.168.100.25]> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alex Bligh wrote: > > > --On 14 October 2005 12:56 +0100 Ben Laurie wrote: > >>> Ok - I had disregarded that possibility because that means that an >>> entire >>> zone can have only 1 hash size, salt, iteration count and algorithm >>> configured. >> >> >> Its a requirement! Otherwise you cannot deny the existence of arbitrary >> domains. > > > Well, speaking theoretically rather in respect of the particular > implementation, the requirement is surely that the server has access to a > zone file where there is AT LEAST ONE 4-tuple of {hash-size, salt, > iteration count, and algorithm} which is present for each label. The > presence of others hanging around shouldn't actually prevent denial > of existence of arbitrary names (though might have other effects). Correct, and this is what the I-D says. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Alex Bligh Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 13:16:25 +0100 Lines: 34 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> <20051014055623.GA10908@outpost.ds9a.nl> <8EE515D76E624D3802FA88AB@[192.168.100.25]> <20051014103731.GB16285@outpost.ds9a.nl> <23B62ABDF3A0DC25AD424269@[192.168.100.25]> <20051014110203.GC16285@outpost.ds9a.nl> <434F970A.5060305@algroup.co.uk> <20051014113621.GD16285@outpost.ds9a.nl> <434F9D02.3050106@algroup.co.uk> <86F457810B84849160970E1C@[192.168.100.25]> <434FA091.2060704@algroup.co.uk> Reply-To: Alex Bligh Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: bert hubert , David Blacka , DNSEXT WG , Alex Bligh X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 14:23:04 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 To: Ben Laurie In-Reply-To: <434FA091.2060704@algroup.co.uk> X-Mailer: Mulberry/4.0.4 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 14 October 2005 13:12 +0100 Ben Laurie wrote: >>>> Ok - I had disregarded that possibility because that means that an >>>> entire >>>> zone can have only 1 hash size, salt, iteration count and algorithm >>>> configured. >>> >>> >>> Its a requirement! Otherwise you cannot deny the existence of arbitrary >>> domains. >> >> >> Well, speaking theoretically rather in respect of the particular >> implementation, the requirement is surely that the server has access to a >> zone file where there is AT LEAST ONE 4-tuple of {hash-size, salt, >> iteration count, and algorithm} which is present for each label. The >> presence of others hanging around shouldn't actually prevent denial >> of existence of arbitrary names (though might have other effects). > > Correct, and this is what the I-D says. So it isn't a requirement that an entire zone "can have only 1 hash size, salt, iteration count and algorithm configured". The requirement is that it has *at least* one consistent hash size, salt (etc.). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Alex Bligh Subject: Re: alg,salt,iter namespaces, was (Re: DNSSEC explanation, comments?) Date: Fri, 14 Oct 2005 13:20:15 +0100 Lines: 23 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> <20051014055623.GA10908@outpost.ds9a.nl> <8EE515D76E624D3802FA88AB@[192.168.100.25]> <20051014103731.GB16285@outpost.ds9a.nl> <23B62ABDF3A0DC25AD424269@[192.168.100.25]> <20051014110203.GC16285@outpost.ds9a.nl> <434F970A.5060305@algroup.co.uk> <20051014113621.GD16285@outpost.ds9a.nl> Reply-To: Alex Bligh Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 14:26:59 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 To: Roy Arends , DNSEXT WG In-Reply-To: X-Mailer: Mulberry/4.0.4 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 14 October 2005 14:08 +0200 Roy Arends wrote: > There must be at least one complete for the entire zone. > Complete means that every ownername must have a NSEC3 associated that has > the same value for the entire zone. ... > To be able to do a slow roll, gradually introducing the new (rolled) > hashed namespace, while maintaining the current hashed namespace, we're > thinking of using the apex' NSEC3 to indicate the namespace. and hence having a tuple for the apex will necessarily imply that that is complete (i.e. present everywhere else too)? Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Ben Laurie Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 13:22:06 +0100 Lines: 46 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> <20051014055623.GA10908@outpost.ds9a.nl> <8EE515D76E624D3802FA88AB@[192.168.100.25]> <20051014103731.GB16285@outpost.ds9a.nl> <23B62ABDF3A0DC25AD424269@[192.168.100.25]> <20051014110203.GC16285@outpost.ds9a.nl> <434F970A.5060305@algroup.co.uk> <20051014113621.GD16285@outpost.ds9a.nl> <434F9D02.3050106@algroup.co.uk> <86F457810B84849160970E1C@[192.168.100.25]> <434FA091.2060704@algroup.co.uk> <554469BA87B1B496F4AEFC72@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bert hubert , David Blacka , DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 14:29:00 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: Alex Bligh In-Reply-To: <554469BA87B1B496F4AEFC72@[192.168.100.25]> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alex Bligh wrote: > > > --On 14 October 2005 13:12 +0100 Ben Laurie wrote: > >>>>> Ok - I had disregarded that possibility because that means that an >>>>> entire >>>>> zone can have only 1 hash size, salt, iteration count and algorithm >>>>> configured. >>>> >>>> >>>> >>>> Its a requirement! Otherwise you cannot deny the existence of arbitrary >>>> domains. >>> >>> >>> >>> Well, speaking theoretically rather in respect of the particular >>> implementation, the requirement is surely that the server has access >>> to a >>> zone file where there is AT LEAST ONE 4-tuple of {hash-size, salt, >>> iteration count, and algorithm} which is present for each label. The >>> presence of others hanging around shouldn't actually prevent denial >>> of existence of arbitrary names (though might have other effects). >> >> >> Correct, and this is what the I-D says. > > > So it isn't a requirement that an entire zone "can have only 1 hash size, > salt, iteration count and algorithm configured". The requirement is > that it has *at least* one consistent hash size, salt (etc.). Yes. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Roy Arends Subject: Re: alg,salt,iter namespaces, was (Re: DNSSEC explanation, comments?) Date: Fri, 14 Oct 2005 14:24:17 +0200 (CEST) Lines: 25 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> <15A7ADF1-EB81-471F-99D3-82D5F8C59FF5@verisignlabs.com> <20051014055623.GA10908@outpost.ds9a.nl> <8EE515D76E624D3802FA88AB@[192.168.100.25]> <20051014103731.GB16285@outpost.ds9a.nl> <23B62ABDF3A0DC25AD424269@[192.168.100.25]> <20051014110203.GC16285@outpost.ds9a.nl> <434F970A.5060305@algroup.co.uk> <20051014113621.GD16285@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 14:30:59 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-X-Sender: roy@netinfo.corporate.telin.nl To: Alex Bligh In-Reply-To: X-OriginalArrivalTime: 14 Oct 2005 12:24:17.0735 (UTC) FILETIME=[325C9570:01C5D0BA] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 14 Oct 2005, Alex Bligh wrote: > --On 14 October 2005 14:08 +0200 Roy Arends wrote: > >> There must be at least one complete for the entire zone. >> Complete means that every ownername must have a NSEC3 associated that has >> the same value for the entire zone. > ... >> To be able to do a slow roll, gradually introducing the new (rolled) >> hashed namespace, while maintaining the current hashed namespace, we're >> thinking of using the apex' NSEC3 to indicate the namespace. > > and hence having a tuple for the apex will necessarily > imply that that is complete (i.e. present everywhere > else too)? Yes. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: bert hubert Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 14:28:33 +0200 Lines: 18 References: <8EE515D76E624D3802FA88AB@[192.168.100.25]> <20051014103731.GB16285@outpost.ds9a.nl> <23B62ABDF3A0DC25AD424269@[192.168.100.25]> <20051014110203.GC16285@outpost.ds9a.nl> <434F970A.5060305@algroup.co.uk> <20051014113621.GD16285@outpost.ds9a.nl> <434F9D02.3050106@algroup.co.uk> <86F457810B84849160970E1C@[192.168.100.25]> <434FA091.2060704@algroup.co.uk> <554469BA87B1B496F4AEFC72@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Ben Laurie , David Blacka , DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 14:34:40 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 To: Alex Bligh Content-Disposition: inline In-Reply-To: <554469BA87B1B496F4AEFC72@[192.168.100.25]> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > So it isn't a requirement that an entire zone "can have only 1 hash size, > salt, iteration count and algorithm configured". The requirement is > that it has *at least* one consistent hash size, salt (etc.). And, practically, that the authoritative nameserver knows about them. One may wonder how a caching nameserver would know - it probably wouldn't. But I'm way out of my depth here. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Roy Arends Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 14:44:16 +0200 (CEST) Lines: 22 References: <8EE515D76E624D3802FA88AB@[192.168.100.25]> <20051014103731.GB16285@outpost.ds9a.nl> <23B62ABDF3A0DC25AD424269@[192.168.100.25]> <20051014110203.GC16285@outpost.ds9a.nl> <434F970A.5060305@algroup.co.uk> <20051014113621.GD16285@outpost.ds9a.nl> <434F9D02.3050106@algroup.co.uk> <86F457810B84849160970E1C@[192.168.100.25]> <434FA091.2060704@algroup.co.uk> <554469BA87B1B496F4AEFC72@[192.168.100.25]> <20051014122833.GA19423@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alex Bligh , Ben Laurie , David Blacka , DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 14:51:55 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-X-Sender: roy@netinfo.corporate.telin.nl To: bert hubert In-Reply-To: <20051014122833.GA19423@outpost.ds9a.nl> X-OriginalArrivalTime: 14 Oct 2005 12:44:16.0907 (UTC) FILETIME=[FD1FB5B0:01C5D0BC] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 14 Oct 2005, bert hubert wrote: >> So it isn't a requirement that an entire zone "can have only 1 hash size, >> salt, iteration count and algorithm configured". The requirement is >> that it has *at least* one consistent hash size, salt (etc.). > > And, practically, that the authoritative nameserver knows about them. One > may wonder how a caching nameserver would know - it probably wouldn't. Indeed, the caching nameserver wouldn't have to know. It would simply take the parameters from the NSEC3 included in the response, and hash the qname (or whatever it needs to check), and match the result with the NSEC3 interval. 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 dhcwg-bounces@ietf.org Fri Dec 29 11:36:43 2006 From: Ralph Droms Subject: Package of DDNS-DHCP drafts ready for review Date: Fri, 14 Oct 2005 10:12:16 -0400 Lines: 9 Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Olaf Kolkman , namedroppers@ops.ietf.org, Stig Venaas , Olafur Gudmundsson , dhcwg@ietf.org X-From: dhcwg-bounces@ietf.org Fri Oct 14 16:20:46 2005 Return-path: X-IronPort-AV: i="3.97,215,1125903600"; d="scan'208"; a="220177767:sNHT29250126" To: Margaret Wasserman , "W.MarkTownsley" X-Mailer: Evolution 2.0.4 (2.0.4-6) X-OriginalArrivalTime: 14 Oct 2005 14:11:56.0629 (UTC) FILETIME=[3C299850:01C5D0C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Now that the dhc WG has submitted its drafts to the IESG, the package of documents related to DDNS-DHCP interaction is ready for IESG review: draft-ietf-dnsext-dhcid-rr-10.txt draft-ietf-dhc-fqdn-option-11.txt draft-ietf-dhc-dhcpv6-fqdn-03.txt draft-ietf-dhc-ddns-resolution-10.txt - Ralph From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: bert hubert Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 17:02:38 +0200 Lines: 32 References: <23B62ABDF3A0DC25AD424269@[192.168.100.25]> <20051014110203.GC16285@outpost.ds9a.nl> <434F970A.5060305@algroup.co.uk> <20051014113621.GD16285@outpost.ds9a.nl> <434F9D02.3050106@algroup.co.uk> <86F457810B84849160970E1C@[192.168.100.25]> <434FA091.2060704@algroup.co.uk> <554469BA87B1B496F4AEFC72@[192.168.100.25]> <20051014122833.GA19423@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alex Bligh , Ben Laurie , David Blacka , DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 17:13:32 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 To: Roy Arends Mail-Followup-To: bert hubert , Roy Arends , Alex Bligh , Ben Laurie , David Blacka , DNSEXT WG Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Oct 14, 2005 at 02:44:16PM +0200, Roy Arends wrote: > >And, practically, that the authoritative nameserver knows about them. One > >may wonder how a caching nameserver would know - it probably wouldn't. > > Indeed, the caching nameserver wouldn't have to know. It would have to learn if it were to be able to figure out the proper NSEC3 to send from its cache with a NO ERROR for example. To this end it would also need to maintain a list of zone cuts just to be sure it has the parameters of 'x.w.example.com' and not just of 'w.example.com'. > It would simply take the parameters from the NSEC3 > included in the response, and hash the qname (or whatever it needs to > check), and match the result with the NSEC3 interval. I love how you use the word 'simply'. NSEC3 is an explosion of complexity, almost impossible to debug as well. Imagine having to brute force your domain list just to figure out where a possible outdated NSEC3 record came from. DNSSEC is hard enough as it is. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: David Blacka Subject: Re: DNSSEC explanation, comments? Date: Fri, 14 Oct 2005 13:19:13 -0400 Lines: 61 References: <23B62ABDF3A0DC25AD424269@[192.168.100.25]> <20051014110203.GC16285@outpost.ds9a.nl> <434F970A.5060305@algroup.co.uk> <20051014113621.GD16285@outpost.ds9a.nl> <434F9D02.3050106@algroup.co.uk> <86F457810B84849160970E1C@[192.168.100.25]> <434FA091.2060704@algroup.co.uk> <554469BA87B1B496F4AEFC72@[192.168.100.25]> <20051014122833.GA19423@outpost.ds9a.nl> <20051014150238.GA19821@outpost.ds9a.nl> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Cc: DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Fri Oct 14 19:29:19 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 In-Reply-To: <20051014150238.GA19821@outpost.ds9a.nl> To: bert hubert X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Oct 14, 2005, at 11:02 AM, bert hubert wrote: > On Fri, Oct 14, 2005 at 02:44:16PM +0200, Roy Arends wrote: > >>> And, practically, that the authoritative nameserver knows about >>> them. One >>> may wonder how a caching nameserver would know - it probably >>> wouldn't. >>> >> >> Indeed, the caching nameserver wouldn't have to know. >> > > It would have to learn if it were to be able to figure out the > proper NSEC3 > to send from its cache with a NO ERROR for example. To this end it > would > also need to maintain a list of zone cuts just to be sure it has the > parameters of 'x.w.example.com' and not just of 'w.example.com'. How does the caching nameserver discover which NSEC records to return for a cached NAME ERROR response? One of the things envisioned by DNSSEC is that caches should not be searching for which NSEC records go with which response -- it should *know*, because it cached that data along with response. So, I'm having a hard time understanding why a cache would need to track zone cuts and the like. It just sounds like the wrong approach to me. >> It would simply take the parameters from the NSEC3 >> included in the response, and hash the qname (or whatever it needs to >> check), and match the result with the NSEC3 interval. >> > > I love how you use the word 'simply'. NSEC3 is an explosion of > complexity, > almost impossible to debug as well. Er, how so? > Imagine having to brute force your domain list just to figure out > where a > possible outdated NSEC3 record came from. Um, what? I just don't understand the scenario here. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: bert hubert Subject: Re: DNSSEC explanation, comments? Date: Sun, 16 Oct 2005 12:01:20 +0200 Lines: 36 References: <434F970A.5060305@algroup.co.uk> <20051014113621.GD16285@outpost.ds9a.nl> <434F9D02.3050106@algroup.co.uk> <86F457810B84849160970E1C@[192.168.100.25]> <434FA091.2060704@algroup.co.uk> <554469BA87B1B496F4AEFC72@[192.168.100.25]> <20051014122833.GA19423@outpost.ds9a.nl> <20051014150238.GA19821@outpost.ds9a.nl> <6B3DEDF4-E9F1-4F26-9B95-CC89EC016500@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Sun Oct 16 12:13:32 2005 Return-path: To: David Blacka Content-Disposition: inline In-Reply-To: <6B3DEDF4-E9F1-4F26-9B95-CC89EC016500@verisignlabs.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Oct 14, 2005 at 01:19:13PM -0400, David Blacka wrote: > One of the things envisioned by DNSSEC is that caches should not be > searching for which NSEC records go with which response -- it should > *know*, because it cached that data along with response. Ah ok. DNSSEC probably means that resolvers too have to enter the 64-bit era, most big caches hover around the 1G mark already. > >I love how you use the word 'simply'. NSEC3 is an explosion of > >complexity, almost impossible to debug as well. > > Er, how so? If you have an NSEC3 record being returned it is rather hard work figuring out which record it corresponds to, especially if you don't have access to the zone - which appears likely given the choice to use NSEC3. My current thinking is for NSEC we can add a call to retrieve the NSEC record straddling the one queried for, which will be fast for all our backends. For NSEC3 things are trickier as we need to first figure out a record in front of the one queried for, and then one after. Then we need to hash both, and see if there is an NSEC3 record that matches that. I haven't thought about wildcards yet.. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: David Blacka Subject: Re: DNSSEC explanation, comments? Date: Sun, 16 Oct 2005 09:59:31 -0400 Lines: 75 References: <434F970A.5060305@algroup.co.uk> <20051014113621.GD16285@outpost.ds9a.nl> <434F9D02.3050106@algroup.co.uk> <86F457810B84849160970E1C@[192.168.100.25]> <434FA091.2060704@algroup.co.uk> <554469BA87B1B496F4AEFC72@[192.168.100.25]> <20051014122833.GA19423@outpost.ds9a.nl> <20051014150238.GA19821@outpost.ds9a.nl> <6B3DEDF4-E9F1-4F26-9B95-CC89EC016500@verisignlabs.com> <20051016100120.GB5187@outpost.ds9a.nl> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Cc: DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Sun Oct 16 16:10:26 2005 Return-path: In-Reply-To: <20051016100120.GB5187@outpost.ds9a.nl> To: bert hubert X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Oct 16, 2005, at 6:01 AM, bert hubert wrote: > On Fri, Oct 14, 2005 at 01:19:13PM -0400, David Blacka wrote: > >> One of the things envisioned by DNSSEC is that caches should not be >> searching for which NSEC records go with which response -- it should >> *know*, because it cached that data along with response. >> > > Ah ok. DNSSEC probably means that resolvers too have to enter the > 64-bit > era, most big caches hover around the 1G mark already. I don't follow. While it is clear that DNSSEC (w/ or w/o NSEC3) will increase the amount of data that is cached, it is unclear that it would, by itself, grow the cache by a factor of more than 4 (to reach the 32-bit ceiling of 4GB). Nor is it clear that they would need to grow at all -- they could just cache fewer things. > >>> I love how you use the word 'simply'. NSEC3 is an explosion of >>> complexity, almost impossible to debug as well. >>> >> >> Er, how so? >> > > If you have an NSEC3 record being returned it is rather hard work > figuring out which record it corresponds to, especially if you > don't have > access to the zone - which appears likely given the choice to use > NSEC3. Ok, I agree that given an NSEC3 record it is difficult to find out what rrset generated it (which is the point of NSEC3, after all). But why would you want to? > My current thinking is for NSEC we can add a call to retrieve the NSEC > record straddling the one queried for, which will be fast for all our > backends. > > For NSEC3 things are trickier as we need to first figure out a > record in > front of the one queried for, and then one after. Then we need to > hash both, > and see if there is an NSEC3 record that matches that. Ok, if you can find the NSEC that "straddles" your qname efficiently, how is finding an NSEC3 that straddles the hash of your qname not efficient? Note that the order of the NSEC3 records is unrelated to the order of the records that they were generated from. So it is not important that you find the name that precedes or follows qname. > I haven't thought about wildcards yet.. You *will* need to know the closest encloser of the qname. But presumably you find that now when looking for wildcards. In that case you just hash the name of the closest encloser an return the NSEC3 that directly matches that, along with the NSEC3 that covers *.closest_encloser. (This is for the rcode=3 case). -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Ben Laurie Subject: Re: DNSSEC explanation, comments? Date: Sun, 16 Oct 2005 17:06:39 +0100 Lines: 25 References: <434F970A.5060305@algroup.co.uk> <20051014113621.GD16285@outpost.ds9a.nl> <434F9D02.3050106@algroup.co.uk> <86F457810B84849160970E1C@[192.168.100.25]> <434FA091.2060704@algroup.co.uk> <554469BA87B1B496F4AEFC72@[192.168.100.25]> <20051014122833.GA19423@outpost.ds9a.nl> <20051014150238.GA19821@outpost.ds9a.nl> <6B3DEDF4-E9F1-4F26-9B95-CC89EC016500@verisignlabs.com> <20051016100120.GB5187@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: David Blacka , DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Sun Oct 16 18:18:16 2005 Return-path: User-Agent: Thunderbird 1.4.1 (Windows/20051006) To: bert hubert In-Reply-To: <20051016100120.GB5187@outpost.ds9a.nl> X-Enigmail-Version: 0.93.0.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk bert hubert wrote: > For NSEC3 things are trickier as we need to first figure out a record in > front of the one queried for, and then one after. Then we need to hash both, > and see if there is an NSEC3 record that matches that. No you don't. You hash the name queried for and find the record that straddles the hash. However, caches aren't supposed to invent negative responses anyway. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Paul Vixie Subject: Re: DNSSEC explanation, comments? Date: Sun, 16 Oct 2005 16:58:56 +0000 Lines: 13 References: <434F970A.5060305@algroup.co.uk> <20051014113621.GD16285@outpost.ds9a.nl> <434F9D02.3050106@algroup.co.uk> <86F457810B84849160970E1C@[192.168.100.25]> <434FA091.2060704@algroup.co.uk> <554469BA87B1B496F4AEFC72@[192.168.100.25]> <20051014122833.GA19423@outpost.ds9a.nl> <20051014150238.GA19821@outpost.ds9a.nl> <6B3DEDF4-E9F1-4F26-9B95-CC89EC016500@verisignlabs.com> <20051016100120.GB5187@outpost.ds9a.nl> X-From: owner-namedroppers@ops.ietf.org Sun Oct 16 19:07:54 2005 Return-path: To: DNSEXT WG In-Reply-To: Your message of "Sun, 16 Oct 2005 12:01:20 +0200." <20051016100120.GB5187@outpost.ds9a.nl> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # ... DNSSEC probably means that resolvers too have to enter the 64-bit era, Um... why? # most big caches hover around the 1G mark already. Um... not in my experience. -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Paul Vixie Subject: Re: DNSSEC explanation, comments? Date: Sun, 16 Oct 2005 17:17:28 +0000 Lines: 35 References: <434F970A.5060305@algroup.co.uk> <20051014113621.GD16285@outpost.ds9a.nl> <434F9D02.3050106@algroup.co.uk> <86F457810B84849160970E1C@[192.168.100.25]> <434FA091.2060704@algroup.co.uk> <554469BA87B1B496F4AEFC72@[192.168.100.25]> <20051014122833.GA19423@outpost.ds9a.nl> <20051014150238.GA19821@outpost.ds9a.nl> <6B3DEDF4-E9F1-4F26-9B95-CC89EC016500@verisignlabs.com> <20051016100120.GB5187@outpost.ds9a.nl> <43527A8F.5090204@algroup.co.uk> Cc: bert hubert , David Blacka , DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Sun Oct 16 19:23:27 2005 Return-path: To: Ben Laurie In-Reply-To: Your message of "Sun, 16 Oct 2005 17:06:39 +0100." <43527A8F.5090204@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # > For NSEC3 things are trickier as we need to first figure out a record in # > front of the one queried for, and then one after. Then we need to hash # > both, and see if there is an NSEC3 record that matches that. # # No you don't. You hash the name queried for and find the record that # straddles the hash. that's hard if you're an authority server in the eyes of the protocol but you're only a protocol front-end in the eyes of the data. powerdns, and bind9+dlz, and bind9+sdb+sql, and presumably other implementations that can currently function as protocol front-ends without having access to the full zone, are going to have a hard time adapting to NSEC3. hubert was pointing out that it'll take an API change so that each backend can find the fast way to do what NSEC3 requires, and i agree. # However, caches aren't supposed to invent negative responses anyway. the message you were responding to talked first about caches and then about authority servers that don't have a priori access to zone content. i was about to reply the same way you did until i realized that hubert's comments about the difficulty of "zone window" protocol front ends in the face of NSEC3 really is higher than the difficulty with just NSEC or no DNSSEC. the dnssec protocol, like axfr, thinks in terms of "zone identity". if you have a windowing front end that only knows the parts of the zone that it has been queried for, or perhaps even less if it has no "hotspot cache", then the identity of the zone isn't known or knowable, and interpretting the rules of axfr or dnssec or anything else that assumes that zones have identity, is a variously hard 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 Fri Dec 29 11:36:43 2006 From: bert hubert Subject: Re: DNSSEC explanation, comments? Date: Sun, 16 Oct 2005 19:26:40 +0200 Lines: 33 References: <434F9D02.3050106@algroup.co.uk> <86F457810B84849160970E1C@[192.168.100.25]> <434FA091.2060704@algroup.co.uk> <554469BA87B1B496F4AEFC72@[192.168.100.25]> <20051014122833.GA19423@outpost.ds9a.nl> <20051014150238.GA19821@outpost.ds9a.nl> <6B3DEDF4-E9F1-4F26-9B95-CC89EC016500@verisignlabs.com> <20051016100120.GB5187@outpost.ds9a.nl> <43527A8F.5090204@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Blacka , DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Sun Oct 16 19:32:02 2005 Return-path: To: Ben Laurie Content-Disposition: inline In-Reply-To: <43527A8F.5090204@algroup.co.uk> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, Oct 16, 2005 at 05:06:39PM +0100, Ben Laurie wrote: > bert hubert wrote: > > For NSEC3 things are trickier as we need to first figure out a record in > > front of the one queried for, and then one after. Then we need to hash both, > > and see if there is an NSEC3 record that matches that. > > No you don't. You hash the name queried for and find the record that > straddles the hash. Ahhh - so an NSEC3 says 'there is no record between these two hashes', and not 'there is no record between the origin of these hashes'? Otherwise your quote above implies: A < B => hash(A) < hash(B) Which is not true generally. > However, caches aren't supposed to invent negative responses anyway. I didn't mean to say that, apologies if it appeared that way. PowerDNS has both a recursive and an authoritative part. Thanks. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: bert hubert Subject: Re: DNSSEC explanation, comments? Date: Sun, 16 Oct 2005 19:38:49 +0200 Lines: 31 References: <434F9D02.3050106@algroup.co.uk> <86F457810B84849160970E1C@[192.168.100.25]> <434FA091.2060704@algroup.co.uk> <554469BA87B1B496F4AEFC72@[192.168.100.25]> <20051014122833.GA19423@outpost.ds9a.nl> <20051014150238.GA19821@outpost.ds9a.nl> <6B3DEDF4-E9F1-4F26-9B95-CC89EC016500@verisignlabs.com> <20051016100120.GB5187@outpost.ds9a.nl> <20051016165856.BE3AE11425@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Sun Oct 16 19:45:10 2005 Return-path: To: Paul Vixie Content-Disposition: inline In-Reply-To: <20051016165856.BE3AE11425@sa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, Oct 16, 2005 at 04:58:56PM +0000, Paul Vixie wrote: > # ... DNSSEC probably means that resolvers too have to enter the 64-bit era, > > Um... why? A cached NXDOMAIN is going to be a lot larger as it needs to store an nsec and an rrssig. An open question is how many nsec's and rrsig's are going to be shared among non-existence answers. I note a lot of queries resulting in NXDOMAINS to recursors. > # most big caches hover around the 1G mark already. > Um... not in my experience. Some of them are lots bigger, indeed, but I know of none in production >4G. But I bet you know lots more installations than I do :-) It might well be possible to retain current service levels with less memory though. Thanks btw to people here for helping me understand DNSSEC and NSEC3, much appreciated! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Ben Laurie Subject: Re: DNSSEC explanation, comments? Date: Sun, 16 Oct 2005 18:44:34 +0100 Lines: 34 References: <434F9D02.3050106@algroup.co.uk> <86F457810B84849160970E1C@[192.168.100.25]> <434FA091.2060704@algroup.co.uk> <554469BA87B1B496F4AEFC72@[192.168.100.25]> <20051014122833.GA19423@outpost.ds9a.nl> <20051014150238.GA19821@outpost.ds9a.nl> <6B3DEDF4-E9F1-4F26-9B95-CC89EC016500@verisignlabs.com> <20051016100120.GB5187@outpost.ds9a.nl> <43527A8F.5090204@algroup.co.uk> <20051016172639.GA12559@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: David Blacka , DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Sun Oct 16 19:50:29 2005 Return-path: User-Agent: Thunderbird 1.4.1 (Windows/20051006) To: bert hubert In-Reply-To: <20051016172639.GA12559@outpost.ds9a.nl> X-Enigmail-Version: 0.93.0.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk bert hubert wrote: > On Sun, Oct 16, 2005 at 05:06:39PM +0100, Ben Laurie wrote: >> bert hubert wrote: >>> For NSEC3 things are trickier as we need to first figure out a record in >>> front of the one queried for, and then one after. Then we need to hash both, >>> and see if there is an NSEC3 record that matches that. >> No you don't. You hash the name queried for and find the record that >> straddles the hash. > > Ahhh - so an NSEC3 says 'there is no record between these two hashes', There's no record whose hash falls between these two hashes. > and > not 'there is no record between the origin of these hashes'? Otherwise your > quote above implies: > > A < B => hash(A) < hash(B) > > Which is not true generally. Indeed. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Paul Vixie Subject: Re: DNSSEC explanation, comments? Date: Sun, 16 Oct 2005 17:48:00 +0000 Lines: 17 References: <434F9D02.3050106@algroup.co.uk> <86F457810B84849160970E1C@[192.168.100.25]> <434FA091.2060704@algroup.co.uk> <554469BA87B1B496F4AEFC72@[192.168.100.25]> <20051014122833.GA19423@outpost.ds9a.nl> <20051014150238.GA19821@outpost.ds9a.nl> <6B3DEDF4-E9F1-4F26-9B95-CC89EC016500@verisignlabs.com> <20051016100120.GB5187@outpost.ds9a.nl> <20051016165856.BE3AE11425@sa.vix.com> <20051016173848.GB12559@outpost.ds9a.nl> Cc: DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Sun Oct 16 19:52:29 2005 Return-path: To: bert hubert In-Reply-To: Your message of "Sun, 16 Oct 2005 19:38:49 +0200." <20051016173848.GB12559@outpost.ds9a.nl> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # > Um... why? # # A cached NXDOMAIN is going to be a lot larger as it needs to store an nsec # and an rrssig. An open question is how many nsec's and rrsig's are going to # be shared among non-existence answers. I note a lot of queries resulting in # NXDOMAINS to recursors. for whitelies zones, it's a lot of metadata. for actual signed zones, it's not very much at all. and in any case, if the limit is cache size rather than aggregate ttl, then you'd just end up caching less, and i don't think that will generally hurt reuse very much. 64-bits isn't the emergency you said. -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Thierry Moreau Subject: Two drafts for Automated Trust Anchor Key Rollover Date: Mon, 17 Oct 2005 20:05:57 -0400 Lines: 66 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Tue Oct 18 01:43:40 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dear all: I submitted two drafts for automated trust anchor key rollover: (1) draft-moreau-dnsext-sdda-rr-00.txt (http://www.ietf.org/internet-drafts/draft-moreau-dnsext-sdda-rr-00.txt) The SEP DNSKEY Direct Authenticator DNS Resource Record (SDDA-RR) Abstract This document specifies a generic DNS resource record format for "direct authentication" of DSNKEY records with the SEP bit (Secure Entry Point) set to "1". Although a generic record format is specified with type fields allowing standardized or proprietary extensions, the only use of SDDA RR in DNSSEC operations is the support of trust anchor key management operations. Schemes using the SDDA-RR format are to be specified in other documents. (2) draft-moreau-dnsext-takrem-dns-00.txt (http://www.ietf.org/internet-drafts/draft-moreau-dnsext-takrem-dns-00.txt) The Trust Anchor Key Renewal Method Applied to DNS Security (TAKREM-DNSSEC) Abstract This document provides additional security protocol elements to the DNS Security Extensions (DNSSEC, [RFC4033], [RFC4034], [RFC4035]), in the area of DNSSEC key management support functions. It specifies an automated key rollover mechanism for trust anchor keys. This mechanism has implications on the trust anchor key generation procedures, because it is an integrated scheme that supports the security of trust anchor signature key pairs used in consecutive cryptoperiods. I offered to make a presentation at IETF-64 in Vancouver on this subject area. IPR disclosure will be posted for draft-moreau-dnsext-takrem-dns-00.txt per RFC3668, hopefully by this coming Thursday (no IPR disclosure required for draft-moreau-dnsext-sdda-rr-00.txt). Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: DNSEXT WGLC: RFC2536bis and RFC2539bis Date: Tue, 18 Oct 2005 00:48:54 -0400 Lines: 26 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Tue Oct 18 06:57:34 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 To: namedroppers@ops.ietf.org X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message starts a 2 week Working Group Last call ending on November 1, for the two following documents: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-06.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-06.txt These two documents replace older RFC's to reflect the fact DSA and Diffie-Hellman keying information is encoded the same way in KEY and DNSKEY RR's (and other DNS RR types). The documents contain few minor textual changes from the RFC's they are replacing, including references to the DNSSEC-bis documents. These documents are on standards track and will be recycled at proposed standard, to be at the same level as DNSSEC-bis. The default action is to advance these documents, if you find any issues with the documents please raise them now. Olafur & Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Brett Carr Subject: Re: DNSSEC explanation, comments? Date: Tue, 18 Oct 2005 22:27:25 +0200 (CEST) Lines: 35 References: <20051001125513.GA6409@outpost.ds9a.nl> <20051013213233.GC27170@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Samuel Weiler , namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Oct 18 22:41:24 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-Authentication-Warning: cow.ripe.net: brettcarr owned process doing -bs To: bert hubert In-Reply-To: <20051013213233.GC27170@outpost.ds9a.nl> X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.004077 / -5.9 X-RIPE-Signature: 77fc34a2adbd6547a9f3382b28700438 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 13 Oct 2005, bert hubert wrote: > On Thu, Oct 13, 2005 at 04:02:30PM -0400, Samuel Weiler wrote: > > a.z.w.example: the second time is the RRSIG inception time, not the > > signing time. The label count is correct (see the sample zone in > > 4035). > > Thanks, will investigate & rectify, same goes for your other suggestions. > Much appreciated. I am happy that most (or all) suggestions so far have not > been for fundamental problems - though they are important. > > > You might want to point readers to the working examples of .se and > > ripe.net, as signed zones running in the wild. > > I've queried for real .se delegations but short of asking here or bothering > the .se administrators nobody could point me to a real DS record 'in the > wild'. But I'm very interested. We should have some DS records in the in-addr.arpa tree in the next few weeks, If you still want to see some then feel free to e-mail me back again the middle of next month and I'll point you in the right direction. Brett -- Brett Carr Ripe Network Coordination Centre System Engineer -- Operations Group Singel 258 Amsterdam NL http://www.ripe.net +31 627 546046 GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8 -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Eastlake III Donald-LDE008 Subject: RE: About draft-ietf-dnsext-ecc-key-07.txt, absence of algorithm restriction in ECC public key encoding Date: Wed, 19 Oct 2005 20:28:26 -0400 Lines: 42 Mime-Version: 1.0 Content-Type: text/plain Cc: rschroe@sandia.gov X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 02:38:17 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Thierry Moreau , namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Actually, if you look in section 5 on page 11, it says you have to use SHA-1... Donald -----Original Message----- From: Thierry Moreau [mailto:thierry.moreau@connotech.com] Sent: Monday, August 15, 2005 9:15 AM To: namedroppers@ops.ietf.org Cc: rschroe@sandia.gov; Eastlake III Donald-LDE008 Subject: About draft-ietf-dnsext-ecc-key-07.txt, absence of algorithm restriction in ECC public key encoding Dear all: A quick question/comment about the draft draft-ietf-dnsext-ecc-key-07.txt, "Elliptic Curve KEYs in the DNS". In this draft document, I didn't see any indication of public key algorithm to be used with a given public key (e.g. the same RSA public key value can be used with SHA-1 or MD5 for signatures, and a different DNSKEY RR encoding prevents an RSA-SHA-1 key to be diverted to RSA-MD5). This is somehow different from key usage, i.e. whether DNS zone signing allowed. For instance of algorithm restriction with ECC public keys, see the draft-ietf-pkix-ecc-pkalgs-01.txt Am I correct in reading the draft draft-ietf-dnsext-ecc-key-07.txt as omitting algorithm restrictions? If yes, I see a difficulty with algorithm change threat once the ECC crypto is applied to DNS. Thus, I would expect the ECC public key format to be reworked before applied to DNS. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Harald Tveit Alvestrand Subject: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Thu, 20 Oct 2005 12:55:36 +0200 Lines: 58 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 13:05:29 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: namedroppers@ops.ietf.org X-Mailer: Mulberry/3.1.6 (Linux/x86) Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, I couldn't find any discussion of this draft on the mailing list, but the draft says that it should be discussed here, so here it goes... WG chairs, please rule me out of order if it isn't appropriate (and ask the author to update the draft...) draft-eastlake-2606bis-00, "Reserved Top Level DNS Names", tries to update the old RFC that reserved ".test", ".example", ".invalid" and ".localhost". RFC 2606 is a BCP, so presumably this document aims for the same status. Summary: This is definitely not a document that I think the IETF should publish as-is. My detailed comments: 1) I believe section 3.1 and 3.4 (reservation of "aso", "gnso", "afrinic", "rfc-editor" and so on) is inappropriate for the IETF and should be removed. This is ICANN's business. Optionally, I could argue that it should be reduced to "example", so that we could use "example.fr" as well as "example.com" in examples. I am less sure about section 3.3 (prohibition of single character and two letter names). There may be technical justification for these (see the RFC describing the "com.com" problem, and how to fix it - the number escapes me) - but I know for a fact that multiple registries do hand out two-letter domain names today, and are likely to continue to do so no matter what the IETF says - so this needs *heavy* justification - my default proposal would be "remove". 2) A different conversation led to the (to me) surprising conclusion that there is no IETF document that conclusively states that top level domains shouldn't be all numeric. I think this is an appropriate thing for the IETF to state in a BCP, since 4-component all-numeric domain names are hard to tell from IP addresses - a technical consideration in many protocols. This could be added as a subsection of section 2 - since it's a new reason for reserving TLDs. 3) The nature of the reservation of tagged domain names (xn--) in section 3.3 needs to be explained - the sentence is even grammatically incomplete. I *think* it's intended to reserve these labels at all levels until a normative interpretation is given in an IETF standard. But the para does not say. I believe there might be an IANA registry of those tags somewhere? If so, this should be mentioned. Harald -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Mark Andrews Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Thu, 20 Oct 2005 21:17:34 +1000 Lines: 78 References: Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 13:24:16 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Harald Tveit Alvestrand In-reply-to: Your message of "Thu, 20 Oct 2005 12:55:36 +0200." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Hi, > > I couldn't find any discussion of this draft on the mailing list, but the > draft says that it should be discussed here, so here it goes... WG chairs, > please rule me out of order if it isn't appropriate (and ask the author to > update the draft...) > > draft-eastlake-2606bis-00, "Reserved Top Level DNS Names", tries to update > the old RFC that reserved ".test", ".example", ".invalid" and ".localhost". > > RFC 2606 is a BCP, so presumably this document aims for the same status. > > Summary: This is definitely not a document that I think the IETF should > publish as-is. > > My detailed comments: > > 1) I believe section 3.1 and 3.4 (reservation of "aso", "gnso", "afrinic", > "rfc-editor" and so on) is inappropriate for the IETF and should be > removed. This is ICANN's business. > > Optionally, I could argue that it should be reduced to "example", so that > we could use "example.fr" as well as "example.com" in examples. > > I am less sure about section 3.3 (prohibition of single character and two > letter names). There may be technical justification for these (see the RFC > describing the "com.com" problem, and how to fix it - the number escapes > me) - but I know for a fact that multiple registries do hand out two-letter > domain names today, and are likely to continue to do so no matter what the > IETF says - so this needs *heavy* justification - my default proposal would > be "remove". > > 2) A different conversation led to the (to me) surprising conclusion that > there is no IETF document that conclusively states that top level domains > shouldn't be all numeric. I think this is an appropriate thing for the IETF > to state in a BCP, since 4-component all-numeric domain names are hard to > tell from IP addresses - a technical consideration in many protocols. RFC 1123 comes close. If a dotted-decimal number can be entered without such identifying delimiters, then a full syntactic check must be made, because a segment of a host domain name is now allowed to begin with a digit and could legally be entirely numeric (see Section 6.1.2.4). However, a valid host name can never have the dotted-decimal form #.#.#.#, since at least the highest-level component label will be alphabetic. > This could be added as a subsection of section 2 - since it's a new reason > for reserving TLDs. > > 3) The nature of the reservation of tagged domain names (xn--) in section > 3.3 needs to be explained - the sentence is even grammatically incomplete. > > I *think* it's intended to reserve these labels at all levels until a > normative interpretation is given in an IETF standard. But the para does > not say. > > I believe there might be an IANA registry of those tags somewhere? > If so, this should be mentioned. > > Harald > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Harald Tveit Alvestrand Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Thu, 20 Oct 2005 13:37:41 +0200 Lines: 39 References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 13:44:18 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 To: Mark Andrews In-Reply-To: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> X-Mailer: Mulberry/3.1.6 (Linux/x86) Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On torsdag, oktober 20, 2005 21:17:34 +1000 Mark Andrews wrote: >> 2) A different conversation led to the (to me) surprising conclusion >> that there is no IETF document that conclusively states that top level >> domains shouldn't be all numeric. I think this is an appropriate thing >> for the IETF to state in a BCP, since 4-component all-numeric domain >> names are hard to tell from IP addresses - a technical consideration in >> many protocols. > > RFC 1123 comes close. > > If a dotted-decimal number can be entered without such > identifying delimiters, then a full syntactic check must be > made, because a segment of a host domain name is now allowed > to begin with a digit and could legally be entirely numeric > (see Section 6.1.2.4). However, a valid host name can never > have the dotted-decimal form #.#.#.#, since at least the > highest-level component label will be alphabetic. Yep - but I'm betting that this will be ruled non-normative eventually, because some people want IDNs in TLDs, and Punycode uses numbers in its encoding. It's a long leap from "must be alphabetic" to "can be all-numeric" - but I'd prefer to have something explicit somewhere, so that we don't end up there by accident. I *think* it's uncontroversial. But better safe than sorry. -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Edward Lewis Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Thu, 20 Oct 2005 08:16:39 -0400 Lines: 61 References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Mark Andrews , namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 14:23:56 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 In-Reply-To: <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> To: Harald Tveit Alvestrand X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 13:37 +0200 10/20/05, Harald Tveit Alvestrand wrote: >--On torsdag, oktober 20, 2005 21:17:34 +1000 Mark Andrews > wrote: > >>> 2) A different conversation led to the (to me) surprising conclusion >>> that there is no IETF document that conclusively states that top level >>> domains shouldn't be all numeric. I think this is an appropriate thing >>> for the IETF to state in a BCP, since 4-component all-numeric domain >>> names are hard to tell from IP addresses - a technical consideration in >>> many protocols. >> >> RFC 1123 comes close. >> >> If a dotted-decimal number can be entered without such >> identifying delimiters, then a full syntactic check must be >> made, because a segment of a host domain name is now allowed >> to begin with a digit and could legally be entirely numeric >> (see Section 6.1.2.4). However, a valid host name can never >> have the dotted-decimal form #.#.#.#, since at least the >> highest-level component label will be alphabetic. > >Yep - but I'm betting that this will be ruled non-normative eventually, >because some people want IDNs in TLDs, and Punycode uses numbers in its >encoding. >It's a long leap from "must be alphabetic" to "can be all-numeric" - but I'd >prefer to have something explicit somewhere, so that we don't end up there by >accident. > >I *think* it's uncontroversial. But better safe than sorry. As many of us have said before, 1123 refers to host names, not domain names. (Host names are a subset of domain names.) In an NS and MX record, you want a host name, not necessarily so in a RRSIG record. I disagree with the suggestion to bar all-numeric names. Mostly because I don't like "rules" that are unnecessary. I don't see the necessity of such a restriction. I am not arguing against what 1123 says. From what I understand, if a domain name represents a host, then a numeric label can cause confusion for an application like telnet (to pick on an old, tired horse). There is a necessity for that, even if there is a "newer version [of the application] out there." But in general, I don't see the harm of an all numeric label, even a TLD. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar True story: Only a routing "expert" would fly London->Minneapolis->Dallas->Minneapolis to get home from a conference. (Cities changed to protect his identity.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Tony Finch Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Thu, 20 Oct 2005 14:10:33 +0100 Lines: 33 References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 15:21:00 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Edward Lewis In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 20 Oct 2005, Edward Lewis wrote: > > I disagree with the suggestion to bar all-numeric names. Mostly because I > don't like "rules" that are unnecessary. I don't see the necessity of such a > restriction. > > I am not arguing against what 1123 says. From what I understand, if a domain > name represents a host, then a numeric label can cause confusion for an > application like telnet (to pick on an old, tired horse). There is a > necessity for that, even if there is a "newer version [of the application] out > there." > > But in general, I don't see the harm of an all numeric label, even a TLD. All-numeric labels are fine, so long as they aren't TLDs. There is a vast amount of code out there that assumes that a string containing only dots and digits is an IP address. If you allow TLDs to be all-numeric then these applications will have to be changed so that they consult the DNS before treating it as an IP address, which will increase the number of pointless queries going to the root name servers. Tony. -- f.a.n.finch http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Harald Tveit Alvestrand Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Thu, 20 Oct 2005 15:16:21 +0200 Lines: 62 References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Andrews , namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 15:21:00 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,BIZ_TLD, NORMAL_HTTP_TO_IP autolearn=no version=3.1.0 To: Edward Lewis In-Reply-To: X-Mailer: Mulberry/3.1.6 (Linux/x86) Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ed, I must be feeling rather uncharitable today. --On torsdag, oktober 20, 2005 08:16:39 -0400 Edward Lewis wrote: >> It's a long leap from "must be alphabetic" to "can be all-numeric" - but >> I'd prefer to have something explicit somewhere, so that we don't end up >> there by accident. >> >> I *think* it's uncontroversial. But better safe than sorry. > > As many of us have said before, 1123 refers to host names, not domain > names. (Host names are a subset of domain names.) In an NS and MX > record, you want a host name, not necessarily so in a RRSIG record. > > I disagree with the suggestion to bar all-numeric names. Mostly because > I don't like "rules" that are unnecessary. I don't see the necessity of > such a restriction. My opinion: The distinction between "hostnames" and "domain names" makes sense in many places, but this is NOT one of them. Hiding behind that distinction is a way to duck the problem that I won't accept; it may be that dnsext is the wrong WG to do it, because dnsext has (mostly successfully) stayed out of the "meaning" issues, but I think it's an IETF problem, and the IETF should solve it. We (the IETF, which has protocols ranging from layers 2 to 7) have defined protocols which break in the presence of all-numeric hostnames; if you can put the following record into the DNS: 129.241.1.99. A 158.38.152.233 two reasonable interpretations of the HTTP spec can end up querying two different webservers for the URL http://129.241.1.99/proof-of-concept.html just to give one example. That is, in my book, a problem, and should be fixed. If there is a rule about numeric TLDs not being allowed, this problem is fixed once, and for all protocols with this problem. If not, each and every protocol needs updating with its own "tie-breaker rule" - that's stupid. It's possible to write that rule in many different forms. But I think it's the IETF's job to pick one. Harald -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Edward Lewis Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Thu, 20 Oct 2005 09:30:38 -0400 Lines: 55 References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis , Mark Andrews , namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 15:38:28 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, NORMAL_HTTP_TO_IP autolearn=ham version=3.1.0 In-Reply-To: <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> To: Harald Tveit Alvestrand X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:16 +0200 10/20/05, Harald Tveit Alvestrand wrote: >I must be feeling rather uncharitable today. ;) >We (the IETF, which has protocols ranging from layers 2 to 7) have defined >protocols which break in the presence of all-numeric hostnames; if you can put >the following record into the DNS: Maybe we are entering a rat hole - I also agree that all-numeric host names are a problem. It's that generalizing a ban on all-numeric domain names isn't justified to me. > 129.241.1.99. A 158.38.152.233 > >two reasonable interpretations of the HTTP spec can end up querying >two different webservers for the URL > > http://129.241.1.99/proof-of-concept.html > >just to give one example. That's a valid example. in that case the 129.241.1.99 is occupying a place where a host name is expected. This is a case where a hard failure (name error, NXDOMAIN) is desirable. >If there is a rule about numeric TLDs not being allowed, this problem is fixed >once, and for all protocols with this problem. That's akin to an amputation to mend a hangnail. Okay, something more serious that a hangnail because of the hit root servers would take (as Mr. Finch pointed out). Thinking about this for a moment - this is a problem fixed in IPv6, huh? IPv6 text conventions use a different separator than DNS. That makes two reasons to switch to IPv6. ;) Maybe we(=$some_appropriate_group) can just reserve the labels 0 through 255 in the root zone. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar True story: Only a routing "expert" would fly London->Minneapolis->Dallas->Minneapolis to get home from a conference. (Cities changed to protect his identity.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Harald Tveit Alvestrand Subject: All-numeric (Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications) Date: Thu, 20 Oct 2005 15:45:05 +0200 Lines: 41 References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Andrews , namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 15:55:54 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,BIZ_TLD, NORMAL_HTTP_TO_IP,NUMERIC_HTTP_ADDR autolearn=no version=3.1.0 To: Edward Lewis In-Reply-To: X-Mailer: Mulberry/3.1.6 (Linux/x86) Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On torsdag, oktober 20, 2005 09:30:38 -0400 Edward Lewis wrote: >> 129.241.1.99. A 158.38.152.233 >> >> two reasonable interpretations of the HTTP spec can end up querying >> two different webservers for the URL >> >> http://129.241.1.99/proof-of-concept.html >> >> just to give one example. > > That's a valid example. in that case the 129.241.1.99 is occupying a > place where a host name is expected. This is a case where a hard failure > (name error, NXDOMAIN) is desirable. Sorry, I didn't understand that. NXDOMAIN for what, and why? in fact what's needed for the IPv4 case is a ban on 1-4-component, all-numeric domain names where all the numbers are within certain ranges (yes, http://12345678/ is a perfectly valid URL, and resolves to a specific IP address - and spammers have proved that it works!) The nice thing about requiring no all-numeric at the root is that there's only one operator (no new code, no user education) that needs to agree to make it effective - and it breaks exactly zero existing applications to make it so. Any other way to achieve the same result seems far more complex to me. Occam's razor.... -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Edward Lewis Subject: Re: All-numeric (Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications) Date: Thu, 20 Oct 2005 10:02:01 -0400 Lines: 57 References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> <3C193BD5D16ADA0D52ABFE51@svartdal.hjemme.alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis , Mark Andrews , namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 16:12:07 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 In-Reply-To: <3C193BD5D16ADA0D52ABFE51@svartdal.hjemme.alvestrand.no> To: Harald Tveit Alvestrand X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:45 +0200 10/20/05, Harald Tveit Alvestrand wrote: >> That's a valid example. in that case the 129.241.1.99 is occupying a >> place where a host name is expected. This is a case where a hard failure >> (name error, NXDOMAIN) is desirable. > >Sorry, I didn't understand that. NXDOMAIN for what, and why? If a resolver queried for "QNAME=129.241.1.99, QTYPE=A, QCLASS=IN" and there wasn't already a negative entry for this, the root would look to see if "99." was an existing label. In short, "99." does not exist, so a name error (represented by the letters NXDOMAIN in RFCs since at least 2136, longer in code in BIND) is indicated in the response code field of the DNS reply message. (This is from the algorithm described in RFC 1034, section 4.3.2.) >in fact what's needed for the IPv4 case is a ban on 1-4-component, all-numeric >domain names where all the numbers are within certain ranges (yes, http:// >12345678/ is a perfectly valid URL, and resolves to a specific IP >address - and >spammers have proved that it works!) It sounds to me that in hindsight, we should have done better. But that's water under the bridge. The tradeoff here is (protocol) engineering vs. operations. You can build a system to avoid a problem or to recover from one. Or you can operate a system to avoid problems. That's where this debate will fall into. What we are asking to do is set up some more operations maintained bumper guards. >The nice thing about requiring no all-numeric at the root is that there's only >one operator (no new code, no user education) that needs to agree to make it >effective - and it breaks exactly zero existing applications to make >it so. Any >other way to achieve the same result seems far more complex to me. > >Occam's razor.... By the same logic, the root and .arpa should have been signed with DNSSEC long ago. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar True story: Only a routing "expert" would fly London->Minneapolis->Dallas->Minneapolis to get home from a conference. (Cities changed to protect his identity.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Jim Reid Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Thu, 20 Oct 2005 15:00:16 +0100 Lines: 21 References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Cc: Harald Tveit Alvestrand , Mark Andrews , namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 16:13:15 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 In-Reply-To: To: Edward Lewis X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Oct 20, 2005, at 14:30, Edward Lewis wrote: >> 129.241.1.99. A 158.38.152.233 >> >> two reasonable interpretations of the HTTP spec can end up >> querying two different webservers for the URL > That's a valid example. in that case the 129.241.1.99 is occupying > a place where a host name is expected. Is it? Is the glass half-empty or half-full? It could be argued that the example above is a domain name that happens to have an A record. I don't recall any rule that says only owner-names that happen to be valid hostnames are allowed to have A records. RFC2181 implies 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 Fri Dec 29 11:36:43 2006 From: Mark Andrews Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Fri, 21 Oct 2005 00:01:42 +1000 Lines: 66 References: Cc: Harald Tveit Alvestrand , namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 16:13:43 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, NORMAL_HTTP_TO_IP autolearn=ham version=3.1.0 To: Edward Lewis In-reply-to: Your message of "Thu, 20 Oct 2005 09:30:38 -0400." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 15:16 +0200 10/20/05, Harald Tveit Alvestrand wrote: > > >I must be feeling rather uncharitable today. > > ;) > > >We (the IETF, which has protocols ranging from layers 2 to 7) have defined > >protocols which break in the presence of all-numeric hostnames; if you can p > ut > >the following record into the DNS: > > Maybe we are entering a rat hole - I also agree that all-numeric host > names are a problem. It's that generalizing a ban on all-numeric > domain names isn't justified to me. > > > 129.241.1.99. A 158.38.152.233 > > > >two reasonable interpretations of the HTTP spec can end up querying > >two different webservers for the URL > > > > http://129.241.1.99/proof-of-concept.html > > > >just to give one example. > > That's a valid example. in that case the 129.241.1.99 is occupying a > place where a host name is expected. This is a case where a hard > failure (name error, NXDOMAIN) is desirable. > > >If there is a rule about numeric TLDs not being allowed, this problem is fix > ed > >once, and for all protocols with this problem. > > That's akin to an amputation to mend a hangnail. Okay, something > more serious that a hangnail because of the hit root servers would > take (as Mr. Finch pointed out). > > Thinking about this for a moment - this is a problem fixed in IPv6, > huh? IPv6 text conventions use a different separator than DNS. That > makes two reasons to switch to IPv6. ;) > > Maybe we(=$some_appropriate_group) can just reserve the labels 0 > through 255 in the root zone. You have to remove all values upto 2^32-1. 1.16777215 is equivalent to 1.255.255.255 > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > True story: > Only a routing "expert" would fly London->Minneapolis->Dallas->Minneapolis > to get home from a conference. (Cities changed to protect his identity.) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Paul Vixie Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Thu, 20 Oct 2005 14:13:07 +0000 Lines: 71 References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 16:24:14 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, NORMAL_HTTP_TO_IP autolearn=ham version=3.1.0 To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Thu, 20 Oct 2005 15:16:21 +0200." <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # I must be feeling rather uncharitable today. welcome. # ... # We (the IETF, which has protocols ranging from layers 2 to 7) have defined # protocols which break in the presence of all-numeric hostnames; if you can # put the following record into the DNS: # # 129.241.1.99. A 158.38.152.233 # # two reasonable interpretations of the HTTP spec can end up querying two # different webservers for the URL # # http://129.241.1.99/proof-of-concept.html # # just to give one example. # # That is, in my book, a problem, and should be fixed. it's a problem, yes. maybe it should be fixed. maybe the fix is in dns rather than in http. maybe it just needs to be documented and recommended against? # If there is a rule about numeric TLDs not being allowed, this problem is # fixed once, and for all protocols with this problem. if only that were true. consider RFC 1535. this isn't just a TLD problem unless you think browsers won't use domain-suffix search lists or you think users will put a "." at the end of the dotted-quad-thing. # If not, each and every protocol needs updating with its own "tie-breaker # rule" - that's stupid. # # It's possible to write that rule in many different forms. # But I think it's the IETF's job to pick one. when did the ietf community start ruling by law rather than leading by recommendations? can't we just say "any application or library which does DNS lookups to translate presentation-layer endpoint identifiers into network-layer endpoint identifiers should take care to avoid doing DNS lookups for presentation-layer content which is syntactically valid as an IPv4 or IPv6 host name"? we can leave open the possibility that the conversion will be done using string arithmetic or not, but what we really care about is that a DNS lookup not be made for such names. we do NOT have to say that the lookup is undefined or invalid, since that would mean defining which domain names are "hostnames", which i'd regard as an overspecification. we just have to recommend that the queries not be made. that would also help reduce the unwanted traffic on the root name servers, assuming that a lot of end systems were upgraded to follow this recommendation. note that bind's gethostbyname() has had this logic for some years now: /* * All-numeric, no dot at the end. * Fake up a hostent as if we'd actually * done a lookup. */ if (!inet_aton(name, &host_addr)) { ... (that's from bind4's gethnamaddr.c file, similar stuff is in bind8/bind9.) -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Harald Tveit Alvestrand Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Thu, 20 Oct 2005 17:04:31 +0200 Lines: 55 References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> <20051020141307.99E4A11426@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 17:12:43 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Paul Vixie , namedroppers@ops.ietf.org In-Reply-To: <20051020141307.99E4A11426@sa.vix.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On torsdag, oktober 20, 2005 14:13:07 +0000 Paul Vixie wrote: ># If not, each and every protocol needs updating with its own "tie-breaker ># rule" - that's stupid. ># ># It's possible to write that rule in many different forms. ># But I think it's the IETF's job to pick one. > > when did the ietf community start ruling by law rather than leading by > recommendations? can't we just say "any application or library which > does DNS lookups to translate presentation-layer endpoint identifiers > into network-layer endpoint identifiers should take care to avoid doing > DNS lookups for presentation-layer content which is syntactically valid > as an IPv4 or IPv6 host name"? Except that we've now created a class of names that are OK to register, and OK to populate in the DNS, but some applications will never be able to look up.... that's kind of bizarre. I think the "don't register numeric TLDs" is a recommendation too, in the sense that everything the IETF produces for external consumption is. And a simpler one. > note that bind's gethostbyname() has had this logic for some years now: > > /* > * All-numeric, no dot at the end. > * Fake up a hostent as if we'd actually > * done a lookup. > */ > if (!inet_aton(name, &host_addr)) { > ... > > (that's from bind4's gethnamaddr.c file, similar stuff is in bind8/bind9.) entirely tangential, but illustrates something, I think.... this line of code is mostly responsible for the widely held but erroneous belief that hta@129.241.1.99 is a valid email address. hta@[129.241.1.99] is a valid email address. hta@129.241.1.99 isn't. Some mailers get it right, some don't. Harald -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Stephane Bortzmeyer Subject: Reservations of labels at all levels considered VERY BAD (Was: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Thu, 20 Oct 2005 17:14:44 +0200 Organization: NIC France Lines: 21 References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 17:25:38 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 To: Harald Tveit Alvestrand Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Oct 20, 2005 at 12:55:36PM +0200, Harald Tveit Alvestrand wrote a message of 57 lines which said: > 1) I believe section 3.1 and 3.4 (reservation of "aso", "gnso", > "afrinic", "rfc-editor" and so on) is inappropriate for the IETF and > should be removed. This is ICANN's business. Correct, it is inappropriate (thanks for finding this word, I was thinking of something much more violent). But it is not ICANN's business' either. The rules under ".fr" (or any other ccTLD) are not to be defined by IETF or ICANN, period (unless of course they are syntactical ruls or rules *necessary* for good interoperability, but business rules like those of the draft are a no-no). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Harald Tveit Alvestrand Subject: Re: Reservations of labels at all levels considered VERY BAD (Was: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Thu, 20 Oct 2005 17:22:50 +0200 Lines: 34 References: <20051020151444.GA28736@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 17:31:13 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Stephane Bortzmeyer In-Reply-To: <20051020151444.GA28736@nic.fr> X-Mailer: Mulberry/3.1.6 (Linux/x86) Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On torsdag, oktober 20, 2005 17:14:44 +0200 Stephane Bortzmeyer wrote: > On Thu, Oct 20, 2005 at 12:55:36PM +0200, > Harald Tveit Alvestrand wrote > a message of 57 lines which said: > >> 1) I believe section 3.1 and 3.4 (reservation of "aso", "gnso", >> "afrinic", "rfc-editor" and so on) is inappropriate for the IETF and >> should be removed. This is ICANN's business. > > Correct, it is inappropriate (thanks for finding this word, I was > thinking of something much more violent). But it is not ICANN's > business' either. The rules under ".fr" (or any other ccTLD) are not > to be defined by IETF or ICANN, period (unless of course they are > syntactical ruls or rules *necessary* for good interoperability, but > business rules like those of the draft are a no-no). I happen to agree with you in the case of ccTLDs :-) - but that fight too is ICANN's business to fight. We (speaking as an IETF participant) shouldn't get involved - either in saying "yes" or in saying "no" to such restrictions. Harald -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Paul Vixie Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Thu, 20 Oct 2005 16:12:01 +0000 Lines: 46 References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> <20051020141307.99E4A11426@sa.vix.com> <209FCC95A2DF6AF7E4B6CF5F@svartdal.hjemme.alvestrand.no> X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 18:18:41 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Thu, 20 Oct 2005 17:04:31 +0200." <209FCC95A2DF6AF7E4B6CF5F@svartdal.hjemme.alvestrand.no> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # > when did the ietf community start ruling by law rather than leading by # > recommendations? can't we just say "any application or library which # > does DNS lookups to translate presentation-layer endpoint identifiers # > into network-layer endpoint identifiers should take care to avoid doing # > DNS lookups for presentation-layer content which is syntactically valid # > as an IPv4 or IPv6 host name"? # # Except that we've now created a class of names that are OK to register, and # OK to populate in the DNS, but some applications will never be able to look # up.... that's kind of bizarre. then make a recommendation that IANA not allocate such names as toplevels? (what people choose to do further down the tree is not up to us to decide.) # I think the "don't register numeric TLDs" is a recommendation too, in the # sense that everything the IETF produces for external consumption is. And a # simpler one. right. # > (that's from bind4's gethnamaddr.c file, similar stuff is in bind8/bind9.) # # entirely tangential, but illustrates something, I think.... # # this line of code is mostly responsible for the widely held but erroneous # belief that hta@129.241.1.99 is a valid email address. worse than that: it's valid for some people some of the time. the logic in gethostbyname() was put there because applications could not be depended upon to say "if it's a valid address, use it, else look it up as a hostname" and so gethostbyname() became a dual-purpose function. probably it would've been better to return an error on the basis of non-RFC952-compliance. (who knew?) # hta@[129.241.1.99] is a valid email address. hta@129.241.1.99 isn't. # Some mailers get it right, some don't. really? i know that mailnames used to have to start with non-numeric, but 3com.com asked for a change and got it. do the current (2821/2822) railroad diagrams really say that 129.241.1.99 is not a valid mailname? -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Harald Tveit Alvestrand Subject: 2821 and friends (Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications) Date: Thu, 20 Oct 2005 18:39:17 +0200 Lines: 46 References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> <20051020141307.99E4A11426@sa.vix.com> <209FCC95A2DF6AF7E4B6CF5F@svartdal.hjemme.alvestrand.no> <20051020161201.9A6E411425@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 18:48:00 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Paul Vixie , namedroppers@ops.ietf.org In-Reply-To: <20051020161201.9A6E411425@sa.vix.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Changing the subject on this particular tangent.... --On torsdag, oktober 20, 2005 16:12:01 +0000 Paul Vixie wrote: ># hta@[129.241.1.99] is a valid email address. hta@129.241.1.99 isn't. ># Some mailers get it right, some don't. > > really? i know that mailnames used to have to start with non-numeric, but > 3com.com asked for a change and got it. do the current (2821/2822) > railroad diagrams really say that 129.241.1.99 is not a valid mailname? RFC 2821: 3.6 Domains Only resolvable, fully-qualified, domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or A RRs. Local nicknames or unqualified names MUST NOT be used. ............. 4.1.2 Command Argument Syntax Domain = (sub-domain 1*("." sub-domain)) / address-literal sub-domain = Let-dig [Ldh-str] address-literal = "[" IPv4-address-literal / IPv6-address-literal / General-address-literal "]" ; See section 4.1.3 Mailbox = Local-part "@" Domain Here's where the "hostname" charset restriction occurs too - but no text there about TLDs. -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Harald Tveit Alvestrand Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Thu, 20 Oct 2005 18:40:01 +0200 Lines: 29 References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> <20051020141307.99E4A11426@sa.vix.com> <209FCC95A2DF6AF7E4B6CF5F@svartdal.hjemme.alvestrand.no> <20051020161201.9A6E411425@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 18:49:03 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Paul Vixie , namedroppers@ops.ietf.org In-Reply-To: <20051020161201.9A6E411425@sa.vix.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On torsdag, oktober 20, 2005 16:12:01 +0000 Paul Vixie wrote: ># > when did the ietf community start ruling by law rather than leading by ># > recommendations? can't we just say "any application or library which ># > does DNS lookups to translate presentation-layer endpoint identifiers ># > into network-layer endpoint identifiers should take care to avoid doing ># > DNS lookups for presentation-layer content which is syntactically valid ># > as an IPv4 or IPv6 host name"? ># ># Except that we've now created a class of names that are OK to register, ># and OK to populate in the DNS, but some applications will never be able ># to look up.... that's kind of bizarre. > > then make a recommendation that IANA not allocate such names as toplevels? > > (what people choose to do further down the tree is not up to us to > decide.) that's exactly what I'd like draft-eastlake-2606bis-00 to do.... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: "Eric A. Hall" Subject: Re: 2821 and friends (Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications) Date: Thu, 20 Oct 2005 13:13:22 -0400 Lines: 40 References: <200510201117.j9KBHYb6033105@drugs.dv.isc.org> <500955810D4CE03A82D7FC9C@svartdal.hjemme.alvestrand.no> <72E3B614EE413656376A863B@svartdal.hjemme.alvestrand.no> <20051020141307.99E4A11426@sa.vix.com> <209FCC95A2DF6AF7E4B6CF5F@svartdal.hjemme.alvestrand.no> <20051020161201.9A6E411425@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Paul Vixie , namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 20 19:20:25 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en To: Harald Tveit Alvestrand In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 10/20/2005 12:39 PM, Harald Tveit Alvestrand wrote: > Changing the subject on this particular tangent.... > > --On torsdag, oktober 20, 2005 16:12:01 +0000 Paul Vixie > wrote: > > >># hta@[129.241.1.99] is a valid email address. hta@129.241.1.99 isn't. >># Some mailers get it right, some don't. >> >>really? i know that mailnames used to have to start with non-numeric, but >>3com.com asked for a change and got it. do the current (2821/2822) >>railroad diagrams really say that 129.241.1.99 is not a valid mailname? > > > RFC 2821: It should also be pointed out that even though labels may contain numbers, the entire hostname sequence is expected to contain at least one letter. This is spelled out in the requirements prior to the relaxation in rfc1123, but its also confirmed in 1123 itself If a dotted-decimal number can be entered without such identifying delimiters, then a full syntactic check must be made, because a segment of a host domain name is now allowed to begin with a digit and could legally be entirely numeric (see Section 6.1.2.4). However, a valid host name can never have the dotted-decimal form #.#.#.#, since at least the highest-level component label will be alphabetic. -- 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 Dec 29 11:36:43 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2538bis-09.txt Date: Thu, 20 Oct 2005 18:50:02 -0400 Lines: 93 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Oct 21 01:00:41 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 To: i-d-announce@ietf.org 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 : Storing Certificates in the Domain Name System (DNS) Author(s) : S. Josefsson Filename : draft-ietf-dnsext-rfc2538bis-09.txt Pages : 17 Date : 2005-10-20 Cryptographic public keys are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). This document obsoletes RFC 2538. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-09.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-rfc2538bis-09.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-rfc2538bis-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-20181005.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2538bis-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2538bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-20181005.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 Dec 29 11:36:43 2006 From: Simon Josefsson Subject: Re: I-D ACTION:draft-ietf-dnsext-rfc2538bis-09.txt Date: Fri, 21 Oct 2005 09:25:19 +0200 Lines: 27 References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Fri Oct 21 09:37:11 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 To: namedroppers@ops.ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051021:i-d-announce@ietf.org::OnTIylVI4OhMDdmp:0n2X X-Hashcash: 1:21:051021:internet-drafts@ietf.org::WZbx9ZqMIY2FI6RY:355y X-Hashcash: 1:21:051021:namedroppers@ops.ietf.org::J4KEDIqqvrJD17Q4:8hK0 In-Reply-To: (Internet-Drafts@ietf.org's message of "Thu, 20 Oct 2005 18:50:02 -0400") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Internet-Drafts@ietf.org writes: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-09.txt Dear WG: That draft address some IESG review comments. Of those changes, only one is substantial: Russ Housley suggested adding a type value for Attribute Certificates (RFC 3281). I complied, and added the ACPKIX and IACPKIX types. Please review the above document again. You can find the differences compared to -08 in: http://josefsson.org/rfc2538bis/draft-ietf-dnsext-rfc2538bis-09-from-8.diff.html As always, more information, including links to the IESG review comments and the I-D tracker can be found at: http://josefsson.org/rfc2538bis/ Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: "Olaf M. Kolkman" Subject: Re: I-D ACTION:draft-ietf-dnsext-rfc2538bis-09.txt Date: Fri, 21 Oct 2005 09:59:52 +0200 Lines: 56 References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3--896946458" Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Oct 21 10:07:50 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 In-Reply-To: To: Simon Josefsson X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-3--896946458 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > >> http://www.ietf.org/internet-drafts/draft-ietf-dnsext- >> rfc2538bis-09.txt >> > > Dear WG: > > That draft address some IESG review comments. Just to set a deadline to this groups review of the changes. If you haven't heard anything by next Friday you may assume this group has no problems with these changes. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-3--896946458 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDWJ/4tN/ca3YJIocRAsfKAJ9YA35tP5dVO3U9QmOcLJ3RSMC9eACgl28o 4KVK38wMBmW33rnaqw37wJY= =a02l -----END PGP SIGNATURE----- --Apple-Mail-3--896946458-- -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Thierry Moreau Subject: Re: About draft-ietf-dnsext-ecc-key-07.txt, absence of algorithm restriction in ECC public key encoding Date: Fri, 21 Oct 2005 10:29:58 -0400 Lines: 42 References: <62173B970AE0A044AED8723C3BCF23810B40CC70@ma19exm01.e6.bcs.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, rschroe@sandia.gov X-From: owner-namedroppers@ops.ietf.org Fri Oct 21 16:10:28 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Eastlake III Donald-LDE008 In-Reply-To: <62173B970AE0A044AED8723C3BCF23810B40CC70@ma19exm01.e6.bcs.mot.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Eastlake III Donald-LDE008 wrote: > Actually, if you look in section 5 on page 11, it says you have to use SHA-1... > > Donald Thanks for pointing this out. Since the transition from SHA-1 to other hash algorithm is going to be a big issue some time in the future, perhaps it should be made more manifest that this draft assigns the RFC4034-allocated DNSSEC Algorithm Type value 4 to ECC **with SHA-1**. Are there other variations in ECC signature algorithms that are fixed by the draft and should be made more manifest? Someone pointed out that the draft was only "about storing keys". Does it completely specify ECC signatures? I think other DNSSEC Algorithm Type values do fully specify the respective signature algorithms. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Stephane Bortzmeyer Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Fri, 21 Oct 2005 16:15:16 +0200 Organization: NIC France Lines: 14 References: 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 Fri Oct 21 16:23:44 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Harald Tveit Alvestrand Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Oct 20, 2005 at 12:55:36PM +0200, Harald Tveit Alvestrand wrote a message of 57 lines which said: > I couldn't find any discussion of this draft on the mailing list, > but the draft says that it should be discussed here, Yes, but DNSop would be more adapted, no? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Stephane Bortzmeyer Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications Date: Fri, 21 Oct 2005 16:23:15 +0200 Organization: NIC France Lines: 29 References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Oct 21 16:32:17 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Harald Tveit Alvestrand Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Oct 20, 2005 at 12:55:36PM +0200, Harald Tveit Alvestrand wrote a message of 57 lines which said: > 1) I believe section 3.1 and 3.4 (reservation of "aso", "gnso", "afrinic", > "rfc-editor" and so on) is inappropriate for the IETF and should be > removed. 3.1 is clearly completely out-of-scope and must be removed. There is no reason that strings like "iab" or "iana" should be prohibited. 3.4 is a bit different because we no longer talk about "back office" organisations like IAB or ARIN but about operational uses. "nic" and "whois" could be seen are reasonable names to reserve to the infrastructure. I'm more hesitant about "www". While I understand that http://www.example/ could be seen as a Web site authoritative about the TLD example, I'm not sure that we should reserve "www" and not "mail", for instance. Probably, the logical conclusion will be to drop 3.4 completely, because I'm not sure we can have a consensus on the list (may be just on "nic"?) -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Eastlake III Donald-LDE008 Subject: RE: About draft-ietf-dnsext-ecc-key-07.txt, absence of algorithm restriction in ECC public key encoding Date: Fri, 21 Oct 2005 10:25:35 -0400 Lines: 45 Mime-Version: 1.0 Content-Type: text/plain Cc: namedroppers@ops.ietf.org, rschroe@sandia.gov X-From: owner-namedroppers@ops.ietf.org Fri Oct 21 16:34:59 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Thierry Moreau X-Mailer: Internet Mail Service (5.5.2657.72) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'll make the SHA-1 usage more apparent in this next version of the draft. I do not think there are any other similar functions fixed in the draft. The earliest versions of this draft covered both keys and signatures. Then signatures were removed for several versions. Now signatures have been added back in... Donald -----Original Message----- From: Thierry Moreau [mailto:thierry.moreau@connotech.com] Sent: Friday, October 21, 2005 10:30 AM To: Eastlake III Donald-LDE008 Cc: namedroppers@ops.ietf.org; rschroe@sandia.gov Subject: Re: About draft-ietf-dnsext-ecc-key-07.txt, absence of algorithm restriction in ECC public key encoding Eastlake III Donald-LDE008 wrote: > Actually, if you look in section 5 on page 11, it says you have to use SHA-1... > > Donald Thanks for pointing this out. Since the transition from SHA-1 to other hash algorithm is going to be a big issue some time in the future, perhaps it should be made more manifest that this draft assigns the RFC4034-allocated DNSSEC Algorithm Type value 4 to ECC **with SHA-1**. Are there other variations in ECC signature algorithms that are fixed by the draft and should be made more manifest? Someone pointed out that the draft was only "about storing keys". Does it completely specify ECC signatures? I think other DNSSEC Algorithm Type values do fully specify the respective signature algorithms. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Roy Arends Subject: base32 alphabet rant - rhaaaaa rfc3548 Date: Thu, 20 Oct 2005 23:50:48 +0200 Lines: 36 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Sat Oct 22 08:36:41 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-X-Sender: roy@cc730311-a To: namedroppers@ops.ietf.org X-AtHome-MailScanner-Information: Please contact support@home.nl for more information X-AtHome-MailScanner: Found to be clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk There exist multiple base32 alphabets. The two mostly used are "A-Z2-7" (examples in rfc3548) and "0-9A-V" (examples in rfc2938). The problem with "A-Z2-7" is that the sort order of a set of binary values is different than the sort order of its base32 equivalent in ascii order. As an example, it is obvious that 1091 is lower than 26624. However, if one would sort the base32 representations in ascii order (1091="BCD" and 26624= "2AA") then 2AA is lower than BCD. In NSEC3, owner names contain base32 encodings of binary hash values, while the 'next hashed owner name' contains a binary hash value. After adding NSEC3 and before signing, the set of NSEC3s is sorted in 'canonical order'. When a validating resolver validates (for instance) an NXDOMAIN response, it compares the hashed QNAME with the two values in the NSEC3 record. In all these things, order is important. To end this ordering problem, we're not going to use the base32 alphabet "A-Z2-7" explained in rfc3548, but use the "0-9A-V" alphabet that is explained in for instance rfc2938. Note that rfc3548 is informational, and that it refers to the origin of this base32 alphabet on a work in progress. However, this work in progress does not mention any base32 encoding. RFC3548 also refers to rfc2938, but this rfc is using the "0-9A-V" alphabet. I'll prolly add a section on this base "0-9A-V" alphabet. Something I hoped wasn't necessary, but since the sort order is screwed, I have to. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Simon Josefsson Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Sat, 22 Oct 2005 14:47:13 +0200 Lines: 31 References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Oct 22 14:57:05 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 To: Roy Arends OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051022:namedroppers@ops.ietf.org::LJrvjAT+WACgK/Qb:MOt X-Hashcash: 1:21:051022:roy@dnss.ec::CQRrO7mV2nEBojUR:EgN8 In-Reply-To: (Roy Arends's message of "Thu, 20 Oct 2005 23:50:48 +0200") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends writes: > There exist multiple base32 alphabets. The two mostly used are > "A-Z2-7" (examples in rfc3548) and "0-9A-V" (examples in rfc2938). We could update RFC 3548 to add an alternative base32 alphabet, to handle this problem. I have some other pending nits to that document, available from . > Note that rfc3548 is informational, and that it refers to the origin of > this base32 alphabet on a work in progress. However, this work in progress > does not mention any base32 encoding. Look at the 00..02 versions of that draft; it was agreed by the SASL WG to split out the part that uses base32 into a separate document, but that document hasn't materialized itself yet. I may convince them to use the 0-9A-V alphabet instead. > I'll prolly add a section on this base "0-9A-V" alphabet. Something I > hoped wasn't necessary, but since the sort order is screwed, I have to. I agree. Regards, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Paul Vixie Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Sat, 22 Oct 2005 14:42:06 +0000 Lines: 17 References: X-From: owner-namedroppers@ops.ietf.org Sat Oct 22 16:51:26 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Sat, 22 Oct 2005 14:47:13 +0200." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # > There exist multiple base32 alphabets. The two mostly used are # > "A-Z2-7" (examples in rfc3548) and "0-9A-V" (examples in rfc2938). # # We could update RFC 3548 to add an alternative base32 alphabet, to # handle this problem. I have some other pending nits to that document, # available from . i think the presentation encoding doesn't matter much. ordering should be by network encoding, not by the presentation encoding. the fact that presentation and network encoding yield different orders is ugly but nonfatal. -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Ben Laurie Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Sat, 22 Oct 2005 16:02:47 +0100 Lines: 29 References: <20051022144206.D945011426@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Oct 22 17:08:53 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Thunderbird 1.4.1 (Windows/20051006) To: Paul Vixie In-Reply-To: <20051022144206.D945011426@sa.vix.com> X-Enigmail-Version: 0.93.0.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie wrote: > # > There exist multiple base32 alphabets. The two mostly used are > # > "A-Z2-7" (examples in rfc3548) and "0-9A-V" (examples in rfc2938). > # > # We could update RFC 3548 to add an alternative base32 alphabet, to > # handle this problem. I have some other pending nits to that document, > # available from . > > i think the presentation encoding doesn't matter much. ordering should be by > network encoding, not by the presentation encoding. the fact that > presentation and network encoding yield different orders is ugly but nonfatal. This is the network encoding, not the presentation encoding. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Simon Josefsson Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Sat, 22 Oct 2005 17:45:16 +0200 Lines: 37 References: <20051022144206.D945011426@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Oct 22 17:53:25 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 To: Paul Vixie OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051022:paul@vix.com::jSavqf1nitsA6a93:3E9Q X-Hashcash: 1:21:051022:namedroppers@ops.ietf.org::ZSiiIr8d+mihbMj8:0tFE In-Reply-To: <20051022144206.D945011426@sa.vix.com> (Paul Vixie's message of "Sat, 22 Oct 2005 14:42:06 +0000") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: > # > There exist multiple base32 alphabets. The two mostly used are > # > "A-Z2-7" (examples in rfc3548) and "0-9A-V" (examples in rfc2938). > # > # We could update RFC 3548 to add an alternative base32 alphabet, to > # handle this problem. I have some other pending nits to that document, > # available from . > > i think the presentation encoding doesn't matter much. ordering should be by > network encoding, not by the presentation encoding. the fact that > presentation and network encoding yield different orders is ugly but nonfatal. This is the network encoding, since it is the owner name that is base32 encoded. Resolvers can't be expected to base32 decode NSEC3 owner names before canonical ordering. However, is the complexity induced by base32 needed? In my NO proposal, which is pretty much the same as NSEC3, I referenced the base-n document but for the base-16 encoding. That is, I used the hex encoding, resulting in records such as: 1b7838c69a66eb50cc215f66ee4554d0c4c940a5 IN NO A 0x222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1 222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1 IN NO NS SOA MX 0x839ebd4386c0b26d81f147421b5b7036e61438cf 839ebd4386c0b26d81f147421b5b7036e61438cf IN NO A 0x906a0ad5e604b1905828499dc8672ecb8de73e2f Regards, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Paul Vixie Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Sat, 22 Oct 2005 16:46:37 +0000 Lines: 34 References: <20051022144206.D945011426@sa.vix.com> X-From: owner-namedroppers@ops.ietf.org Sat Oct 22 18:55:16 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Sat, 22 Oct 2005 17:45:16 +0200." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # This is the network encoding, since it is the owner name that is # base32 encoded. Resolvers can't be expected to base32 decode NSEC3 # owner names before canonical ordering. ah. # However, is the complexity induced by base32 needed? In my NO # proposal, which is pretty much the same as NSEC3, I referenced the # base-n document but for the base-16 encoding. That is, I used the hex # encoding, resulting in records such as: # # 1b7838c69a66eb50cc215f66ee4554d0c4c940a5 # IN NO A 0x222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1 # 222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1 # IN NO NS SOA MX 0x839ebd4386c0b26d81f147421b5b7036e61438cf # 839ebd4386c0b26d81f147421b5b7036e61438cf # IN NO A 0x906a0ad5e604b1905828499dc8672ecb8de73e2f while i was a fan of the NO RR, none of these encodings are wonderful. ideally we would allocate an extended label type that said "it's 8-bit binary data, without case folding" and the presentation format for it would be the similar to what we use for unknown RR types, or bitstring labels. putting the complexity of "avoid case folding, and only use printable characters" into the wire encoding of what is essentially binary data is really doing everything the long way. -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Simon Josefsson Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Sat, 22 Oct 2005 19:09:47 +0200 Lines: 29 References: <20051022144206.D945011426@sa.vix.com> <20051022164637.9CD9911425@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Oct 22 19:17:58 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 To: Paul Vixie OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051022:namedroppers@ops.ietf.org::RiRxsTIX4lf/R4Ce:2iuF X-Hashcash: 1:21:051022:paul@vix.com::ywuEKQ06fpPJ/bE/:DUfM In-Reply-To: <20051022164637.9CD9911425@sa.vix.com> (Paul Vixie's message of "Sat, 22 Oct 2005 16:46:37 +0000") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: > ideally we would allocate an extended label type that said "it's 8-bit > binary data, without case folding" and the presentation format for it > would be the similar to what we use for unknown RR types, or bitstring > labels. Do we know that introducing a new label type work? Adding a new label type sounds like plenty of work, complexity and risk to me. I believe it would be detrimental to the deployment of NSEC3 to conflate it with the use of a new label type. Using a new label type was suggested for NO too, and was dropped back then due to similar concerns too. > putting the complexity of "avoid case folding, and only use printable > characters" into the wire encoding of what is essentially binary data > is really doing everything the long way. Not really. Without positive feedback from deployment experiments with extended label types, using owner names that are hex (or base32) encoded sounds more practical to me. Regards, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Paul Vixie Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Sat, 22 Oct 2005 17:15:17 +0000 Lines: 21 References: <20051022144206.D945011426@sa.vix.com> <20051022164637.9CD9911425@sa.vix.com> X-From: owner-namedroppers@ops.ietf.org Sat Oct 22 19:21:26 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Sat, 22 Oct 2005 19:09:47 +0200." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # Do we know that introducing a new label type work? Adding a new label # type sounds like plenty of work, complexity and risk to me. any protocol agent that has to be upgraded to understand NSEC3 can be upgraded to understand any other new element, like a new extended label type, at the same time. # ... Without positive feedback from deployment experiments with extended # label types, using owner names that are hex (or base32) encoded sounds # more practical to me. it was the intent of RFC 2671 to make it possible to do the right thing. the feedback from other features to date that were based on 2671 encodings has been positive. i have no reason to think a new extended label type will pose any special challenge. -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Simon Josefsson Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Sat, 22 Oct 2005 20:03:38 +0200 Lines: 45 References: <20051022144206.D945011426@sa.vix.com> <20051022164637.9CD9911425@sa.vix.com> <20051022171517.19A9711425@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Oct 22 20:10:01 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 To: Paul Vixie OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051022:namedroppers@ops.ietf.org::f+FIIwfFIP8F0qAO:upC X-Hashcash: 1:21:051022:paul@vix.com::KAHgzLwYXacgCMYv:C0Wc In-Reply-To: <20051022171517.19A9711425@sa.vix.com> (Paul Vixie's message of "Sat, 22 Oct 2005 17:15:17 +0000") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: > # Do we know that introducing a new label type work? Adding a new label > # type sounds like plenty of work, complexity and risk to me. > > any protocol agent that has to be upgraded to understand NSEC3 can be > upgraded to understand any other new element, like a new extended label > type, at the same time. Of course. I was talking about what was practical to do. Pro: ? Con: The work and added complexity involved to define a new extended label type. Occam's razor... > # ... Without positive feedback from deployment experiments with extended > # label types, using owner names that are hex (or base32) encoded sounds > # more practical to me. > > it was the intent of RFC 2671 to make it possible to do the right thing. > the feedback from other features to date that were based on 2671 encodings > has been positive. i have no reason to think a new extended label type > will pose any special challenge. Has any extended label types been defined? I can't even find the IANA registry for EDNS Label Type's. Presumably because nobody has done any serious work with extended label types. I think an extended label type would involve plenty of extra work for the NSEC3 authors, which would slow their effort down, with no apparent gain. Regards, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Simon Josefsson Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Sat, 22 Oct 2005 20:24:35 +0200 Lines: 30 References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Oct 22 20:32:08 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 To: Roy Arends OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051022:roy@dnss.ec::4Y0HB6qsv1KqZfYA:4nNe X-Hashcash: 1:21:051022:namedroppers@ops.ietf.org::Y1Ph+btMFQ6zbDEF:7wvS In-Reply-To: (Roy Arends's message of "Sat, 22 Oct 2005 19:59:02 +0200 (W. Europe Daylight Time)") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends writes: >>> I'll prolly add a section on this base "0-9A-V" alphabet. Something I >>> hoped wasn't necessary, but since the sort order is screwed, I have to. > > Is the pending-nits combined with a second alphabet for base32 > substantional enough to justify 3548-bis ? We only find out if we try. > Would be nice since a normative reference is more handsome than > adding yet another appendix explaining base32. Agreed. Getting rid of incompatible base-n descriptions was the goal of the document. The cut-off date for initial drafts has passed, but I'll submit draft-josefsson-rfc3548bis-00 after the IETF meeting. As always, the live document can be found at , and I invite comments and suggestions. I haven't added the base32 0-9A-V alphabet yet, though. Cheers, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Paul Vixie Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Sat, 22 Oct 2005 19:15:43 +0000 Lines: 49 References: <20051022144206.D945011426@sa.vix.com> <20051022164637.9CD9911425@sa.vix.com> <20051022171517.19A9711425@sa.vix.com> X-From: owner-namedroppers@ops.ietf.org Sat Oct 22 21:22:41 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Sat, 22 Oct 2005 20:03:38 +0200." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # Pro: # ? # # Con: # The work and added complexity involved to define a new extended label type. # # Occam's razor... that's a little quick on the draw, don't you think? the pro is, we keep wanting non-case-folder non-printable labels, and we keep inventing ways to encode them. base32 is an inefficient way to do this, it means some bits on the wire are meaningless constants (MBZ/MB1). for that matter the IDN encoding is an inefficient way to do this. sooner or later we ought to allocate a label type that does what we want. why not now? (i'll help!) # Has any extended label types been defined? only the metameta (to allow for future expansion beyond the current extended labels.) # I can't even find the IANA registry for EDNS Label Type's. Presumably # because nobody has done any serious work with extended label types. i don't think that's a reason to say they aren't or can't be useful. any time we're proposing to change all participating protocol agents we have to think about piggybacking other changes. like DNSSEC ended up depending on EDNS due to packet size and option issues. an NSEC3 that depends on a new label type is "no big deal". # I think an extended label type would involve plenty of extra work for the # NSEC3 authors, which would slow their effort down, with no apparent gain. if the NSEC3 authors were working alone, or with a blank slate, that would matter. but deploying NSEC3 is a burden and benefit to a much larger community, and that community has a say as to what ought to be piggybacked. i dearly wish that i had included binary-octet (non-bitstring binary) label types in the EDNS0 draft. i think that when i split things off into EDNS1, i cut too deep. IDN needed this. NSEC3 now needs it. if i write it up, would anyone (other than simon, apparently) agree to make NSEC3 dependent on 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 Fri Dec 29 11:36:43 2006 From: Simon Josefsson Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Sun, 23 Oct 2005 00:58:52 +0200 Lines: 44 References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sun Oct 23 01:09:19 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 To: Roy Arends OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051022:roy@dnss.ec::6yk66gXUvlMwKT69:2I4E X-Hashcash: 1:21:051022:namedroppers@ops.ietf.org::N8fc5vVdFbBqr5Vv:PM1M In-Reply-To: (Roy Arends's message of "Sat, 22 Oct 2005 21:23:15 +0200 (W. Europe Daylight Time)") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends writes: > On Sat, 22 Oct 2005, Simon Josefsson wrote: > >> Roy Arends writes: >> >>>>> I'll prolly add a section on this base "0-9A-V" alphabet. Something I >>>>> hoped wasn't necessary, but since the sort order is screwed, I have to. >>> >>> Is the pending-nits combined with a second alphabet for base32 >>> substantional enough to justify 3548-bis ? >> >> We only find out if we try. > > Lets try. I have added the 0-9A-V base32 alphabet to draft-josefsson-rfc3548bis-00, which is available from: I would appreciate to hear about other problems with that document. I will submit the document when the I-D editor re-opens after the meeting. Perhaps the document could advance together with NSEC3, if you chose to use the base32 encoding, that is. Perhaps we could even push rfc3548bis onto the standards track; the document is used as a normative reference by a few standards. I'll check with the SASL WG if they wish to continue using the A-Z2-7 alphabet for the GSS-API mechanism document. If not, I think we should make the 0-9A-V alphabet the default alphabet. The A-Z2-7 alphabet could then be the non-canonical "special" alphabet, compare the situation for base64. The A-Z2-7 alphabet reduces mistakes when the base32 data is entered by humans (0 can be confused with O and 1 with I and l), so there are some merit to it. Cheers, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: "Christian Huitema" Subject: RE: base32 alphabet rant - rhaaaaa rfc3548 Date: Sun, 23 Oct 2005 08:41:45 -0700 Lines: 29 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: X-From: owner-namedroppers@ops.ietf.org Sun Oct 23 17:49:58 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: base32 alphabet rant - rhaaaaa rfc3548 Thread-Index: AcXXXVPEMzpc1N+URxO6i1dW/UP70wAUokMg To: "Simon Josefsson" , "Roy Arends" X-OriginalArrivalTime: 23 Oct 2005 15:41:45.0049 (UTC) FILETIME=[45A0FC90:01C5D7E8] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I'll check with the SASL WG if they wish to continue using the A-Z2-7 > alphabet for the GSS-API mechanism document. If not, I think we > should make the 0-9A-V alphabet the default alphabet. If we change the alphabet, we should consider a somewhat more sophisticated solution than 0-9A-V, in order to avoid name collisions and letter confusion. Name collision is a classic problem with literal representation of binary numbers. You can inadvertently obtain a string of letters that include dictionary words, some of which can be offensive. A simple way to minimize the problem is to avoid commonly used vowels. Letter confusion occurs when people have to copy or type in labels. For example, there is a significant risk of confusing the number 0 and the letter O, the number 1 and the letter I or the lower case letter l. The set 0-9A-Z includes 36 code points. The 0-9A-V solution just drops the last letters in sequence, WXYZ. It may be more productive to remove the letters A (vowel), E (vowel), I (vowel, confusion with number 1) and O (vowel, confusion with number 0). -- Christian Huitema -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Simon Josefsson Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Sun, 23 Oct 2005 18:13:00 +0200 Lines: 50 References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: , "Roy Arends" X-From: owner-namedroppers@ops.ietf.org Sun Oct 23 18:20:31 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 To: "Christian Huitema" OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051023:namedroppers@ops.ietf.org::LAIuHA4anWOPPzvU:0HPa X-Hashcash: 1:21:051023:huitema@windows.microsoft.com::xeyYFqGnMTbhJyTO:1FpS X-Hashcash: 1:21:051023:roy@dnss.ec::i96saJKbcdmHoV1A:7Miw In-Reply-To: (Christian Huitema's message of "Sun, 23 Oct 2005 08:41:45 -0700") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Christian Huitema" writes: >> I'll check with the SASL WG if they wish to continue using the A-Z2-7 >> alphabet for the GSS-API mechanism document. If not, I think we >> should make the 0-9A-V alphabet the default alphabet. > > If we change the alphabet, we should consider a somewhat more > sophisticated solution than 0-9A-V, in order to avoid name collisions > and letter confusion. > > Name collision is a classic problem with literal representation of > binary numbers. You can inadvertently obtain a string of letters that > include dictionary words, some of which can be offensive. A simple way > to minimize the problem is to avoid commonly used vowels. > > Letter confusion occurs when people have to copy or type in labels. For > example, there is a significant risk of confusing the number 0 and the > letter O, the number 1 and the letter I or the lower case letter l. > > The set 0-9A-Z includes 36 code points. The 0-9A-V solution just drops > the last letters in sequence, WXYZ. It may be more productive to remove > the letters A (vowel), E (vowel), I (vowel, confusion with number 1) > and O (vowel, confusion with number 0). Changing the alphabet would be fine if rfc3548bis aimed for the standards track. However, currently, rfc3548 is merely informative, and the aim was to try to document existing practices. We know 0-9a-z is used, it is from rfc 2938, and a-z2-7 was used in the SASL WG document. I believe base-n encoding are important enough to be on the standards track. I will aim for that in the revised document, and see if people approve. I'll propose to make the "standard" base32 alphabet be the 0-9b-df-hj-np-z alphabet. It preserve sort order (which was the requirement here) and it avoid some easily visually confusing letters (which was the requirement in rfc3548). It sometime also avoid offensive words, which is a nice feature. However, if that was a requirement, we would need a more complicated set of rules (I believe there are offensive words that don't contain a, e, i, or o). Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Roy Arends Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Sat, 22 Oct 2005 19:59:02 +0200 (W. Europe Daylight Time) Lines: 41 References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 04:15:18 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 To: Simon Josefsson In-Reply-To: X-X-Sender: roy@trinitario.schlyter.se X-AtHome-MailScanner-Information: Please contact support@home.nl for more information X-AtHome-MailScanner: Found to be clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, 22 Oct 2005, Simon Josefsson wrote: > Roy Arends writes: > >> There exist multiple base32 alphabets. The two mostly used are >> "A-Z2-7" (examples in rfc3548) and "0-9A-V" (examples in rfc2938). > > We could update RFC 3548 to add an alternative base32 alphabet, to > handle this problem. I have some other pending nits to that document, > available from . That would be a good thing. >> Note that rfc3548 is informational, and that it refers to the origin of >> this base32 alphabet on a work in progress. However, this work in progress >> does not mention any base32 encoding. > > Look at the 00..02 versions of that draft; it was agreed by the SASL > WG to split out the part that uses base32 into a separate document, > but that document hasn't materialized itself yet. I may convince them > to use the 0-9A-V alphabet instead. That would be a good thing too. >> I'll prolly add a section on this base "0-9A-V" alphabet. Something I >> hoped wasn't necessary, but since the sort order is screwed, I have to. Is the pending-nits combined with a second alphabet for base32 substantional enough to justify 3548-bis ? Would be nice since a normative reference is more handsome than adding yet another appendix explaining base32. Thanks, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Roy Arends Subject: RE: base32 alphabet rant - rhaaaaa rfc3548 Date: Sun, 23 Oct 2005 22:04:12 +0200 (W. Europe Daylight Time) Lines: 40 References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Simon Josefsson , namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 09:23:10 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 To: Christian Huitema In-Reply-To: X-X-Sender: roy@trinitario.schlyter.se X-AtHome-MailScanner-Information: Please contact support@home.nl for more information X-AtHome-MailScanner: Found to be clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 23 Oct 2005, Christian Huitema wrote: >> I'll check with the SASL WG if they wish to continue using the A-Z2-7 >> alphabet for the GSS-API mechanism document. If not, I think we >> should make the 0-9A-V alphabet the default alphabet. > > If we change the alphabet, we should consider a somewhat more > sophisticated solution than 0-9A-V, in order to avoid name collisions > and letter confusion. > > Name collision is a classic problem with literal representation of > binary numbers. You can inadvertently obtain a string of letters that > include dictionary words, some of which can be offensive. A simple way > to minimize the problem is to avoid commonly used vowels. > > Letter confusion occurs when people have to copy or type in labels. For > example, there is a significant risk of confusing the number 0 and the > letter O, the number 1 and the letter I or the lower case letter l. > > The set 0-9A-Z includes 36 code points. The 0-9A-V solution just drops > the last letters in sequence, WXYZ. It may be more productive to remove > the letters A (vowel), E (vowel), I (vowel, confusion with number 1) > and O (vowel, confusion with number 0). The I!=1 and O!=0 confusion I can somewhat understand, eventhough this doesn't really apply to NSEC3 imho. Trying to create an alphabet that avoids base32 encoded data parts colliding with some dictionary word in some language is a nice social idea, but just doesn't scale, hence rediculous to require. (You may still upset those Tashlhiyt' Berber speaking folk if you'd avoid vowels). It might be a classic problem, but not on this layer. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: "Olaf M. Kolkman" Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 09:48:16 +0200 Lines: 61 References: <20051022144206.D945011426@sa.vix.com> <20051022164637.9CD9911425@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-12--638442272" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 09:56:18 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 In-Reply-To: <20051022164637.9CD9911425@sa.vix.com> To: Namedroppers X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-12--638442272 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed It took me a while to crock why the owner names are not in binary encoded format and why we need the encoding wizardry for the owner names. Paul's remark helped: > ideally we would allocate an extended label type that said "it's 8-bit > binary data, without case folding" and the presentation format for it > would be the similar to what we use for unknown RR types, or bitstring > labels. > It might be wise to add a paragraph to explain that the representation format of the owner name is chosen so it survives case folding. --Olaf namedropper. ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-12--638442272 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDXJHAtN/ca3YJIocRAgARAJ9KW1bxTb3elESjB8WHSJewjpL9ZwCePSbe 7UEJxlpKUhAiInvgOHjYo94= =fGMl -----END PGP SIGNATURE----- --Apple-Mail-12--638442272-- -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Peter Koch Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 09:55:23 +0200 Lines: 17 References: <20051022164637.9CD9911425@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 10:00:09 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Sat, 22 Oct 2005 16:46:37 -0000." <20051022164637.9CD9911425@sa.vix.com> Content-ID: <23531.1130140514.1@tyrannia.TechFak.Uni-Bielefeld.DE> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie wrote: > ideally we would allocate an extended label type that said "it's 8-bit > binary data, without case folding" and the presentation format for it > would be the similar to what we use for unknown RR types, or bitstring > labels. this could also elegantly solve the "paradox problem", where the NSEC3 chain denies its owners' existance. -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 Fri Dec 29 11:36:43 2006 From: Roy Arends Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 10:07:42 +0200 (CEST) Lines: 26 References: <20051022144206.D945011426@sa.vix.com> <20051022164637.9CD9911425@sa.vix.com> <5DA2632B-10DA-4EAA-8390-60C071397D40@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Namedroppers X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 10:14:59 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-X-Sender: roy@netinfo.corporate.telin.nl To: "Olaf M. Kolkman" In-Reply-To: <5DA2632B-10DA-4EAA-8390-60C071397D40@NLnetLabs.nl> X-OriginalArrivalTime: 24 Oct 2005 08:07:43.0098 (UTC) FILETIME=[0292E5A0:01C5D872] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 24 Oct 2005, Olaf M. Kolkman wrote: > It took me a while to crock why the owner names are not in binary encoded > format and why we need the encoding wizardry for the owner names. > > Paul's remark helped: > >> ideally we would allocate an extended label type that said "it's 8-bit >> binary data, without case folding" and the presentation format for it >> would be the similar to what we use for unknown RR types, or bitstring >> labels. >> > > It might be wise to add a paragraph to explain that the representation format > of the owner name is chosen so it survives case folding. Good point, will add, though we just submitted version -03 of the nsec3 draft. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Roy Arends Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 10:17:54 +0200 (CEST) Lines: 22 References: <200510240755.j9O7tOb23536@tyrannia.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 10:26:11 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-X-Sender: roy@netinfo.corporate.telin.nl To: Peter Koch In-Reply-To: <200510240755.j9O7tOb23536@tyrannia.TechFak.Uni-Bielefeld.DE> X-OriginalArrivalTime: 24 Oct 2005 08:17:54.0388 (UTC) FILETIME=[6EEE5940:01C5D873] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 24 Oct 2005, Peter Koch wrote: > Paul Vixie wrote: > >> ideally we would allocate an extended label type that said "it's 8-bit >> binary data, without case folding" and the presentation format for it >> would be the similar to what we use for unknown RR types, or bitstring >> labels. > > this could also elegantly solve the "paradox problem", where the NSEC3 chain > denies its owners' existance. Does it matter wrt the paradox problem if a label exists at labeltype 00 or labeltype 0100002 ? Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Ben Laurie Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 11:30:27 +0100 Lines: 33 References: <20051022144206.D945011426@sa.vix.com> <20051022164637.9CD9911425@sa.vix.com> <5DA2632B-10DA-4EAA-8390-60C071397D40@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Olaf M. Kolkman" , Namedroppers X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 12:37:17 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Thunderbird 1.4.1 (Windows/20051006) To: Roy Arends In-Reply-To: X-Enigmail-Version: 0.93.0.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends wrote: > On Mon, 24 Oct 2005, Olaf M. Kolkman wrote: > >> It took me a while to crock why the owner names are not in binary >> encoded format and why we need the encoding wizardry for the owner names. >> >> Paul's remark helped: >> >>> ideally we would allocate an extended label type that said "it's 8-bit >>> binary data, without case folding" and the presentation format for it >>> would be the similar to what we use for unknown RR types, or bitstring >>> labels. >>> >> >> It might be wise to add a paragraph to explain that the representation >> format of the owner name is chosen so it survives case folding. > > Good point, will add, though we just submitted version -03 of the nsec3 > draft. You have 1.5 hours to submit -04 :-) -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Ben Laurie Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 11:29:58 +0100 Lines: 33 References: <200510240755.j9O7tOb23536@tyrannia.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 12:37:30 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Thunderbird 1.4.1 (Windows/20051006) To: Peter Koch In-Reply-To: <200510240755.j9O7tOb23536@tyrannia.TechFak.Uni-Bielefeld.DE> X-Enigmail-Version: 0.93.0.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Peter Koch wrote: > Paul Vixie wrote: > >> ideally we would allocate an extended label type that said "it's 8-bit >> binary data, without case folding" and the presentation format for it >> would be the similar to what we use for unknown RR types, or bitstring >> labels. > > this could also elegantly solve the "paradox problem", where the NSEC3 chain > denies its owners' existance. It could? How? Are you suggesting that different label types are somehow in different spaces? Hmm. Now here's a fun problem. If an 8-bit label type is introduced and used for anything other than NSEC3, then how does it work with NSEC? Canonical ordering for NSEC doesn't account for 8-bit data... Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Peter Koch Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 13:32:18 +0200 Lines: 37 References: <435CB7A6.6040500@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 13:43:06 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Mon, 24 Oct 2005 11:29:58 BST." <435CB7A6.6040500@algroup.co.uk> Content-ID: <25421.1130153526.1@tyrannia.TechFak.Uni-Bielefeld.DE> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben Laurie wrote: > It could? How? Are you suggesting that different label types are somehow > in different spaces? Roy Arends wrote: > Does it matter wrt the paradox problem if a label exists at labeltype 00 > or labeltype 0100002 ? New label types extend the alphabet available for labels and by doing so extend the namespace. "New" labels do not belong to the classic namespace. Section 6.1 of RFC 4034 does only define sort order for old style labels. Bitstring labels (RFC 2673) hook themselves into the namespace by explicitly specifying their relation to "canonical sort order". > Canonical ordering for NSEC doesn't account for 8-bit data... Right, so if we do not define any sort order for this new label type, it cannot be secured by NSEC RRs, but that's not a problem. We don't even need to prohibit those labels to own anything but NSEC, since anybody tempted should "know what they are doing". The new namespace extension would be contiguous and separate from the old space and would not interfere with it. That's different from what real and rational numbers do in mathematics :-) However, the new label type might add some complexity which would need very careful consideration. -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 Fri Dec 29 11:36:43 2006 From: bert hubert Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 13:56:20 +0200 Lines: 21 References: <435CB7A6.6040500@algroup.co.uk> <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 14:02:21 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL autolearn=no version=3.1.0 To: Peter Koch Content-Disposition: inline In-Reply-To: <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Does it matter wrt the paradox problem if a label exists at labeltype 00 > > or labeltype 0100002 ? > > New label types extend the alphabet available for labels and by doing so > extend the namespace. "New" labels do not belong to the classic namespace. Be aware btw that adding whole new label types (again) raises the bar significantly for adoption of NSEC3 and hence DNSSEC. I politely disagree with Paul V when he says that adding a label type is not harder than adding another record, it is way more fundamental. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Chris Thompson Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 13:12:35 +0100 (BST) Lines: 27 References: <5DA2632B-10DA-4EAA-8390-60C071397D40@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 14:18:50 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ To: namedroppers@ops.ietf.org In-Reply-To: <5DA2632B-10DA-4EAA-8390-60C071397D40@NLnetLabs.nl> from "Olaf M. Kolkman" at Oct 24, 5 09:48:16 am X-Mailer: ELM [version 2.4 PL24] Content-Length: 887 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Olaf Kolkman writes: [...] > It might be wise to add a paragraph to explain that the > representation format of the owner name is chosen so it survives case > folding. As a reductio ad absurdum of this whole thread, perhaps it should be pointed out that we could avoid those pesky liable-to-case-folding letters altogether, without using binary labels. There are 34 other printable ASCII characters that can occur in labels in master files without having to be quoted: !#%&'*+,-/0123456789:<=>?@[]^_`{|} * and @ have special meanings only when they occur in isolation, but we can even drop those and retain enough for a base32 encoding ... -- Chris Thompson Email: cet1@cam.ac.uk -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Simon Josefsson Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 15:44:33 +0200 Lines: 72 References: <20051022144206.D945011426@sa.vix.com> <20051022164637.9CD9911425@sa.vix.com> <20051022171517.19A9711425@sa.vix.com> <20051022191543.8424F11425@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 15:53:18 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 To: Paul Vixie OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051024:namedroppers@ops.ietf.org::+X9GKXmqM47y1fO1:3kE X-Hashcash: 1:21:051024:paul@vix.com::9qXphUmXRDlfJjKm:KKhd In-Reply-To: <20051022191543.8424F11425@sa.vix.com> (Paul Vixie's message of "Sat, 22 Oct 2005 19:15:43 +0000") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: > # Pro: > # ? > # > # Con: > # The work and added complexity involved to define a new extended label type. > # > # Occam's razor... > > that's a little quick on the draw, don't you think? Well, we are still discussing the matter. > the pro is, we keep wanting non-case-folder non-printable labels, and we keep > inventing ways to encode them. base32 is an inefficient way to do this, it > means some bits on the wire are meaningless constants (MBZ/MB1). for that > matter the IDN encoding is an inefficient way to do this. sooner or later we > ought to allocate a label type that does what we want. why not now? (i'll > help!) I don't see justification of why NSEC3 should use an extended label type here. I only see justification of why a document that describe binary label type would be a good idea. I think such a document may be useful. If that effort was successful, future RRs may utilize it. > # I can't even find the IANA registry for EDNS Label Type's. Presumably > # because nobody has done any serious work with extended label types. > > i don't think that's a reason to say they aren't or can't be useful. any > time we're proposing to change all participating protocol agents we have to > think about piggybacking other changes. like DNSSEC ended up depending on > EDNS due to packet size and option issues. an NSEC3 that depends on a new > label type is "no big deal". I disagree. > # I think an extended label type would involve plenty of extra work for the > # NSEC3 authors, which would slow their effort down, with no apparent gain. > > if the NSEC3 authors were working alone, or with a blank slate, that would > matter. but deploying NSEC3 is a burden and benefit to a much larger > community, and that community has a say as to what ought to be piggybacked. Sure. My opinion is clear, given what has been presented on the status of extended label types so far. > i dearly wish that i had included binary-octet (non-bitstring binary) label > types in the EDNS0 draft. i think that when i split things off into EDNS1, > i cut too deep. IDN needed this. NSEC3 now needs it. if i write it up, > would anyone (other than simon, apparently) agree to make NSEC3 dependent > on it? I strongly disagree that IDN and NSEC3 "needs" this. IDN could not have used a new label type. It was a requirement in IDN that DNS resolvers and servers should not have to be upgraded. NSEC3 _could_ utilize a new label type, but it is definitely not a critical dependency, and it brings no advantages that I can see. A few disadvantages have already been explained. Cheers, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Simon Josefsson Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 15:49:22 +0200 Lines: 34 References: <5DA2632B-10DA-4EAA-8390-60C071397D40@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 15:54:53 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 To: Chris Thompson OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051024:cet1@cus.cam.ac.uk::qfnDmja0Mr2TR4m9:3ut7 X-Hashcash: 1:21:051024:namedroppers@ops.ietf.org::Ow7FDWbJqgstvYvQ:MnF In-Reply-To: (Chris Thompson's message of "Mon, 24 Oct 2005 13:12:35 +0100 (BST)") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Chris Thompson writes: > Olaf Kolkman writes: > > [...] >> It might be wise to add a paragraph to explain that the >> representation format of the owner name is chosen so it survives case >> folding. > > As a reductio ad absurdum of this whole thread, perhaps it should be > pointed out that we could avoid those pesky liable-to-case-folding > letters altogether, without using binary labels. There are 34 other > printable ASCII characters that can occur in labels in master files > without having to be quoted: > > !#%&'*+,-/0123456789:<=>?@[]^_`{|} > > * and @ have special meanings only when they occur in isolation, but > we can even drop those and retain enough for a base32 encoding ... The point of using a base32 encoding (0-9a-v, a-z0-7 or even 0-9b-df-hj-np-z) was that the alphabet, unlike base64, is not liable to case folding. I don't see what benefit a non-alphabetical alphabet (sic!) would bring. We have already solved the case-folding problem by using base32, the only remaining problem is to preserve sort order. Regards, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Ben Laurie Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 15:26:52 +0100 Lines: 44 References: <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 16:37:34 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Thunderbird 1.4.1 (Windows/20051006) To: Peter Koch In-Reply-To: <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> X-Enigmail-Version: 0.93.0.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Peter Koch wrote: > Ben Laurie wrote: > >> It could? How? Are you suggesting that different label types are somehow >> in different spaces? > > Roy Arends wrote: > >> Does it matter wrt the paradox problem if a label exists at labeltype 00 >> or labeltype 0100002 ? > > New label types extend the alphabet available for labels and by doing so > extend the namespace. "New" labels do not belong to the classic namespace. > > Section 6.1 of RFC 4034 does only define sort order for old style labels. > Bitstring labels (RFC 2673) hook themselves into the namespace by explicitly > specifying their relation to "canonical sort order". > >> Canonical ordering for NSEC doesn't account for 8-bit data... > > Right, so if we do not define any sort order for this new label type, > it cannot be secured by NSEC RRs, but that's not a problem. We don't > even need to prohibit those labels to own anything but NSEC, since > anybody tempted should "know what they are doing". The new namespace > extension would be contiguous and separate from the old space and would > not interfere with it. That's different from what real and rational > numbers do in mathematics :-) > > However, the new label type might add some complexity which would need > very careful consideration. Don't we have enough careful consideration already? -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Roy Arends Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 16:56:43 +0200 (CEST) Lines: 69 References: <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 17:07:11 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-X-Sender: roy@netinfo.corporate.telin.nl To: Peter Koch In-Reply-To: <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> X-OriginalArrivalTime: 24 Oct 2005 14:56:43.0602 (UTC) FILETIME=[25DAA320:01C5D8AB] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 24 Oct 2005, Peter Koch wrote: > Ben Laurie wrote: > >> It could? How? Are you suggesting that different label types are somehow >> in different spaces? > > Roy Arends wrote: > >> Does it matter wrt the paradox problem if a label exists at labeltype 00 >> or labeltype 0100002 ? > > New label types extend the alphabet available for labels and by doing so > extend the namespace. "New" labels do not belong to the classic namespace. Is there any specific section in rfc4033/4/5 that restricts using DNSSEC to prove absence/presence of records with extended label types in its ownername ? > Section 6.1 of RFC 4034 does only define sort order for old style labels. > Bitstring labels (RFC 2673) hook themselves into the namespace by explicitly > specifying their relation to "canonical sort order". True but non-sequitur. Your point was: ''this could also elegantly solve the "paradox problem", where the NSEC3 chain denies its owners' existance.'' Where ''this'' refered to using an extended label type for 8 bit labels. >> Canonical ordering for NSEC doesn't account for 8-bit data... > > Right, so if we do not define any sort order for this new label type, > it cannot be secured by NSEC RRs, but that's not a problem. Indeed. One would need to define sort-order for 8 bit labels for the purpose of dnssec. > We don't even need to prohibit those labels to own anything but NSEC, > since anybody tempted should "know what they are doing". The new > namespace extension would be contiguous and separate from the old space > and would not interfere with it. That's different from what real and > rational numbers do in mathematics :-) This still doesn't convince me that 8bit labels offer a solution to the paradox problem. On one end, if 8 bit labels were for NSEC3 only, sure, there is no point in NSEC3 acknowledging the existence of itself, and hence, declare this special label type outside the 'provable existent namespace'. On the other end, if 8 bit labels can be used by anything, we'd need to be able to prove their existence/absence, and there we have the paradox problem again. > However, the new label type might add some complexity which would need > very careful consideration. I don't think the 'paradox problem' is a real issue. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Paul Vixie Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 16:33:20 +0000 Lines: 19 References: <435CB7A6.6040500@algroup.co.uk> <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> <20051024115620.GB24941@outpost.ds9a.nl> Cc: Peter Koch , namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 18:49:50 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: bert hubert In-Reply-To: Your message of "Mon, 24 Oct 2005 13:56:20 +0200." <20051024115620.GB24941@outpost.ds9a.nl> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # Be aware btw that adding whole new label types (again) raises the bar # significantly for adoption of NSEC3 and hence DNSSEC. deployment difficulty is first a function of the number of protocol agents you have to upgrade, ans second the complexity of the protocol or software itself. as far as i can tell, no existing middlebox will tolerate NSEC3. # I politely disagree with Paul V when he says that adding a label type is not # harder than adding another record, it is way more fundamental. i didn't say records, i said edns elements. rolling out a new label type is not going to be harder than rolling out the OPT RR was, and probably easier. -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: David Blacka Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 12:58:50 -0400 Lines: 43 References: <435CB7A6.6040500@algroup.co.uk> <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> <20051024115620.GB24941@outpost.ds9a.nl> <20051024163320.C39AE11425@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Cc: DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 19:11:52 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 In-Reply-To: <20051024163320.C39AE11425@sa.vix.com> To: Paul Vixie X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Oct 24, 2005, at 12:33 PM, Paul Vixie wrote: > # Be aware btw that adding whole new label types (again) raises the > bar > # significantly for adoption of NSEC3 and hence DNSSEC. > > deployment difficulty is first a function of the number of protocol > agents you > have to upgrade, ans second the complexity of the protocol or > software itself. > > as far as i can tell, no existing middlebox will tolerate NSEC3. What do you mean by "tolerate"? It seems to me that, while validating through an NSEC3-unaware middlebox is not likely to work, the answer itself should get through. > # I politely disagree with Paul V when he says that adding a label > type is not > # harder than adding another record, it is way more fundamental. > > i didn't say records, i said edns elements. rolling out a new > label type is > not going to be harder than rolling out the OPT RR was, and > probably easier. What happens when pre-EDNS0 DNS software sees an extended label type? What happens when post-ENDS0 softwares sees an unknown extended label type? -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Alex Bligh Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 18:04:26 +0100 Lines: 17 References: <435CB7A6.6040500@algroup.co.uk> <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> <20051024115620.GB24941@outpost.ds9a.nl> <20051024163320.C39AE11425@sa.vix.com> Reply-To: Alex Bligh Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Koch , namedroppers@ops.ietf.org, Alex Bligh X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 19:14:20 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 To: Paul Vixie , bert hubert In-Reply-To: <20051024163320.C39AE11425@sa.vix.com> X-Mailer: Mulberry/4.0.4 (Win32) Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --On 24 October 2005 16:33 +0000 Paul Vixie wrote: > as far as i can tell, no existing middlebox will tolerate NSEC3. Really? All middleboxen filter out all RRs they do not fully understand, no matter what the purpose of said middleboxen are? That's a surprising statement. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Mike StJohns Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 13:14:00 -0400 Lines: 33 References: <435CB7A6.6040500@algroup.co.uk> <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> <20051024115620.GB24941@outpost.ds9a.nl> <20051024163320.C39AE11425@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Peter Koch , namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 19:21:38 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 To: Paul Vixie , bert hubert In-Reply-To: <20051024163320.C39AE11425@sa.vix.com> References: <435CB7A6.6040500@algroup.co.uk> <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> <20051024115620.GB24941@outpost.ds9a.nl> <20051024163320.C39AE11425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:33 PM 10/24/2005, Paul Vixie wrote: ># Be aware btw that adding whole new label types (again) raises the bar ># significantly for adoption of NSEC3 and hence DNSSEC. > >deployment difficulty is first a function of the number of protocol agents you >have to upgrade, ans second the complexity of the protocol or software itself. > >as far as i can tell, no existing middlebox will tolerate NSEC3. > ># I politely disagree with Paul V when he says that adding a label type is not ># harder than adding another record, it is way more fundamental. > >i didn't say records, i said edns elements. rolling out a new label type is >not going to be harder than rolling out the OPT RR was, and probably easier. My turn to politely disagree. OPT RRs are still RRs are are ignored by non-compliant (hmm... to clarify I mean resolvers that don't understand OPT) resolvers. A label type that is neither 0 (normal) nor 3 (pointer) will probably return BADLABELTYPE in most resolvers and halt processing of the entire message. Which suggests that this could only be sent to a resolver that explicitly indicates it understands the new label type(s). So I think you're talking changes to either the OPT RR or something else in addition to whatever other changes if you add a new label type. Are there also master file format changes to indicate the new label type? *yuck* -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Paul Vixie Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 17:14:41 +0000 Lines: 29 References: <435CB7A6.6040500@algroup.co.uk> <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> <20051024115620.GB24941@outpost.ds9a.nl> <20051024163320.C39AE11425@sa.vix.com> X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 19:23:23 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: DNSEXT WG In-Reply-To: Your message of "Mon, 24 Oct 2005 12:58:50 -0400." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # > as far as i can tell, no existing middlebox will tolerate NSEC3. # # What do you mean by "tolerate"? It seems to me that, while validating # through an NSEC3-unaware middlebox is not likely to work, the answer # itself should get through. your explaination is better. what i meant was, there will be a sea-to-sea upgrade to get NSEC3 in place. if we're going to touch that many agents, can we please pay in advance for what we want instead of paying in arrears for what we needed? # What happens when pre-EDNS0 DNS software sees an extended label type? it won't, since it will not do the EDNS negotiation, and this element will not be usable in messages to such agents. # What happens when post-ENDS0 softwares sees an unknown extended label type? again, it won't. this would be a new element whose structure is not known by EDNS0 agents, and so it would require a version number increment. (unlike flags, whose structure is known but whose meaning is not... with a flag, you only have to increment the version number if "ignored by older agents" is not acceptable to the flag-designer.) -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Paul Vixie Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 17:24:15 +0000 Lines: 29 References: <435CB7A6.6040500@algroup.co.uk> <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> <20051024115620.GB24941@outpost.ds9a.nl> <20051024163320.C39AE11425@sa.vix.com> <6.2.1.2.2.20051024125920.05e40e60@localhost> Cc: bert hubert , Peter Koch , namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 19:33:21 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Mike StJohns In-Reply-To: Your message of "Mon, 24 Oct 2005 13:14:00 -0400." <6.2.1.2.2.20051024125920.05e40e60@localhost> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # >i didn't say records, i said edns elements. rolling out a new label type # >is not going to be harder than rolling out the OPT RR was, and probably # >easier. # # My turn to politely disagree. OPT RRs are still RRs are are ignored by # non-compliant (hmm... to clarify I mean resolvers that don't understand # OPT) resolvers. OPT will never be seen in a response by an agent who did not solicit them, and an ignored initiatory OPT just means "EDNS negotiation failed." # A label type that is neither 0 (normal) nor 3 (pointer) will probably return # BADLABELTYPE in most resolvers and halt processing of the entire message. # Which suggests that this could only be sent to a resolver that explicitly # indicates it understands the new label type(s). it's all about solicitation. # So I think you're talking changes to either the OPT RR or something else in # addition to whatever other changes if you add a new label type. Are there # also master file format changes to indicate the new label type? *yuck* yes. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Paul Vixie Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 17:20:44 +0000 Lines: 20 References: <435CB7A6.6040500@algroup.co.uk> <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> <20051024115620.GB24941@outpost.ds9a.nl> <20051024163320.C39AE11425@sa.vix.com> <76AFC476D1D6F7CCAB8BDC4F@[192.168.100.25]> X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 19:33:47 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Mon, 24 Oct 2005 18:04:26 +0100." <76AFC476D1D6F7CCAB8BDC4F@[192.168.100.25]> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # > as far as i can tell, no existing middlebox will tolerate NSEC3. # # Really? All middleboxen filter out all RRs they do not fully understand, no # matter what the purpose of said middleboxen are? That's a surprising # statement. assuming that the middlebox ends up receiving and caching an NSEC3, it will not include it in regenerated forwarded responses, nor in responses from cache. NSEC3 agents behind pre-NSEC3 middleboxes will have to make a third query to fetch the NSEC3, based on bits they see in the zone apex data, which they'll have had to make a second query to see, since it wouldn't've been included earlier either. it's interesting that folks complain about how DLV makes an extra query :-). -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: David Blacka Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 14:12:24 -0400 Lines: 48 References: <435CB7A6.6040500@algroup.co.uk> <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> <20051024115620.GB24941@outpost.ds9a.nl> <20051024163320.C39AE11425@sa.vix.com> <76AFC476D1D6F7CCAB8BDC4F@[192.168.100.25]> <20051024172044.AE8E511425@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 20:23:07 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 In-Reply-To: <20051024172044.AE8E511425@sa.vix.com> To: Paul Vixie X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Oct 24, 2005, at 1:20 PM, Paul Vixie wrote: > # > as far as i can tell, no existing middlebox will tolerate NSEC3. > # > # Really? All middleboxen filter out all RRs they do not fully > understand, no > # matter what the purpose of said middleboxen are? That's a surprising > # statement. > > assuming that the middlebox ends up receiving and caching an NSEC3, > it will > not include it in regenerated forwarded responses, nor in responses > from > cache. NSEC3 agents behind pre-NSEC3 middleboxes will have to make > a third > query to fetch the NSEC3, based on bits they see in the zone apex > data, > which they'll have had to make a second query to see, since it > wouldn't've > been included earlier either. What bits in the zone apex data? What are you talking about? In general, validation through a non--aware middlebox doesn't work, for RFC 4035 DNSSEC or NSEC3. The validator isn't going to make extra queries for the missing NSEC/NSEC3's, because, in a number of cases, it won't know what qname to use. In RFC 4035 this occurs for rcode=3. In NSEC3, this is true for NOERROR/NODATA responses as well. > it's interesting that folks complain about how DLV makes an extra > query :-). NSEC3 doesn't introduce extra queries AFAICT. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Paul Vixie Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 18:15:45 +0000 Lines: 14 References: <435CB7A6.6040500@algroup.co.uk> <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> <20051024115620.GB24941@outpost.ds9a.nl> <20051024163320.C39AE11425@sa.vix.com> <76AFC476D1D6F7CCAB8BDC4F@[192.168.100.25]> <20051024172044.AE8E511425@sa.vix.com> <8216CDE1-D8FE-4EBA-9FD8-22285AD9181F@verisignlabs.com> X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 20:25:42 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Mon, 24 Oct 2005 14:12:24 -0400." <8216CDE1-D8FE-4EBA-9FD8-22285AD9181F@verisignlabs.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # In general, validation through a non--aware middlebox doesn't work, # for RFC 4035 DNSSEC or NSEC3. The validator isn't going to make extra # queries for the missing NSEC/NSEC3's, because, in a number of cases, it # won't know what qname to use. In RFC 4035 this occurs for rcode=3. In # NSEC3, this is true for NOERROR/NODATA responses as well. so, NSEC3 will be a sea-to-sea change, and NSEC-aware middleboxes will have to be upgraded, not just authority servers and query-initiating "clients"? -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: David Blacka Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 14:16:16 -0400 Lines: 40 References: <435CB7A6.6040500@algroup.co.uk> <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> <20051024115620.GB24941@outpost.ds9a.nl> <20051024163320.C39AE11425@sa.vix.com> <20051024171441.CEA4411426@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Cc: DNSEXT WG X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 20:28:15 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 In-Reply-To: <20051024171441.CEA4411426@sa.vix.com> To: Paul Vixie X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Oct 24, 2005, at 1:14 PM, Paul Vixie wrote: > # What happens when pre-EDNS0 DNS software sees an extended label > type? > > it won't, since it will not do the EDNS negotiation, and this > element will > not be usable in messages to such agents. > > # What happens when post-ENDS0 softwares sees an unknown extended > label type? > > again, it won't. this would be a new element whose structure is > not known > by EDNS0 agents, and so it would require a version number > increment. (unlike > flags, whose structure is known but whose meaning is not... with a > flag, you > only have to increment the version number if "ignored by older > agents" is not > acceptable to the flag-designer.) I see. Adding an extended label type implies increasing the EDNS version. This wasn't clear to me. It doesn't seem to be stated one way or another in RFC 2671. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Rob Austein Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 14:30:11 -0400 Lines: 56 References: Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 20:39:18 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 To: namedroppers@ops.ietf.org In-Reply-To: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I am somewhat leery of getting back into the extended label type swamp, given how long it took us to figure out the problem last time, but to be clear on what happened last time: - Bitlabels were intended to provide a clean way to express addresses in the IPv6 reverse tree (it was already too late for IPv4). - Query usage of bitlabels in the reverse tree would have required -every- name server in the resolution path to understand bitlabels, because queries are always expressed in terms of the QNAME. Eg, if the name servers for the root zone didn't understand bitlabels, using bitlabels in the reverse tree wouldn't work, even though the root name servers would always just be delegating to the .arpa nameservers -- root server would return Format Error, game over. - While cleaner, the only place where bitlabels made it possible to do something that just couldn't be done with old-fashioned labels was when dealing with IPv6 reverse tree entries that needed to be delegated in the least significant four bits, which, given the way the IPv6 address architecture evolved, is not likely to happen. - So the joint DNSEXT/NGTRANS WG meeting held to sort out what we should do about DNS in IPv6 concluded (somewhat roughly) that the pain involved in getting bitlabels to work outweighed the benefits. It is not immediately obvious to me (either way) which of these arguments apply to NSEC3. Last time I checked, the theory was that one never queries for NSEC or NSEC3 RRs directly, so the issue of including them as part of the QNAME may not apply here. There is still the problem of getting Format Error from implemenetions that don't understand extended label types, but DNSSEC is a much larger change to the DNS protocol than support for IPv6 addresses was. So I dunno. I would caution all parties to please think this through and perform the analysis rather than jumping to conclusions (either way) based on the IPv6 reverse tree example. We know that it's hard to get fundamental changes to DNS deployed; we also know that DNSSEC is a fundamental change that is totally backwards compatable in some ways and totally backwards incompatible in other ways. Neither "it didn't work last time so give up" nor "it didn't work last time but it damned well should have so let's try again" is likely to help here (with apologies to anyone who finds this an unkind characterization of their position on the subject). We need people thinking hard about what each entity in the protocol is going to do when it receives these packets, and we need people running workshops to verify our thinking. My own guess is that extended label types in this case are not going to be worth the trouble, because I don't see anything here that can't be done via more a conservative approach, and thus see no need to live on the bleeding edge. But that's just an opinion, and could be wrong. -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: "Olaf M. Kolkman" Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Mon, 24 Oct 2005 21:57:21 +0200 Lines: 54 References: <435CB7A6.6040500@algroup.co.uk> <200510241132.j9OBWJI25434@tyrannia.TechFak.Uni-Bielefeld.DE> <20051024115620.GB24941@outpost.ds9a.nl> <20051024163320.C39AE11425@sa.vix.com> <76AFC476D1D6F7CCAB8BDC4F@[192.168.100.25]> <20051024172044.AE8E511425@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-26--594697273" Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Oct 24 22:12:54 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 In-Reply-To: <20051024172044.AE8E511425@sa.vix.com> To: Paul Vixie X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-26--594697273 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Oct 24, 2005, at 19:20 , Paul Vixie wrote: > NSEC3 agents behind pre-NSEC3 middleboxes will have to make a third > query to fetch the NSEC3, based on bits they see in the zone apex > data, > Huh? How will these client know the QNAME, QTYPE, [QCLASS] at which to find that NSEC3 record??? Its worse than with DNSSECbis.. You will never know where to find a missing NSEC3 (I think). --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-26--594697273 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDXTystN/ca3YJIocRAvQdAKCdf8hBKhAIJQ4nDMfFQsts7ZategCg4Gau ITVyTL8dOsgzdb/TjoCLPXo= =y3Qg -----END PGP SIGNATURE----- --Apple-Mail-26--594697273-- -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Samuel Weiler Subject: Re: NSEC3 signalling mechanism Date: Tue, 25 Oct 2005 14:34:13 -0400 (EDT) Lines: 34 References: <430082DB.7090901@algroup.co.uk> <434ECAB8.8030600@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Oct 25 20:52:16 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-X-Sender: weiler@filbert To: Ben Laurie In-Reply-To: <434ECAB8.8030600@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 13 Oct 2005, Ben Laurie wrote: > ... all I can work out from it is > concerns that if you don't understand NSEC3 you can't work properly in > an NSEC3 world. This is not surprising. If "can't work properly" means "you (the NSEC-classic-only resolver) see NSEC3 zones as Insecure", that's fine. That's a tolerable form of "can't work properly". Without a signaling mechanism, I think we instead have "you see negative answers from NSEC3s zone as Bogus (when you have a secure entry point into that zone, perhaps as a DS record in an NSEC-classic parent)". That's a form of "can't work properly" that I see as dangerous. Assuming the root were signed with NSEC-classic and you sign your TLD with NSEC3 -- if you have the root publish a DS for your zone, BIND 9.3-era resolvers (and perhaps later) may see your zone's negative answers as bogus, and not through any fault of their own. Do you really want to sign your TLD with NSEC3 under those circumstances? > If you want comment on a concrete proposal, then propose one. I did. See: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01087.html -- 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 Dec 29 11:36:43 2006 From: Simon Josefsson Subject: Re: NSEC3 signalling mechanism Date: Wed, 26 Oct 2005 10:18:54 +0200 Lines: 43 References: <430082DB.7090901@algroup.co.uk> <434ECAB8.8030600@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org, Ben Laurie X-From: owner-namedroppers@ops.ietf.org Wed Oct 26 10:29:32 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 To: Samuel Weiler OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051026:weiler@tislabs.com::QnxwpmE8uQo0Y76j:3uF4 X-Hashcash: 1:21:051026:ben@algroup.co.uk::45GlUmSs7MAF2EHW:pA1 X-Hashcash: 1:21:051026:namedroppers@ops.ietf.org::B4NeFYSz+sZLcYVa:AYDO In-Reply-To: (Samuel Weiler's message of "Tue, 25 Oct 2005 14:34:13 -0400 (EDT)") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Samuel Weiler writes: > On Thu, 13 Oct 2005, Ben Laurie wrote: > >> ... all I can work out from it is >> concerns that if you don't understand NSEC3 you can't work properly in >> an NSEC3 world. This is not surprising. > > If "can't work properly" means "you (the NSEC-classic-only resolver) > see NSEC3 zones as Insecure", that's fine. That's a tolerable form of > "can't work properly". > > Without a signaling mechanism, I think we instead have "you see > negative answers from NSEC3s zone as Bogus (when you have a secure > entry point into that zone, perhaps as a DS record in an NSEC-classic > parent)". That's a form of "can't work properly" that I see as > dangerous. > > Assuming the root were signed with NSEC-classic and you sign your TLD > with NSEC3 -- if you have the root publish a DS for your zone, BIND > 9.3-era resolvers (and perhaps later) may see your zone's negative > answers as bogus, and not through any fault of their own. Do you > really want to sign your TLD with NSEC3 under those circumstances? One option is to have one NSEC record to deny everything in the zone, just so that legacy resolvers can accept the data. Attackers can deny everything in the zone, but I believe that would be an acceptable risk given the circumstances. On the other hand, I seriously doubt that the deployed base of application that require DNSSECbis is large enough so that this is a practical problem. If you switch to pure-NSEC3 and forget about NSEC users, these users will realize they bought a poor solution and switch. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: bert hubert Subject: Re: NSEC3 signalling mechanism Date: Wed, 26 Oct 2005 10:47:38 +0200 Lines: 17 References: <430082DB.7090901@algroup.co.uk> <434ECAB8.8030600@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Samuel Weiler , namedroppers@ops.ietf.org, Ben Laurie X-From: owner-namedroppers@ops.ietf.org Wed Oct 26 10:55:18 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Simon Josefsson Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Oct 26, 2005 at 10:18:54AM +0200, Simon Josefsson wrote: > practical problem. If you switch to pure-NSEC3 and forget about NSEC > users, these users will realize they bought a poor solution and > switch. No, they will realise that the adage that DNSSEC is perpetually "ready 6 months from now" is as true as ever. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Ben Laurie Subject: Re: NSEC3 signalling mechanism Date: Wed, 26 Oct 2005 12:08:18 +0100 Lines: 57 References: <430082DB.7090901@algroup.co.uk> <434ECAB8.8030600@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Oct 26 13:15:07 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Thunderbird 1.4.1 (Windows/20051006) To: Samuel Weiler In-Reply-To: X-Enigmail-Version: 0.93.0.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Samuel Weiler wrote: > On Thu, 13 Oct 2005, Ben Laurie wrote: > >> ... all I can work out from it is >> concerns that if you don't understand NSEC3 you can't work properly in >> an NSEC3 world. This is not surprising. > > If "can't work properly" means "you (the NSEC-classic-only resolver) > see NSEC3 zones as Insecure", that's fine. That's a tolerable form of > "can't work properly". > > Without a signaling mechanism, I think we instead have "you see > negative answers from NSEC3s zone as Bogus (when you have a secure > entry point into that zone, perhaps as a DS record in an NSEC-classic > parent)". That's a form of "can't work properly" that I see as > dangerous. Why? Anyone who cares can investigate, observe that in fact the problem is that they are getting NSEC3 records and their resolver doesn't understand them, and fix the resolver. > Assuming the root were signed with NSEC-classic and you sign your TLD > with NSEC3 -- if you have the root publish a DS for your zone, BIND > 9.3-era resolvers (and perhaps later) may see your zone's negative > answers as bogus, and not through any fault of their own. Do you > really want to sign your TLD with NSEC3 under those circumstances? It doesn't sound like a massive risk to me. >> If you want comment on a concrete proposal, then propose one. > > I did. See: > http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01087.html OK. If the WG decides that signalling is necessary then either of these proposals works for me. Perhaps the productive thing to do at this stage is to figure out whether we think signalling is needed or whether the fact that DNSSEC has such limited deployment means we can forget about it this time (despite the theoretical need for it)? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Peter Koch Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Wed, 26 Oct 2005 16:41:59 +0200 Lines: 48 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Wed Oct 26 16:56:12 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Mon, 24 Oct 2005 16:56:43 +0200." Content-ID: <6179.1130229181.1@tyrannia.TechFak.Uni-Bielefeld.DE> X-PGP-Fingerprint: 85 89 64 AD 73 79 92 1F C8 76 95 2D 15 09 19 93 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends wrote: > Is there any specific section in rfc4033/4/5 that restricts using DNSSEC > to prove absence/presence of records with extended label types in its > ownername ? No, the DNSSEC-bis set of document simply doesn't cover non-standard labels. This makes them "unsortable" and thus they are not covered by NSEC RRs. Presence of RRSets with such labels is no problem at all. > Your point was: > > ''this could also elegantly solve the "paradox problem", where the NSEC3 > chain denies its owners' existance.'' > > Where ''this'' refered to using an extended label type for 8 bit labels. Exactly. There were two previous approaches to this anomaly: 1) Declare the owners of NSEC to be outside the namespace - by definition. This is straightforward, but has the drawback that the property of the name is determined by its ownership of a special RR type. 2) IIRC marka once suggested to use the hash only as an ownername (without appending $ORIGIN). Solves the length issue, uses a different namespace but more or less changes the paradigm from data based to transaction based. A new label type makes the owner of an NSEC3 RR be outside the classic namespace while still being adata based approach. > Indeed. One would need to define sort-order for 8 bit labels for the > purpose of dnssec. No, why? > I don't think the 'paradox problem' is a real issue. It is an anomaly. I do not know whether it will turn out to be an issue. -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 Fri Dec 29 11:36:43 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec3-03.txt Date: Wed, 26 Oct 2005 10:50:01 -0400 Lines: 91 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Oct 26 17:03:30 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 To: i-d-announce@ietf.org 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 : DNSSEC Hash Authenticated Denial of Existence Author(s) : B. Laurie, et al. Filename : draft-ietf-dnsext-nsec3-03.txt Pages : 40 Date : 2005-10-26 The DNS Security Extensions introduces the NSEC resource record for authenticated denial of existence. This document introduces a new resource record as an alternative to NSEC that provides measures against zone enumeration and allows for gradual expansion of delegation-centric zones. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec3-03.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-nsec3-03.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-nsec3-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-26102803.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec3-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec3-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26102803.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 Dec 29 11:36:43 2006 From: Matt Larson Subject: Re: NSEC3 signalling mechanism Date: Wed, 26 Oct 2005 11:14:20 -0400 Lines: 27 References: <430082DB.7090901@algroup.co.uk> <434ECAB8.8030600@algroup.co.uk> <435F63A2.30205@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Samuel Weiler , namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Oct 26 17:24:26 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 To: Ben Laurie Content-Disposition: inline In-Reply-To: <435F63A2.30205@algroup.co.uk> User-Agent: Mutt/1.5.11 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 26 Oct 2005, Ben Laurie wrote: > Perhaps the productive thing to do at this stage is to figure out > whether we think signalling is needed or whether the fact that DNSSEC > has such limited deployment means we can forget about it this time > (despite the theoretical need for it)? Another factor to consider in making this determination is the unlikelihood that .com and .net will be signed using NSEC. VeriSign is quite interested in NSEC3, especially its authoritative-only feature. Dave Blacka has implemented NSEC3 in his authoritative server, which we will test in the NSEC3 workshop that Olaf is arranging. We are focusing our efforts on kicking the tires of NSEC3. Multiple parties have expressed interest in the features it provides, so we think it's important that the working group keep NSEC3 moving along. Matt -- Matt Larson VeriSign Naming and Directory Services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: David Blacka Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Wed, 26 Oct 2005 11:25:51 -0400 Lines: 87 References: <200510261441.j9QEfxr21556@tyrannia.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Oct 26 17:35:54 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 In-Reply-To: <200510261441.j9QEfxr21556@tyrannia.TechFak.Uni-Bielefeld.DE> To: Peter Koch X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Oct 26, 2005, at 10:41 AM, Peter Koch wrote: > > > Roy Arends wrote: > > >> Is there any specific section in rfc4033/4/5 that restricts using >> DNSSEC >> to prove absence/presence of records with extended label types in its >> ownername ? >> > > No, the DNSSEC-bis set of document simply doesn't cover non- > standard labels. > This makes them "unsortable" and thus they are not covered by NSEC > RRs. > Presence of RRSets with such labels is no problem at all. Um, just because RFCs 4033-4035 don't cover non-standard labels doesn't make them problem-free wrt DNSSEC. > >> Your point was: >> >> ''this could also elegantly solve the "paradox problem", where the >> NSEC3 >> chain denies its owners' existance.'' >> >> Where ''this'' refered to using an extended label type for 8 bit >> labels. >> > > Exactly. There were two previous approaches to this anomaly: > > 1) Declare the owners of NSEC to be outside the namespace - by > definition. > This is straightforward, but has the drawback that the property > of the > name is determined by its ownership of a special RR type. > > 2) IIRC marka once suggested to use the hash only as an ownername > (without > appending $ORIGIN). Solves the length issue, uses a different > namespace > but more or less changes the paradigm from data based to > transaction based. > > A new label type makes the owner of an NSEC3 RR be outside the classic > namespace while still being adata based approach. IF this paradox problem is in fact a problem, there is an easier solution than #2. > >> Indeed. One would need to define sort-order for 8 bit labels for the >> purpose of dnssec. >> > > No, why? So that any other RR type using the extended label would be coverable by DNSSEC. Or are you suggesting that an extended label type be dedicated to NSEC3? > >> I don't think the 'paradox problem' is a real issue. >> > > It is an anomaly. I do not know whether it will turn out to be an > issue. Me neither. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Paul Vixie Subject: Re: NSEC3 signalling mechanism Date: Wed, 26 Oct 2005 15:26:15 +0000 Lines: 17 References: <430082DB.7090901@algroup.co.uk> <434ECAB8.8030600@algroup.co.uk> <435F63A2.30205@algroup.co.uk> Cc: Samuel Weiler , namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Oct 26 17:37:17 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Ben Laurie In-Reply-To: Your message of "Wed, 26 Oct 2005 12:08:18 +0100." <435F63A2.30205@algroup.co.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # > Without a signaling mechanism, I think we instead have "you see negative # > answers from NSEC3s zone as Bogus (when you have a secure entry point into # > that zone, perhaps as a DS record in an NSEC-classic parent)". That's a # > form of "can't work properly" that I see as dangerous. # # Why? Anyone who cares can investigate, observe that in fact the problem is # that they are getting NSEC3 records and their resolver doesn't understand # them, and fix the resolver. i don't think that a failure mode this unpleasant should be the result of not caring enough to investigate. -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:43 2006 From: Simon Josefsson Subject: Re: NSEC3 signalling mechanism Date: Wed, 26 Oct 2005 18:28:41 +0200 Lines: 26 References: <430082DB.7090901@algroup.co.uk> <434ECAB8.8030600@algroup.co.uk> <435F63A2.30205@algroup.co.uk> <20051026152615.E611211426@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Samuel Weiler , namedroppers@ops.ietf.org, Ben Laurie X-From: owner-namedroppers@ops.ietf.org Wed Oct 26 18:40:26 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 To: Paul Vixie OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051026:weiler@tislabs.com::zOoM517bHl+EUciz:oGT X-Hashcash: 1:21:051026:namedroppers@ops.ietf.org::2tMmSy97IKLkUQn+:0zw8 X-Hashcash: 1:21:051026:paul@vix.com::/zl06oTsvMIPW+Fq:Bzx5 X-Hashcash: 1:21:051026:ben@algroup.co.uk::FCFgilhLpW7UDY+v:9048 In-Reply-To: <20051026152615.E611211426@sa.vix.com> (Paul Vixie's message of "Wed, 26 Oct 2005 15:26:15 +0000") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: > # > Without a signaling mechanism, I think we instead have "you see negative > # > answers from NSEC3s zone as Bogus (when you have a secure entry point into > # > that zone, perhaps as a DS record in an NSEC-classic parent)". That's a > # > form of "can't work properly" that I see as dangerous. > # > # Why? Anyone who cares can investigate, observe that in fact the problem is > # that they are getting NSEC3 records and their resolver doesn't understand > # them, and fix the resolver. > > i don't think that a failure mode this unpleasant should be the result of > not caring enough to investigate. There are no non-experimental DS delegations in live zone's today, as far as I know. So I believe a flag day would be fine, since there are no real users that would be harmed by that. Cheers, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Peter Koch Subject: Re: base32 alphabet rant - rhaaaaa rfc3548 Date: Wed, 26 Oct 2005 21:29:35 +0200 Lines: 20 References: <200510261441.j9QEfxr21556@tyrannia.TechFak.Uni-Bielefeld.DE> <640B4E6D-C545-4E39-A511-F80492B58AAD@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Wed Oct 26 21:46:25 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 To: IETF DNSEXT WG Content-Disposition: inline In-Reply-To: <640B4E6D-C545-4E39-A511-F80492B58AAD@verisignlabs.com> User-Agent: Mutt/1.4i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David Blacka wrote: > So that any other RR type using the extended label would be coverable > by DNSSEC. Or are you suggesting that an extended label type be > dedicated to NSEC3? "dedicated" in the sense that this label type would primarily satisfy the needs of NSEC3 -- yes. "dedicated" in the sense that other RR type MUST NOT be owned by an owner with such label -- no. Anyone brave enough to do so would have to know and accept that in this part of the name space there is no authenticated denial. -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 i-d-announce-bounces@ietf.org Fri Dec 29 11:36:43 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-tsig-sha-05.txt Date: Wed, 26 Oct 2005 15:50:02 -0400 Lines: 98 Reply-To: internet-drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: i-d-announce-bounces@ietf.org Wed Oct 26 22:01:06 2005 Return-path: To: i-d-announce@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org --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 : HMAC SHA TSIG Algorithm Identifiers Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-tsig-sha-05.txt Pages : 10 Date : 2005-10-26 Use of the TSIG DNS resource record requires specification of a cryptographic message authentication code. Currently identifiers have been specified only for the HMAC-MD5 and GSS TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-sha-05.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-tsig-sha-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-tsig-sha-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: <2005-10-26112929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-tsig-sha-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-tsig-sha-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26112929.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-08.txt Date: Wed, 26 Oct 2005 15:50:03 -0400 Lines: 92 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Oct 26 22:01:27 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 To: i-d-announce@ietf.org 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 : DNSSEC Opt-In Author(s) : D. Blacka, et al. Filename : draft-ietf-dnsext-dnssec-opt-in-08.txt Pages : 17 Date : 2005-10-26 In the DNS security extensions (DNSSEC, defined in RFC 4033 [3], RFC 4034 [4], and RFC 4035 [5]), delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not practical or necessary. This document describes an experimental "Opt-In" model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-opt-in-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-opt-in-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-26120148.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-opt-in-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-opt-in-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26120148.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 Dec 29 11:36:43 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-ecc-key-08.txt Date: Wed, 26 Oct 2005 15:50:02 -0400 Lines: 90 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Oct 26 22:01:39 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 To: i-d-announce@ietf.org 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 and Signatures in the DNS Author(s) : R. Schroeppel, D. Eastlake Filename : draft-ietf-dnsext-ecc-key-08.txt Pages : 16 Date : 2005-10-26 The standard method for storing elliptic curve cryptographic keys and elliptic curve SHA-1 based signatures in the Domain Name System is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-08.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-ecc-key-08.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-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-26112409.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ecc-key-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ecc-key-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26112409.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 Dec 29 11:36:43 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-signed-nonexistence-requirements-02.txt Date: Wed, 26 Oct 2005 15:50:03 -0400 Lines: 93 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Oct 26 22:01:40 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 To: i-d-announce@ietf.org 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 : Requirements related to DNSSEC Signed Proof of Non-Existence Author(s) : R. Loomis, B. Laurie Filename : draft-ietf-dnsext-signed-nonexistence-requirements-02.txt Pages : 15 Date : 2005-10-26 DNSSEC-bis uses the NSEC record to provide authenticated denial of existence of RRsets. NSEC also has the side-effect of permitting zone enumeration, even if zone transfers have been forbidden. Because some see this as a problem, this document has been assembled to detail the possible requirements for denial of existence A/K/A signed proof of non-existence. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signed-nonexistence-requirements-02.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-signed-nonexistence-requirements-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-signed-nonexistence-requirements-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: <2005-10-26151316.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-signed-nonexistence-requirements-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-signed-nonexistence-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26151316.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 Dec 29 11:36:43 2006 From: Ben Laurie Subject: Re: NSEC3 signalling mechanism Date: Wed, 26 Oct 2005 22:02:18 +0100 Lines: 27 References: <430082DB.7090901@algroup.co.uk> <434ECAB8.8030600@algroup.co.uk> <435F63A2.30205@algroup.co.uk> <20051026152615.E611211426@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Samuel Weiler , namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Oct 26 23:11:55 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Thunderbird 1.4.1 (Windows/20051006) To: Paul Vixie In-Reply-To: <20051026152615.E611211426@sa.vix.com> X-Enigmail-Version: 0.93.0.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie wrote: > # > Without a signaling mechanism, I think we instead have "you see negative > # > answers from NSEC3s zone as Bogus (when you have a secure entry point into > # > that zone, perhaps as a DS record in an NSEC-classic parent)". That's a > # > form of "can't work properly" that I see as dangerous. > # > # Why? Anyone who cares can investigate, observe that in fact the problem is > # that they are getting NSEC3 records and their resolver doesn't understand > # them, and fix the resolver. > > i don't think that a failure mode this unpleasant should be the result of > not caring enough to investigate. How unpleasant is it to get "bogus" for a domain that doesn't exist? As opposed to "I can't resolve anything securely in this domain", that is? -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: Samuel Weiler Subject: Re: DNSEXT Minutes @ IETF-63 Date: Wed, 26 Oct 2005 16:57:15 -0400 (EDT) Lines: 20 References: <6.2.3.4.2.20050901145800.04065900@localhost> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: quoted-printable Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Oct 26 23:35:29 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-X-Sender: weiler@filbert To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= In-Reply-To: <6.2.3.4.2.20050901145800.04065900@localhost> X-MIME-Autoconverted: from 8bit to quoted-printable by tislabs.com id j9QKvFS8015220 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 1 Sep 2005, [iso-8859-1] =D3lafur[iso-8859-1] Gu=F0mundsson wrot= e: > There was some further discussion if NSEC3 and OPT-IN are separative > and/or required. Chair made the comment that if Opt-In feature is > removed from NSEC3 then that requires changing the name to NSEC4. I didn't catch this assertion at the time. I don't understand why the chair thinks a name change would be required nor why the name "NSEC4" would be required. Is this just an error in the minutes? -- 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 Dec 29 11:36:43 2006 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: NSEC++ (Was: Re: DNSEXT Minutes @ IETF-63) Date: Wed, 26 Oct 2005 22:30:30 -0400 Lines: 34 References: <6.2.3.4.2.20050901145800.04065900@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 27 04:39:09 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 To: Samuel Weiler , =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= In-Reply-To: References: <6.2.3.4.2.20050901145800.04065900@localhost> X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:57 26/10/2005, Samuel Weiler wrote: >On Thu, 1 Sep 2005, [iso-8859-1] =D3lafur[iso-8859-1] Gu=F0mundsson wrote: > > > There was some further discussion if NSEC3 and OPT-IN are separative > > and/or required. Chair made the comment that if Opt-In feature is > > removed from NSEC3 then that requires changing the name to NSEC4. > >I didn't catch this assertion at the time. I don't understand why the >chair thinks a name change would be required nor why the name "NSEC4" >would be required. > >Is this just an error in the minutes? This is correct, each time a major change is made to the NSEC++ proposals we will roll the trailing number to allow identification of whole proposals. Removing Selective Security (i.e. Opt-in in marketing speak) is a qualifying major change. Similarly dropping the iteration field that some are uncomfortable with would also require a suffix change. The plan is that when the privacy enhanced NSEC (NSEC++ or NSECn) gets selected then we will select a new and better name before the RFC is issued. Right now we are (still) in the solution tuning space. 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 Fri Dec 29 11:36:43 2006 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Document Advancement: TSIG/SHA1 for DS Date: Wed, 26 Oct 2005 23:49:38 -0400 Lines: 87 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Olaf M. Kolkman" , Mark Townsley , ogud@ogud.com, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 27 05:58:47 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 To: Margaret Wasserman X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The DNSEXT working group is requesting publications of draft-ietf-dnsext-tsig-sha-05.txt as a Draft Standard. Review questions and answers: 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the IESG for publication? Yes and yes. 2) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Yes and no. 3) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? Not really, this document specifies a transaction signature, that uses SHA-1 and SHA-2 as a digest. 4) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or whether there really is a need for it, etc., but at the same time these issues have been discussed in the WG and the WG has indicated it wishes to advance the document anyway. No. 5) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document has been under development and review for about a year, there is strong consensus that this is a good thing to do and the specification has been implemented and tested. 6) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize what are they upset about. No. 7) Have the chairs verified that the document adheres to _all_ of the ID nits? (see http://www.ietf.org/ID-nits.html). Yes. 8) For Standards Track and BCP documents, the IESG approval announcement includes a writeup section with the following sections: - Technical Summary This document specifies an EXTENSION to the TSIG (Transaction SIGnature) mechanism in DNS. The extension adds more secure digest algorithm that are mandated. TSIG is used by DNS for authentication as well as authorization of dynamic updates, thus it is important to start the process to phase out MD5 which is the current digest algorithm. This specification allows truncation of digests and sets some basic rules to prevent excessive truncation. - Working Group Summary The DNSEXT WG has come to strong consensus in support of acceptance of this specification as an Internet Standard. - Protocol Quality As this is a simple expansion of an existing mechanism the specification is straight forward. Implementation experience has validated that this is an implement able specification. Olafur & Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:43 2006 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: IETF-64 DNSEXT Agenda Date: Thu, 27 Oct 2005 00:18:08 -0400 Lines: 145 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Thu Oct 27 06:25:07 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 To: namedroppers@ops.ietf.org X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk As we have now a new tool to post agenda's on-line in real time newer versions of this agenda may get posted at http://www3.ietf.org/proceedings/05nov/agenda/dnsext.html Olafur & Olaf WG: DNSEXT @ IETF-64 in Vancouver Date: 2005/11/07 Monday Time: 9;00 - 11:30 Location ?: Chairs: Olafur Gudmundsson ogud@ogud.com Olaf Kolkman olaf@ripe.net Version: 1.0 Agenda Bashing and appointment of scribes: Documents Status: Documents Advanced: LLMNR: in a limbo between IETF Last Call and nits http://ietf.org/internet-drafts/draft-ietf-dnsext-mdns-45.txt Case Insensitive: In RFC-editors queue http://ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-06.txt CERT RR: Still at IESG waiting for votes http://ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-09.txt TSIG-SHA: Advanced to IESG waiting for IETF Last call to start. http://ietf.org/internet-drafts/draft-ietf-dnsext-tsig-sha-05.txt DHCID Advanced to IESG waiting for IETF Last call to start. http://ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-09.txt Last call completed waiting for chair: Waiting for chairs to forward to AD http://ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-08.txt Drafts in last calls: Derivation of DNS Name Predecessor and Successor http://ietf.org/internet-drafts/draft-ietf-dnsext-dns-name-p-s-01.txt Minimally Covering NSEC Records and DNSSEC On-line Signing http://ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-online-signing-00.txt NSID Name Server Identifier Option http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsid-00.txt DSA Keying and Signature Information in the DNS http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-06.txt Storage of Diffie-Hellman Keying Information in the DNS http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-06.txt Drafts waiting for Last calls: Evaluating DNSSEC Transition Mechanisms http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-03.txt DNSSEC experiments http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-experiments-01.txt Elliptic Curve Keys in the DNS http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-08.txt Ongoing Clarifications and Implementation Notes for DNSSECbis http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-01 Domain Name System (DNS) IANA Considerations http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-01.txt Enhanced Privacy on Negative answers NSEC replacement Requirements http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signed-nonexistence-requirements-02.txt DNSSEC Hash Authenticated Denial of Existence http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec3-02.txt Automated DNSSEC Trust anchor management: Automated Updates of DNSSEC Trust Anchors: http://www.ietf.org/wg/internet-drafts/draft-ietf-dnsext-trustupdate-timers-01.txt An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for DNSSEC Trust Anchors. http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-trustupdate-threshold/draft-ietf-dnsext-trustupdate-threshold-00.txt Other Proposals: By Thierry Moreau two draft for one new proposal The Trust Anchor Key Renewal Method Applied to DNS Security http://www.ietf.org/internet-drafts/draft-moreau-dnsext-takrem-dns-00.txt The SEP DNSKEY Direct Authentication DNS Resource Record (SDDA-RR) http://www.ietf.org/internet-drafts/draft-moreau-dnsext-sdda-rr-00.txt By Ben Laurie Distributing Keys for DNSSEC http://www.links.org/dnssec/draft-laurie-dnssec-key-distribution-00.txt Other Draft discussion: DNS Start of Authority Discovery Mark Andrews http://www.ietf.org/internet-drafts/draft-ietf-andrews-soa-discover-00.txt Future and possible direction of the working group: Is it time to close down the working group? The productivity of the working group has declined, there are no major protocol issues pressing for attention. Most of the work in front of us is process related advancement and there seems to be limited interest in doing this work. Is there any need for this group? If the WG continues What should the WG be doing ? (new charter needed) What should the milestones be ? Interoperabilty testing reports: DNS Compliance testing report: Nobumichi Ozoe http://www.tahi.org/dns/ Drafts from other WG's requesting review: None at this point Wrap-up -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:44 2006 From: Samuel Weiler Subject: Re: DNSEXT WGLC: RFC2536bis and RFC2539bis Date: Thu, 27 Oct 2005 02:07:51 -0400 (EDT) Lines: 23 References: <6.2.3.4.2.20051017155946.03fbdd88@localhost> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 27 08:17:17 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-X-Sender: weiler@filbert To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair In-Reply-To: <6.2.3.4.2.20051017155946.03fbdd88@localhost> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This message starts a 2 week Working Group Last call ending on > November 1, for the two following documents: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-06.txt > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-06.txt I have not thoroughly reviewed either of these drafts, nor do I plan to do so in the immediate future. > The default action is to advance these documents, if you find any > issues with the documents please raise them now. I oppose this default and, in particular, I oppose publication of these two documents under this WG's name without a meaningful review. If the WG cannot find the resources to review these documents, then we should consider dropping them as WG work items. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:44 2006 From: Eastlake III Donald-LDE008 Subject: RE: I-D ACTION:draft-ietf-dnsext-tsig-sha-05.txt Date: Thu, 27 Oct 2005 08:25:48 -0400 Lines: 68 Mime-Version: 1.0 Content-Type: text/plain X-From: owner-namedroppers@ops.ietf.org Thu Oct 27 14:38:17 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The only changes to this draft were boilerplate trivia to fix IDnits. Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, October 26, 2005 3:50 PM To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-tsig-sha-05.txt 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 : HMAC SHA TSIG Algorithm Identifiers Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-tsig-sha-05.txt Pages : 10 Date : 2005-10-26 Use of the TSIG DNS resource record requires specification of a cryptographic message authentication code. Currently identifiers have been specified only for the HMAC-MD5 and GSS TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-sha-05.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-tsig-sha-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-tsig-sha-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. -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:44 2006 From: Eastlake III Donald-LDE008 Subject: RE: I-D ACTION:draft-ietf-dnsext-ecc-key-08.txt Date: Thu, 27 Oct 2005 08:28:00 -0400 Lines: 65 Mime-Version: 1.0 Content-Type: text/plain X-From: owner-namedroppers@ops.ietf.org Thu Oct 27 14:38:28 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The only changes in this draft were to make the fact that it covers signatures based on SHA-1 clearer and to add a reference for SHA-1. Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, October 26, 2005 3:50 PM To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-ecc-key-08.txt 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 and Signatures in the DNS Author(s) : R. Schroeppel, D. Eastlake Filename : draft-ietf-dnsext-ecc-key-08.txt Pages : 16 Date : 2005-10-26 The standard method for storing elliptic curve cryptographic keys and elliptic curve SHA-1 based signatures in the Domain Name System is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-08.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-ecc-key-08.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-08.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. -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:44 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-trans-03.txt Date: Thu, 27 Oct 2005 10:50:01 -0400 Lines: 90 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 27 17:02:37 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 To: i-d-announce@ietf.org 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 : Evaluating DNSSEC Transition Mechanisms Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-trans-03.txt Pages : 16 Date : 2005-10-27 This document collects and summarizes different proposals for alternative and additional strategies for authenticated denial in DNS responses, evaluates these proposals and gives a recommendation for a way forward. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-trans-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-trans-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-27081954.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-trans-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-trans-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-27081954.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 Dec 29 11:36:44 2006 From: Peter Koch Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-trans-03.txt Date: Thu, 27 Oct 2005 17:14:39 +0200 Lines: 25 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Thu Oct 27 17:24:33 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Message of "Thu, 27 Oct 2005 10:50:01 EDT." Content-ID: <4175.1130426072.1@tyrannia.TechFak.Uni-Bielefeld.DE> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This draft is a work item of the DNS Extensions Working Group of the IETF. > > Title : Evaluating DNSSEC Transition Mechanisms > Author(s) : R. Arends, et al. > Filename : draft-ietf-dnsext-dnssec-trans-03.txt Changes from -02: o Dropped empty section 2.1.8 o Changed 2.2.3 "Unknown Algorithm in RRSIG" to 2.2.3. "Unknown (New) Algorithm in DS, DNSKEY, and RRSIG" based on comments received from Sam o Added 2.2.4. "Unknown (New) Hash Algorithm in DS" per Sam's suggestion o Fixed references, new boilerplate This was the "other round" mentioned in the Paris meeting minutes -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 Fri Dec 29 11:36:44 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-trustupdate-threshold-01.txt Date: Thu, 27 Oct 2005 15:50:03 -0400 Lines: 99 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Oct 27 22:04:11 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 To: i-d-announce@ietf.org 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 : An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for DNSSEC Trust Anchors Author(s) : J. Ihren, et al. Filename : draft-ietf-dnsext-trustupdate-threshold-01.txt Pages : 24 Date : 2005-10-27 The DNS Security Extensions (DNSSEC) works by validating so called chains of authority. The start of these chains of authority are usually public keys that are anchored in the DNS clients. These keys are known as the so called trust anchors. This memo describes a method how these client trust anchors can be replaced using the DNS validation and querying mechanisms (in-band) when the key pairs used for signing by zone owner are rolled. This memo also describes a method to establish the validity of trust anchors for initial configuration, or priming, using out of band mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-trustupdate-threshold-01.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-trustupdate-threshold-01.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-trustupdate-threshold-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-27125644.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-trustupdate-threshold-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-trustupdate-threshold-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-27125644.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 Dec 29 11:36:44 2006 From: Mark Andrews Subject: Re: IETF-64 DNSEXT Agenda Date: Fri, 28 Oct 2005 14:09:27 +1000 Lines: 13 References: <6.2.5.6.2.20051027001221.03f0a480@ogud.com> X-From: owner-namedroppers@ops.ietf.org Fri Oct 28 06:22:52 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: namedroppers@ops.ietf.org In-reply-to: Your message of "Thu, 27 Oct 2005 00:18:08 -0400." <6.2.5.6.2.20051027001221.03f0a480@ogud.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Other Draft discussion: > DNS Start of Authority Discovery > Mark Andrews > http://www.ietf.org/internet-drafts/draft-ietf-andrews-soa-discover-00.t > xt http://www.ietf.org/internet-drafts/draft-andrews-dnsext-soa-discovery-00.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:44 2006 From: David Blacka Subject: NSEC3 pilot Date: Fri, 28 Oct 2005 12:16:18 -0400 Lines: 81 Mime-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="=_cliffie-1308-1130516179-0001-2" X-From: owner-namedroppers@ops.ietf.org Fri Oct 28 18:27:15 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.1.0 X-Gpgmail-State: !signed To: DNSEXT WG X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_cliffie-1308-1130516179-0001-2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed This is just a quick note to announce the availability of our NSEC3 pilot: http://nsec3.verisignlabs.com/ The pilot provides a NSEC3-, opt-in signed version of .com and .net, as well as a mechanism for adding DS records to the pilot. The pilot attempts to adhere (currently) to the -03 version of the NSEC3 document. Send any questions about the pilot to me, or subscribe and post to the dnssec@verisignlabs.com mailing list. -- David Blacka Sr. Engineer VeriSign Applied Research --=_cliffie-1308-1130516179-0001-2 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFnjCCAlcw ggHAoAMCAQICAw+nGDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUxMDEzMTQzNjA4WhcNMDYxMDEzMTQzNjA4WjBJMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSYwJAYJKoZIhvcNAQkBFhdkYXZpZGJAdmVyaXNpZ25s YWJzLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyzP1izF46evByd+R5GlKx4j2Eo6a Z1xXLc/JhxagaNuUujieUyiHCHikbf8PF/tf2Z9GfIDe1ygCZTQfqRCFbb/vwt66KwGHtYH0yi+l mFx3ojdO8Xtnig4jK9KjkbuAbzz4ITZI/b3O1XW0suKWFAtqT9mA8DvDEAblRTFA09ECAwEAAaM0 MDIwIgYDVR0RBBswGYEXZGF2aWRiQHZlcmlzaWdubGFicy5jb20wDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQAm67tKl2ra+HsW023l6DNHq15uOgueAtSRx2PQD8hubg8BKMA8l56vN8KN iWExdIsi9+nlYVO5hV9A32EVu5CLpHx2+I83dylZY7f4aBSRbsCDAvSAD9WEfVOyNMG02Wi9X+gb 2LFgn6Lcj2NSFvPqdieL8CJ68AGf9D6hELF5rTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEF BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAw MDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r 1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPq Cy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx 0x1G/11fZU8xggJmMIICYgIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIDD6cYMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MTAyODE2MTYxOVowIwYJKoZIhvcNAQkEMRYEFFfozwfEn0X0Vfe3V9uf W36lSCmUMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPpxgwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDD6cYMA0GCSqGSIb3DQEBAQUABIGAdmnuL3/88NrIcKNxfo/B Pr0yyb7Vz1hHao4Z2C0kv1/Q7x+EUG3ipFkkqeh5bBRRj4OHM66hRp4DRpX4un7s9P7Q/gsyvYet p0+k2FOSjicWsaUEBxgtEb+16ZKMdH8ie+NzLD0Cr/MIthOSuDQNj5a2q+x1GKCpOHSX5SM2hsIA AAAAAAA= --=_cliffie-1308-1130516179-0001-2-- -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:44 2006 From: Peter Koch Subject: Re: WGLC: Name Server Identifier Option Date: Fri, 28 Oct 2005 18:17:19 +0200 Lines: 41 References: <20051011190314.629FE41A7@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Fri Oct 28 18:27:16 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Tue, 11 Oct 2005 15:03:14 EDT." <20051011190314.629FE41A7@thrintun.hactrn.net> Content-ID: <17037.1130516235.1@tyrannia.TechFak.Uni-Bielefeld.DE> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Rob Austein wrote: > > balancer and there might be other reasons. The person debugging > > then can't even tell whether subsequent responses originate from > > the same server, but it could hand over the info received to the > > server admin for further inspection. > > Thought I'd covered this: > > o It could be some sort of dynamicly generated identifier so that > only the name server operator could tell whether or not any two > queries had been answered by the same server. yes, indeed. Please accept my apology. > If the WG would prefer that we just use an empty NSID option rather > than the SI flag bit, that's a simple change. Good. > Absent a specification for what non-empty NSID payload from client to > server would mean, I think it should be empty (name server MUST ignore > NSID payload, client MUST NOT/SHOULD NOT send NSID payload). If and Agreed. "MUST ignore" is future safe (forward compatible) on the server side. > My main concerns at this point are: (a) that this specification be > complete rather than making forward references to specifications that > might never be written, and (b) that we finish this promptly, per the > discussion in Paris. Same here. My suggestion was not meant as a preparation of client side ID. Whether or not this option can be reused I don't care for now. -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 Fri Dec 29 11:36:44 2006 From: "Olaf M. Kolkman" Subject: Re: NSEC3 signalling mechanism Date: Fri, 28 Oct 2005 10:25:58 -0700 Lines: 71 References: <430082DB.7090901@algroup.co.uk> <434ECAB8.8030600@algroup.co.uk> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-10--258180420" Content-Transfer-Encoding: 7bit Cc: Namedroppers X-From: owner-namedroppers@ops.ietf.org Fri Oct 28 19:35:47 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 In-Reply-To: To: Simon Josefsson X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-10--258180420 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Oct 26, 2005, at 01:18 , Simon Josefsson wrote: > One option is to have one NSEC record to deny everything in the zone, > just so that legacy resolvers can accept the data. Attackers can deny > everything in the zone, but I believe that would be an acceptable risk > given the circumstances. It is hard to assess 'acceptable risk' but I would rather keep the property that data modification leads to "BOGUS" results instead. It feels bad to change the security properties of DNSSECbis to get NSEC3 deployed. Personally I would like to keep backwards compatibility. I do not agree with the notion that people wo deploy DNSSEC bis bought a poor solution. There is real DNSSEC deployment happening --- on a small scale, I agree. Lets not dismiss those initiatives and demotivate early deployment by forcing a flag date. I would have to check the archives but I think that at the time we forwarded DNSSECbis we decided that privacy protection could be added while maintaining backwards compatibility. The work on the particular mechanism is still in progress. --Olaf namedropper, not wearing hats. ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-10--258180420 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDYl8mtN/ca3YJIocRAtCGAJ9WbFx2gUaInJtAmipnjIGod059ggCgwEs2 QXD53RJ7AVgh4cp0Sn8681w= =DJg+ -----END PGP SIGNATURE----- --Apple-Mail-10--258180420-- -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:44 2006 From: Samuel Weiler Subject: NSEC3 design FAQ Date: Fri, 28 Oct 2005 14:08:59 -0400 (EDT) Lines: 65 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Fri Oct 28 20:16:57 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-X-Sender: weiler@filbert To: Namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I've collected some of the questions I've gotten about the design of NSEC3. Here they are along with my own answers. It's clear that others have different perspectives, particularly about the need for signaling -- again, these are MY answers. Hopefully they'll be useful to others. Q: Why can't the hash string for an NSEC3 RR go in its RDATA instead of the owner name? A: It can, so long as two hashes appear in the RDATA. For more details, see http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00683.html Q: But why won't a single hash work? A: Two reasons. The first: so long as the owner name of the NSEC3 RR's includes a real name, the zone can be walked. (This is true so long as the owner name of the NSEC is obviously related to the QNAME (e.g. the closest preceding existing name) -- having a real owner name appear that is unrelated to the QNAME might work, but hasn't been explored much.) The second: NSEC proofs wouldn't work. NSEC (and NSEC3) proofs both rely on the NSEC/NSEC3 specifying a range of names (or a range of hashes) between which there are no records (or no records other than delegations, for the 'delegation-only' or 'opt-in' variations). NSEC specifies a range of real names. NSEC3 specifies a range of hashes. Specifying one real name and one hash does not specify a range, so a validator can't check whether a QNAME is covered by such a record, hence whether or not the proof is valid. Q: Why do we have to mark a zone as using NSEC3? A: What happens if a legacy (NSEC-only) resolver attempts to validate an NSEC3-only zone without having been told that this is an NSEC3-only zone? Any answer requiring an nonexistence proof (NXDOMAIN, name errors, wildcard synthesis, unsecure delegations) will lack the requisite NSEC RR's, hence result in a validation failure. This would provide a tremendous incentive to not sign zones with NSEC3 -- doing so would generate these spurious validation failures. Instead, we need to somehow make the legacy resolvers think that the new zone is unsecure. Q: But why can't we just add a new RR type at the zone apex to signal the use of NSEC3? A: A legacy (NSEC-only) resolver won't know to check for that RR. Absent some other signaling mechanism that it understands, it will expect the zone to be secured and provide NSEC RR's as needed. When the zone doesn't do that, all answers requiring a nonexistence proof will be treated as Bogus. -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:44 2006 From: Thierry Moreau Subject: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM Date: Fri, 28 Oct 2005 18:10:44 -0400 Lines: 38 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri Oct 28 23:46:35 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Namedroppers , dnssec-deployment@shinkuro.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dear all: We are pleased to announce the release some software tools for DNSSEC Trust Anchor Key rollover. You may download from http://www.connotech.com/takrem_tools/trust-anchor-foundry_01.tar.gz This is a first step towards facilitating TAKREM deployment a practical solution for DNSSEC automated trust anchor key rollover (draft draft-moreau-dnsext-takrem-dns-00.txt). The emphasis has been put on documenting the software design issues and providing a workable software base (GPL'ed free software). Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:44 2006 From: Paul Vixie Subject: Re: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM Date: Sat, 29 Oct 2005 05:26:02 +0000 Lines: 7 References: <4362A1E4.40505@connotech.com> Cc: Namedroppers , dnssec-deployment@shinkuro.com X-From: owner-namedroppers@ops.ietf.org Sat Oct 29 07:35:39 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Thierry Moreau In-Reply-To: Your message of "Fri, 28 Oct 2005 18:10:44 -0400." <4362A1E4.40505@connotech.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk isn't TAKREM based on patent-protected IPR? -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:44 2006 From: "william(at)elan.net" Subject: Re: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM Date: Fri, 28 Oct 2005 23:18:23 -0700 (PDT) Lines: 16 References: <4362A1E4.40505@connotech.com> <20051029052602.36B8E11459@sa.vix.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Thierry Moreau , Namedroppers , dnssec-deployment@shinkuro.com X-From: owner-namedroppers@ops.ietf.org Sat Oct 29 08:24:27 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs To: Paul Vixie In-Reply-To: <20051029052602.36B8E11459@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, 29 Oct 2005, Paul Vixie wrote: > isn't TAKREM based on patent-protected IPR? https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=640 -- William Leibzon Elan Networks william@elan.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:44 2006 From: Ben Laurie Subject: Re: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM Date: Sat, 29 Oct 2005 14:06:23 +0100 Lines: 16 References: <4362A1E4.40505@connotech.com> <20051029052602.36B8E11459@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thierry Moreau , Namedroppers , dnssec-deployment@shinkuro.com X-From: owner-namedroppers@ops.ietf.org Sat Oct 29 15:15:01 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Thunderbird 1.4.1 (Windows/20051006) To: Paul Vixie In-Reply-To: <20051029052602.36B8E11459@sa.vix.com> X-Enigmail-Version: 0.93.0.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie wrote: > isn't TAKREM based on patent-protected IPR? That is my understanding. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:44 2006 From: Paul Vixie Subject: Re: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM Date: Sat, 29 Oct 2005 14:54:59 +0000 Lines: 28 References: <4362A1E4.40505@connotech.com> <20051029052602.36B8E11459@sa.vix.com> X-From: owner-namedroppers@ops.ietf.org Sat Oct 29 17:02:34 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Namedroppers , dnssec-deployment@shinkuro.com In-Reply-To: Your message of "Fri, 28 Oct 2005 23:18:23 MST." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk to this: # > isn't TAKREM based on patent-protected IPR? i recieved two replies: # From: "william(at)elan.net" # # https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=640 and: # From: Ben Laurie # # That is my understanding. it is therefore my plan, and my recommendation to others, to ignore TAKREM, to not evaluate the specific proposal nor the tools, and to oppose its adoption as an Internet standard of any kind. it is my advice to Thierry Moreau that all work toward supporting DNSSEC with this technology be stopped. (note: i don't have any hats.) -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:44 2006 From: Ben Laurie Subject: Re: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM Date: Sat, 29 Oct 2005 18:29:59 +0100 Lines: 37 References: <4362A1E4.40505@connotech.com> <20051029052602.36B8E11459@sa.vix.com> <20051029145459.2F61711426@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Namedroppers , dnssec-deployment@shinkuro.com X-From: owner-namedroppers@ops.ietf.org Sat Oct 29 19:37:50 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Thunderbird 1.4.1 (Windows/20051006) To: Paul Vixie In-Reply-To: <20051029145459.2F61711426@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie wrote: > to this: > > # > isn't TAKREM based on patent-protected IPR? > > i recieved two replies: > > # From: "william(at)elan.net" > # > # https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=640 > > and: > > # From: Ben Laurie > # > # That is my understanding. > > it is therefore my plan, and my recommendation to others, to ignore TAKREM, to > not evaluate the specific proposal nor the tools, and to oppose its adoption > as an Internet standard of any kind. it is my advice to Thierry Moreau that > all work toward supporting DNSSEC with this technology be stopped. > > (note: i don't have any hats.) FWIW, I agree. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:44 2006 From: Matt Larson Subject: Re: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM Date: Sat, 29 Oct 2005 17:17:53 -0400 Lines: 29 References: <4362A1E4.40505@connotech.com> <20051029052602.36B8E11459@sa.vix.com> <20051029145459.2F61711426@sa.vix.com> <4363B197.30604@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sat Oct 29 23:26:07 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 To: Namedroppers , dnssec-deployment@shinkuro.com Content-Disposition: inline In-Reply-To: <4363B197.30604@algroup.co.uk> User-Agent: Mutt/1.5.6i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, 29 Oct 2005, Ben Laurie wrote: > Paul Vixie wrote: > > it is therefore my plan, and my recommendation to others, to ignore TAKREM, to > > not evaluate the specific proposal nor the tools, and to oppose its adoption > > as an Internet standard of any kind. it is my advice to Thierry Moreau that > > all work toward supporting DNSSEC with this technology be stopped. > > > > (note: i don't have any hats.) > > FWIW, I agree. And I further agree. I had already been ignoring TAKEM because of the patent holder's heretofore inability to produce an IPR statement and his apparent evasiveness on that topic. DNSSEC has enough of an uphill deployment hurdle without throwing in patent-encumbered technology. (Although IANAL, the posted license terms are unacceptable to VeriSign.) Matt -- Matt Larson VeriSign Naming and Directory Services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:44 2006 From: Jakob Schlyter Subject: Re: [dnssec-deployment] DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM Date: Sun, 30 Oct 2005 00:48:50 +0200 (CEST) Lines: 22 References: <4362A1E4.40505@connotech.com> <20051029052602.36B8E11459@sa.vix.com> <20051029145459.2F61711426@sa.vix.com> <4363B197.30604@algroup.co.uk> Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1645864238-1130626005=:11783" Cc: DNSSEC deployment , Namedroppers X-From: owner-namedroppers@ops.ietf.org Sun Oct 30 00:56:04 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 In-Reply-To: Content-ID: 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. --0-1645864238-1130626005=:11783 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: Until TAKREM is free to implement and use for DNSSEC (without restrictions), I believe it should be ignored. my suggestion is to move forward with a combination of Johan Ihrén's n-of-m proposal and Mike StJohns' revoke-bit. jakob --0-1645864238-1130626005=:11783-- -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:44 2006 From: bmanning@vacation.karoshi.com Subject: Re: [dnssec-deployment] DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM Date: Sun, 30 Oct 2005 16:29:52 +0000 Lines: 42 References: <4362A1E4.40505@connotech.com> <20051029052602.36B8E11459@sa.vix.com> <20051029145459.2F61711426@sa.vix.com> <4363B197.30604@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: DNSSEC deployment , Jakob Schlyter , Namedroppers X-From: owner-namedroppers@ops.ietf.org Sun Oct 30 17:39:07 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 To: Ben Laurie Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, Oct 30, 2005 at 04:24:35PM +0000, Ben Laurie wrote: > Jakob Schlyter wrote: > > Until TAKREM is free to implement and use for DNSSEC (without > > restrictions), I believe it should be ignored. > > > > my suggestion is to move forward with a combination of Johan Ihrén's > > n-of-m proposal > > Isn't that also encumbered? > > > and Mike StJohns' revoke-bit. > > Dunno the status of this, IP-wise. both of these proposals have been tagged by the diversinet patent. that patent was issued in Israel, filed and withdrawn in Europe, filed in Canada, extended twice (still not issued) ... my legal council indicated that since the m/n work was based on the SET work, that we could proceed w/ a reference implementation, as long as the work was not done in Israel. Not that the IETF cares of course. --bill > > -- > http://www.apache-ssl.org/ben.html http://www.thebunker.net/ > > "There is no limit to what a man can do or how far he can go if he > doesn't mind who gets the credit." - Robert Woodruff > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:44 2006 From: Ben Laurie Subject: Re: [dnssec-deployment] DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM Date: Sun, 30 Oct 2005 16:24:35 +0000 Lines: 24 References: <4362A1E4.40505@connotech.com> <20051029052602.36B8E11459@sa.vix.com> <20051029145459.2F61711426@sa.vix.com> <4363B197.30604@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: DNSSEC deployment , Namedroppers X-From: owner-namedroppers@ops.ietf.org Sun Oct 30 17:39:26 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Thunderbird 1.4.1 (Windows/20051006) To: Jakob Schlyter In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Jakob Schlyter wrote: > Until TAKREM is free to implement and use for DNSSEC (without > restrictions), I believe it should be ignored. > > my suggestion is to move forward with a combination of Johan Ihrén's > n-of-m proposal Isn't that also encumbered? > and Mike StJohns' revoke-bit. Dunno the status of this, IP-wise. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:44 2006 From: "Olaf M. Kolkman" Subject: Forwarding report for wcard-clarify Date: Sun, 30 Oct 2005 23:20:42 -0800 Lines: 145 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-26--35295798" Content-Transfer-Encoding: 7bit Cc: Mark Townsley , Namedroppers , Edward Lewis X-From: owner-namedroppers@ops.ietf.org Mon Oct 31 08:35:58 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 To: Margaret Wasserman X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-26--35295798 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Dear Margaret, Hereby the report for draft-ietf-dnsext-wcard-clarify-09. The DNSEXT working group requests that this document it to be published on the standards track. Questions: 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the IESG for publication? Yes, both of them. This draft has been carefully written, it provides a clear motivation and has its topics have been worked out thoroughly. 2) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Yes, it has been thoroughly reviewed and we have no concerns. 3) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? We have no such concerns. 4) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or whether there really is a need for it, etc., but at the same time these issues have been discussed in the WG and the WG has indicated it wishes to advance the document anyway. The document updates RFC1034 (full standard), although the file-name suggests otherwise this is not _only_ a clarification document. (This is clear from the title, abstract and introduction) 5) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document has seen two last calls in its lifetime. One concluded with overall consensus that the document is fulfilling a need but also identified a few open issues. After these were addressed a new last call was issued. We believe that the consensus is solid. 6) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize what are they upset about. Not that we are aware off. 7) Have the chairs verified that the document adheres to _all_ of the ID nits? (see http://www.ietf.org/ID-nits.html). Yes. 8) For Standards Track and BCP documents, the IESG approval announcement includes a writeup section with the following sections: - Technical Summary - Working Group Summary - Protocol Quality This document started out as a clarification of the behavior of wildcards. In order to be able to understand the excact methods to proof the non-existence of matches against a DNS query in the context of DNSSEC, a good description was needed. It was intended to add the description herein as an appendix to the DNSSECbis specification but since this document updates RFC1034 it was thought that it better stands on its own. Another purpose of this document is to clarify behavior that is often misunderstood and clearly identify the limitations of wildcard use. The document is consciously verbose in its descriptions e.g. in order to describe the behavior the terms closest encloser is introduced. The document introduces a change to the case where a CNAME RR is owned by a wildccard record. (*.foo.example CNAME bla.example). A strict interpretation of the algorith would imply that CNAME substitution would not take place. This document changes this part of the specification and makes the interaction the same as with other wildcard owned records of other types. Most implementations already behave as is specified in this document. Further more the document assesses the behavior of wildcard in the presence of Resource Record types that are part of the "control plane" of the DNS. Although the document started of as "a DNSSEC bis appendix" it has matured into a stand-alone document. The document for this document will be shepherded by Olaf Kolkman. Olaf and Olafur ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-26--35295798 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDZcXatN/ca3YJIocRAuCCAKDu6IFcwl9s+jdNfE44NiZm7DNeAQCfa47+ Z3nwbMPV9bwwqq/f0BDXtK8= =v17/ -----END PGP SIGNATURE----- --Apple-Mail-26--35295798-- -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:44 2006 From: Simon Josefsson Subject: Re: draft-josefsson-openpgp-mailnews-header and draft-ietf-dnsext-rfc2538bis-09.txt Date: Mon, 31 Oct 2005 10:19:49 +0100 Lines: 30 References: <20051031072532.GC29693@progsoc.uts.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: atom@smasher.org, namedroppers@ops.ietf.org, ietf-openpgp@imc.org X-From: owner-namedroppers@ops.ietf.org Mon Oct 31 10:29:11 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 To: Anand Kumria OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:051031:atom@smasher.org::zps4UTjWjQPDkkXk:DFD X-Hashcash: 1:21:051031:ietf-openpgp@imc.org::65CcOm6jPNVce6UH:05TY X-Hashcash: 1:21:051031:wildfire@progsoc.uts.edu.au::CMH89fihcir08DM5:32Lv X-Hashcash: 1:21:051031:namedroppers@ops.ietf.org::5o48/ciODQblpBLq:4HKV In-Reply-To: <20051031072532.GC29693@progsoc.uts.edu.au> (Anand Kumria's message of "Mon, 31 Oct 2005 18:25:32 +1100") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Anand Kumria writes: > Hi there, > > The openpgp-mailnews-header defines a mechanism for senders to notify > recipients of both their preferences (w.r.t OpenPGP keys) and the keying > material to be used (e.g. keyid). > > dnsext-rfc2538bis defines a mechanism where keying material is stored > within the DNS (e.g. OpenPGP). The overlap here is that users may wish > to store their key in the DNS (via dnsext-rfc2538bis) and refer to them > using openpgp-mailnews-header. > > Since openpgp-mailnews-header specifies using a URI to refer to the > location, it would seem -- to me at least -- that there needs to be some > kind of URI specification to allow you to refer to DNS resource records. > > Is there one already, or work underway to produce a DNS URI spec.? Hi Anand! Thanks for your interest. The document you refer to is in the RFC Editor's queue; see also . Cheers, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:44 2006 From: Ben Laurie Subject: Re: NSEC3 design FAQ Date: Mon, 31 Oct 2005 12:49:27 +0000 Lines: 40 References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Namedroppers X-From: owner-namedroppers@ops.ietf.org Mon Oct 31 13:59:11 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Thunderbird 1.4.1 (Windows/20051006) To: Samuel Weiler In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Samuel Weiler wrote: > Q: But why won't a single hash work? > > A: Two reasons. > > The first: so long as the owner name of the NSEC3 RR's includes a > real name, the zone can be walked. (This is true so long as the > owner name of the NSEC is obviously related to the QNAME (e.g. the > closest preceding existing name) -- having a real owner name > appear that is unrelated to the QNAME might work, but hasn't been > explored much.) > > The second: NSEC proofs wouldn't work. NSEC (and NSEC3) proofs > both rely on the NSEC/NSEC3 specifying a range of names (or a range > of hashes) between which there are no records (or no records other > than delegations, for the 'delegation-only' or 'opt-in' > variations). NSEC specifies a range of real names. NSEC3 > specifies a range of hashes. Specifying one real name and one hash > does not specify a range, so a validator can't check whether a > QNAME is covered by such a record, hence whether or not the proof > is valid. This seems incorrect - a real name plus a hash would work fine as a range of hashes, from the hash of the real name to the other hash. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:44 2006 From: Roy Arends Subject: Re: NSEC3 design FAQ Date: Mon, 31 Oct 2005 14:17:21 +0100 (CET) Lines: 39 References: <436612D7.10004@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Samuel Weiler , Namedroppers X-From: owner-namedroppers@ops.ietf.org Mon Oct 31 14:25:05 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-X-Sender: roy@netinfo.corporate.telin.nl To: Ben Laurie In-Reply-To: <436612D7.10004@algroup.co.uk> X-OriginalArrivalTime: 31 Oct 2005 13:17:21.0258 (UTC) FILETIME=[6CE964A0:01C5DE1D] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 31 Oct 2005, Ben Laurie wrote: > Samuel Weiler wrote: >> Q: But why won't a single hash work? >> >> A: Two reasons. >> >> The first: so long as the owner name of the NSEC3 RR's includes a >> real name, the zone can be walked. (This is true so long as the >> owner name of the NSEC is obviously related to the QNAME (e.g. the >> closest preceding existing name) -- having a real owner name >> appear that is unrelated to the QNAME might work, but hasn't been >> explored much.) >> >> The second: NSEC proofs wouldn't work. NSEC (and NSEC3) proofs >> both rely on the NSEC/NSEC3 specifying a range of names (or a range >> of hashes) between which there are no records (or no records other >> than delegations, for the 'delegation-only' or 'opt-in' >> variations). NSEC specifies a range of real names. NSEC3 >> specifies a range of hashes. Specifying one real name and one hash >> does not specify a range, so a validator can't check whether a >> QNAME is covered by such a record, hence whether or not the proof >> is valid. > > This seems incorrect - a real name plus a hash would work fine as a > range of hashes, from the hash of the real name to the other hash. Your statment is correct, but this would leak too much info. Since one name is leaked, it is trivial to do a binary search, hence enumerate the zone content. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:44 2006 From: Ben Laurie Subject: Re: NSEC3 design FAQ Date: Mon, 31 Oct 2005 13:54:51 +0000 Lines: 43 References: <436612D7.10004@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Samuel Weiler , Namedroppers X-From: owner-namedroppers@ops.ietf.org Mon Oct 31 15:08:15 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Thunderbird 1.4.1 (Windows/20051006) To: Roy Arends In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends wrote: > On Mon, 31 Oct 2005, Ben Laurie wrote: > >> Samuel Weiler wrote: >>> Q: But why won't a single hash work? >>> >>> A: Two reasons. >>> >>> The first: so long as the owner name of the NSEC3 RR's includes a >>> real name, the zone can be walked. (This is true so long as the >>> owner name of the NSEC is obviously related to the QNAME (e.g. the >>> closest preceding existing name) -- having a real owner name >>> appear that is unrelated to the QNAME might work, but hasn't been >>> explored much.) >>> >>> The second: NSEC proofs wouldn't work. NSEC (and NSEC3) proofs >>> both rely on the NSEC/NSEC3 specifying a range of names (or a range >>> of hashes) between which there are no records (or no records other >>> than delegations, for the 'delegation-only' or 'opt-in' >>> variations). NSEC specifies a range of real names. NSEC3 >>> specifies a range of hashes. Specifying one real name and one hash >>> does not specify a range, so a validator can't check whether a >>> QNAME is covered by such a record, hence whether or not the proof >>> is valid. >> >> This seems incorrect - a real name plus a hash would work fine as a >> range of hashes, from the hash of the real name to the other hash. > > Your statment is correct, but this would leak too much info. True, but that's the first reason. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:44 2006 From: Roy Arends Subject: Re: NSEC3 design FAQ Date: Mon, 31 Oct 2005 15:24:25 +0100 (CET) Lines: 47 References: <436612D7.10004@algroup.co.uk> <4366222B.80309@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Samuel Weiler , Namedroppers X-From: owner-namedroppers@ops.ietf.org Mon Oct 31 15:34:31 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-X-Sender: roy@netinfo.corporate.telin.nl To: Ben Laurie In-Reply-To: <4366222B.80309@algroup.co.uk> X-OriginalArrivalTime: 31 Oct 2005 14:24:25.0762 (UTC) FILETIME=[CBB3F820:01C5DE26] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 31 Oct 2005, Ben Laurie wrote: > Roy Arends wrote: >> On Mon, 31 Oct 2005, Ben Laurie wrote: >> >>> Samuel Weiler wrote: >>>> Q: But why won't a single hash work? >>>> >>>> A: Two reasons. >>>> >>>> The first: so long as the owner name of the NSEC3 RR's includes a >>>> real name, the zone can be walked. (This is true so long as the >>>> owner name of the NSEC is obviously related to the QNAME (e.g. the >>>> closest preceding existing name) -- having a real owner name >>>> appear that is unrelated to the QNAME might work, but hasn't been >>>> explored much.) >>>> >>>> The second: NSEC proofs wouldn't work. NSEC (and NSEC3) proofs >>>> both rely on the NSEC/NSEC3 specifying a range of names (or a range >>>> of hashes) between which there are no records (or no records other >>>> than delegations, for the 'delegation-only' or 'opt-in' >>>> variations). NSEC specifies a range of real names. NSEC3 >>>> specifies a range of hashes. Specifying one real name and one hash >>>> does not specify a range, so a validator can't check whether a >>>> QNAME is covered by such a record, hence whether or not the proof >>>> is valid. >>> >>> This seems incorrect - a real name plus a hash would work fine as a >>> range of hashes, from the hash of the real name to the other hash. >> >> Your statment is correct, but this would leak too much info. > > True, but that's the first reason. Sorry to nit, but Sams first reason deals with ownernames. My statement is not restricted to ownernames. If a name (not hash) is present anywhere in the NSEC or NSEC3 record (ownername or RDATA), it can be walked. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:44 2006 From: Ben Laurie Subject: Re: NSEC3 design FAQ Date: Mon, 31 Oct 2005 14:33:43 +0000 Lines: 54 References: <436612D7.10004@algroup.co.uk> <4366222B.80309@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Samuel Weiler , Namedroppers X-From: owner-namedroppers@ops.ietf.org Mon Oct 31 15:42:18 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Thunderbird 1.4.1 (Windows/20051006) To: Roy Arends In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends wrote: > On Mon, 31 Oct 2005, Ben Laurie wrote: > >> Roy Arends wrote: >>> On Mon, 31 Oct 2005, Ben Laurie wrote: >>> >>>> Samuel Weiler wrote: >>>>> Q: But why won't a single hash work? >>>>> >>>>> A: Two reasons. >>>>> >>>>> The first: so long as the owner name of the NSEC3 RR's includes a >>>>> real name, the zone can be walked. (This is true so long as the >>>>> owner name of the NSEC is obviously related to the QNAME (e.g. the >>>>> closest preceding existing name) -- having a real owner name >>>>> appear that is unrelated to the QNAME might work, but hasn't been >>>>> explored much.) >>>>> >>>>> The second: NSEC proofs wouldn't work. NSEC (and NSEC3) proofs >>>>> both rely on the NSEC/NSEC3 specifying a range of names (or a range >>>>> of hashes) between which there are no records (or no records other >>>>> than delegations, for the 'delegation-only' or 'opt-in' >>>>> variations). NSEC specifies a range of real names. NSEC3 >>>>> specifies a range of hashes. Specifying one real name and one hash >>>>> does not specify a range, so a validator can't check whether a >>>>> QNAME is covered by such a record, hence whether or not the proof >>>>> is valid. >>>> >>>> This seems incorrect - a real name plus a hash would work fine as a >>>> range of hashes, from the hash of the real name to the other hash. >>> >>> Your statment is correct, but this would leak too much info. >> >> True, but that's the first reason. > > Sorry to nit, but Sams first reason deals with ownernames. My statement > is not restricted to ownernames. If a name (not hash) is present > anywhere in the NSEC or NSEC3 record (ownername or RDATA), it can be > walked. Sure, if you want to nit, nit away. My nit is that this is orthogonal to my point, which is that name+hash works fine to specify a hash range. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:44 2006 From: Thierry Moreau Subject: Re: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM Date: Mon, 31 Oct 2005 11:55:42 -0500 Lines: 61 References: <4362A1E4.40505@connotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Mon Oct 31 17:40:43 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Namedroppers , dnssec-deployment@shinkuro.com In-Reply-To: <4362A1E4.40505@connotech.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dear all: Some participants indicated their reluctance to study the draft draft-moreau-dnsext-takrem-dns-00.txt on the basis of IPR issues, presumably on the basis of other solutions, less encumbered by IPR issues, for the technical problem at hand, i.e automated trust anchor key rollover procedures. If there was a clear problem statement with some consensus on the technical requirements, it might be acceptable to state that "solution A" meets these requirements and the IETF DNSEXT wg is satisfied. However, the problem statement and the technical requirements for an automated trust anchor key rollover scheme are not well established. Part of the proposal being ignored address this aspect of the DNSEXT wg activities. Moreover, the RFC3979 section 8 assigns a discretion to IETF wg to adopt a technology in the presence of IPR claims, based on an economic analysis, i.e. if the wg finds "that this technology is superior enough to alternatives with fewer IPR claims or free licensing to outweigh the potential cost of the licenses." Having this discretion and the mandate to solve the trust anchor key rollover problem, the DNSEXT wg should determine that the IPR encumbered technology is *not* superior enough. If those who are strict in their reluctance to study the draft-moreau-dnsext-takrem-dns-00.txt are convinced that this is the inescapable outcome of the wg activities, they merely decline to participate in progress towards this determination. In summary, I suggests that in the absence of a clear problem statement with some consensus on the technical requirements, abstaining from a review of the draft draft-moreau-dnsext-takrem-dns-00.txt is potentially introducing delays in the DNSEXT wg progress. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:44 2006 From: Ben Laurie Subject: Re: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM Date: Mon, 31 Oct 2005 16:56:28 +0000 Lines: 49 References: <4362A1E4.40505@connotech.com> <43664C8E.105@connotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Namedroppers , dnssec-deployment@shinkuro.com X-From: owner-namedroppers@ops.ietf.org Mon Oct 31 18:07:37 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 User-Agent: Thunderbird 1.4.1 (Windows/20051006) To: Thierry Moreau In-Reply-To: <43664C8E.105@connotech.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Thierry Moreau wrote: > Moreover, the RFC3979 section 8 assigns a discretion to IETF wg > to adopt a technology in the presence of IPR claims, based on an > economic analysis, i.e. if the wg finds "that this technology is > superior enough to alternatives with fewer IPR claims or free > licensing to outweigh the potential cost of the licenses." > > Having this discretion and the mandate to solve the trust anchor > key rollover problem, the DNSEXT wg should determine that the IPR > encumbered technology is *not* superior enough. If those who are > strict in their reluctance to study the > draft-moreau-dnsext-takrem-dns-00.txt are convinced that this is > the inescapable outcome of the wg activities, they merely decline > to participate in progress towards this determination. Since key rollover will be mandatory, this statement applies: "An IETF consensus has developed that no mandatory-to-implement security technology can be specified in an IETF specification unless it has no known IPR claims against it or a royalty-free license is available to implementers of the specification unless there is a very good reason to do so. " So, until we have determined that there is no IPR-free route to solving the problem, there is little point in reviewing the I-D. Thanks for pointing this out, I should've read it sooner. I suppose at this point I should remind people that my key distribution I-D (http://www.links.org/dnssec/draft-laurie-dnssec-key-distribution-00.txt) could also be used for key rollover, probably with only minor changes, and has not, so far, had any IPR claims against it. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:44 2006 From: "Olaf M. Kolkman" Subject: Requirements for rollovers (was DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM) Date: Mon, 31 Oct 2005 09:21:07 -0800 Lines: 69 References: <4362A1E4.40505@connotech.com> <43664C8E.105@connotech.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-31-728822" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Mon Oct 31 18:30:49 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 In-Reply-To: To: Namedroppers X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.734) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-31-728822 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear colleagues, Since we have addressed all formal RFC3979 issues I think that we should get actual work done. I think Thierry has a point when he refers to the requirements. Making the now implicit requirements more explicit is probably a good step for a work item where we have multiple authors each promoting their own ideas. Any volunteers that want to start compiling the requirements. Making a start by enumerating those on the list is probably a good idea. We can see later if we want to cast them into an I-D or make them an integral part of the specification. (Casting requirements into an I-D has proven difficult at times) Having a first iteration by Monday next week might actually be useful. Any takers??? I'd prefer somebody that does not have their name on one of the drafts. Please let me and Olafur know off-line if you want to take up this work. --Olaf PS: I posted this to Namedroppers only, this is about IETF process. ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-31-728822 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFDZlKDtN/ca3YJIocRApPJAJ4gL/Mcs7KNXezVM3T0l7Dx6wdkfQCggaRU J0ib1KrHq5jCRiKHGJgiqJU= =ckfL -----END PGP SIGNATURE----- --Apple-Mail-31-728822-- -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:44 2006 From: Marcus Better Subject: NSEC3 chain walking Date: Mon, 31 Oct 2005 18:35:36 +0100 Lines: 126 Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060105060507030303000702" X-From: owner-namedroppers@ops.ietf.org Mon Oct 31 18:51:17 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 User-Agent: Debian Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: en-us, en To: namedroppers@ops.ietf.org X-Enigmail-Version: 0.91.0.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (kakmonster.int.dactylis.com [192.168.1.2]); Mon, 31 Oct 2005 18:35:37 +0100 (CET) X-Scanned-By: MIMEDefang 2.53 on 192.168.1.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms060105060507030303000702 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, I have a comment concerning the problem of chain walking mentioned in section 11 of draft-ietf-dnsext-nsec3-03: "Walking the NSEC3 RRs will reveal the total number of records in the zone, and also what types they are. This could be mitigated by adding dummy entries, but certainly an upper limit can always be found." It seems that this little nuisance can be eliminated quite easily. (Disclaimer: I am not a DNS expert, so if this is really dumb or has already been discussed, I apologize for wasting your time.) The following changes are made to the draft: 1. The Next Hash Ownername field is modified so that it contains a _double_ hash of the next hashed ownername, i.e. H2(H1(name)) where H1 and H2 are hash algorithms. (One could possibly take H1=H2.) 2. The hash order is now determined according to the double hash. Note that the ownername of the NSEC3 RR is still the single hash of the owner name. So the record would look in principle like H1(foo.example.) NSEC3 H2(H1(bar.example.)) This record would prove the non-existence of original ownernames name.example such that H2(H1(foo.example.)) < H2(H1(name.example.)) < H2(H1(bar.example.)) Since the RR only contains the double hash of the next name, which is not used as an ownername in the zone, this information cannot be used to make further queries. So it becomes impossible to walk the NSEC3 chain. An obvious drawback is that the verifier must do extra work to compute the additional hashes. Regards, Marcus --------------ms060105060507030303000702 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ3DCC BOowggLSoAMCAQICAwFoODANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTA4 MjYxNDM4NThaFw0wNjA4MjYxNDM4NThaMDkxFjAUBgNVBAMTDU1hcmN1cyBCZXR0ZXIxHzAd BgkqhkiG9w0BCQEWEG1hcmN1c0BiZXR0ZXIuc2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQC/8HaMDsC4P8W0/jGAhVTkPgKcVWo/GkQUTTtUQmDBZ8dSEh/atndnDEz9bPn/ X/lHMc5APm+q3kRsRnRMUIp2niNFWWpfQm1Q8ZKcLilq9OvEOEg8YCu7HAdaVW0x6+iSRfL9 5rBxeODhi7UOGAvStmXgKjgtmiu8U1GJIwFa0U5Y/EAeuZLE453iBMz5j8DZKX4pojFoNJoq 417ikRrLSgTUaJ2dJLtldG8w7QR5E1tDSPpWhUgcOYRKh+Z8540z8DSqaI1LmS5aP1CXnw5K UfdAfPsBzeglVMRNgm0lLgg6lQtwGN7AjYqIsDeRF22QaW5xcl/rZ+PH5LoL/8yVAgMBAAGj gbowgbcwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcw MgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBsG A1UdEQQUMBKBEG1hcmN1c0BiZXR0ZXIuc2UwDQYJKoZIhvcNAQEEBQADggIBAKa2//8L+2LV m84ne1EwOtcw+iZDylvoDw+X/hBIR6wzE8XIe6V30SSQJ1lUgqinWQStKZdVWPAY5AVwWl6h YLgWN4BHmTrq+fQXxLZrPqpZWJw3UEl/QTo0wN403W5+P0zIdx8gbUVui3XiGgjv4kP7XUKw 7gtriuDhrKhI6OMPkQBy+sQHcrT7rzdFHX1rXNgJlYoweZg6L0t2gzGB9Q0zsE0Fgtp3jqlv DvE2eG3bwYFoZ5FU8IZ58F7pRCSgdgf+n/gsqm5lH2wpZcGgSUof0M4QJU97b16fTtcDaBQU XV34zTQt4sZHjAFyQQGVzVWJkw1S0+V+iCJqH+I4o0rg3geu5OAuwNjrdUyHZKb1GjkxNuh4 nBsrzbk2KAHr7NXeatB1CRv8MCfeebR6uxIHodQrPX61EIrNh/fkbwQfTZnwAk+0NEK5UTVM A3BcPv6du7UDp+mmpvmCV8AryhoH3TaZ33F/hP5zMGdni0WZkebel+8HlZmnd/MR2xwOqvc4 JJ6PT6m6uf8rIWzC9bAQgotXlPj41wmAHpthNkk3b9a9Ed5Xf8iwV7WdvJdXg2euRVVABr5s Ff+lt2Ikmj4yc/DId0FmtcEI4fZro01mPrdR8RQsuqbLOm8BC2eESsZP/Xm7Lh/nqV/XO6jY p5mbpkRAe0JOy9WXPzxQbd0kMIIE6jCCAtKgAwIBAgIDAWg4MA0GCSqGSIb3DQEBBAUAMHkx EDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAG A1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9y dEBjYWNlcnQub3JnMB4XDTA1MDgyNjE0Mzg1OFoXDTA2MDgyNjE0Mzg1OFowOTEWMBQGA1UE AxMNTWFyY3VzIEJldHRlcjEfMB0GCSqGSIb3DQEJARYQbWFyY3VzQGJldHRlci5zZTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL/wdowOwLg/xbT+MYCFVOQ+ApxVaj8aRBRN O1RCYMFnx1ISH9q2d2cMTP1s+f9f+UcxzkA+b6reRGxGdExQinaeI0VZal9CbVDxkpwuKWr0 68Q4SDxgK7scB1pVbTHr6JJF8v3msHF44OGLtQ4YC9K2ZeAqOC2aK7xTUYkjAVrRTlj8QB65 ksTjneIEzPmPwNkpfimiMWg0mirjXuKRGstKBNRonZ0ku2V0bzDtBHkTW0NI+laFSBw5hEqH 5nznjTPwNKpojUuZLlo/UJefDkpR90B8+wHN6CVUxE2CbSUuCDqVC3AY3sCNioiwN5EXbZBp bnFyX+tn48fkugv/zJUCAwEAAaOBujCBtzAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJ FkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0 dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGGFmh0dHA6 Ly9vY3NwLmNhY2VydC5vcmcwGwYDVR0RBBQwEoEQbWFyY3VzQGJldHRlci5zZTANBgkqhkiG 9w0BAQQFAAOCAgEAprb//wv7YtWbzid7UTA61zD6JkPKW+gPD5f+EEhHrDMTxch7pXfRJJAn WVSCqKdZBK0pl1VY8BjkBXBaXqFguBY3gEeZOur59BfEtms+qllYnDdQSX9BOjTA3jTdbn4/ TMh3HyBtRW6LdeIaCO/iQ/tdQrDuC2uK4OGsqEjo4w+RAHL6xAdytPuvN0UdfWtc2AmVijB5 mDovS3aDMYH1DTOwTQWC2neOqW8O8TZ4bdvBgWhnkVTwhnnwXulEJKB2B/6f+CyqbmUfbCll waBJSh/QzhAlT3tvXp9O1wNoFBRdXfjNNC3ixkeMAXJBAZXNVYmTDVLT5X6IImof4jijSuDe B67k4C7A2Ot1TIdkpvUaOTE26HicGyvNuTYoAevs1d5q0HUJG/wwJ955tHq7Egeh1Cs9frUQ is2H9+RvBB9NmfACT7Q0QrlRNUwDcFw+/p27tQOn6aam+YJXwCvKGgfdNpnfcX+E/nMwZ2eL RZmR5t6X7weVmad38xHbHA6q9zgkno9Pqbq5/yshbML1sBCCi1eU+PjXCYAem2E2STdv1r0R 3ld/yLBXtZ28l1eDZ65FVUAGvmwV/6W3YiSaPjJz8Mh3QWa1wQjh9mujTWY+t1HxFCy6pss6 bwELZ4RKxk/9ebsuH+epX9c7qNinmZumREB7Qk7L1Zc/PFBt3SQxggOHMIIDgwIBATCBgDB5 MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBv cnRAY2FjZXJ0Lm9yZwIDAWg4MAkGBSsOAwIaBQCgggHbMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MTAzMTE3MzUzNlowIwYJKoZIhvcNAQkEMRYEFG8j HIDKScCmIxSqxvF0Vz2fsFp/MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3 dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJ KoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwFoODCBkwYLKoZIhvcNAQkQAgsxgYOg gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3Jn MSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJz dXBwb3J0QGNhY2VydC5vcmcCAwFoODANBgkqhkiG9w0BAQEFAASCAQBo2iIp5E/8K5wM1gYO tvYkegGnlKJATdZ8Rfvd2pmL4fIEo876BNwZYFbc8LVqhj4yGIdYeKLYaP/RqihydqZ4boSO MFUH8jdoPi8Oy0oVwEeqgcTiYbVXudCxUgg/8zMm8+1yN7FPn+v5i8PH1xyOWjN0hHC0KoqK Le0kIcAmA3uytTEHLGbrORCkqkLfjXNXUtDSoKb3sD/Ewz69MIE6HAJuNSbYzYY1yoJzmdKO tVt6nuBGJG36oAu04BEh3277efBcq5UHIxZ5QQj2PANeS9zHT1WK3GFoh8CR4OmYY0R+zdPP roIu6iTvhGAwoV2pjvUOlQWLxcjf/7AF8l9wAAAAAAAA --------------ms060105060507030303000702-- -- to unsubscribe send a message to namedroppers-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 Dec 29 11:36:44 2006 From: Chris Thompson Subject: Re: NSEC3 chain walking Date: Mon, 31 Oct 2005 17:59:12 +0000 (GMT) Lines: 52 References: <436655E8.6030608@better.se> 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 Oct 31 19:11:23 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ To: marcus@better.se (Marcus Better) In-Reply-To: <436655E8.6030608@better.se> from "Marcus Better" at Oct 31, 5 06:35:36 pm X-Mailer: ELM [version 2.4 PL24] Content-Length: 2072 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk marcus@better.se (Marcus Better) writes: > I have a comment concerning the problem of chain walking mentioned in > section 11 of draft-ietf-dnsext-nsec3-03: > > "Walking the NSEC3 RRs will reveal the total number of records in the > zone, and also what types they are. This could be mitigated by > adding dummy entries, but certainly an upper limit can always be > found." > > It seems that this little nuisance can be eliminated quite easily. > > (Disclaimer: I am not a DNS expert, so if this is really dumb or has > already been discussed, I apologize for wasting your time.) > > The following changes are made to the draft: > > 1. The Next Hash Ownername field is modified so that it contains a > _double_ hash of the next hashed ownername, i.e. H2(H1(name)) where H1 > and H2 are hash algorithms. (One could possibly take H1=H2.) > > 2. The hash order is now determined according to the double hash. > > Note that the ownername of the NSEC3 RR is still the single hash of the > owner name. So the record would look in principle like > H1(foo.example.) NSEC3 H2(H1(bar.example.)) > > This record would prove the non-existence of original ownernames > name.example such that > H2(H1(foo.example.)) < H2(H1(name.example.)) < H2(H1(bar.example.)) > > Since the RR only contains the double hash of the next name, which is > not used as an ownername in the zone, this information cannot be used to > make further queries. So it becomes impossible to walk the NSEC3 chain. > > An obvious drawback is that the verifier must do extra work to compute > the additional hashes. It prevents sequential walking, but it is just as subject to random probing as using H2(H1(x)) as the hash function in the first place would be. And we know that random probing is (nearly) as effective as sequential walking, don't we? -- Chris Thompson Email: cet1@cam.ac.uk -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Dec 29 11:36:44 2006 From: Samuel Weiler Subject: Re: DNSSEC Trust Anchor Key rollover -- software tools released for TAKREM Date: Mon, 31 Oct 2005 13:00:18 -0500 (EST) Lines: 31 References: <4362A1E4.40505@connotech.com> <43664C8E.105@connotech.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Namedroppers , dnssec-deployment@shinkuro.com X-From: owner-namedroppers@ops.ietf.org Mon Oct 31 19:11:55 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-X-Sender: weiler@filbert To: Thierry Moreau In-Reply-To: <43664C8E.105@connotech.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 31 Oct 2005, Thierry Moreau wrote: > abstaining from a review of the draft > draft-moreau-dnsext-takrem-dns-00.txt is potentially introducing > delays in the DNSEXT wg progress. One might also argue that introducing a draft with known IPR issues also delays the process. Like many others, I'm reluctant to spend more time on this draft due to its IPR issues. That said, my review of the description posted to the dnssec-deployment list over the summer led me to think that there's nothing superior in this technology. I wrote: > First, the idea of prepublishing public keys (or hashes of them) has > been discussed in the DNSSEC community for quite some time. > ... > The idea of using MASH's rather than an unparameterized hash > function may be new in this community, but I'm not sure it adds > sufficient value over using a strong non-parameterized hash > function. -- 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 Dec 29 11:36:44 2006 From: Anand Kumria Subject: draft-josefsson-openpgp-mailnews-header and draft-ietf-dnsext-rfc2538bis-09.txt Date: Mon, 31 Oct 2005 18:25:32 +1100 Lines: 61 Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rUQ1rXFx4trAG42S" Cc: namedroppers@ops.ietf.org, ietf-openpgp@imc.org X-From: owner-namedroppers@ops.ietf.org Thu Nov 03 20:22:29 2005 Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 To: atom@smasher.org, simon@josefsson.org Content-Disposition: inline User-Agent: Mutt/1.5.9i X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: wildfire@progsoc.uts.edu.au X-SA-Exim-Scanned: No (on succubus.progsoc.uts.edu.au); SAEximRunCond expanded to false X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] --rUQ1rXFx4trAG42S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi there, The openpgp-mailnews-header defines a mechanism for senders to notify recipients of both their preferences (w.r.t OpenPGP keys) and the keying material to be used (e.g. keyid). dnsext-rfc2538bis defines a mechanism where keying material is stored within the DNS (e.g. OpenPGP). The overlap here is that users may wish to store their key in the DNS (via dnsext-rfc2538bis) and refer to them using openpgp-mailnews-header. Since openpgp-mailnews-header specifies using a URI to refer to the location, it would seem -- to me at least -- that there needs to be some kind of URI specification to allow you to refer to DNS resource records. Is there one already, or work underway to produce a DNS URI spec.? Cheers, Anand --=20 `When any government, or any church for that matter, undertakes to say to its subjects, "This you may not read, this you must not see, this you are forbidden to know," the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, "If this goes on --" --rUQ1rXFx4trAG42S Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQCVAwUBQ2XG7GRmcAD8BdppAQKJQAQAh3AN51i/TNMRPueGAaid+rwwe1ATT8Fp K6h9kgRMG7pyiAGobvh+/on91cnm1c6Zu5oXB228LupZlyniHkZYsTCuL1DNoEU3 B+nu+lv+3Sh8aE1D8zc4zgI8FLQ02E3rFStCZDDCz4FThwZ6RE6n07RMVQgkCA/Z BUvxXbu0Sy4= =nGK2 -----END PGP SIGNATURE----- --rUQ1rXFx4trAG42S-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: